c08
Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : David Schwartz
Date : Tue May 03 2005 02:45 am


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d56vs2$lvt$03$1@news.t-online.com...

>>     Consider code like this, where the 'FooFinder' lock protects creation
>> and destruction of 'Foo' objects so that we don't have two by the same 
>> name
>> and can safely find them by name.
>>
>> FooFinder::Lock();
>> Foo *j=FooFinder->FindFooByName("foo");
>> if(j!=NULL)
>> {
>>  j->X(); // internally locks this particular foo
>>  j->Y(); // internally locks this particular foo
>> }
>> FooFinder::Unlock();
>>
>>     If the 'X' and 'Y' functions internally lock 'foo', you have a 
>> problem
>> since you had to release the FooFinder lock before you could lock the 
>> lock
>> built into the 'j' object again.

> Hmm. I don't see any problem, though it is not the kind how I
> use object locking b/c in my code j->X() would lock the objects
> it needs to access, do its job, and then release them, so would
> j->Y() and any other function.


    Well that's the problem. You see, j->Y() would lock the same lock j->X() 
just released. Your hierarchy specifically prohibits that.

> If you don't use a recursive Lock() and/or do Lock() in one function
> and Unlock() in a different function then things will become
> very complex. I would recommend a method like my above Locker
> helper class and a recursive Lock(). There is virtually no overhead
> in recursive locking. It just checks whether the lock request is from
> the same thread like the current lock owner and increments a counter
> and returns true to indicate success. Ie.
> o1.Lock()
> o1.Lock()
> called from the same thread is harmless regardless where each
> of them is called. See also example above.

    But your hierarchy doesn't allow that. Consider:

SomeFunction()
{
 o1.Lock();
 o2.SomeFunctionWhichLocksAndThenUnlocks();
 o2.SomeFunctionWhichLocksAndThenUnlocks();
 o1.Unlock();
}

    Your hierarchy does not allow you to relock o2 while you still hold the 
o1 lock. So this is not legal.

    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.

> The theorem is mainly intended for deadlock-free locking of
> groups of usually independent/hierarchyless objects inside
> multiple threads for the purpose of accessing them as a set.
> And I would say this kind of resource aquisition leads to better
> performace than to lock the same group in just one lock (maybe
> this sounds weird but it's not).

    Perhaps, but since the theorem imposes needless requirements, it just 
restricts what you can do for no benefit.

    DS

.

0