Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Re: Debugging Multiple Code Paths with Multiple SpinL ocks

David_J._CraigDavid_J._Craig Member Posts: 1,885
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)
>
>
>
>

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Releasing locks in acquisition order can improve concurrency, as
    releasing them out of order potentially causes waiters to wait longer
    for the lock in similar/same code paths.



    -----Original Message-----
    From: Roddy, Mark [mailto:xxxxx@stratus.com]
    Sent: Monday, August 04, 2003 10:26 AM
    To: Windows System Software Developers Interest List
    Subject: [ntdev] Re: Debugging Multiple Code Paths with Multiple SpinL
    ocks

    The DDK is overstating the case here. However, as a colleague pointed
    out,
    the implementation of spinlocks in NT requires one to maintain IRQL
    levels
    appropriately. (For example, if you release locks in arbitrary order and
    use
    the lock-specific previous irql on release you can end up falling below
    dispatch level before releasing all of your locks.) Probably the easiest
    way
    to do this is to always release in acquisition order, but this is not
    mandatory. At any rate, I wasn't commenting about the implementation of
    locks in NT, but rather the general ordering rule for deadlock
    avoidance,
    which applies only to acquisition, and not to release.


    =====================
    Mark Roddy
    Hollis Technology Solutions
    www.hollistech.com
    xxxxx@hollistech.com


    -----Original Message-----
    From: Nick Ryan [mailto:xxxxx@nryan.com]
    Sent: Monday, August 04, 2003 1:16 PM
    To: Windows System Software Developers Interest List
    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@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@softek.fujitsu.com
    To unsubscribe send a blank email to xxxxx@lists.osr.com
  • (1) Agree releasing of locks can occur in any order.
    (2) I think you are correct that one should release in the reverse order
    as this can give concurrency a boost and most of the time you did this
    anyway since you are not to hold the longer than necessary.
    (3!!!!!) What I am trying to do with the orginal discussion, I now see
    the need for code because we are going off in tangents. I am not talking
    of deadlock prevention nor of using a a heirarchy and release. What I am
    trying to developement is a covering tool using the while (1) loops
    described earlier. So lets us say we have 3 Threads T1, T3 and T7 with on
    shared synchronization object called S1. The while (1) with its body
    described earlier will get all the CPUs executining the the while (1) loop
    then I can release them in the 3! ways to make sure all my code
    KeAcqiureSpinLock() have been Tested. With VMWare saving of the machine
    state this can be cool tool. I will write code to demostration. You guys
    are really cool and I must say I am digging this. Please excuse this
    "Thread of Discussion" for a awhile while I develop code to demostrate
    what I am "trying" to talk about. Email if interested in code and anyway
    I will post the code hear too. Wish me luck.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space