> The alternative is to adopt neither.
That's fine with me.
I like proposal 1 because it could make apps more responsive to interrupts.
However I think interrupt is almost a lost cause when 3rd party code is
involved -- and when no 3rd party code is involved I can build my own
I don't like proposal 2. At this late stage, it seems like a lot of trouble
on account of interrupt, and it *could* affect the behavior of existing apps
that have been attempting to finesse interrupt/notify in strange ways.
Btw, I assume these proposals have nothing to do with whether
m.wait(timeout) can consume a notification. wait(timeout) should either
consume a notification or it should timeout and throw IE, but not both. (I
think of it this way: If it is notified then it did not timeout, no matter
how long it waited...)
----- Original Message -----
From: "Bill Pugh" <email@example.com>
Sent: Tuesday, July 29, 2003 9:21 AM
Subject: JavaMemoryModel: Spec on on wait and interrupts
Unfortunately, I don't think we reached consensus on this:
At 11:03 AM -0400 5/26/03, Bill Pugh wrote:
>OK, to clarify the thoughts that have been floating around over the
>past dozen or so messages, I think there are two concrete proposals.
>Proposal 1: a thread performing a wait should prefer throwing an IE
>over returning normally. In particular, if
>* thread T1 calls m.wait()
>* thread T2 calls T1.interrupt()
>* thread T2 calls m.notify() or m.notifyAll()
>Then T1 should exit the wait by throwing an IE.
>Sun's current VM's fail this test (code attached at bottom).
>Proposal 2: if a thread T1 performing a wait on object m is removed
>from the wait set via a call to m.notify(), and T1 exits the call to
>wait by throwing an IE, then the VM should ensure that another
>m.notify() is performed. Since spurious returns are allowed, one
>implementation of this would be to have any call to wait that throws
>an IE perform a re-notification.
In the last email on this, David Holmes said:
At 9:18 AM +1000 6/10/03, David Holmes wrote:
>I believe the VM must take responsibility for avoiding "lost
>notifications", but that the relative order of interrupt vs. notify is
Does anyone know if any existing VM's violate proposal 2?
So I'm going to suggest that the spec drop proposal 1, and adopt
proposal 2. The alternative is to adopt neither.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT