[concurrency-interest] Condition.await policy

Doug Lea dl@cs.oswego.edu
Sat, 15 Nov 2003 11:43:18 -0500


Some of you have seen variants of this issue on the JSR-133/JMM list
(See http://www.cs.umd.edu/~pugh/java/memoryModel/) as it applies to
built-in monitors.

In Condition.await (and timeout versions of await) there are potential
interactions among notifications, interrupts and timeouts.  There has
to be a policy for dealing with them.

First, interrupts: When a thread enters Condition.await, you might define
two intervals at which interrupts occur:

  Interrupt-before-signal:
     Either the thread was already interrupted before waiting, or the
     thread started waiting but was interrupted before it was signalled

  Signal-before-interrupt:
     The thread started waiting, was signalled, but was then
     interrupted before returning from await. (Usually, this means it
     was interrupted while reacquiring the lock, which it must do even
     if interrupted.)

The main question is whether these cases should be handled differently.
The two options are

  1. Throw InterruptedException (IE) in both of these cases.
vs
  2. Throw IE in case of interrupt-before-signal; otherwise return normally
     (but with the thread's interrupt status still set true).

That is: Is it more important for callers to be informed of
interruptions as soon as they are discovered, or more important to
know that a thread woke up as a consequence of a signal versus an
interrupt?

The choices for timeouts in await(timeout, unit) work the same way:
  1. Return false (i.e. timeout) if timeout elapsed upon return, else true
vs
  2. Return true if signalled before timeout elapsed, else false if
     the timeout occurred after being signalled but before return
(where, in both cases, the corresponding interrupt rules hold
if interrupted.)

There are some further complications that usually enter discussion of
this issue, including the fact that the borderlines between the
intervals may involve race conditions, so can be problematic to
describe and deal with, and also that some policies may entail
additional spurious wakeups.

But ignoring these, I'd like to know if people on this list have a
compellingly strong rationale for changing (or keeping) the current
policy in all JSR-166 Condition implementations of taking choice (1)
for both interrupts and timeouts.

Thanks!

-Doug