Dispatch object and thread context

Hi all
I want to clarify my understand about Dispatch Object and IRQL.
The DDK said the driver can not wait on the Dispatch object (such as mute ,even) in nonarbitrary thread context.
It doesn’t say “why” ,only say “can’t” (And lots of DDK document uses this explaination style. I don’t like it).

In my understand, the DDK intend to tell us: If you don’t know what the current thread context is,your driver should not let the thread halt. If you indeed know that the current thread is the right thread you want to wait on the Dispatch object ,you can let it to wait.In fact,the Driver can wait on a Dispatch objcet in a arbitrary thread context,but it may halt some other bad luck thread.

Is this right?
plus a another question:
Can the window kernal be re-entry? I mean whether two threads can run in keranl stack at same time (for example ,one user mode thread call a API to kernel, and the system schedular switch another user mode thread to run ,and the second thread call API to kernal mode. The first thread is put to ready state,not wait state(I mean it doesn’t wait on a even or mute.the sytem swith to second thread is because the time slice of first thread is run out).
Can this case occur on windows?

thanks
donglw


Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

> If you indeed know that the current thread is the right thread you want to wait on the Dispatch

object ,you can let it to wait.In fact,the Driver can wait on a Dispatch objcet in a arbitrary thread context,
but it may halt some other bad luck thread. Is this right?

Nope…

The fact that code runs at elevated IRQL means that it runs in atomic context (i.e. either ISR/DPC or a piece of code that synchronizes with ISR/DPC by holding a spinlock). This concept is present virtually under all multi-tsking OSes - under Windows they call it “elevated IRQL”, and under UNIX it is known as “cannot block”…

I mean whether two threads can run in keranl stack at same time

Once every thread has its own kernel and user stacks, it just cannot happen…

Anton Bassov

The documentation is ridiculous on this subject. It might be actually true,
in that if you are in an arbitrary thread context then you are also at IRQL

= DISPATCH_LEVEL, but the actual limitation is IRQL < DISPATCH_LEVEL rather
than ‘not in an arbitrary thread context’.

The kernel is most certainly re-entrant. Every kernel thread is executing in
its own stack, a point that was not clear from your attempt to define
‘reentrant’.

On Sun, Sep 28, 2008 at 2:09 AM, rech dong wrote:

> Hi all
> I want to clarify my understand about Dispatch Object and IRQL.
> The DDK said the driver can not wait on the Dispatch object (such as
> mute ,even) in nonarbitrary thread context.
> It doesn’t say “why” ,only say “can’t” (And lots of DDK document uses
> this explaination style. I don’t like it).
>
> In my understand, the DDK intend to tell us: If you don’t know what the
> current thread context is,your driver should not let the thread halt. If you
> indeed know that the current thread is the right thread you want to wait on
> the Dispatch object ,you can let it to wait.In fact,the Driver can wait on a
> Dispatch objcet in a arbitrary thread context,but it may halt some other bad
> luck thread.
>
> Is this right?
>
> plus a another question:
> Can the window kernal be re-entry? I mean whether two threads can run
> in keranl stack at same time (for example ,one user mode thread call a API
> to kernel, and the system schedular switch another user mode thread to run
> ,and the second thread call API to kernal mode. The first thread is put to
> ready state,not wait state(I mean it doesn’t wait on a even or mute.the
> sytem swith to second thread is because the time slice of first thread is
> run out).
> Can this case occur on windows?
>
> thanks
> donglw
>
>
>
>
> ------------------------------
> Discover the new Windows Vista Learn more!http:
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Mark Roddy</http:>

thanks. Maybe you are right.
an arbitrary thread context only refers to IRQL >= DISPATCH_LEVEL.
CPU run in this level may not belong to a any thread.
Scheduler run on this DISPATCH_LEVEL,so waiting on Dispatch object on this IRQL will cause system hang .

Date: Tue, 30 Sep 2008 09:48:49 -0700From: xxxxx@hollistech.comTo: xxxxx@lists.osr.comSubject: Re: [ntdev] Dispatch object and thread context

The documentation is ridiculous on this subject. It might be actually true, in that if you are in an arbitrary thread context then you are also at IRQL >= DISPATCH_LEVEL, but the actual limitation is IRQL < DISPATCH_LEVEL rather than ‘not in an arbitrary thread context’.

The kernel is most certainly re-entrant. Every kernel thread is executing in its own stack, a point that was not clear from your attempt to define ‘reentrant’.
On Sun, Sep 28, 2008 at 2:09 AM, rech dong wrote:

Hi all I want to clarify my understand about Dispatch Object and IRQL. The DDK said the driver can not wait on the Dispatch object (such as mute ,even) in nonarbitrary thread context. It doesn’t say “why” ,only say “can’t” (And lots of DDK document uses this explaination style. I don’t like it). In my understand, the DDK intend to tell us: If you don’t know what the current thread context is,your driver should not let the thread halt. If you indeed know that the current thread is the right thread you want to wait on the Dispatch object ,you can let it to wait.In fact,the Driver can wait on a Dispatch objcet in a arbitrary thread context,but it may halt some other bad luck thread. Is this right? plus a another question: Can the window kernal be re-entry? I mean whether two threads can run in keranl stack at same time (for example ,one user mode thread call a API to kernel, and the system schedular switch another user mode thread to run ,and the second thread call API to kernal mode. The first thread is put to ready state,not wait state(I mean it doesn’t wait on a even or mute.the sytem swith to second thread is because the time slice of first thread is run out). Can this case occur on windows? thanksdonglw

Discover the new Windows Vista Learn more!— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer – Mark Roddy— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&amp;mkt=en-US&amp;form=QBRE