Part of the problem here is that we still have trouble saying exactly
where the contoversy lies. Here's a stab at it, but I suspect that
even this folmulation itself may be controversial.
I see this as two distinct issues.
A. When one thread, t, does a wait -- for completeness, assume a timed wait,
mon.wait(msecs)
there is in intrinsic race among the following ways for the wait to return:
1. Some thread invokes mon.notify, and thread t was chosen
2. Some thread invokes mon.notifyAll
3. Some thread invokes t.interrupt
4. The wait times out
5. The wait spuriously returns
The choices for governing this are:
A1. Must an implementation ensure that if causes (3), (4), or (5) have
already occurred (at some hypothetical instant), that cause (1) does
NOT also occur? Or,
A2. Are multiple/indeterminate causes allowed?
The main question here is whether choice A1 is actually implementable
(without exorbitant cost/overhead) on all the platforms Java runs on.
B. When the above wait returns,
B1. Must wait() throw InterruptedException ONLY if the "cause" of the
return was case (3) above, or
B2. May wait also throw IE if unblocking occurred under the other
causes but the thread is known to be interrupted upon return from wait.
This question arises because some programmers would like, in general,
IE to be thrown as soon as interruption status is detected, while
others prefer to use the information about IE to help disentangle
which cases in (A) arose and act accordingly.
-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:50 EDT