Threads' blocking

I'm new in Kernel Programming.
I'm reading the Oney's book.
I don't understand where he say that at a certain irql
threads can't be blocked.
I'd be grateful if you could give me only only an idea about that.

Regards.

Don
Mon Sep 20 09:08:10 CDT 2004

The scheduler that controls which thread runs, runs at DISPATCH_LEVEL (i.e.
dispatch a thread). So at less than DISPATCH_LEVEL a thread can be blocked
waiting for event such as a timer, and another thread run while the first is
waiting. At DISPATCH_LEVEL and higher, this cannot happen the thread may
use a spinlock but this still has the thread running. An interrupt which
runs above DISPATCH_LEVEL runs in an arbitrary thread context, i.e. it takes
the currently running thread and uses it to service the interrupt, so again
the thread is not blocked.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Sergio" <sorrowforsorrow@yahoo.com> wrote in message
news:eiXrFdxnEHA.3684@TK2MSFTNGP10.phx.gbl...
>
> I'm new in Kernel Programming.
> I'm reading the Oney's book.
> I don't understand where he say that at a certain irql
> threads can't be blocked.
> I'd be grateful if you could give me only only an idea about that.
>
> Regards.
>
>
>

Martin
Tue Sep 21 03:54:46 CDT 2004


"Sergio" <sorrowforsorrow@yahoo.com> wrote in message
news:eiXrFdxnEHA.3684@TK2MSFTNGP10.phx.gbl...
>
> I'm new in Kernel Programming.
> I'm reading the Oney's book.
> I don't understand where he say that at a certain irql
> threads can't be blocked.
> I'd be grateful if you could give me only only an idea about that.
>

Giving a quick and generalised overview:

Whether a thread is blocked or not is dependent on the scheduler making a
decision on which thread to run, and then setting appropriate processor
state for the thread. This may occur as a result of a call
(WaitForSingleObject), or as a result of a timer interrupt. Whichever it is,
the appropriate context switch operations happen at DISPATCH_LEVEL.

In general, this means that when you're running at an IRQL less than
DISPATCH level, you can be pre-empted by (among other things) the scheduler,
and fitting in with this general scheme of things, it means that you have a
valid (although not necessarily well determined) thread context.

Remember the rules about running at a certain IRQ level means that you can
only be pre-empted by higher IRL level interrupts? This means that when
executing at dispatch level or above, you won't be pre-empted by the
scheduler - which means that your code will "just run" until the IRQL is
lowered.

Notice that this also means that when operating at an IRQL above (or
sometimes at) dispatch, your code will be executing as a result of an
interrupt, which is likely not dependent on the exact thread running at the
time, so your current thread context is arbitrary, hence (making a big
generalisation):

- No blocking! (You can't easily anyway, as the various calls that might
allow the scheduler to block you can't work because you're running at higher
IRQL).
- No implicit assumptions about thread state.
- You can't page fault (demand paging requires context switches), so non
paged memory is the order of the day.

Think that covers most of the basics.

e&o accepted.

MH.