> Seems to me that the notion of prioritization makes no sense in the absence
> of a defined order for notify() and interrupt() invocations. So to say
> we're disallowing prioritization of interrupt amounts to saying that we're
> defining an order for notify/interrupt invocations. I rather assumed that
> the order we were heading for was program order.
None of the essential nondeterminism of Thread.interrupt etc here ever
occurs when notify and interrupt are issued by the same thread. So it
would be is possible to constrain specs to say that even though
effects are not guaranteed to be synchronous, they are guaranteed to
occur in program order with respect to each other when occuring in the
same thread. If I knew of a context in which this had any practical
impact, I might suggest we do it.
The main implementation-based reason that the Thread.interrupt spec
must have some nondeterminism is to permit cases where an interrupt
"really" occurred before a notify (or before any other event, but only
notify is relevant here), but the JVM consistently interprets it, wrt
both the notifying thread and notified thread, the other way
around. Note that here, the interrupt must have been performed by some
third interrupting thread.
Consider the common (near-universal) case of a JVM using an underlying
thread blocking mechanism that either doesn't report or can lie about
the "reason" for wakeups. Here, wakeups and status checks for
interruption are intrinsically separated in time, causing races. There
is an arbitrarily brief window in which the interrupted thread has
woken up due to interrupt but doesn't know yet that the wakeup
indicates interruption. The solution amounts to making sure the
notifying thread does not know it either, so has the effect of
reordering/delaying the interrupt.
This effect is not reliably obeservable, but is in principle
detectable by sets of threads "spying" on these events. For example,
if all three of the waiting, notifying, and interrupting threads
record timestamps, and both the waiting and notifying threads are
context-switched out long enough at the wrong times, some other thread
could see from the time stamps that the reordering took place: the
waiting thread had been interrupted from the point of view of the
interrupting thread, but returned normally from wait.
If this nondeterminism in Thread.interrupt is not allowed, we are back
to the issue being unsolvable without introducing heavier machinery
that JVMs won't want to implement and users won't want to bear the
performance consequences of.
Another way of saying this is that the choice seems to be among:
1. Some nondeterminism in Thread.interrupt spec
2. Messier specs of Object monitor methods
3. Crummy performance
Given that (1) already holds (there has always been nondeterminism in
the Thread.interrupt spec, and there don't seem to be any bug reports
or complaints about it) it seems like an easy call. As I said, we could
revise to more carefully limit this nondeterminism if anyone can think
of a reason to bother.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:55 EDT