Re: Debugging Multiple Code Paths with Multiple SpinL ocks

NTDEV
1

Sure it *can* do that, but it also might decrease concurrency by holding
locks no longer needed while other threads are waiting for them (in
dissimilar code paths.) So it really depends on your code, and a mistaken
mandate such as the one in the DDK, might prevent a programmer from
resolving a performance problem.

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

-----Original Message-----
From: McDowell, Steve [mailto:xxxxx@softek.fujitsu.com]
Sent: Monday, August 04, 2003 1:42 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Debugging Multiple Code Paths with Multiple SpinL ocks

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

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