>Honestly this is a paper changing exercise, not a change to any
>existing function/behaviour.
Ok - I'll accept that.
However, we should at least now try to make the API documentation correctly
reflect the behaviour. As I understand the situation, some JVMs will do
something like this as their implementation of wait()
[I'm ignoring races with interrupt() here].
If the interrupt flag is set then
reset it.
throw InterruptedException
fi
Add this thread to the wait set of the object.
Unlock the object monitor
Wait until this thread no longer in the wait set
Lock the object monitor
If the interrupt flag is set then
Reset it
Notify the monitor
Throw InterruptedException
fi
Return normally
The justification for allowing this is that it is impossible for a program
to distinguish between a JVM that does it this way, and one that does it
strictly according to the specification of wait, notify and interrupt, but
with the caveat that a wait may wake up at any time regardless of program
actions.
Does anyone have a proof that this is true?
At the moment, I think I can construct an (albeit non-trivial) counter example.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:45 EDT