RE: JavaMemoryModel: Waits, Interrupts and Notify-s

From: Doug Lea (
Date: Sat May 24 2003 - 12:20:07 EDT

I think there are three distinct subissues here. Here's my current
view on them:

1. For the sake of portability, the spec for wait must say that
   a thread returns from wait() when:

   a. Some other thread issued a notifyAll
   b. Some other thread issued a notify and the thread happened to be chosen
   c. The thread was interrupted
   d. Time elapsed under a timed wait
   e. Any other time, for no apparent reason (i.e., spuriously).

   Like the Java programmer, the JVM doesn't necessarily "know" the
   root cause of awakening (if any), and doesn't tell you. (Unlike
   some pthread implementations and OSes that tell you but sometimes
   lie :-)

2. For the sake of responsiveness, wait() should throw
   InterruptedException rather than return normally if the thread is
   in fact interrupted, regardless of "why" the thread awakened. This
   is a policy decision, not a logical necessity (or even something
   that can be adequately specified). But it is, I think, favored by
   all Java prgrammers who regularly need to deal with cancellation,
   and conveniently fits in well with (1) -- if the JVM doesn't know
   that a thread awakened due to interrupt, it must check status
   before returning back from wait anyway. As with all state-based
   checks, there is an arbitrary point within any implementation at
   which the return vs throw path is decided. As a quality of
   implementation issue, the closer the check is to the ultimate
   return from wait() the better, but the spec for wait() can't say
   anything about this.

3. For the sake of courtesy(?) to Java programmers, if, per (2), a JVM
   sees that a thread is interrupted upon awakening, should it issue a
   notify, under the reasoning that:
      a. The thread might have been woken up by a single notify. And...
      b. The thread might be involved in a cacading/chained notify
         design in which each participating thread must perform a single
         notify to the others else lose liveness. (Notice that this
         issue never arises in designs relying solely on notifyAll.) And ...
      c. Because the current thread has been interrupted, it will
         probably not act on that notification. And ...
      d. The Java programmer might have forgotten to manually
         propagate the notify because it is easy get cancellation wrong.

   Put in this way, there is not a very compelling case here.

   But most people/programmers don't think about the issue in this way
   (but instead in terms of "lost" signals). And given the lack of
   harm by requiring that JVMs issue notify here, I don't have strong
   feelings about it. The kinds of single-notify designs affected are
   pretty rare, so the impact either way is small.

JavaMemoryModel mailing list -

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