Sylvia Else wrote:
> Maybe I'm missing the point you're making here, but my line
> of thinking was
> that the expected usage of wait() takes the following form:
>
> synchronized(m) {
> try {
> while(m.flag == false) {
> m.wait();
> }
> // I woke up for a valid reason.
> }
> catch (InterruptedException ex) {
> // Someone interrupted me.
> }
> }
There are a couple of variants to the above:
a) the try-catch is inside the while-loop
b) the exception is thrown directly out of the method
For example,
synchronized void someBlockingMethod() throws InterruptedException
{
while (!inRightState)
wait();
// do something
}
Under the existing spec an interrupt while waiting will propagate
straight out of the method. Under your proposal the interrupted thread
gets a chance to check the state again and potentially do something.
An application might keep tight control over interruption and
know/require that an interrupted thread will not "do something"
again - it might have had resources released that prevent it from
"doing something". To keep the existing semantics the above code would
have to be changed to:
synchronized void someBlockingMethod() throws InterruptedException
{
while (!inRightState) {
wait();
if (Thread.interrupted() )
throw new InterruptedException();
}
// do something
}
David Holmes
-------------------------------
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