Re: JavaMemoryModel: Thread model algorithm.

From: Sylvia Else (sylviae@optushome.com.au)
Date: Tue Nov 18 2003 - 17:18:44 EST


At 12:25 PM 18/11/2003 -0800, Jerry Schwarz wrote:

>Perhaps the concern is the behavior of wait when the thread has been
>interrupted. I've never seen a clear statement of that, but it has always
>been my assumption that wait would throw an InterruptedException
>immediately in that case. So
>
> while ( foo.wait() ) {
> ... ; // something short
> }
>
>does not need any explicit check of Thread.interrupted().

I had thought that it was clearly stated in the API, but now that look
there, all I can find are statements about InterruptedException that are at
best open to interpretation.

I think Jerry's assumption is a fair one. If wait() is not so defined, then
a loop similar to Jerry's, but including a test for Thread.interrupted()

         for(;;) {
                 if(Thread.interrupted()) throw new InterruptedException();
                         // <---- point x.
                 foo.wait();
                   ... ; // something short
         }

would have a race with Thread.interrupt(). If that occurred at point x,
then the interrupt would not succeed in interrupting the thread, which
would block waiting for a notify. Indeed, for this reason, it is not
sufficient for wait() to perform this test on entry to the method.
Something of an equivalent nature has to be done somewhere further in.

On this subject, another question occurs to me. If the thread has already
been interrupted prior to the entry to wait(), is wait() permitted to
release the monitor, and then reacquire it, or must it throw
InterruptedException without ever releasing the monitor?

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:54 EDT