[concurrency-interest] Deadlock detection

Oliver Zeigermann oliver at zeigermann.de
Fri Apr 6 17:40:44 EDT 2007


Right. Wouldn't it be a good idea to have some sort of manager that
sees after consistent lock ordering and actually guarantees it?

Oliver

2007/4/6, Brian Goetz <brian at quiotix.com>:
> Scanning for deadlocks with JMX is reactive; what you want is to
> identify the causes of deadlock, which is inconsistent lock ordering.
> One approach, which requires run-time weaving with aspects, is here:
>
> http://www-128.ibm.com/developerworks/java/library/j-jtp08226.html
>
> Sam Berlin wrote:
> > Hi Oliver,
> >
> > JMX features provide the ability to scan through all locks for
> > deadlocked code.  I can't quite tell by reading the link you provided
> > if this is what you're looking for.  It doesn't provide the ability to
> > know ahead of time if acquiring a given lock would produce a deadlock
> > (that would be a neat JVM switch -- I wonder how slow it would make
> > things), but it will tell you afterwards if you've encountered a
> > deadlock.  (It will even correctly report a trio of threads, where the
> > third is waiting on something the first two have deadlocked in.)
> > There's no ability to rollback any deadlocks, but that is always
> > fraught with peril anyway.  For an example of using the JMX features,
> > see the following deadlock detection class:
> > <https://www.limewire.org/fisheye/browse/limecvs/gui/com/limegroup/gnutella/gui/DeadlockSupport.java?r=1.3>
> > .  That class is written to work best on Java 1.6, but also work
> > well-enough on Java 1.5.
> >
> > Sam
> >
> > On 4/6/07, Oliver Zeigermann <oliver at zeigermann.de> wrote:
> >> Folks!
> >>
> >> I plan to write some code for deadlock detection for Java programming
> >> using the concurrent package introduced in Java 1.5.
> >>
> >> The code is intended for a new version of
> >>
> >> http://jakarta.apache.org/commons/transaction/
> >>
> >> and there to replace the old code which is described in
> >>
> >> http://jakarta.apache.org/commons/transaction/locks/deadlock.html
> >>
> >> I doubt that the idea and code described there are especially good and
> >> would be pleased if anyone could point me to a better direction.
> >>
> >> I was especially concerned about
> >>  *  whether a check for a deadlock with potentially every locking
> >> request really is a good idea or if it is smarter to let an additional
> >> thread check for deadlocks from time to time, and
> >>  * if there is any algorithm that does not have to check the whole
> >> dependency graph for cycles, and
> >>  * a more elegant version of the existing code could be written that
> >> does not have the drawback of potentially rolling back both threads
> >> that are part of a deadlock (one should be enough)
> >>
> >> That code has been written by me, so if you want to comment, please do
> >> not be polite ;)
> >>
> >> Thanks for any hints in advance and cheers
> >>
> >> Oliver
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at altair.cs.oswego.edu
> >> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list