[concurrency-interest] Deadlock detection

Sam Berlin sberlin at gmail.com
Fri Apr 6 14:18:27 EDT 2007


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
>


More information about the Concurrency-interest mailing list