Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : David Schwartz
Date : Tue May 03 2005 12:55 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d587qb$dg5$00$1@news.t-online.com...

>>     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.

>> 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.

>>     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?

> I'm currently extending it for detecting violations of the theorem (ie. an
> automatic deadlock detector conditionally compiled only in debug build.
> IMO it even could be used in release build since the overhead seems not 
> that much).

    It's very expensive to do this in a release build, but it's *great* for 
a debug build.

    DS

.