Now I remember this impass...
Part of the reason Sylvia's approach works as stated is that it
returns normally vs throwing InterruptedException even when the thread
is interrupted, but the interrupt occurred after the notification. I
think programmers prefer to know about interrupts as soon as
possible. On the other hand, I don't recall ever canvassing developers
about the issue. So I sent out the following to the JSR166 interest
list (which mainly consists of developers) about the
java.util.concurrent version, (I didn't cross-post just to avoid the
chaos this usually leads to.) It would be very helpful to find
compelling reasons for adopting one or the other policy.
While I'm at it, here's my main reason, which might not be compelling
enough to upset Sylvia's story: I first noticed the issue in programs
with lots of threads that could sometimes all be woken up via
notifyAll and also sometimes all be interrupted for the purpose of
cancellation. It sometimes takes a very long time for some of these
threads to reacquire the lock after being notified (because they are
so many of them), during which time they might be interrupted. Yet if
wait() returns normally when threads are interrupted after being
notified, the threads don't realize they've been interrupted, which
means that cancellation doesn't take effect until the next interrupt
check point (usually a subsequent wait()). While I could workaround
this by rechecking Thread.interrupted() upon return from wait(), the
fact that I would always want to do this made me conclude that wait()
should do it itself, especially since I've never written any code
where I needed to be able to tell whether an interrupted thread was
woken up by a notify before an interrupt occurred.
> From: Doug Lea <dl@cs.oswego.edu>
> Sender: concurrency-interest-admin@cs.oswego.edu
> To: <concurrency-interest@altair.cs.oswego.edu>
> Subject: [concurrency-interest] Condition.await policy
> Date: 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:53 EDT