Sylvia Else wrote:
> 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.
Interesting proposal but it just seems inherently 'wrong' to change
the notion of interrupts in this way - at least to me as I always
liked my view of how it was supposed to work. :)
> 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.
To maintain existing (expected) semantics the wait loop would have to
be rewritten with an explicit Thread.interrupted() check. It could
impact real apps that know they only interrupt threads whilst they are
waiting, and so know that once interrupted that thread won't follow
the normal code path.
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:45 EDT