Subj : Re: recursive mutexes
To   : comp.programming.threads,comp.unix.programmer
From : Uenal Mutlu
Date : Sun May 15 2005 03:41 pm

"David Schwartz" wrote
>
> "Uenal Mutlu" wrote
>
> > 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.
>
>     Yes, it can and must know that it already has the lock. A function that
> operates on X should be defined as being called with X locked, or with X
> unlocked. It could even take a boolean that indicates whether the caller has
> locked the object or not, though this is rarely the right thing to do.

You are unnecessarily complicating things and make the program
slower by doing these testings. These tests are not necessary if
your design is good.

>     Simply put, the only thing recursive mutexes gives you is the ability to
> write code that deals with X that can be called whether or not X is locked.

Not true. It is the caller's job to call X only after having the lock.
It is not X's job to check whether the object was locked.
Do you see the difference, and the consequence, and what it means for performance?

> This is not only almost never useful, but it's almost always dangerous.

Recursive locking has less dangers than locking without recursive feature.
Proof: using recursive locking you never can block or deadlock yourself,
but using a locking method without recursive feature you can very easily deadlock yourself.
In the latter case even just blocking (ie. waiting for the lock) means deadlock!
Don't you see that?

.