Subj : Re: recursive mutexes
To   : comp.programming.threads
From : David Schwartz
Date : Sun May 15 2005 12:58 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d67h31$utf$01$1@news.t-online.com...

>> > The code above is IMO wrong, obviously it should be:
>> >  A) Lock mutex
>> >  B) Do something
>> >  C) Unlock mutex

>> David meant what he said.  What if the something is signaling another
>> thread to go ahead with something that locks the mutex, and then wait
>> for that other thread to signal you back?  Deadlock.

> This has nothing to do with recursive locking per se, does it?

    Yes, it does.

> I mean: the same
> would happen also without recursive locking, wouldn't it?

    No. Because with locks that are not recursive, an 'unlock' function 
actually unlocks something.

> And, apart from that I don't think this way. In my thinking each thread
> knows itself only and tries to lock the shared object(s) before changing
> its/their content. We are talking of locking some shared objects here, 
> don't we?
> You maybe should give a practical example in pseudocode for what you mean.

    Okay, let me put it as simple as possible. There are some things you can 
only do when you hold a lock, like manipulate shared data. There are some 
things you can only do when you don't hold a lock, like block or wait for 
shared data to change. Thus code that manipulates shared data needs to know 
whether it holds a lock or not.

> This is a shortsighted view. What do you think recursive locking is 
> intended for?
> Recursive locking has nearly no overhead if the implementation of lock()
> and unlock() were properly done.
> They have many many advantages.

    The *only* advantage is that you can write code that acquires a 
particular lock without knowing whether it already holds that same lock. 
However, code has to know what locks it holds *anyway* in order to be 
developed sanely.

    DS

.