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
>implementation dependent.
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.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:47 EDT