Re:FYI- JProbe Threadalyzer

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

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.