Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : David Schwartz
Date : Wed May 04 2005 08:43 pm


"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message 
news:xJeee.27664$Cq2.10968@fe2.news.blueyonder.co.uk...

>>>I'm currently extending it for detecting violations of the theorem (ie. 
>>>an
>>>automatic deadlock detector conditionally compiled only in debug build.
>>>IMO it even could be used in release build since the overhead seems not 
>>>that much).

>>     It's very expensive to do this in a release build, but it's *great* 
>> for a debug build.

> Automatic deadlock detection is not expensive.

    Granted, but we're talking about violations of the locking hierarchy 
whether or not they cause deadlocks.

> First let's consider the case of global deadlock, where *all* threads
> of a program are waiting on locks. There is no significant performance
> overhead involved in detecting this state (i.e. the state when the
> scheduler has no runnable threads and no thread is blocked for another
> reason, such as I/O). The complexity cost of doing so is also very
> small. So there is no excuse at all for concurrent systems not to provide
> this level of deadlock detection for all builds.

    Agreed.

> Detecting mutual deadlock between some subset of threads, as opposed to
> global deadlock (i.e. where it would be impossible for the threads that
> are still running to resolve the deadlock) is a bit more complicated.
> However, it need not be more expensive, because of the following
> observation:

    Not all violations of a locking hierarchy result in deadlock. The point 
is to detect violations, not deadlocks.

    DS

.