At 11:03 AM 26/05/2003 -0400, Bill Pugh wrote:
>OK, to clarify the thoughts that have been floating around over the past
>dozen or so messages, I think there are two concrete proposals.
>
>Proposal 1: a thread performing a wait should prefer throwing an IE over
>returning normally. In particular, if
>* thread T1 calls m.wait()
>* thread T2 calls T1.interrupt()
>* thread T2 calls m.notify() or m.notifyAll()
>
>Then T1 should exit the wait by throwing an IE.
>
>Sun's current VM's fail this test (code attached at bottom).
>
>Proposal 2: if a thread T1 performing a wait on object m is removed from
>the wait set via a call to m.notify(), and T1 exits the call to wait by
>throwing an IE, then the VM should ensure that another m.notify() is
>performed. Since spurious returns are allowed, one implementation of this
>would be to have any call to wait that throws an IE perform a re-notification.
Proposal 3: On entry, the wait call atomically throws IE if the interrupted
flag is _already_ set, and otherwise enters the wait state. Once the wait
state is entered, not even interrupting the thread can make the method
throw IE. Instead, interrupting the thread merely wakes it, and leaves it
with its interrupted flag set.
This is permitted if spurious wakeups are allowed because there is no way
the thread can distinguish this scenario from one where a spurious wakeup
is immediately followed by an interrupt. Since the expectation is that
wakeups are performed inside a loop that tests for the condition being
waited on, this should not break existing programs.
Although this looks like an unnecessary delay in responding to an
interrupt, I can't see that this will have a noticeable impact in reality.
Sylvia.
-------------------------------
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