Hi,
On the prioritisation of notify vs interrupt, I have taken that view that
these are just operations, with no inherent characteristics that suggest a
preference of one over the other. On this basis, a behaviour that acts on
the operations in the order that they occur seems reasonable to me.
But even if we decide that interrupt somehow has a higher priority than
notify (or timeout), the implementational consequences of that seem
limited. Once any event occurs that conceptually removes a thread from a
wait set, the thread then has to reacquire the monitor. Even if a 'higher'
priority interrupt now occurs, it doesn't change this basic fact.
As Doug observes, in the notifyAll case, there may be many threads queued
on the monitor, and some can take a long time to return from the wait()
call, but attaching a higher priority to interrupt() won't change that. The
best that is available is for the wait() call to throw InterruptedException
in this case - after it has acquired the monitor.
So the only tangible benefit of attaching a higher priority to interrupt()
is that the programmer who is concerned to get maximally fast response to
interrupt() (and doesn't care about lost notifications) does not have to add
if(Thread.interrupted()) throw InterruptedException;
immediately after the call to wait.
Having lost notifications and/or spurious wakeups inherent in the model
seems a high price to pay for this.
If we really want a higher priority interrupt mechanism, then we need to
provide a way for a thread to continue without reacquiring the monitor. I
don't think there's anything in the JVM specification that prohibits this,
but it clearly does not fit into Java's block structured synchronization
model, so we can't reach the desired goal by changing the semantics of
wait/notify/interrupt.
Sylvia.
>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
-------------------------------
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