File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Not Clear about Interrupt Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Not Clear about Interrupt" Watch "Not Clear about Interrupt" New topic
Author

Not Clear about Interrupt

Dan Temple
Ranch Hand

Joined: Jul 10, 2001
Posts: 93
I was hoping someone could clear something up for me. I am still not entirely sure what the interrupt method of Thread DOES. I have read that it should be used to replace the deprecated stop() method. So that makes it seem like the interrupt kills another thread. But then I also have read that a Sleeping Thread that recieves an interrupt() call moves immediately into the Ready state; when it gets to run it will execute its InterruptedException handler. So this makes it seem like it actually awakes the thread rather than kills it. What am I missing here? What happens to the thread after it handles the InterruptedException? Does it continue to execute?
Thanks in advance
Dan
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
The thread continues to execute - with stop() as well as with interrupt().
The stop() method throws an unchecked ThreadDeath error. This error is processed the way any other throwable is processed - finally clauses get executed, etc, and the thread could conceivably even catch ThreadDeath and continue executing. It would be bad manners, but it could.
The interrupt() method, first and foremost, sets the interrupted flag (see Thread.interrupted()). In addition, if the thread is sleep()ing, it is moved into the ready to run state immediately. Thread.sleep() will clear the flag and throw an InterruptedException as soon as it starts running. If, on the other hand, the thread is wait()ing, it is moved into the waiting for lock state; as soon as it has acquired the lock and starts running, Object.wait() will clear the flag and throw an InterruptedException.
In general, you should write your code so that either a ThreadDeath or an InterruptedException causes the thread of execution to leave the run() method; that, and no earlier, is the moment the thread terminates. If there be any lengthy computations, the Thread.interrupted() flag should be checked regularly. One way of handling it would be to throw your own InterruptedException if the flag is set.
- Peter

[This message has been edited by Peter den Haan (edited August 25, 2001).]
Kezia Matthews
Ranch Hand

Joined: May 19, 2001
Posts: 107
Hi Peter,
I am a beginner to "Threads". Summarizing my understanding on the sleep() and the wait() methods,
Thread.sleep() method puts the currently executing thread to sleep. After the specified time, this thread throws InterruptedException; which causes this thread to move to the ready-to-run state.
wait() makes the currently executing thread to transit to the waiting state, till another thread calls the notify() method; When a thread gets notified, it throws the InterruptedException, and the thread moves to the lock pool to acquire the lock on the object.
I am not sure whether my concepts about sleep() and wait() methods are correct. Please correct me if I am wrong.
(i) Is there a need to call the interrupt() and interrupted() methods in this scenario?(ii) In case the above mentioned methods need to be called; where should we place these calls?
(iii) If these methods are not called by the programmer, would JVM call them?
Kezia.

[This message has been edited by Kezia Matthews (edited August 26, 2001).]
[This message has been edited by Kezia Matthews (edited August 27, 2001).]
Dan Temple
Ranch Hand

Joined: Jul 10, 2001
Posts: 93
Okay I think I understand. Its not that the InterruptedException kills the thread, but rather within catch InterruptedException, this is where the programmer should write code to ensure that that thread dies. Is this correct?
Dan
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Dan Temple:
Okay I think I understand. Its not that the InterruptedException kills the thread, but rather within catch InterruptedException, this is where the programmer should write code to ensure that that thread dies. Is this correct?

The thread dies when it leaves the run() method (of the Thread or the Runnable interface). When you want an interrupt to kill your thread, you'll have to make sure that an InterruptedException causes the thread to exit the run() method.
The easy way of doing this is to catch the InterruptedException only at the very highest level:

- Peter
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Thread.sleep() method puts the currently executing thread to sleep. After the specified time, this thread throws InterruptedException
After the specified time, the thread wakes up again. InterruptedException is thrown only if the thread is interrupted before the sleep time has expired.
wait() makes the currently executing thread to transit to the waiting state, till another thread calls the notify() method; When a thread gets notified, it throws the InterruptedException
Again, InterruptedException is not thrown normally.
- Peter
Xavier Casals
Greenhorn

Joined: Aug 16, 2001
Posts: 4
So, the ONLY way to exit a thread is exiting its run method?
What happens if it is not possible. For example, if we have a blocking call in the highest level (and the only exceptions that can be caught are the ones thrown by it).

Any suggestions?
Kezia Matthews
Ranch Hand

Joined: May 19, 2001
Posts: 107
Thanks Peter for correcting me.
Here is a piece of code. I am not able to understand as to why the 'interrupted()' method returns 'false' in the handler for 'InterruptedException'.

The output of the above code is
In run
Exception handler for sleep
interrupted() is false
Awake
When does the call to interrupted() return 'true'?
Kezia.
[This message has been edited by Kezia Matthews (edited August 28, 2001).]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Xavier Casals:
So, the ONLY way to exit a thread is exiting its run method?
What happens if it is not possible. For example, if we have a blocking call in the highest level (and the only exceptions that can be caught are the ones thrown by it).

Well known problem - you're basically stuffed A common "fix" used with socket communications is to close() the socket from another thread. This is crude and undocumented but it works.
For a taste of things to come, look in the JDK 1.4 beta, java.nio.*.
- Peter
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Kezia Matthews:
Here is a piece of code. I am not able to understand as to why the 'interrupted()' method returns 'false' in the handler for 'InterruptedException'.

When an InterruptedException is thrown, the interrupt flag is cleared. Just imagine that sleep() contains effectively the following code:Remember that Thread.interrupted() clears the interrupt flag as a side effect.
- Peter

Kezia Matthews
Ranch Hand

Joined: May 19, 2001
Posts: 107
Peter,
Does this mean that, there never arises a situation when a Java programmer needs to check the condition whether the interrupted() method returned 'true' or 'false'? If this is true, then why is this function provided?
Thanks.
Kezia.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
An InterruptedException is only thrown if the thread was in a wait() or sleep() at the time it was interrupted. (Or if you code a "throw new InterruptException()", but that's a different story...) What happens if the thread is doing something else when it's interrupted? Like say, performing lengthy calculations? No InterruptedException is thrown in this case - instead, it's up to the programmer to write the code so that it periodically checks the interrupted() method, and exits the run() method if an interrupt has occurred. The purpose of handling interrupts this way is that it allows programs to exit gracefully from interrupts - they get a chance to choose when and how to respond to the interrupt, so they can perform necesssary cleanup before exiting. The down side is that the programmer must assume the responsibility of checking the interruped() status periodically, or the usefulness of the interrupt() method is lost.


"I'm not back." - Bill Harding, Twister
Kezia Matthews
Ranch Hand

Joined: May 19, 2001
Posts: 107

The usefulness of the interrupted() method is clear to me now.
Thanks Jim.
Kezia.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Not Clear about Interrupt