(Published in Dr.Dobb’s Journal, Jan.1998, p.10)

Dear DDJ,
I read with interest Alan Vermeulen’s “Java Deadlock” in the Sept. number. Vermeulen is only partly right when he says that deadlock is “a condition where all of the threads have stopped and are waiting for each other.” (“Stopped” in the daily meaning of the word, I assume, not Java’s). Deadlock is a mutual starvation between at least two threads that can’t satisfy each other. The rest of the threads may run for weeks, until the service of one of the threads engaged in the deadly embrace is required. The final result could be as Vermeulen states, but it doesn’t have to - with tenths of threads it is unlikely that they all will be part of the circle of threads waiting for each other.
   Controlling deadlock in Java doesn’t have to be some sort of black art. Instead of Hoare’s monitor (that the Java language offers), we can make monitors invisible and use Hoare's later CSP on top of them. Have a look at the CSP-library under development, start at http://www.hensa.ac.uk/parallel/groups/wotug/java/discussion/. The library simulates occam semantics (occam is a safe multithreading programming language), a proven multithreading solution during the last 10-15 years. Using this library and a set of rules, you can avoid deadlock for sure. If you specify the same system in textual CSP, you may run a deadlock checker that doesn’t let deadlock pass! (http://www.comlab.ox.ac.uk/archive/csp.html)

Øyvind Teig

Back