RE: deadlock detection

[Jacob Gladish <gladish at spinnakernet dot com>]

On Sat, 2003-09-06 at 05:40, Andrew Haley wrote:
> Boehm, Hans writes:
> 
>  > I think that if you want to detect deadlocks on the fly, you really
>  > only have to check as you are about to lock a heavyweight lock.
>  > And then it suffices to do a depth-first search of only the
>  > heavyweight locks reachable from the one we're trying to acquire.
> 
> Oh, of course!  Thanks Hans.
> 
> That's obvious, but for some reason I didn't think of it -- you only
> have to look at the part of the graph you changed.
> 

That's something I hadn't thought of. I wrote a small simulator this
weekend to try some different graph implementations. I'll definitely
incorporate the partial graph search you suggested.

>  > 1) This is typically very cheap, since you only pay on persistent
>  > 1) contention, and there probably aren't very many heavyweight
>  > 1) locks.
>  > 
>  > 2) There are probably weird cases for which it's expensive.  It
>  > 2) probably shouldn't be the default.
>  > 
>  > It seems to me that the result is still quite limited though, since
>  > it only detects deadlocks involving exclusively locks, as opposed
>  > to wait/notify or more obscure dependencies (IO, wait loops on
>  > volatiles, etc.)  My guess is that this covers around half the half
>  > the Java deadlocks I've seen, though my experience may be atypical.
> 
> That's a useful insight.

I hadn't considered the ability to do any analysis other then exclusive
locks. Do any other java implementations attempt to do this?