I'm cross-posting this to testdrivendevelopment, agile-testing, and
extremeprogramming.

In the January 2006 Issue of Dr. Dobb's Journal, Tomer Abramson
presents an article, "Detecting Potential Deadlocks". It's certainly
possible to purchase a PDF of the whole issue; I'm not sure whether
the article is fully available free on line or not. Check
http://www.ddj.com/documents/s=9938/ddj0601n/0601n.html .

The article describes a "Deadlock Detection Application", written as
a DLL for Visual C++ 6 under Windows 2000. It works by hooking
references to shared resource mutexes, and logging all locks and
releases by all threads. Then an analysis program looks at the
sequences of locks and computes whether there are cycles in any
sequence. If there is, this represents a potential deadlock, and the
program reports on it.

Now, in general, testing is a weak way to detect deadlocks, since
conventional tests can run forever and never encounter a deadlock
that will happen in real life. Threading and deadlock detection are,
so far, areas where TDD techniques, and other approaches commonly
used in Agile software development, have not been very helpful.

It seems to me that it might be possible for a Mock Object expert or
experts to build some mock objects that could be clicked into place
instead of conventional mutex access, record the sequence of events,
and then produce an analysis of whether there were potential
deadlocks in the program.

It seems to me that it ought to be possible, and if it were done, it
would be both a valuable contribution, and a demonstration of the
kind of place where mocks are clearly advantageous.

Consider yourselves challenged!

Ron Jeffries
www.XProgramming.com
He who will not apply new remedies must expect old evils. -- Francis Bacon