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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:43 EST