releasing a spinlock when not at dispatch level

NTDEV
21

> I’ll simplify the problem:

//
// always called at DISPATCH_LEVEL
//
foo()
{
KeAcquireSpinLockAtDpcLevel(&spinlock1);
KeAcquireSpinLockAtDpcLevel(&spinlock2);
stuffRequiringLock1andLock2();
KeReleaseSpinLockFromDpcLevel(&spinlock1);
stuffRequiringLock2();
KeReleaseSpinLockFromDpcLevel(&spinlock2);
}

ok - now that IRQL is out of the picture, what exactly is the problem?

No problem, but

KeAcquireSpinLockAtDpcLevel(&spinlock2);
KeAcquireSpinLockAtDpcLevel(&spinlock1);
stuffRequiringLock1andLock2();
KeReleaseSpinLockFromDpcLevel(&spinlock1);
stuffRequiringLock2();
KeReleaseSpinLockFromDpcLevel(&spinlock2);

is cleaner, so why wouldn’t you do it that way?

James

22

>

The correct IRQL is maintained entirely by the dispatch spinlock user
which is
why KeAcquireSpinLockAtDpcLevel can exist. Yes I understand what the
docs say.
And as I have said repeatedly, you do have to maintain the IRQL state
correctly, but what does that actually mean?

I am claiming that it means this:
In a sequence of dispatch spinlock acquisitions, the first acquire
sets the
IRQL state from <= DISPATCH_LEVEL to DISPATCH_LEVEL and saves the
initial IRQL
state. The last release restores the IRQL level from DISPATCH_LEVEL to
the
saved IRQL state. The optimization KeAcquireSpinLockAtDpcLevel exists
because
the client, the user of spinlocks, knows the IRQL state I just
described and
can make an informed decision at acquire time regarding which form of
acquire
to use.

There is no functional requirement to do the release of the locks in
any
specific order. Docs and prefast may differ. This isn’t an
implementation
detail it is fundamental to dispatch spinlocks. You cannot cause a
spinlock
deadlock on lock release, but you do have to maintain the IRQL
correctly.

No functional requirement now, but there is a contractual requirement.
You are right from a functional point of view, right now, but if Windows
decides to implement hypervisor controlled locks or something like that
to improve scheduling decisions under high lock contention situations
you may be in trouble.

IMHO, if the docs say don’t do something (eg “It is an error to call
KeReleaseSpinLockFromDpcLevel if the given spin lock was acquired by
calling KeAcquireSpinLock because …”) then don’t do it, regardless of
what follows the “because”.

James

23

PLEASE listen to Mr. Roddy… he’s entirely correct on this topic.

The caller is required to restore the IRQL properly. As long as you do this, you can release the locks in any order you want.

As far as this little quote from the WDK docs:

"
It is an error to call KeReleaseSpinLockFromDpcLevel if the given spin
lock was acquired by calling KeAcquireSpinLock because the caller’s
original IRQL is not restored, which can cause deadlocks or fatal page
faults.
"
This is, at very best, not a particularly good choice of words and probably misleading. Somebody should file a bug in the WDK Bug Bash.

As far as THIS:

I hate to disagree with Dr. Newcomber, but while this might be a fundamental principal of SOME locking somewhere, this is not a fundamental principal of locking in Windows.

The fundamental principals of locking in Windows that I can think of off the top of my head are:

a) The caller is responsible for properly restoring the IRQLs on lock releases…

b) the caller is responsible for maintaining an appropriate locking hierarchy to avoid deadlocks

c) Locks should be held only for the duration that they are needed, and should be released when they are no longer required and (a) you cannot reasonably predict when you will need to reacquire the lock, or (b) you can predict you will NOT need to reacquire the same lock “real soon now” – locks also need to be released, regardless of the necessity to reacquire them to maintain the proper locking hierarchy.

Release in inverse order? Not really a requirement or even a Windows principal.

Peter
OSR

24

xxxxx@osr.com wrote:

Release in inverse order? Not really a requirement or even a Windows principal.

Yes. The real computer science principle here is that intertwined locks
always need to be acquired in the same order. Disaster ensues from code
like this:

KeAcquireSpinLock( &lock1, … );
KeAcquireSpinLock( &lock2, … );

when elsewhere you have

KeAcquireSpinLock( &lock2, … );
KeAcquireSpinLock( &lock1, … );

With that scenario, you can easily get into a situation where thread 1
has acquired lock1 and is waiting for lock2, while thread 2 has acquired
lock2 and is waiting for lock1. That’s a deadly embrace, and is
absolutely fatal. There is no escape, other than the power button.

I theorize (with insufficient data) that this unlock-in-inverse-order
decree arises from some fear that the same kind of deadlock can happen,
but after a few moments with a whiteboard, I don’t think that’s possible.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

25

>

xxxxx@osr.com wrote:
> Release in inverse order? Not really a requirement or even a
Windows
principal.

Yes. The real computer science principle here is that intertwined
locks
always need to be acquired in the same order. Disaster ensues from
code
like this:

KeAcquireSpinLock( &lock1, … );
KeAcquireSpinLock( &lock2, … );

when elsewhere you have

KeAcquireSpinLock( &lock2, … );
KeAcquireSpinLock( &lock1, … );

With that scenario, you can easily get into a situation where thread 1
has acquired lock1 and is waiting for lock2, while thread 2 has
acquired
lock2 and is waiting for lock1. That’s a deadly embrace, and is
absolutely fatal. There is no escape, other than the power button.

I theorize (with insufficient data) that this unlock-in-inverse-order
decree arises from some fear that the same kind of deadlock can
happen,
but after a few moments with a whiteboard, I don’t think that’s
possible.

The thing that bugs me is why would you release the locks in any order
other than the inverse of the order in which you acquired them? I think
that if a situation arose where you had a problem that you could only
solve by doing that then you need to rethink your locking scheme.

James

26

Refer to my simplified example. You release in some other order because you
no longer need one of the locks you own, and that lock gets released. This
allows other threads to acquire that lock and do useful work. If the counter
claim is that all such threads always have to acquire the entire
lock hierarchy up to the lock you just released, then I would suggest all of
those locks could be collapsed into one.

As I’ve said all along, your code looks better if the locks are released in
inverse order, but it might not be the most efficient way to write your
code.

Mark Roddy

On Wed, Aug 25, 2010 at 8:46 PM, James Harper > wrote:

> >
> > xxxxx@osr.com wrote:
> > > Release in inverse order? Not really a requirement or even a
> Windows
> > principal.
> >
> > Yes. The real computer science principle here is that intertwined
> locks
> > always need to be acquired in the same order. Disaster ensues from
> code
> > like this:
> >
> > KeAcquireSpinLock( &lock1, … );
> > KeAcquireSpinLock( &lock2, … );
> >
> > when elsewhere you have
> >
> > KeAcquireSpinLock( &lock2, … );
> > KeAcquireSpinLock( &lock1, … );
> >
> > With that scenario, you can easily get into a situation where thread 1
> > has acquired lock1 and is waiting for lock2, while thread 2 has
> acquired
> > lock2 and is waiting for lock1. That’s a deadly embrace, and is
> > absolutely fatal. There is no escape, other than the power button.
> >
> > I theorize (with insufficient data) that this unlock-in-inverse-order
> > decree arises from some fear that the same kind of deadlock can
> happen,
> > but after a few moments with a whiteboard, I don’t think that’s
> possible.
> >
>
> The thing that bugs me is why would you release the locks in any order
> other than the inverse of the order in which you acquired them? I think
> that if a situation arose where you had a problem that you could only
> solve by doing that then you need to rethink your locking scheme.
>
> James
>
> —
> 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
>

27

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@osr.com wrote:
>> Release in inverse order? Not really a requirement or even a Windows
>> principal.
>
> Yes. The real computer science principle here is that intertwined locks
> always need to be acquired in the same order. Disaster ensues from code
> like this:
>
> KeAcquireSpinLock( &lock1, … );
> KeAcquireSpinLock( &lock2, … );
>
> when elsewhere you have
>
> KeAcquireSpinLock( &lock2, … );
> KeAcquireSpinLock( &lock1, … );
>
> With that scenario, you can easily get into a situation where thread 1
> has acquired lock1 and is waiting for lock2, while thread 2 has acquired
> lock2 and is waiting for lock1. That’s a deadly embrace, and is
> absolutely fatal. There is no escape, other than the power button.
>
> I theorize (with insufficient data) that this unlock-in-inverse-order
> decree arises from some fear that the same kind of deadlock can happen,
> but after a few moments with a whiteboard, I don’t think that’s possible.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

But this situation is specific to KeSpinlocks, where the previous IRQL
is the only context you need to restore.
For some other spinlock types the saved context is opaque, so it
is less obvious that you can release not in inverse order:
Consider KeAcquireInStackQueuedSpinLock and NdisAcquireSpinLock.
The tiny voice of aesthetic sense may be rationalized by ability to choose
the lock type (or, to abstract from the lock type).
– pa

28

I’m going to side with the camp that says locks should be released in the
inverse order they are acquired, using the below message as a problem case.
You can certainly come up with trivial cases where this is not a
requirement, but there also are cases where it is.

So the lock hierarchy is spinllock1 then spinlock2, and as long as you
always take ownership and release ownership of the locks in the same order
you supposed to be are ok. But in the below code, suppose after you call
KeReleaseSpinLock(&spinlock1, Irql1);, which returns you to PASSIVE_LEVEL,
your thread is context switched and some other code tried to follow the same
lock hierarchy. It may deadlock because it raises IRQL to DISPATCH_LEVEL by
acquiring spinlock1, and can never acquire spinlock2, because it’s already
held in the other thread. On a single processor system, you have just
guaranteed a system deadlock, even though no individual function violated
the take ownership rules. What was violated was the paring of spinlocks with
their IRQL.

The WDK docs DO actually talk about lock release order at
“http://msdn.microsoft.com/en-us/library/ms810047.aspx” file .doc file on
“Driver Lifecycle Fundamentals->Key Driver Concepts->Lock, Deadlocks, and
Synchronization” at http://www.microsoft.com/whdc/driver/kernel/locks.mspx
has these same words.

It says “Similarly, a code sequence that uses multiple locks should release
them in the inverse of the order in which it acquired them. That is, it
should release the most recently acquired lock first.”

As the title of this message thread says “releasing a spinlock when not at
dispatch level”, the docs for KeReleaseSpinLock says “Callers of this
routine are running at IRQL = DISPATCH_LEVEL”, which would be violated if
you tried to release it anything except DISPATCH_LEVEL. The code below is
also likely invalid for this reason, as spinlock2 will need to get unlocked
eventually, and you are already at < DISPATCH_LEVEL.

Jan

Consider the following scenario:

KIRQL irql1,irql2;

KeAcquireSpinLock(&spinlock1, &irql1);

KeAcquireSpinLock(&spinlock2, &irql2);

…

KeReleaseSpinLock(&spinlock1, Irql1);

Assuming that the original call was made at IRQL< DPC_LEVEL the above line
will set IRQL to its original level, despite the fact that spinlock2 is
still being
held…

29

You only get to that deadlock by conflating IRQL state management with
spinlocks. As I said from the outset, you have to maintain the correct IRQL
state. That state is determined by the first lock you acquire in a sequence
of lock acquisitions and must be restored on the release of the LAST lock
released.

So again, after accounting for correct IRQL management, what deadlock
potential exists on release?

Mark Roddy

On Thu, Aug 26, 2010 at 12:17 AM, Jan Bottorff wrote:

> I’m going to side with the camp that says locks should be released in the
> inverse order they are acquired, using the below message as a problem case.
> You can certainly come up with trivial cases where this is not a
> requirement, but there also are cases where it is.
>
> So the lock hierarchy is spinllock1 then spinlock2, and as long as you
> always take ownership and release ownership of the locks in the same order
> you supposed to be are ok. But in the below code, suppose after you call
> KeReleaseSpinLock(&spinlock1, Irql1);, which returns you to PASSIVE_LEVEL,
> your thread is context switched and some other code tried to follow the
> same
> lock hierarchy. It may deadlock because it raises IRQL to DISPATCH_LEVEL by
> acquiring spinlock1, and can never acquire spinlock2, because it’s already
> held in the other thread. On a single processor system, you have just
> guaranteed a system deadlock, even though no individual function violated
> the take ownership rules. What was violated was the paring of spinlocks
> with
> their IRQL.
>
> The WDK docs DO actually talk about lock release order at
> “http://msdn.microsoft.com/en-us/library/ms810047.aspx” file .doc file on
> “Driver Lifecycle Fundamentals->Key Driver Concepts->Lock, Deadlocks, and
> Synchronization” at http://www.microsoft.com/whdc/driver/kernel/locks.mspx
> has these same words.
>
> It says “Similarly, a code sequence that uses multiple locks should release
> them in the inverse of the order in which it acquired them. That is, it
> should release the most recently acquired lock first.”
>
> As the title of this message thread says “releasing a spinlock when not at
> dispatch level”, the docs for KeReleaseSpinLock says “Callers of this
> routine are running at IRQL = DISPATCH_LEVEL”, which would be violated if
> you tried to release it anything except DISPATCH_LEVEL. The code below is
> also likely invalid for this reason, as spinlock2 will need to get unlocked
> eventually, and you are already at < DISPATCH_LEVEL.
>
> Jan
>
> >
> > Consider the following scenario:
> >
> > KIRQL irql1,irql2;
> >
> > KeAcquireSpinLock(&spinlock1, &irql1);
> >
> > KeAcquireSpinLock(&spinlock2, &irql2);
> >
> >
> > …
> >
> >
> >
> > KeReleaseSpinLock(&spinlock1, Irql1);
> >
> >
> > Assuming that the original call was made at IRQL< DPC_LEVEL the above
> line
> > will set IRQL to its original level, despite the fact that spinlock2 is
> still being
> > held…
>
>
>
>
>
>
>
> —
> 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
>

30

As Mark points out, the potential deadlock only occurs on NT systems in this
scenario because the IRQL rules were violated, not any implied locking
rules.

To better see this assume that the NT rules were such that a spinlock may
only be acquired at IRQL == DISPATCH_LEVEL and that one had to explicitly
raise IRQL to DISPATCH_LEVEL if you were not sure you were already at
DISPATCH_LEVEL. Then the sequence becomes:

  1. Raise IRQL
  2. Acquire Lock1
  3. Acquire Lock2
  4. Do something with 1&2
  5. Release Lock1
  6. Do something more with 2
  7. Release Lock2
  8. Restore IRQL (NOTE: Restore, not lower).

As was noted by a previous poster, no deadlock ever occurred by dropping a
lock. As long as the lock escalation order is obeyed, deadlock is avoided.

Now of course this presumes that locking has only the side-effect of
acquiring the lock and is otherwise free of supporting ?state?.

As was pointed out in this thread this is not true of NDIS spinlocks which
embed the IRQL storage in the opaque spinlock structure and thus *cannot* be
used in this way as there is no DDI in NDIS to ‘raise irql’ (well, ok, you
can allocate a spinlock on the stack, initialize it, and acquire it to the
same effect on NT). But NDIS does provide bindings to spinlock functions
that do not modify IRQL and so you can pretty much do the same thing if you
can get the CPU to or know it is at DISPATCH_LEVEL.

And of course the same can be said for KMDF spinlocks as they also hide away
whatever it is that is needed to correctly save prior IRQL when acquired
with the appropriate DDI.

My only suggestion is that when coding such a sequence that the IRQL
manipulation be made explicit for clarity (which it would need to be in NDIS
or KMDF but not so in KeXxxx() routines) to avoid exactly the scenario that
Jan illustrates.

Dave Cattley

31

Wow . “conflating” . had to look that one up . to bring together, to meld or
fuse, two or more things into a unified whole, which can lead to fallacious
reasoning if care is not taken.J

In my case, thinking spinlock always gives me a headache, and thinking
MULTIPLE spinlocks simply gives me SUPER MULTIPLE headaches, and I’m out of
aspirin in the house. I can see Marks point that there may be occasions
where more efficient code may lead to out of order release, but for the sake
of my own sanity, I most likely will always release by inverse order. Were
it an order of magnitude more efficient for either memory or processing
time, then I might consider it, but not to save one or two lines of code. It
just isn’t worth the extra time needed to get it right, nor the trip to the
pharmacy for the aspirin.

Gary G. Little

H (952) 223-1349

C (952) 454-4629

xxxxx@comcast.net

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, August 26, 2010 7:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] releasing a spinlock when not at dispatch level

You only get to that deadlock by conflating IRQL state management with
spinlocks. As I said from the outset, you have to maintain the correct IRQL
state. That state is determined by the first lock you acquire in a sequence
of lock acquisitions and must be restored on the release of the LAST lock
released.

So again, after accounting for correct IRQL management, what deadlock
potential exists on release?

Mark Roddy

On Thu, Aug 26, 2010 at 12:17 AM, Jan Bottorff
wrote:

I’m going to side with the camp that says locks should be released in the
inverse order they are acquired, using the below message as a problem case.
You can certainly come up with trivial cases where this is not a
requirement, but there also are cases where it is.

So the lock hierarchy is spinllock1 then spinlock2, and as long as you
always take ownership and release ownership of the locks in the same order
you supposed to be are ok. But in the below code, suppose after you call
KeReleaseSpinLock(&spinlock1, Irql1);, which returns you to PASSIVE_LEVEL,
your thread is context switched and some other code tried to follow the same
lock hierarchy. It may deadlock because it raises IRQL to DISPATCH_LEVEL by
acquiring spinlock1, and can never acquire spinlock2, because it’s already
held in the other thread. On a single processor system, you have just
guaranteed a system deadlock, even though no individual function violated
the take ownership rules. What was violated was the paring of spinlocks with
their IRQL.

The WDK docs DO actually talk about lock release order at
“http://msdn.microsoft.com/en-us/library/ms810047.aspx” file .doc file on
“Driver Lifecycle Fundamentals->Key Driver Concepts->Lock, Deadlocks, and
Synchronization” at http://www.microsoft.com/whdc/driver/kernel/locks.mspx
has these same words.

It says “Similarly, a code sequence that uses multiple locks should release
them in the inverse of the order in which it acquired them. That is, it
should release the most recently acquired lock first.”

As the title of this message thread says “releasing a spinlock when not at
dispatch level”, the docs for KeReleaseSpinLock says “Callers of this
routine are running at IRQL = DISPATCH_LEVEL”, which would be violated if
you tried to release it anything except DISPATCH_LEVEL. The code below is
also likely invalid for this reason, as spinlock2 will need to get unlocked
eventually, and you are already at < DISPATCH_LEVEL.

Jan

>
> Consider the following scenario:
>
> KIRQL irql1,irql2;
>
> KeAcquireSpinLock(&spinlock1, &irql1);
>
> KeAcquireSpinLock(&spinlock2, &irql2);
>
>
> …
>
>
>
> KeReleaseSpinLock(&spinlock1, Irql1);
>
>
> Assuming that the original call was made at IRQL< DPC_LEVEL the above line
> will set IRQL to its original level, despite the fact that spinlock2 is
still being
> held…

—
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

— 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

32

> No functional requirement now, but there is a contractual requirement. You are right from

a functional point of view, right now, but if Windows decides to implement hypervisor controlled
locks or something like that to improve scheduling decisions under high lock contention situations…

So what is it going to change??? Look - when it comes to deadlocks, lock acquisition order is the only thing that matters. As long as locks are acquired in the same order it just does not matter in which order they get released. This is true for locking constructs of any description, so that a change in internal implementation is not going to break it…

IMHO, if the docs say don’t do something (eg “It is an error to call KeReleaseSpinLockFromDpcLevel
if the given spin lock was acquired by calling KeAcquireSpinLock because …”) then
don’t do it, regardless of what follows the “because”.

Well, the very first everyday life analogue to the above statement that comes to my mind is never crossing a street on the red light in any situation, including totally empty street with no cars anywhere in sight. As they say, “the rule is for the obedience of fools and guidance of wise men” (unfortunately I cannot immediately tell you who is the author of this wonderful phrase)…

Anton Bassov

33

I can’t believe we’re still having this discussion.

I’d comment at greater length if I wasn’t in the middle of teaching a seminar… All I can say is that EVEN ANTON agrees with Mr. Roddy.

Do what you need to stay sane, Mr. Little. That’s probably important. And, as Mr. Roddy said, it’s MORE ATTRACTIVE to release spin locks in inverse order. The code LOOKS wrong when you fail to do so. Releasing “out of order” causes the guys who come after you to have the same argument we’re having here. But, REALLY… you can’t deadlock on RELEASE… how COULD you? Therefore, the ORDER in which you RELEASE the locks isn’t important. All that’s important is that (a) You DO release them in a timely and efficient manner, (b) You DO manage your IRQL properly, (c) You maintain your locking hierarchy (order of acquisition).

This debate wouldn’t last 2 minutes over on NTFSD, where File Systems acquired multiple locks and then released in various orders routinely.

In terms of what the documentation does or does not say, all I can tell you is that the documentation is not definitive. In this particular case, it seems the docs are straying into GUIDANCE (describing recommended practice) as opposed to placing REQUIREMENTS. This is well meaning, and not unusual in the WDK in my experience. If the thought of multiple spin locks makes your head hurt, then follow the WDK’s guidance. You’ll be safe that way. Otherwise, do what you need to do and “be careful out there.”

But I’ll tell you this for certain: It IS ABSOLUTELY NOT a Windows architectural requirement that spin locks have to be released in the inverse order in which they were acquired.

Peter
OSR

34

+1

Mary Mother of God Make It Stop

On Aug 26, 2010 6:02 PM, wrote:
> I can’t believe we’re still having this discussion.
>
> I’d comment at greater length if I wasn’t in the middle of teaching a
seminar… All I can say is that EVEN ANTON agrees with Mr. Roddy.
>
>


>
> Do what you need to stay sane, Mr. Little. That’s probably important. And,
as Mr. Roddy said, it’s MORE ATTRACTIVE to release spin locks in inverse
order. The code LOOKS wrong when you fail to do so. Releasing “out of order”
causes the guys who come after you to have the same argument we’re having
here. But, REALLY… you can’t deadlock on RELEASE… how COULD you?
Therefore, the ORDER in which you RELEASE the locks isn’t important. All
that’s important is that (a) You DO release them in a timely and efficient
manner, (b) You DO manage your IRQL properly, (c) You maintain your locking
hierarchy (order of acquisition).
>
> This debate wouldn’t last 2 minutes over on NTFSD, where File Systems
acquired multiple locks and then released in various orders routinely.
>
> In terms of what the documentation does or does not say, all I can tell
you is that the documentation is not definitive. In this particular case, it
seems the docs are straying into GUIDANCE (describing recommended practice)
as opposed to placing REQUIREMENTS. This is well meaning, and not unusual in
the WDK in my experience. If the thought of multiple spin locks makes your
head hurt, then follow the WDK’s guidance. You’ll be safe that way.
Otherwise, do what you need to do and “be careful out there.”
>
> But I’ll tell you this for certain: It IS ABSOLUTELY NOT a Windows
architectural requirement that spin locks have to be released in the inverse
order in which they were acquired.
>
> Peter
> OSR
>
>
> —
> 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

35

>

> IMHO, if the docs say don’t do something (eg “It is an error to
call
> KeReleaseSpinLockFromDpcLevel
> if the given spin lock was acquired by calling KeAcquireSpinLock
because
> …”) then
> don’t do it, regardless of what follows the “because”.

Well, the very first everyday life analogue to the above statement
that comes
to my mind is never crossing a street on the red light in any
situation,
including totally empty street with no cars anywhere in sight. As they
say,
“the rule is for the obedience of fools and guidance of wise men”
(unfortunately I cannot immediately tell you who is the author of this
wonderful phrase)…

I like that.

James

36

I apologize for starting this mess again. It was an offhand comment to
somebody else’s code review castigation.

But what about Mr. Assov?

Mark Roddy

On Thu, Aug 26, 2010 at 6:03 PM, wrote:

> I can’t believe we’re still having this discussion.
>
> I’d comment at greater length if I wasn’t in the middle of teaching a
> seminar… All I can say is that EVEN ANTON agrees with Mr. Roddy.
>
>


>
> Do what you need to stay sane, Mr. Little. That’s probably important.
> And, as Mr. Roddy said, it’s MORE ATTRACTIVE to release spin locks in
> inverse order. The code LOOKS wrong when you fail to do so. Releasing “out
> of order” causes the guys who come after you to have the same argument we’re
> having here. But, REALLY… you can’t deadlock on RELEASE… how COULD
> you? Therefore, the ORDER in which you RELEASE the locks isn’t important.
> All that’s important is that (a) You DO release them in a timely and
> efficient manner, (b) You DO manage your IRQL properly, (c) You maintain
> your locking hierarchy (order of acquisition).
>
> This debate wouldn’t last 2 minutes over on NTFSD, where File Systems
> acquired multiple locks and then released in various orders routinely.
>
> In terms of what the documentation does or does not say, all I can tell you
> is that the documentation is not definitive. In this particular case, it
> seems the docs are straying into GUIDANCE (describing recommended practice)
> as opposed to placing REQUIREMENTS. This is well meaning, and not unusual
> in the WDK in my experience. If the thought of multiple spin locks makes
> your head hurt, then follow the WDK’s guidance. You’ll be safe that way.
> Otherwise, do what you need to do and “be careful out there.”
>
> But I’ll tell you this for certain: It IS ABSOLUTELY NOT a Windows
> architectural requirement that spin locks have to be released in the inverse
> order in which they were acquired.
>
> Peter
> OSR
>
>
> —
> 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
>

37

>

I apologize for starting this mess again. It was an offhand comment to
somebody else’s code review castigation.

I have found this discussion quite educational and I can’t be the only
one. IMHO as far as heated discussions on ntdev go this one has been
quite sane. Peter’s right when he said it’s well and truly run its
course but I don’t see a need to apologize

:slight_smile:

James

38

Mr.Roddy,

[quote]

But what about Mr. Assov?
Mark Roddy

[end quote]

If you don’t mind, could you please explain yourself

Thanks in advance

Anton Bassov

39

bantonassov (Mr. Assov?) was the OP, no?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, August 26, 2010 8:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] releasing a spinlock when not at dispatch level

Mr.Roddy,

[quote]

But what about Mr. Assov?
Mark Roddy

[end quote]

If you don’t mind, could you please explain yourself

Thanks in advance

Anton Bassov

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

40

sorry. my mistake. bantonassov was OP on another thread.

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> bantonassov (Mr. Assov?) was the OP, no?
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@hotmail.com
> Sent: Thursday, August 26, 2010 8:01 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] releasing a spinlock when not at dispatch level
>
> Mr.Roddy,
>
>
> [quote]
>
>
> But what about Mr. Assov?
> Mark Roddy
>
> [end quote]
>
> If you don’t mind, could you please explain yourself
>
> Thanks in advance
>
> Anton Bassov
>
> —
> 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
>
>