InterruptedException

[mohammed usman]

Hi,
I got a small doubt.
Does a thread stops its execution because of InterruptedException.
I will be happy if some one clear this doubt.
thanks in advance
usman

[Ajith Kallambella]

Mohammad,
I wrote a small program to demonstrates how InterruptedException affects a thread. Since the program is self-documented, I don't want to deliberate too much on the details.
Just remember that when a running thread is interrupted, the catch/finally part of the exception handler is excecuted. Then the thread goes to the ready state again. When it gets picked up by the scheduler, the execution will resumefrom the point where it had stopped.
You can observe this happening when you run the following program. After the InterruptedException is caught, the Tick counter will continue from where it had stopped instead of starting from zero again.

// Demonstrates how a running thread is restarted after
// the InterruptedException is caught.
class InterruptDemo extends Thread
{
    // Run a loop for 25 times, each time sleeping for a
    // second. Note that after the InterruptedException is
    // caught, the thread restarts.
    public void run()
    {
        int Counter = 0 ;
        System.out.println( "Running....");
        for ( ;Counter < 25;  ) 
        {
             System.out.println("Tick.." + Counter++);
             try  {
                 sleep( 1000 );    
             }
             catch( InterruptedException ex )   {
               System.out.println( "Caught InterruptedException");    
             }
        }
    }
    
    public static void main( String[] s)
    {
        InterruptDemo  myThread = new InterruptDemo();
        
        // Start the thread.
        myThread.start();
        
        // Allow the new thread to run.
        Thread.yield();
        
        // Just a dummy loop so that we can let the counter
        // thread run for a while.
        for ( int i = 0 ; i < Integer.MAX_VALUE ; i++);
        
        // Try to interrupt the running thread.
        myThread.interrupt();        
        
        // Tracer to ensure the control comes back here 
        System.out.println("Back in main method");
    }
}

Here is the sample out on my machine. The results will be consistent, though the Tick at which the execution resumes might differ based on the processor.

Running.....
Tick..0
Tick..1
Tick..2
Tick..3
Tick..4
Tick..5
Tick..6
Tick..7
Tick..8
Tick..9
Tick..10
Tick..11
Caught InterruptedException
Tick..12
Back in main method
Tick..13
Tick..14
Tick..15
Tick..16
Tick..17
Tick..18
Tick..19
Tick..20
Tick..21
Tick..22
Tick..23
Tick..24
Tick..25

Hope this gives you something to start with.
Ajith

[This message has been edited by Ajith Kallambella (edited July 26, 2000).]

[Anonymous]

When you say that the interrupted thread picks up where it left off, isn't that really just due to how you structure your try/catch block? Since your try/catch block is within your for loop, the next statement after the catch is the for loop test condition.
In other words, what you're seeing in this code is normal exception (try/catch) behavoir and nothing really specific to threads other than the fact that you're calling a thread-related exception.
Let me know if I'm missing something.

[Praveen Zala]

Hi Ajith,
I tried the code u have given for InterruptDemo !
Believe me, all the time the execution goes thru
successfully and there is no exception...........
Wonder why this happens ???
It meekly prints Back to Main.... at the end of its
execution.
Can u please highlight more on the behaviour of your
code or threads in general ??
Praveen Zala

[rajsim]

Ajith's program shows that Thread doesn't stop because of
InterruptedException. It is the opposite. If the thread
is sleeping or waiting, InterruptedException causes the
thread to move to ready-to-run and then running states.
However, if the exception is not caught, the thread will
die as usual with other exceptions.

[Ajith Kallambella]

Dab,
Actually when the interrupted thread becomes ready for running, if there are any other threads waiting to be run, they might get picked up. And after running the pending threads, the execution of the interrupted thread will start.
Here is the modified code where I am starting another thread. The ticker thread which blocks other threads is interrupted after starting another thread. Note that though the InterruptedException is caught, the Ticker thread will not start running immediately. The scheduler picks up the "Bing"er thread. After Binger completes, the Ticker will resume its execution with Ticks running from where had stopped.

// Demonstrates how a running thread is restarted after
// the InterruptedException is caught.
class AnotherThread extends Thread
{
    public void run()
    {
        System.out.println("Running the other thread...");    
        for ( int i = 0 ; i < 4 ; i ++ )
            System.out.println( "Bing...");
        System.out.println("Finished running the other thread...");    
    }
}
class InterruptDemo extends Thread
{
    // Run a loop for 25 times, each time sleeping for a
    // second. Note that after the InterruptedException is
    // caught, the thread restarts.
    public void run()
    {
        int Counter = 0 ;
        System.out.println( "Running....");
        for ( ;Counter < 25;  ) 
        {
             System.out.println("Tick.." + Counter++);
             try  {
                 sleep( 1000 );    
             }
             catch( InterruptedException ex )   {
               System.out.println( "Caught InterruptedException");    
             }
        }
    }
    
    public static void main( String[] s)
    {
        InterruptDemo  myThread = new InterruptDemo();
        
        // Just the priority of the Ticker thread to 10 so that
        // it starts running first.
        myThread.setPriority(10);
        
        
        AnotherThread th = new AnotherThread();
        
        // Start the Ticker thread.
        myThread.start();
        // Allow the Ticker thread to run.
        Thread.yield();
        
        // Just a dummy loop so that we can let the Ticker
        // thread run for a while.
        for ( int i = 0 ; i < Integer.MAX_VALUE ; i++);
        
        // Now start the Binger thread. Since the Ticker
        // thread is blocking all other threads, this will
        // not run immediately.
        th.start();
        // Try to interrupt the Ticker running thread.
        System.out.println("Now interrupting the Tick thread");
        myThread.interrupt();        
        
        // ..Scheduler picks up the Binger thread here!!
        
        
        // Tracer to ensure the control comes back here 
        System.out.println("Back in main method");
    }
}

Again, here is the output dump produced on my machine. As noted earlier, actual results may vary, but the behaviour should be consistent.

Running....
Tick..0
Tick..1
Tick..2
Tick..3
Tick..4
Tick..5
Tick..6
Tick..7
Tick..8
Tick..9
Tick..10
Tick..11
Tick..12
Tick..13
Now interrupting the Tick thread
Caught InterruptedException
Tick..14
Back in main method
Running the other thread...
Bing...
Bing...
Bing...
Finished running the other thread...
Tick..15
Tick..16
Tick..17
Tick..18
Tick..19
Tick..20
Tick..21
Tick..22
Tick..23
Tick..24

Praveen - perhaps you are running a faster machine than I am. Try increasing the loop count of the ticker and/or replicate the dummy loop in the main method. The intention here is to let the ticker run for a while before it gets interrupted so that we can observe the consecutive Ticks. Otherwise the ticker will always stop at 0 and the "Back in main method" always appears at the last.
Hope this helps,
Ajith
[This message has been edited by Ajith Kallambella (edited July 26, 2000).]

[Marcela Blei]

Ajith: I can�t understand two lines of code from your program, could you explain this to me?
First:

// Allow the Ticker thread to run.
Thread.yield();
Why do you do this? Up to now I thought the yield method isn�t necessarily in this case. This has a relation between daemon and no daemon threads?


// Just a dummy loop so that we can let the Ticker
// thread run for a while.
for ( int i = 0 ; i < Integer.MAX_VALUE ; i++);

Could you explain me how this works? I am a bit confused...
Thanks Ajith, no more doubts.

[Ajith Kallambella]

Marcela,
I would really like you to try my code commenting one or both of these two lines. See what happens. I can surely explain why they are there, but I feel you will understand it much better if you "experience" it.
Ofcourse, you can always come back here if you get thrown overboard.
Goodluck,
Ajith

[Marcela Blei]

Ajith: I tried it now, sorry I didn�t tried it first to my reply. Now I understand the for loop but when I commented the yield line, program behavior doesn�t changed. Could it be that you put the yield because the first thread has a higher priority that the second one, and that how the JVM attends the priority order is system dependent so, putting yield you enssure that the second thread �ll start in the middle of the execution of the first one?
Thanks for your reply and for the code you made, it is a large job...
[This message has been edited by Marcela Blei (edited July 26, 2000).]

[Ajith Kallambella]

Marcela,
Yes. You are absolutely right.
The yield was to make sure the Ticker thread started immediately instead of allowing the execution of main thread to continue. And I put the for loop so that the Ticker thread runs for a while and we don't interrupt it immediately after it gets started( Ticker = 0 ). This also helps prove another important concept - "interrupt() is a better way of stopping a selfish thread than stop()".
Perhaps one can do without the for loop, but it is mostly going to be machine dependent. Since I was focussing more on establishing a consistent behavioural pattern, I didn't pay much attention to redundancies like this
Ajith

[This message has been edited by Ajith Kallambella (edited July 26, 2000).]

[Anonymous]

Hi Ajith,
I too tried the same code. Very nice code to learn.
So what you meant to say is you want the main thread to be on ready stage and the mythread to be on running stage. For that you used both yield() ans for loop but either one is ok. I tried the same code just commenting the for loop and leving with yield, the main thread started just after Tick 0. Next time commented both yield and for loop and tried got the same result.
Is it b'cas of scheduler.

[Ajith Kallambella]

If you omit the for loop and just retain the yield call, the Ticker thread gets preempted at the first loop( Tick = 0 ) and then the main thread resumes. This happens because all the three threads( the main thread, the Ticker thread and the Binger thread ) are of the same priority. I wanted the main thread to go to the pending pool and hence I bumped up the priority of the Ticker thread in the second code snippet that I posted.
Now, as Marcela pointed out, in the scenario where the Ticker thread is running with a higher priority, just the call to yield will do the job. Again, we have the dominant variable here which is the platform-dependent thread scheduler. Hence different people are experiencing different outputs with or without these statements.
( see how well I convince you )
Ajith

[Anonymous]

Hi Ajith,
Thanks for your time. Actually I just had an idea about the interrupt method. Today got a chance to experience it. Now I got an inspiration to try some more code like this.
Could you pls. explain for me about the Deamon thread (which is another thread out there)

[Vivek Shrivastava]

Hi ajith,
After running your excellent program I got impression about interrupt() function that it doesn�t always stop a running thread. The thread could catch the exception and continue running. Is that true? If it is true then what should I do in case:
Which may cause a running thread to stop the execution?
1. sleep
2. intrrupt()
Should I pick option '2' or not in exam?
Your help would be appreciated!
vivek

[Ajith Kallambella]

Vivek,
Yes, you should probably pick (2) ie., interrupt().
Remember, interrupt stops the execution of the thread. Though the word "stop" may not be very appropriate to use here since the thread will eventually continue to run, if there are other threads waiting to run, the scheduler can use this opportunity to run them.
In case of the sleep(), the thread is still running and hence if it is a selfish thread, there is no chance for the other threads to run. For the scheduler, a sleeping thread is as good as the running thread!!
Hope this helps,
Ajith

[Vivek Shrivastava]

Hi ajith,
I am really getting confuse with word "stop". what does it exactly mean for the exam point of view? because what i think is that all the following action will cause a thread to stop the execution?
1. sleep()
2. stop()
3. suspend()
4. yield()
5. interrupt()
5. method like waitforID() or waitforData()
6. blocked for io
7. thread with hiegher priority
8. wait()
9. when there is no user thread exists any more
am i missing something here?
ajith i know u can help me. your help would be appreciated.
vivek
[This message has been edited by Vivek Shrivastava (edited July 26, 2000).]
[This message has been edited by Vivek Shrivastava (edited July 26, 2000).]

[Ajith Kallambella]

Vivek,
I can understand the cause of confusion here( belive me it happened to me too! ).
"Stop" can means -
* Thread has done its job, and so is "dead"
* Thread has been moved from the running stage and is no longer
using the CPU
* The scheduler can use this opportunity to run any pending
threads( provided the scheduling policy permits that )
"Blocked" means thread is still running( using CPU ), but it
is not actively executing any code. The thread is waiting
for something to happen, probably a resource handle or a return
status from a method call. If the running thread is blocked, the
scheduler cannot pull it out and let other threads run.

Now if we look at your list, the following can stop a running
thread( either temporarily or permanently )
* suspend- temporary
* yield - temporary
* interrupt - temporary
* stop- permanent
* Normal completion of the thread.- permanent
* thread with higher priority( if the scheduler honors priority ) - temporary
* wait- temporary

The ones that block the execution
* method like waitforID() or waitforData()
* blocked for io

I have tried to answer your question. However, due to subtle differences in how these terms are interpreted, one can always contest my explanations. If that happens, I will be more than happy to elaborate more on such confusing issues.
Ajith

[Ajith Kallambella]

Here is a state diagram( pardon the mess ) which hopefully will clarify the things.

  [NEW]------start-----> [RUNNABLE]--------done----->[DEAD]

  [        ]                         [       ]
  [RUNNABLE]-------->sleep---------->[BLOCKED]
  [        ]<------done sleeping-----[       ]
  [        ]                           [       ]
  [RUNNABLE]-------->suspend---------->[BLOCKED]
  [        ]<--------resume------------[       ]

  [        ]                         [       ]
  [RUNNABLE]-------->wait----------->[BLOCKED]
  [        ]<------notify------------[       ]
  [        ]                         [       ]
  [RUNNABLE]-------->i/o------------>[BLOCKED]
  [        ]<--------i/o complete----[       ]

Ajith
[This message has been edited by Ajith Kallambella (edited July 26, 2000).]

[Kourosh Keshavarzi]

I've learned a lot reading this post but I don't fully understand the output.
1. My first question is regarding the first code you submitted:
When you call myThread.interrupt(), shoudn't the output
have been :

Tick..11
Caught InterruptedException
Back in main Method
Tick..12
why is it that in your output you got Tick..12 before
writing back in main . The interrupt was suppose to stop
the thread and totaly let main take over right?
2. My second question is simmilar:
Its regarding the second piece of code you submitted.
When you have Thread.yield();
That stops the main method and give control to the higher
priority thread myThread. Nothing should happend till that
higher priority thread is compeletly finished.
So the line after Thread.yield in the main method should not
happen until myThread (higher priority) has completely
finished. How can the program even get to
myThread.interrupt when thats command is comming from a
lower priority thread.
Thanks in advance

[Kourosh Keshavarzi]

Just thought I'd bring this up again?

[girish hegde]

hey ajit,
which system are you working on.
on a windows system it does not make much of a difference wheather you put Thread.yeild() or not because it is time sliced.
if you are working on a pre-emptive system then it might make a difference.
In windows Thread.sleep(1000) acts as though for 1000ms the thread has stopped and allows other threads to run.

[Ajith Kallambella]

When you interrupt a thread, it may not stop immediately. The JVM sets an internal flag to indicate the thread has been interrupted and eventually the thread stops running.( Take a look at <code>Thread.interrupted()</code> method. ) That's why the Tick 12 appears and then the control comes back to main method.
Again, the behaviour depends largely on the scheduler.
girish, <code>sleep()</code> puts the running thread to sleep. It is not equivalent to the <code>yield()</code> method where the thread allows other threads to run. When a thread sleeps, it is still in the "running pool of threads" and waiting threads continue to wait!
Ajith