Doug Lea wrote:
> I think there are three distinct subissues here. Here's my current
> view on them:
>
> 2. For the sake of responsiveness, wait() should throw
> InterruptedException rather than return normally if the thread is
> in fact interrupted, regardless of "why" the thread awakened.
>
> 3. For the sake of courtesy(?) to Java programmers, if, per (2), a JVM
> sees that a thread is interrupted upon awakening, should it issue a
> notify.
Sorry if this question is overly naive, I'm pretty much just an average
Java programmer. If a thread is in an interrupted state and invokes
wait(), is it guaranteed to throw an InterruptedException? The API
documentation I have does not explicitly state this, but it seems like
it should be true and it seemed to be true for a test program.
If that's the case, I'd favor an implementation that does not swallow
notifies when it throws InterruptedExceptions (obeys the requirements of
3). Theoretically it seems that interrupt handling could be done by a
JVM by just setting the interrupted status of a thread, issuing a
notify, then throwing an InterruptedException the next time wait() was
invoked.
I'd imagine there's a much faster way to implement this that avoided the
extra notify for better performance in most cases, but this seems
correct in a world where spurius notifies are allowed.
-- 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