Re: JavaMemoryModel: Prioritizing IE without notifyAll().

From: Sylvia Else (
Date: Tue Nov 25 2003 - 06:03:03 EST

I have been having some off-list discussion with Doug Lea about the effects
of his variant of my proposal for prioritizing the interrupts over
notifications. We have reached the point where it appears that we agree
about the effects, but disagree about whether they are permitted.

The particular scenario is illustrated by this execution trace, involving
three waiting threads, and a notifying/interrupting thread N. For the
purposes of this trace, any woken threads are assumed not to have
reacquired the monitor until after N has performed its second notify and
its interrupt.

Thread 1: Wait
Thread 2: Wait
N: Notify
Thread 3: Wait
N: Notify
             Interrupt Thread 1

Consider the point after N has interrupted thread 1, but before it releases
the monitor.

We know from the algorithm that thread 1 and thread 2 are queued on the
monitor. Now let N release the monitor. Only threads 1 and 2 are queued on
it. Suppose that thread 1 acquires it. According to the algorithm, thread 1
will find no threads available to notify, because thread 3 waited too late,
and thread 2 is not in the wait set any more.

Thread 1 is still committed to throwing IE, so it discards its own
notification. When it releases the monitor, thread 2 acquires it and
returns normally. Thread 3 is still waiting.

Essentially the same outcome occurs if thread 2 gets the monitor before
thread 1.

As I understand it, what we disagree on is whether this outcome is should
be permitted, and indeed whether the JSR133 specification in its current
form permits it.

The behaviour I would prefer is one where the outcome is as if any
interrupted threads had never been notified, but had simply been
interrupted while waiting, with the caveat from the specification about the
non-predictability where interrupt and notify are demonstrably applied to
the same thread before wait returns. In this case, thread 3 would have been
notified, and would return normally.

I believe the algorithm as I described it (with my correction to it)
achieves this, so on the face of it, it's not an unreasonably restrictive



JavaMemoryModel mailing list -

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