Bill Pugh wrote:
> We allow a or b, but not c.
I concur.
> * lost notifications due to time-outs: we aren't going to
> do anything about this, because nothing we can do will work.
There is no need to do anything. A timeout can't consume a
notification because the application sees wait() return in the same
way - normally. By the time the application tries to determine if it
timed out then it may appear to have timed out, so the only sensible
thing for the application to do is recheck the condition.
That said, I'll need to double-check the JSR-166 Condition behaviour
because it does return a different value on timeout.
> The easiest implementation strategy would be, when a thread exits a
> wait on M by throwing an IE, to always perform notifyAll on
> M.
This is only an issue if the implementation wants to give preference
to the IE even if actually notified. If the notification takes
precedence then the logic is basically:
if (wasNotified) return;
if (Thread.interrupted()) throw new InterruptedException();
return; // timeout or spurious
and there's no need for additional notifications.
David Holmes
-------------------------------
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