What are the exact definitions of "arbitrary thread context" and "nonarbitrary thread context"?

Discussion in 'Windows Vista Drivers' started by xmllmx, Aug 18, 2007.

  1. xmllmx

    xmllmx Guest

    The DDK documentation explains little on the two terms. I consulted
    Walter Oney's book, and got some tips. I post my premature
    understanding here and hope experts to correct my errors or give me
    some comments.

    To my understanding,

    1) If thread A sends IRP_MJ_CREATE to driver X, and next, sends
    IRP_MJ_XXX to driver X's corresponding dispatch routine, then, the
    dispatch routine is being executed in a "nonarbitrary thread context".

    2) If thread A sends IRP_MJ_CREATE to driver X, and next, another
    thread, say thread B, sends IRP_MJ_XXX to driver X's corresponding
    dispatch routine, then, the dispatch routine is being executed in an
    "arbitrary thread context".

    3) For a given dispatch routine, DDK (or Microsoft) specifies whether
    it must be called in a "nonarbitrary thread context" or in an
    "arbitrary thread context" (with some exceptions, see DDK
    documentation : "Dispatch Routine IRQL and Thread Context")

    Is my understanding correct?

    Any comments will be helpful. Thanks.
     
    xmllmx, Aug 18, 2007
    #1
    1. Advertisements

  2. This statement isn't quite correct.

    Multiple threads can open a handle on a device and multiple threads can
    make calls to various calls to the driver.

    For those listed as "non-arbitrary", the context will be the context of the
    caller intil the call returns. For example, when thread A makes a call to
    Read, Write or DeviceIoControl the driver is called in the context of thread
    A. Same for thread B (or C, or...).

    IOW, the concept of "arbitrary" and "non-arbitrary" applies from the point
    the IRP_MJ_XYZ handler is entered until the point where it returns.

    If you are considering only the interface between user-mode applications and
    your driver, then the documentation is describing the behavior of the I/O
    manager is. For example, the documentation is telling the driver writer that
    "If a user-mode application does a Read on a device, then the I/O manager
    will call your driver at IRP_MJ_READ in the non-arbitrary context of the
    user-mode applications thread".

    Hope this helps.

    Thomas F. Divine
     
    Thomas F. Divine, Aug 18, 2007
    #2
    1. Advertisements

  3. "Arbitrary thread context" means a DPC or even ISR, where you can assume
    nothing about what is the current thread. The notion of "current thread" is
    just plain invalid in DPCs and calls made by DPCs (completion routines,
    ClientEventXxx in TDI, ProtocolReceive(Packet) and so on).

    Work items, generally speaking, are also arbitrary thread, but all these
    threads belong to System process, that's why the term "system thread context"
    is more often used for them.

    DriverEntry and MJ_PNP paths are also called from system thread context -
    i.e. some unknown thread, and it is only known it is in the System process.
     
    Maxim S. Shatskih, Aug 18, 2007
    #3
  4. xmllmx

    xmllmx Guest

    Thomas & Maxim,

    Thank you very much for correcting my errors.
     
    xmllmx, Aug 18, 2007
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.