Subj : Re: Lockable objects
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sat May 21 2005 05:46 pm

Uenal Mutlu wrote:


>> In a few words, you should NOT call any function between a lock() and an
>> unlock(). That because mutexes protect data, and function calls are not
>> data to protect.
> 
> This limitation is not necessary if a recursive mutex is used.

This is not a limitation.

> 
>> 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.

There isn't any problem to be solved about that.

> 
>> You are confusing too much the two things, I am afraid.
> 
> No, but OTOH you shouldn't overlook your own arrogancy, just
> reread your postings to see it.

It is not arrogance; at worst irony, sometimes it's even concern for you.
Many other people have treated you much worse than me here, questioning
your personality and intellectual ability, even if politely (and sometimes
not so politely), a thing that I ALWAYS refrain from doing.

> 
>> Oh, but there aren't condition waits in Windows... sorry...
>>
>> However, someone created them for you.
> 
> Windows has CriticalSection, which is a recursive mutex.
> There is also a non-recursive mutex available.
> But, this all is not specific to Windows only.

Mutex are not condition variables, and they can't be confused. Mutex
(reentrant or not) cannot be used to wait for something relevant to happen.
They must be used to ensure that shared data is accessed sequentially.
Entering a function is not accessing shared data. You fail to acknowledge
this basic - yet extremely important - fact.

Two primitives are necessary and sufficient to perform correct threading:
- mutexes
- event variables (providing the wait-and-release-mutex atomic semantic).
Recently, even Windows introduced the SignalObjectAndWait() function to
comply with this necessity. POSIX has the "condition variable" which is an
event provided with the appropriate semantics.

You can have your application run (and never deadlock, if that matters at
all) also with reentrant mutexes, right, but at the cost of turning it in a
single thread application most of the time, (and especially, in the most
interesting points where parallelism would help it). After all, if you run
a thread at a time, you don't even need coordination. And if you kill the
ill people, they won't need to heal.

There's no way by which a mutex (recursive or not) can act as an event
variable. I suggest you to google for "man pthread_cond_init"; even if not
a theoretic document, the manpages for the various systems should explain
why we do things in a certain way, and why a condition wait cannot be
substituted with a mutex acquisition. I hope.

Bests,
Giancarlo Niccolai.

.