791
Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : David Schwartz
Date : Mon May 02 2005 08:46 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d56lh6$5ab$02$1@news.t-online.com...

> Theorem (updated):
>   a) There will be no deadlock if the objects are locked in the same 
> order.
>   b) Unlocking can be done in any order.
>   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.)

    While now probably true, this would result in a very crippled locking 
hierarchy. Any thread that wanted to acquire a lock would need to know the 
full history of the thread's locking since the first lock it acquired. Even 
calling two functions from the same class would be problemmatic if each 
function locked the object.

    Many of the most common patterns can't be used under this rule. For 
example, you can't have one lock that controls the existence of objects of a 
class and an individual lock for each object to protect that particular 
object. Without this, reference counting is nearly impossible.

    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.

    DS

.

0