I think there are three distinct subissues here. Here's my current
view on them:
1. For the sake of portability, the spec for wait must say that
a thread returns from wait() when:
a. Some other thread issued a notifyAll
b. Some other thread issued a notify and the thread happened to be chosen
c. The thread was interrupted
d. Time elapsed under a timed wait
e. Any other time, for no apparent reason (i.e., spuriously).
Like the Java programmer, the JVM doesn't necessarily "know" the
root cause of awakening (if any), and doesn't tell you. (Unlike
some pthread implementations and OSes that tell you but sometimes
lie :-)
2. For the sake of responsiveness, wait() should throw
InterruptedException rather than return normally if the thread is
in fact interrupted, regardless of "why" the thread awakened. This
is a policy decision, not a logical necessity (or even something
that can be adequately specified). But it is, I think, favored by
all Java prgrammers who regularly need to deal with cancellation,
and conveniently fits in well with (1) -- if the JVM doesn't know
that a thread awakened due to interrupt, it must check status
before returning back from wait anyway. As with all state-based
checks, there is an arbitrary point within any implementation at
which the return vs throw path is decided. As a quality of
implementation issue, the closer the check is to the ultimate
return from wait() the better, but the spec for wait() can't say
anything about this.
3. For the sake of courtesy(?) to Java programmers, if, per (2), a JVM
sees that a thread is interrupted upon awakening, should it issue a
notify, under the reasoning that:
a. The thread might have been woken up by a single notify. And...
b. The thread might be involved in a cacading/chained notify
design in which each participating thread must perform a single
notify to the others else lose liveness. (Notice that this
issue never arises in designs relying solely on notifyAll.) And ...
c. Because the current thread has been interrupted, it will
probably not act on that notification. And ...
d. The Java programmer might have forgotten to manually
propagate the notify because it is easy get cancellation wrong.
Put in this way, there is not a very compelling case here.
But most people/programmers don't think about the issue in this way
(but instead in terms of "lost" signals). And given the lack of
harm by requiring that JVMs issue notify here, I don't have strong
feelings about it. The kinds of single-notify designs affected are
pretty rare, so the impact either way is small.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:45 EDT