Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 04 2005 01:17 am

"David Schwartz" wrote
> "Uenal Mutlu" wrote
>
> >>     Your hierarchy does not allow you to relock o2 while you still hold
> >> the o1 lock. So this is not legal.
>
> > No, Sir. This scenario I'm using so often that it is "natural" for me.
> > That is: the theorem covers this and it is heavily used in how I use
> > locking in applications.
> > I wonder why you think this should not be possible? I'd suggest
> > to take a look again at the f1() and f2() functions of my prev posting.
> > It is exactly the same scenario like yours above, and it works.
>
>     Your theorem states:
>
>    c) If there are multiple threads then the set of objects to lock within
>        a thread must not contain the same object more than once.
>       (Unlocking all in the set and starting over again (either the same
>       or a
>        different set of objects), either in the same block or in a
>        different block, is ok.)
>
>     This prohibits locking o2 again while the o1 lock is still held. In this
> case, only part of the set has been unlocked, not all of it.

Good observation, yes, rule c is not well or completely formulated :-(
But the point should be clear. Rule c should exclude this case, or a
rule d should be formulated. But since english is not my native language
it's not easy to find the right formulation to describe this case. Any idea?  :-)

> >> And recursive locks are just plain wrong. You cannot write sane code
> >> unless you know what locks you hold (at the same or lower levels in a
> >> hierarchy), and recursive locking is only helpful if you don't know what
> >> locks you hold (at the same or lower levels in a hierarchy). The worst
> >> part
> >> about recursive locking is it sets you up for problems because you don't
> >> know what 'unlock' is actually going to do.
>
> > Hmm. maybe we have different meanings of recursive locking.
> > In my definition it is a locking mechanism where the same owner (thread)
> > can lock an object multiple times in series without the need of first
> > unlocking it.
> > o1.Lock();
> > o1.Lock();
> > o1.Lock();
> > Obviously there must be 3 Unlock() calls to release the objects.
> > As said in my prev. posting this kind of recursive locking is valid
> > for the _current lock owner_ (thread) only, and there is virtually no
> > overhead (just an incrementing of a counter; if it becomes 0 (due to
> > Unlock() calls)
> > then the object is released). And: for recursive locking there is no
> > need to know what other objects are locked or not; recursive locking
> > is applied on the same one object for the same one thread only.
>
>     I agree that it's valid, just useless and dangerous. Please read my
> criticism again.

Hmm. IMO it is by no means useless or dangerous. It is a very important
feature, because it simplifies object locking very good; you don't need to
check or unlock whether the object is already locked. In case it is
"me" (the current thread) who already has it locked then a second
lock request again by me simply increments the lock counter of the object
and the lock is (again) granted. Of course one also can do these checkings
also in the application code, but IMO it doesn't belong therein.

> >>     Perhaps, but since the theorem imposes needless requirements, it just
> >> restricts what you can do for no benefit.
>
> > Hmm. I personally don't feel it has needless requirements or restrictions,
> > It is designed for and applied in real-world apps, ie. not only in theory.
> > For me it is simple, intuitive, and very fast.
>
>     How do you guarantee that you don't hold any locks when you need to
> re-acquire a lock you recently released?

It is not necessary to check whether other objects are locked.
The lock request is for the underlying object only.
Normal behaviour of Lock() is to block until the object can be
locked (ie. until the other thread releases the lock). There is
of course also a TryLock() function which tries to lock, and returns
immediately; the return code says whether it succeeded or not.
The job of Lock() is not indended to also to check for possible deadlock
since this (deadlock prevention) happens implicitly when the theorem is applied.

.