At 07:54 PM 22/11/2003 -0500, Doug Lea wrote:
>Sylvia,
>
>I admire your persistence. Especially since it sometimes it pays off!
Thanks, Doug, though whether it's persistence (a virtue), or just being
plain stubborn (a vice), I don't know.
Anyway, as has probably been apparent all along, my main target has been
spurious wakeups.
For my proposal, or your more elegant variant of it, to work, it's a
prerequisite that an interrupted thread know whether or not it was woken by
a notify. I cannot imagine an implementation in which the thread does not
know immediately prior to the interrupt whether it was woken by a notify,
but does know sometime afterwards. From this I conclude that any
implementation that uses this approach to avoid using notifyAll() for
interrupted threads will, at the point where it is about to return from
wait, be in one of the following waking states that are distinguishable by
the thread.
1) Not notified, and timer has not expired
2) Not notified, timer has not expired, but thread interrupted.
3) Not notified, timer has expired
4) Not notified, timer has expired, and thread interrupted.
5) Notified, and timer has expired.
6) Notified, and timer has expired, and thread interrupted.
7) Notified, and timer has not expired.
8) Notified, and timer has not expired, and thread interrupted.
In cases 2, 4, 6, 8 the method throws Interrupted Exception.
In cases 3, 5, 7 the method returns normally.
Which leaves only case 1, which represents a spurious wakeup from some
unknown source. But since the wakeup is recognisably spurious, then the
wait() method should loop back and try again.
Maybe another algorithm exists that allows interrupted threads to avoid
notifyAll(), without knowing whether or not the interrupted thread was
notified....but I'm sceptical.
This appears to mean that any implementation that needs to be allowed to
perform spurious wakeups is also going to use the sledgehammer approach of
notifyAll for interrupted threads.
Has the balance now shifted in favour of disallowing spurious wakeups.
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:54 EDT