David Holmes wrote:
> Joe Hendrix wrote:
>>If a thread is in an interrupted
>>state and invokes wait(), is it guaranteed to throw an
>>InterruptedException?
>
> Yes this is true for wait() - though as you say the spec is not
> crystal clear on this.
>
> For sleep() it's mostly true - but there is a grey area with sleep(0)
>
> For join() it need not be true because the thread being joined may
> already have terminated, so no blocking occurs and so there's no need
> to check interruption.
This is a side issue, but is there a good reason why Java couldn't
guarantee that all these throw an InterruptedException if entered in the
original state? I think this would be a nice invariant for these functions.
> But as
> I've mentioned pthreads/POSIX allows pthread_cond_wait to return zero
> when interrupted by a system call so if pthread_cond_wait is used at a
> low-level then having it return normally doesn't tell the VM why it
> returned: notification or interruption.
Thanks for the pointer to the pthreads description in the other email.
That's unfortunate that pthread_cond_wait doesn't return an [EINTR] as
it seems useful assuming the implementation in pthreads doesn't have a
race condition.
I'd like the guarantee that no notifies are lost. There are two
solutions that I see without an additional race condition:
1) Sylvia's suggestion
2) Before throwing an InterruptedException in a blocking operation,
invoke notifyAll() on the object being monitored.
I think those are perfectly valid solutions for edge cases, but handling
every interrupt like that does seem wrong. Certainly neither behavior
should be mandated. At most the spec should simply dissallow notifies
from being dropped.
Joe Hendrix
-------------------------------
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