If a spin lock structure has a slot for the old IRQL, then releasing them
out of order will cause the IRQL to be wrong at some time. Maybe Microsoft
has plans to change some part of the SpinLock implementation that will
require following that rule. Maybe verifier will start to check - because
it can.
“Nick Ryan” wrote in message news:xxxxx@ntdev…
>
> This what I thought too, but the DDK mentions this in a section
> discussing spin locks:
>
> “If a driver makes nested calls to acquire spin locks, it must release
> those spin locks in inverse order: that is, if a driver acquires spin
> lock A before acquiring spin lock B, it must release spin lock B before
> it releases spin lock A.”
>
> As long as the locking heirarchy is not violated at any point in time,
> why should it matter?
>
> Roddy, Mark wrote:
>
> > Enforcing release order is wrong, as release order has no effect on
program
> > correctness.
> >
> >
> > =====================
> > Mark Roddy
> > Hollis Technology Solutions
> > www.hollistech.com
> > xxxxx@hollistech.com
> >
> >
> > -----Original Message-----
> > From: Loren Wilton [mailto:xxxxx@earthlink.net]
> > Sent: Saturday, August 02, 2003 8:27 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Re: Debugging Multiple Code Paths with Multiple
SpinLocks
> >
> >
> > I worked on a machine once that had the locks implemented in the
firmware,
> > and there was a lock level that was part of each lock. If you attempted
to
> > acquire locks in non-ascending order, or release them in non-descending
> > order, you would get a machine fault.
> >
> > This could lead to a week of discussion on the right level for a new
lock,
> > but it also meant that any problems with acquiring locks in the wrong
order
> > or releasing them in the wrong order became obvious real fast. It also
> > meant that lock deadlocks were impossible.
> >
> > Of course you could still create a deadlock, but you had to use an event
as
> > well as a lock to accomplish it, and a number of programmers, annoyed at
the
> > necessary dicipline of figuring out how to use the locks in order would
> > hand-create deadlocks using locks and events rather than order their
code
> > correctly in the first place. Then someone else would have to analyze
the
> > bug and redesign their code for them, because they would always claim
the
> > deadlock was a hardware problem and couldn’t possibly be the result of
THEIR
> > code, and thus would refuse to look at the system dump. (Which says
> > something - negative - about management and hiring practices at that
> > particular company.)
> >
> > There is no reason a spinlock or mutant wrapper couldn’t be created that
> > would assign levels to the locks and bugcheck if they were used in the
wrong
> > order. Of course, since there is nothing but convention that requires
the
> > right usage order now, there are doubtless many cases where they aren’t
used
> > in the right order currently. But at least you could insure that a
given
> > driver was working correctly internally.
> >
> > Loren
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@nryan.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
>