Subj : Re: Lockable objects
To   : comp.programming.threads
From : David Schwartz
Date : Wed May 25 2005 01:50 am


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6nbfq$u6u$00$2@news.t-online.com...

> "Giancarlo Niccolai" wrote

>> If you need to, then you must use a condition wait; they are meant to 
>> wait
>> for something to relevant to happen, i.e. for the data you want to use to
>> be ready.

> Using a recursive mutex solves all these problems.

>It depends on what type of mutex you use. I'm using recursive mutex
>and the following method:
>  Any function which modifies an object shall expect that the object be
>  already locked by the current thread (or the func itself shall do the
>  locking of the object). Modifications must be done only in a locked state
>  and of course by the lock owning thread only.

    This is precisely the crux of the issue. You consider concurrency to be 
the *problem* and recursive mutexes to be the solution.

    You are quite right that recursive mutexes make it very easy to reduce 
concurrency -- just lock the mutex and then do everything you want to do. 
The problem is that concurrency is a fundamental good. That recursive 
mutexes make it easy to reduce concurrency out of laziness and sloppiness is 
one of the reasons that they are usually bad.

    What is the problem with this:

    1) If you need to prevent an object from being modified, lock it.

    2) Do whatever you need to do to the object as quickly and directly as 
possible. Do nothing else while you hold the lock unless you have no choice.

    3) Unlock it and then go on and do other things.

    DS

.