Subj : Re: Deadlock Calculator
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sun May 15 2005 09:23 am

"David Schwartz" wrote
> "Uenal Mutlu" wrote

> > It has nothing to do with whether release or debug build.
> > It just shows the effect of a locking method which permits
> > a thread to lock the same object multiple times without
> > blocking (ie. deadlocking) itself.
>
>     And which cannot detect if this is done accidentally.
>
> > Ie. calling Lock() for an object (here 'a') which is already
> > locked by the same thread).
> > Case 1 is a Lock() method without recursive locking capability, case 2 is
> > with.
>
>     Right, and in case 1, if a thread erroneously locks an object it already
> holds, that is easily detected. In case 2, that is not detected.

Totally different point of view. In case 1 a deadlock will happen, in case 2
a deadlock will not happen. Which is better/safer?  of course case 2, not case 1.

>     It really is this simple: To write sane multi-threaded code, you must
> know what locks you hold at the same or lower levels in the locking
> hierarchy. The only use for recursive locks is to make it possible for code
> to not deadlock if it doesn't know what locks it holds at the same level in
> the locking hierarchy. But code has to know this anyway.

With recursive locking code does not need to know that. It just locks
the objects it wants, regardless whether they are already locked by whom ever.

>     So all it does it hides bugs and make it possible to write bad code.

I totally disagree. Exactly the opposite is true. Recursive locking helps
avoiding self-deadlocking, it simplifies coding, and it helps to encapsulate
the problem; you can concentrate just on your own job without the need
to know what the caller (or the caller of the caller etc.) of your routine has
already done or has not done, ie. whether an object is already locked and/or
by whom etc. It's so simple with recursive locking: just lock it yourself and proceed.

.