Subj : Re: recursive mutexes
To   : comp.programming.threads
From : David Schwartz
Date : Fri May 20 2005 02:39 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6lgls$h1a$05$1@news.t-online.com...

>>     As I said, assuming it's the last unlock.

> Wake not necessary at all (at least in my implementations of both
> recursive and non-recursive mutex methods).

    You can always trade-off expenses in one place by moving them to 
someplace else. That's why I don't make the argument that recursive mutexes 
are bad because they're more expensive than non-recursive mutexes.

    They are in fact more expensive in every implementation I've ever seen 
that didn't just deliberately impose the expense on non-recursive mutexes as 
well. You can't avoid the fact that an 'Unlock' has to determine whether or 
not it's actually going to release the mutex as an additional expense not 
present in a non-recursive mutex. You can only remove that expense by making 
'Lock' much more expensive so that it can handle the case where it failed to 
get the lock but still blocked other threads.

    If you think I'm wrong, prove it. Present an implementation of a 
recursive mutex such that it can't be made significantly less expensive by 
making it non-recursive. I'll even ignore the overhead of the extra 
locks/unlocks, I'm only concerned with the cost of the first lock and the 
first unlock. If you can do it, I will call you a genius.

    That said, it really doesn't matter. The problem with recursive mutexes 
is not that they hurt performance, because that's generally negligible. It's 
that they hide serious design flaws and promote sloppy design. Their *only* 
use is to allow you to write code that manipulates an object without knowing 
whether or not it holds a lock on that object. And that is just bad, bad, 
bad.

    DS

.