One of those great computing myths, hopefully they will fix the
documentation.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Nick Ryan”
To: “Windows System Software Developers Interest List”
Sent: Monday, August 04, 2003 1:16 PM
Subject: [ntdev] Re: Debugging Multiple Code Paths with Multiple SpinL ocks
> 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)
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>