Subj : Re: recursive mutexes
To   : comp.programming.threads
From : David Schwartz
Date : Mon May 16 2005 01:08 pm


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

> You are putting operations into 2 categories:
>  1) operations which can be done only if the object is locked
>  2) operations which can be done only if the object is not locked

    Right.

> This is unneccessary complication, and it's dangerous.

    Huh?

> My point of view is: all operations on a shared object can be done only
> in a locked state (#1 above).

    What?! No. There are plenty of operations on a shared object that can 
only be done in an unlocked state. For example, one cannot wait for another 
thread to do something to a shared object when that object is in a locked 
state!

> So one has to forget #2 and never assume to do #2.

    Have you ever worked on a project of any significance, say 25,000 lines 
or more, that involved multi-threading?!

> An object can be modified only in a locked state, otherwise wait or
> give up your time-slice back to the schedular.

    Exactly. But before you wait or give up your time-slice, you must 
release any locks you hold or you'll be waiting *forever*.

>>     Here's another one:
>>
>> x.Lock();
>> while (x.IsReservedByAnotherThread())
>> {
>>  x.Unlock();
>>  DoOtherStuffSinceXIsNotReady();
>> }
>> x.DoStuff();
>> x.Unlock();
>>
>>     This code will deadlock if the x mutex is recursive. The other thread
>> can never clear its reservation because this thread might still hold the 
>> x
>> mutex through the entire 'while' loop.

> The same would happen with non-recursive locking too, wouldn't it?

    No. Because 'x.Unlock()' is *guaranteed* to unlock the object if the 
lock is not recursive.

> Besides this, it is a bad and buggy design. You never should lock an
> object in a scope and unlock it in a different scope.

    What?! So you don't like:

x.Lock();
if(x.IsAlreadyDone())
{
 x.Unlock();
 return();
}
/* lots of code here to do what has to be done */
x.Unlock();

    What is wrong with that exactly?!

>>     We really mean what we're saying. Really, really. Recursive mutexes 
>> are
>> really bad and they really do hide serious bugs.

> This is simply not true. Recursive locking is a superset of non-recursive 
> locking.
> Everthing possible in non-recursive locking is possible in 
> recursive-locking too,
> except deadlocking himself. So then how can recursive-locking be more 
> dangerous
> than non-recursive locking? This is simple basic logic.

    HAHAHAHAHAHAHAHAHA!

    A loaded gun is a superset of an unloaded gun. Everything possible with 
an unloaded gun is possible with a loaded gun. So how can a loaded gun be 
more dangerous than an unloaded gun? This is your brand of logic.

    DS

.