deadlock detection

Jacob Gladish gladish@spinnakernet.com
Mon Sep 8 14:22:00 GMT 2003


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?


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /