Sunita, I don't know of any on-line tutorials that focus on the interrupt method. Fortunately, the real exam does not place much emphasis on the interrupt method so you really don't need to spend a lot of time on it.
Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>
FYI: interrupt(): sets the interrupted flag in the Thread object on which was called. It does no more. Thread.interrupted(): static, it clears interrupt status of the current thread (the one executing the sentence). It returns the status before clearing it. When a thread that is waiting, sleeping or joining is interrupted by another thread, it wakes up and throws Interruptedexception. Note that the corresponding methods declare the checked Interruptedexception. Whenever a thread throws InterruptedException it clears its interrupt status. Thread.isInterrupted() returns the status but it does not clears it. So what is good for all of this? Concurrent Programming in Java by Dough Lea
interrupt() serves as a request that activities be cancelled...the intended convention is a protocol between cancellers and cancellees to ensure that objects between multiple threads do not become dameged when cancelled threads terminate...But there is nothing about interrupt that forces inmediate termination.
This "protocol" is that if thread A wants thread B to terminate it interrupts it. Thread B must check its interrupt status "periodically". Normally is sufficient to check it whenever covenient or before long operations. Sometimes, you need to ponder if the lapse of time between an interrupt method call, that occured just after a check, and the time of the next check is acceptable for your application. Now suppose thread B has checked that has to terminate. The choices are: Continuation. Some threads are not intended to end. Even here it might be convenient to spawn a new one. Abrupt termination. Applies to threads that provide isolated services that do not require any clean up beyond that provided in a finally clause at the base of a run method. However if the threads are performing services for other threads it might be convenient to set a flag indicator. (Exceptions themselves are not propagated across threads.) Roll-back or Roll-forward techniques in threads that use objects also used by other threads. Hope it helps.