At 11:26 AM 26/11/2003, David Holmes wrote:
>Does it make a difference if the interrupt occurs before or after N
>releases the monitor?
If the interrupt occurs after N releases the monitor, then thread 1 may
wakeup without throwing IE. At some point its interrupted flag will become
set. This is not visibly different from the non-prioritized outcome where
the interrupt precedes N's release in which case the thread returns
normally with its interrupted flag already set.
>Your preferred behaviour makes it appear that the interrupt occurred
>before the notification. Yet the time (and intervening actions)
>between them could actually be great. If we add a few more threads to
>the scenario and interrupt all but the last, does it make sense that a
>notification that occurred when only T1 and T2 were waiting is
>actually received by Tn at some much later point?
It is true that it represents a reordering of events that may have occurred
a long time apart, but the specification already includes that. I've argued
that where the specification talks about interrupt and notify occurring at
approximately the same time, it really means a separation period of
arbitrary length.
I'm not suggesting the unacceptable outcome you mention, and my proposal
does not have that effect any more than Doug's variant of it does. In the
case in point, having thread 3 wakeup is a perfectly permissible outcome,
because the first notify wakes thread 2, the second wakes thread 3, and
thread 1 wakes and throws IE because it was interrupted.
>If you consider real predicates attached to those waits then the
>scenario described could not arise. Remember that to correctly use
>notify() rather than notifyAll(), all threads must be waiting for the
>same condition to hold. Given that thread N must release the monitor
>before T3 can wait(), then T3 should see a condition that does not
>require it to wait. ;-)
I can't immediately think of a counter example, it's true :) But if we're
going to use such reasoning to justify implementations of the thread model,
then the thread model needs to include an application model that
incorporates this.
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