Oyvind writes about the Threadalyzer: > It will warn if any "wait" does not acquire a lock within > a user-defined timeout. Isn't this how standard 100% OK wait > for a channel etc. is done? Don't understand! "wait(n)" waits until either it is "notified" or "n" milliseconds elapses - then tries to reacquire the sync-lock in which its call is embedded. Is the "user-defined timeout" something the user tells Threadalyzer about for the above reacquisition? Or is it the "n"? Either way (and I don't really understand the former), how does this warning help me??? > Same thing, but warn if "wait" is called with no timeout > and "notify" isn't there within a user-defined timeout. The JCSP (and, I'm sure, the CTJ) channels are implemented by a "wait" without any timeout. I don't want to be warned about this! Threadalyzer seems to be assuming some deadlock-paranoid design pattern that says that any blocking without a tiumeout is dangerous - I've seen such sentiments on the rt-java mailing list. CSP designs can be deadlock-free wothout any such paranoa ... I don't understand the second line about the "notify" at all ... except that it might be similar to the previous mention of "user-defined timeout" ... which I didn't understand either ... > It defines a race condition as "when two threads simultaneously > contend for the same object and, as a result, leave the object > in an undefined state". It's not contention that's the problem - it's uncontrolled contention for the same object by different threads ... > Run-time version of occam usage rules? Hopefully. That may even be useful. Java allows too much run-time aliasing to perform parallel usage checks statically. Maybe it does run-time checks of conformance to dynamic CREW usage? Do they give any examples to demonstrate what they are really doing? Cheers, Peter.