The reason the output is false is given in the API for the wait() method:
"Throws: ... InterruptedException - if another thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown."
What this means is that
after an InterruptedException has been thrown, interrupted() will return false. If you'd been able to invoke this method
before the exception was thrown, from within the interrupted thread, you would have seen a true instead. This is only an issue if you're
not calling a method like wait() or sleep(), which are required to detect interruptions for you and respond by throwing InterruptedExceptions. If you're doing some other time-consuming activity, and want to check if there have been interruptions, that's what interrupted() (and isInterrupted()) are for.
[Tony]: Your code is not guaranteed to always acknowledge the interrupt during the call to wait() and thus deadlock. Mmmm, I'm not seeing the loophole here. Are you referring to the possibility that interrupt() might be called before the wait() is executed? Not a problem - wait(), like sleep(), checks for any uncleared interruptions that occurred beforehand, and responds by throwing InterruptedException when appropriate. E.g.:
Note that I replaced interrupted() with isInterrupted() to avoid changing the result on subsequent calls.
In the event I've missed my guess and Tony is actually talking about something else, hopefully the above code will be of interest to Ramya at least.
[ February 15, 2005: Message edited by: Jim Yingst ]