Subj : Re: recursive mutexes
To   : comp.programming.threads
From : doug
Date : Mon May 16 2005 03:59 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d69rcq$r6b$01$1@news.t-online.com...
> "doug" wrote
>>
>> For the current code I'm working on, it would take me several hours, 
>> perhaps
>> days, to type in the lock information his tool requires.
>
> If you strictly follow the deadlock theorem I posted here, then you can
> be assured that no deadlock will happen.
>
>> That's not to mention the fact that threads are created dynamically, and 
>> their behaviour
>> is unpredictable (I see nothing in his tool that allows you to grab this
>> lock OR that lock, depending on some state.).
>
> It is intended for locks put on individual shared objects. Ie. it is not
> for "locking threads" or something that.
> It is irrelevant when the threads are created. It is important what the
> threadproc does: ie. in which order it locks the objects.
> The requirement is: you must create a list of all your shared objects (the 
> order
> is irrelevant), then in each threadproc pick the objects you want to use
> just in the same order as they are on the list.
>
>> All he's done is specialise hierarchical locking for simplified 
>> scenarios.
>
> Not true. The deadlock theorem I formulated is an important 
> generalization.
>
>

Again, not answering the points.  They are:
- I cannot enumerate the list of locks.  Many are dynamically created on the 
fly (to protect a dynamically created piece of data).   There are hundreds 
of threads, and thousands of semaphores.  I cannot actually generate the 
input your program requires.  I see how it would be useful for small stuff, 
e.g. for a Uni project, though.
- Your theory provides no allowance for dynamic flow-of-control - i.e. the 
behaviour of the program must be completely predicatable a priori (or do you 
expect the user to sit and type is every possible combination of acquires 
for each thread??).  Therefore, it's a specialisation, not a generalisation. 
You have tightened the general rules of hierarchical locking to suit your 
restricted problem space.

.