OK, looks like we have reached consensus. I talked with Doug Lea
about this on the phone. I haven't gone through all the details of
everything posted on the mailing list, so please check what I'm
proposing. Going back to my earlier wording:
At 3:14 PM -0400 8/6/03, Bill Pugh wrote:
>Which of the following behaviors is allowed?
>
>a) T1 returns from the call to wait() by throwing interrupted exception,
> T2 returns normally from the call to wait()
>
>b) T1 returns normally from the call to wait() and still has a pending
> interrupt; T2 remains in the waitset for X
>
>c) T1 returns from the call to wait() by throwing interrupted exception;
> T2 remains in the waitset for X
We allow a or b, but not c.
More specifically,
* ordering: If a thread is both notified and interrupted while waiting, it
may either:
- return normally from wait, while still having a pending interrupt
(in other works, a call to Thread.interrupted() would return true)
- return from wait by throwing an InterruptedException
It may not:
- return normally from the call to wait, having swallowed the interrupt.
* We forbid lost notifications due to interrupts: Assume that a set S
of threads
is in the wait set of a monitor M, and another thread performs a notify on M.
Then either
* at least one thread in S must return normally from wait (i.e., not throw
InterruptedException), or
* all of the threads in S must exit wait by throwing InteruptedException
* lost notifications due to time-outs: we aren't going to do anything about
this, because nothing we can do will work. In generally, whenever a call
to wait returns normally (i.e., doesn't throw IE), the calling thread
is responsible for checking whether the condition it was waiting on
has been set before or in addition to checking for timeouts.
The reason we can't do anything is because there are two kinds of time-outs.
Ones where the time expires before the call to wait returns, and ones where
the the thread is notified, but the time expires before the thread is about
to check the clock to see whether time has expired. Whatever we could do
would only handle the first.
The easiest implementation strategy would be, when a thread exits a
wait on M by throwing an IE, to always perform notifyAll on M. Other
strategies that perform fewer notifications might be possible, but it
is unclear if they would provide any improved performance.
Bill
-------------------------------
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