Re: recursive mutexes

From: Måns Rullgård (mru_at_inprovide.com)
Date: 05/15/05 

Date: Sun, 15 May 2005 12:41:35 +0200

"Uenal Mutlu" <520001085531-0001@t-online.de> writes:

> "David Schwartz" wrote
>> red floyd wrote:
>>
>> > May I ask why?
>>
>> There are two possibilities:
>>
>> 1) You don't know the mutex is being used recursively. In this case, the
>> recursive mutex will hide a serious problem.
>>
>> 2) You know the mutex is being recursively. In this case, just don't
>> lock it since you know it's already locked anyway.
>>
>> The problem is that recursive mutexes hide something from you and that
>> something is extremely important. Consider code like this:
>>
>> A) Lock mutex
>> B) Unlock mutex
>> C) Do something, assuming the mutex is unlocked
>>
>> What happens if the mutex is recursive?
>
> Recursive locks work only for the same (current) thread.

I sure hope so.

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

> and this is ok too (here the recursive feature is in action):
> A) Lock mutex
> B) Do something
> C) Lock mutex
> D) Do something2
> E) Unlock mutex
> F) Unlock mutex
>
> C and E are redundant, however application code (the current thread)
> cannot always know that it alread has the lock, though it could test
> for it.

Bad application design. A properly designed application will always
know what to expect.

>> It's just too hard and dangerous to write sensible code that
>> works with a mutex that might or might not start out with that
>> mutex locked and with no way to tell which. And the only value of
>> recursive mutexes is that they let you do this.
>
> Lock objects are initialized at creation, they don't have a random
> state. Recursive locks are very practical. It saves coding and
> prevents from self-deadlocking.

In all the years I've been programming, I have never used a recursive
mutex (except in Java, but that's another story). 

-- 
Måns Rullgård
mru@inprovide.com

Relevant Pages

  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)
  • Re: threads do not get cpa
    ... >>in a routine you are calling. ... >>suspect Linux's brain damaged signaling but you're using IRIX which ... the mutex, instead of while holding the mutex, has some performance ... before the signaler has a chance to release it if it is holding the lock while ...
    (comp.sys.sgi.misc)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [PATCH 4/8] adaptive real-time lock support
    ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
    (Linux-Kernel)