[concurrency-interest] Deadlock detection

Oliver Zeigermann oliver at zeigermann.de
Fri Apr 6 15:36:34 EDT 2007


Hi Sam!

Thanks a lot for that pointer. I had no idea anything like that
existed in JDK 1.6. Cool feature. Your code is instructive as well :)

And yes, my aim is to tell the programmer: "No, I will not give you
this lock, as this would lead to a deadlock!" before acutally
acquiring that lock. And of course, this will only work in a managed
scenario where there is some sort of manager that keeps track of all
locks of a thread. Together with some form of contract the thread and
the manager have.

The manager would signal a deadlock to the thread using an exception.
The thread then is resonsible for undoing a set of actions and
releasing all its locks in order to resolve the deadlock. Both
releasing the locks and undoing all actions can be supported by the
manager. Undoing all actions of a thread is the equivalent to rolling
back a transaction in a DB system. This scenario only makes sense when
the actions done by the thread are restricted to those undoable by the
manager.

Oliver

2007/4/6, Sam Berlin <sberlin at gmail.com>:
> 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