[concurrency-interest] Re: interrupt / notify races even in 6.0 beta?

Doug Lea dl at cs.oswego.edu
Tue May 16 11:26:48 EDT 2006


Bart Jacobs wrote:
> 
> So it seems it would help if the JLS clarified the meaning of "while 
> waiting" (both for 17.8.1 and 17.8.4), by saying that the thread "stops 
> waiting" sometime after the notify()/interrupt() call, and therefore is 
> still considered to "be waiting" until such time.
> 

Yes; this is a good idea.

The effects seen here might seem less mysterious if you know
the basic implementation scheme, which is typically the one
documented for AbstractQueuedSynchronizer.Condition.await; see
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/locks/AbstractQueuedSynchronizer.ConditionObject.html

        1. If current thread is interrupted, throw InterruptedException
        2. Save lock state returned by AbstractQueuedSynchronizer.getState()
        3. Invoke AbstractQueuedSynchronizer.release(int) with saved state as 
argument, throwing IllegalMonitorStateException if it fails.
        4. Block until signalled or interrupted
        5. Reacquire by invoking specialized version of 
AbstractQueuedSynchronizer.acquire(int) with saved state as argument.
        6. If interrupted while blocked in step 4, throw exception


Notice that interrupt status is checked (at least) twice -- on entry, and then
again during/after an OS-level blocking.

This means that response to (notify; interrupt) or (interrupt; notify)
can go either way, depending on whether each came at/before
step 1, or step 4, or later. So even though in the test programs
here, the caller "knows" which came first, it cannot control the
points at which the waiting thread is paying attention to which of these
events.

(This is not a bug; it's a feature! People would not like to use
a condition wait implementation that disables either the "early"
or the "late" checks.)

-Doug




More information about the Concurrency-interest mailing list