Hi,
I m working on a single processor machine. I need to verify i ve got the
concepts rite so plz pardon the naivety of
the question.
Inside a work item if i put certain operations under a spin lock.
<1>can i be preempted by code at DISPATCH_LEVEL running elsewhere.
<2> so can the scheduler preempt this code
<3>can a hardware interrupt at higher than DISPATCH_LEVEL preempt me?
<4>also what are the potential danger in using a spin lock for protecting
code in a single processor.
kutty
The concepts are the same for uni-processor or multi-processor.
DISPATCH_LEVEL is not preemptable by the scheduler, so no other code except
interrupts will run once you have taken the lock which puts you at
DISPATCH_LEVEL. Interrupts, will still be processed, which means if you
want to coordinate with an interrupt routine, you need to use
KeSynchronizeExecution or an interrupt spin lock (which runs at the same
IRQL as the interrupt routine).
The dangers of interrupts are holding them too long, and therefore messing
up scheduling. This is true on any system uni or multi processor. Use the
checked build, which will assert if you hold a spin lock too long.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Kutty Banerjee” wrote in message news:xxxxx@ntdev…
> Hi,
> I m working on a single processor machine. I need to verify i ve got the
> concepts rite so plz pardon the naivety of
> the question.
> Inside a work item if i put certain operations under a spin lock.
> <1>can i be preempted by code at DISPATCH_LEVEL running elsewhere.
> <2> so can the scheduler preempt this code
> <3>can a hardware interrupt at higher than DISPATCH_LEVEL preempt me?
> <4>also what are the potential danger in using a spin lock for protecting
> code in a single processor.
>
> kutty
>
>
>
On Wed, 2004-09-08 at 13:46, Kutty Banerjee wrote:
Hi,
I m working on a single processor machine.
Okay, but realize that you shouldn’t ship with that assumption.
Inside a work item if i put certain operations under a spin lock.
<1>can i be preempted by code at DISPATCH_LEVEL running elsewhere.
No, you own the CPU you’re on until you drop your lock, with the
exception of hardware interrupts.
<2> so can the scheduler preempt this code
No.
<3>can a hardware interrupt at higher than DISPATCH_LEVEL preempt me?
Yes.
<4>also what are the potential danger in using a spin lock for protecting
code in a single processor.
You cannot block, you cannot take a page fault (i.e. you cannot touch
any pageable data or code), you cannot make the function you’re in
pageable if there’s any chance it can be called, and you cannot call
lots of APIs.
If you don’t need a spin lock, don’t use one - consider a lighter-weight
form of synchronization.
-sd
–
Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com
> <1>can i be preempted by code at DISPATCH_LEVEL running elsewhere.
No.
<2> so can the scheduler preempt this code
No.
<3>can a hardware interrupt at higher than DISPATCH_LEVEL preempt me?
Yes, but the list of things the ISR can do is very short - mainly
KeInsertQueueDpc and touching its own hardware.
<4>also what are the potential danger in using a spin lock for protecting
code in a single processor.
No dangers.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Also remember that spinlocks cannot be acquired multiple times -
attempting to do so will result in a deadlock (in contrast with things
like mutexes, which handle a single thread acquiring the lock multiple
times)
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Wednesday, September 08, 2004 12:15 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] spinlock conceptsOn Wed, 2004-09-08 at 13:46, Kutty Banerjee wrote:
> Hi,
> I m working on a single processor machine.Okay, but realize that you shouldn’t ship with that assumption.
> Inside a work item if i put certain operations under a spin lock.
> <1>can i be preempted by code at DISPATCH_LEVEL running elsewhere.No, you own the CPU you’re on until you drop your lock, with
the exception of hardware interrupts.> <2> so can the scheduler preempt this code
No.
> <3>can a hardware interrupt at higher than DISPATCH_LEVEL
preempt me?Yes.
> <4>also what are the potential danger in using a spin lock for
> protecting code in a single processor.You cannot block, you cannot take a page fault (i.e. you
cannot touch any pageable data or code), you cannot make the
function you’re in pageable if there’s any chance it can be
called, and you cannot call lots of APIs.If you don’t need a spin lock, don’t use one - consider a
lighter-weight form of synchronization.-sd
–
Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
On Wed, 2004-09-08 at 16:42, Peter Wieland wrote:
Also remember that spinlocks cannot be acquired multiple times -
attempting to do so will result in a deadlock (in contrast with things
like mutexes, which handle a single thread acquiring the lock multiple
times)
minor clarification: FAST_MUTEXes can’t be acquired recursively, only
KMUTEXes.
-sd