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

Doug Lea dl at cs.oswego.edu
Tue May 16 09:11:56 EDT 2006

First, note that the JLS-3 specs allow some non-determinism here. See
Which says...
[Sec 17.8.4]
   The above specifications allow us to determine several properties having to do
   with the interaction of waits, notification and interruption. If a thread is
   both notified and interrupted while waiting, it may either:

     * return normally from wait, while still having a pending interrupt (in 
other works, a call to Thread.interrupted would return true)
     * return from wait by throwing an InterruptedException

   The thread may not reset its interrupt status and return normally from the
   call to wait.

   Similarly, notifications cannot be lost due to interrupts. Assume that a set s
   of threads is in the wait set of an object m, and another thread performs a
   notify on m. Then either

     * at least one thread in s must return normally from wait, or
     * all of the threads in s must exit wait by throwing InterruptedException

   Note that if a thread is both interrupted and woken via notify, and that
   thread returns from wait by throwing an InterruptedException, then some other
   thread in the wait set must be notified.
[BTW: notice the typo "in other works"!]

This boils down to saying that there are two forbidden outcomes:
   1. A thread woken up via notify does not "lose" its interrupt status.
   2. An InterruptedException does not "lose" the fact there is a
      pending notification (that may wake up some other waiting thread).

These are the "bugs" fixed in 1.5 JVMs in accord with JSR133 specs.

I just threw together a little test program (attached) to verify that
#1 does not happen. It doesn't on the JVMs/platforms I've checked.
(This is not a pretty program because it has to
use spins/yields to advance the threads so as not to contaminate
with additional locks, waits, or sleeps.)

However, it is the case that on all platforms I've tried, sometimes
the "notifyBeforeInterrupt" method says it was interrupted before
notified, and vice versa. This reflects the unavoidable race here,
that will come out one way or the other depending on exactly what
the target thread is doing when signaller invokes notify or interrupt.

(There are also some tests for #2 around developed during JSR133,
but I'm not sure where they are.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: T516.java
Type: text/x-java
Size: 2720 bytes
Desc: not available
Url : /pipermail/attachments/20060516/5c4a3caa/T516.bin

More information about the Concurrency-interest mailing list