Re: recursive spinlocks. Shoot.

[Nikita Danilov <Nikita@Namesys.COM>]

Richard B. Johnson writes:
 > On Tue, 20 May 2003, Robert White wrote:
 > 
 > >
 > >
 > > -----Original Message-----
 > > From: Richard B. Johnson [mailto:root@chaos.analogic.com]
 > > Sent: Tuesday, May 20, 2003 5:23 AM
 > > To: Helge Hafting
 > >
 > > > Recursive locking is a misnomer. It does during run-time that which
 > > > should have been done during design-time. In fact, there cannot
 > > > be any recursion associated with locking. A locking mechanism that
 > > > allows reentry or recursion is defective, both in design, and
 > > > implementation.
 > >
 > > Amusing... but false...
 > >
 > > A lock serves, and is defined by, exactly _ONE_ trait.  A lock asserts and
 > > guarantees exclusive access to a domain (group of data or resources etc).
 > >
 > 
 > The "ONE" trait is incorrect.
 > 
 > The lock must guarantee that recursion is not allowed. Or to put
 > it more bluntly, the lock must result in a single thread of execution
 > through the locked object.
 > 

Suppose you have a set of objects X, each containing pointer to object
from set Y, each y in Y being protected by a lock. To update pointer in
x from y to y' one has to take lock on y, and global lock G in this
order. To read pointer, it is enough to take G. Several x's may point to
the same y.

How to lock all y's pointed to by elements of X?

If you have recursive locking one may just: 

1. take each x from X in turn
2.     lock G
3.     take y pointed to by x
4.     unlock G
5.     lock y
6.     lock G
7.     re-check that y is still pointed to by x, and if not unlock y and go to 3
8.     unlock G

Without recursive locking what would one do, but emulate it?

Nikita.