And while I'm in rave mode, I should point out that a tool to detect
unsynchronized communication is probably not the panacea that some have made it
out to be. I believe (correct me if I'm wrong) that such a tool would be
dynamic, rather than static. Finding "illicit communication" statically would
appear to be about as difficult as solving the halting problem. A dynamic tool
could very easily generate false positives. It takes a lot of execution to get
a system into interesting concurrent states.
At Transarc, an engineer who shall go nameless once switched the labels on
the lock and tryLock primitives in an assembly language source file. As a
result, we were running without synchronization. It took four months for us to
notice that there was a problem, and the problem was not discovered as a result
of day-in day-out execution, but as the result of intensive concurrent bashing
of a new module, with tons of gratuitous yields thrown in. This sort of
experience makes me somewhat doubtful that we should pin our hopes on a tool.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT