[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:FYI- JProbe Threadalyzer
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?