Rajesh according to RH check the page 204 the last few lines interrupt is equivalent to stop The thread does not lose ownership of any monitors-- does this means it will not give a its objects lock if another thread (here means a thread holding a diff objects lock) has interrupted the current thread. The interrupted status of the current thread is cleared (??? what does this mean ) when this exception is thrown.
Jim Yingst
Wanderer
Sheriff
Joined: Jan 30, 2000
Posts: 18670
posted
0
Shan- RHE do not actually say that interrupt is equivalent to stop, only that interrupt is now recommended instead of stop. Whether or not the interrupt ends up causing the thread to stop executing depends on how the InterruptedException is handled. When a thread is interrupted, it does not give up any object locks it has. (Is that what you meant?) I can't tell what the third statement means - what page is it from?
Ah. That isn't very clear, is it? Here's my understanding - you can use the interrupt method on any thread, whether it's doing smething that throws an InterruptedException or not. But the effect can be very different. If the thread is currently in a for loop for example, which does not throw an InterruptedException, then all the interrupt() will do is set the interrupt status to true, which means that if the thread checks its own status using interrupted() or isInterrupted(), it can find out that another thread has indeed interrupted it. But if it doesn't check, then the interrupt() has no other effect - the for loop keeps right on executing. So "interrupt()" is really more like "tryToInterruptIfTheThreadIsPayingAttention()". On the other hand, if the interrupted thread was in a wait(), then it can throw an InterruptedException. If that happens, there's really no need to check the interrupted status - you know an interrupt occurred, because you've caught the exception (or if you didn't, then the JVM has terminated and you really don't care any more ). So to eliminate confusion, they reset the interrupted status for you as soon as the exception is thrown. After that, if isInterrupted() returns true, you know there must have been a second interrupt in addition to the one that caused the exception. To be honest, this feature doesn't really seem very useful to me, but it also doesn't seem to cause any problems, so I guess it doesn't really matter.