RE: JavaMemoryModel: Reconsidering prioritized InterruptedExceptions

From: Sylvia Else (
Date: Thu Nov 27 2003 - 18:32:21 EST

At 01:58 AM 28/11/2003, Doug Lea wrote:
>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.

Ok, I fully accept that there are some implementational issues here, but
the proposal is that the Object.wait() specification be changed to say

The Object.wait spec can just add three words:
    If the current thread is interrupted by another thread while it is

Sorry if I seem to be repeating myself, but I'm trying to put my thoughts
into different words.

My criticism of the current JSR133 draft is that it describes notify in
terms of synchronous effects when the effects are not immediately visible.
However there would be an eventually visible interaction with interrupt, so
to dig itself out of this hole, the specification essentially provides that
the effects of notify() and interrupt() are not ordered.

The FOR A NOTIFICATION clause cannot make sense in the context of unordered
notify/interrupt effects, so it brings back ordering. Once you have
ordering, the effects of notify/interrupt even within a thread cannot be

So I'm arguing that if notify/interrupt reordering is allowed within a
thread, then the proposed specification change does not fit the bill. What
should it say instead?


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:55 EDT