• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Not Clear about Interrupt

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Kezia Matthews
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The usefulness of the interrupted() method is clear to me now.
Thanks Jim.
Kezia.
 
reply
    Bookmark Topic Watch Topic
  • New Topic