Subj : Re: Deadlock Calculator
To   : comp.programming.threads
From : David Schwartz
Date : Sat May 14 2005 11:49 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d66djl$bp1$02$1@news.t-online.com...

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

    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.

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

    DS

.