(Published in Dr.Dobb’s Journal, Jan.1998, p.10)
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
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!