At 11:50 AM -0800 11/8/99, Joshua Bloch wrote:
>Folks,
>
> 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.
While you can do some things statically, you would also likely depend
on dynamic
tools.
The dynamic tools for data race detection don't depend on generating
an anomalous behavior during a run. Most of them simply depend on
generating two accesses to
a variable by different threads, where one of those accesses is a
write, and the
accesses are not ordered by synchronization.
There is another technique, implemented in the Eraser tool, that
tries to verify that
for each variable accessed by different threads, there is some lock
that is always held while that variable is accessed. Eraser generates
some false "you have trouble"
messages, because it doesn't understand some synchronization styles
like doing producer-consumer synchronization through a queue. But
I've been doing some thinking about ways to fix that.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT