RE: JavaMemoryModel: Thread model algorithm.

From: Evan Ireland (eireland@sybase.com)
Date: Mon Nov 17 2003 - 15:06:32 EST


Sylvia,

Is there any interpretation of the current model in which
"lost notifications" are inherent, other than when both an
interrupt and a notify/timeout occur around the same time?
_____________________________________________________

Evan Ireland eireland@sybase.com +64 4 934-5856

Sybase EAServer Engineering, Wellington, New Zealand.
_____________________________________________________

> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Sylvia Else
> Sent: Tuesday, 18 November 2003 8:41 a.m.
> To: Java Memory Model
> Subject: Re: JavaMemoryModel: Thread model algorithm.
>
>
> 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

-------------------------------
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