Re: why spinlock raises IRQL to DISPATCH

I think saying the scheduler runs at DISPATCH_LEVEL will lead to many
problems for people to understand it correctly. It runs when the IRQL is
going to drop below DISPATCH_LEVEL. If you say that the scheduler runs at
DISPATCH_LEVEL you can be lead to believe that multiple threads can run at
DISPATCH_LEVEL on the same CPU.

I have always wondered if a CPU is running a thread at DISPATCH_LEVEL and a
hardware interrupt occurs, how does the hardware/OS decide to use that CPU
or another that might be running at passive. If the other CPU was running
at DIRQL, will that thread that was preempted be switched to the first CPU
that drops below DIRQL? Keeping the stacks straight might be a problem in
doing that. I guess you could have a CPU that is running at passive while
another is running at DIRQL and keeping a DISPATCH_LEVEL from running.

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:%234VWgvhWFHA.2684@xxxxxxxxxxxxxxxxxxxxxxx
Maybe need to add ( for full clearance ) that the thread scheduler run at
DISPATCH_LEVEL , so that's the way of disable sheduling
Arkady
"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:6z0ie.17732$sV7.4879@xxxxxxxxxxx

Because a spinlock has other threads spin on the lock. If you do not
disable scheduling you can create a situation where most of your systems
CPU time is spent spinning on locks, and where a low priority thread has
acquired the lock then is starved by spinning to the point that it taks a
long time to release it.

Spin locks are spupposed to be low overhead locks for short periods of
use. Note: on a uniprocessor implementation the lock is never set, the
implementation is just raise to dispatch to disable scheduling.


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



"Bajamani" <bajamani@xxxxxxxxxxx> wrote in message
news:1116246989.835297.82030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Why does spinlock implementation raise the irql to dispatch level? just
acquiring the lock at passive level should prevent other threads from
accessing the same lock.







.

Relevant Pages