Chapter 5: Stopping a Thread

When you want a thread to terminate or stop based on some condition, you have several approaches available. For ex, you may want to terminate a thread because it has completed the intended operation or because the user clicked the exit button. Though there are many approaches to do it, we are going to take a look at the two most common ways of doing it.

1. Setting a Flag

The most common way of stopping a thread is to set some internal flag to signal that the thread should stop. The thread can then periodically query that flag to determine if it should exit.
Lets look at a sample code that follows this approach

...
public class Test extends Thread {
...
private volatile boolean done = false;
...
public void run( ) {
while (!done) {
...
}
}
public void setDone( ) {
done = true;
}
}


Here we've created the boolean flag done to signal the thread that it should quit. Now instead of looping forever, the run() method examines the state of that variable on every loop and returns when the done flag has been set. That terminates the thread.
The important point to note here is that, this boolean variable must be set appropriately by some part of your code otherwise you will be stuck with a thread that doesn't know when to stop.

For example, we can add this logic of modifying this boolean variable when the user clicks on the “Exit” button.

Trivia:
This raises an interesting question: is it better to create a new thread like this, or would it be better somehow to suspend the existing thread and resume it when we're ready? Of course, we don't yet have the tools necessary to program the suspension and resumption of the thread, so that's the reason we've done it this way. It would be more natural simply to suspend and resume the thread. Don't worry just yet. We will cover that very soon.

2. Interrupting a Thread

The previous method of setting a flag has a simple drawback. Lets say you have a method that updates this boolean flag. But, if you thread started the loop iteration before the flag was updated, it will have to finish the iteration and then it will check the boolean flag during the next iteration.

This may sound to be not too dangerous but imagine this:

Lets say, inside your loop, you are going to wait for user input through the command prompt. Since the user clicked Exit, he thinks the program is over whereas the program is waiting for him to type something. The user isn’t going to input anything and your thread isn’t going to die because they are both stuck.

Now do you understand why the previous method wasn't the best possible way to stop a thread?
When you arrange for a thread to terminate, you often want it to complete its blocking method immediately: you don't want to wait for the data (or whatever be the case) anymore because the thread is going to exit anyway. You can use the interrupt() method of the Thread class to interrupt any blocking method.

The interrupt() method has two effects. First, it causes any blocked method to throw an InterruptedException.

The second effect is to set a flag inside the thread object that indicates the thread has been interrupted. To query this flag, use the isInterrupted() method. That method returns true if the thread has been interrupted.

Here's how a thread uses this information to determine whether or not it should terminate:

public class TestAgain extends Thread {
...

public void run( ) {
while (!isInterrupted( )) {
...
}
}
}


This example is almost exactly the same as the one in which we use a done flag to signal that the thread should return. In this case, we use the interrupted flag instead. That means we no longer need the setDone() method. Instead of calling the setDone() method, the actionPerformed( ) method associated with the Exit button in our application now does this:

producer.interrupt( );

So, when the main thread executes this statement while our thread is sleeping, it gets the interrupted exception and immediately returns from the run() method.
Otherwise, when our thread goes for the next iteration of the loop, it sees that the interrupted flag has been set and returns from its run() method. Either ways, our thread completes its task and terminates.

Note that this technique does not completely eliminate the possibility of indefinite wait that we saw with the set flag technique but is better that technique. Such a situation is called a race condition and we shall be covering it in depth in future and learn how to program in such a way that our threads perform optimally.

Previous: Thread Lifecycle

Next: Determining the Current Thread

Chapter 58: Preventing Thread Execution

In the previous chapters we saw what a thread is and how to run or execute them. But, there is one more important thing that we need to know. Let me give a clue. Lets say you have multiple threads and you want one of your threads to finish before the others. It would definitely be sweet to alter the way our threads run and finish, wouldn't it? That is exactly what we are going to learn in this chapter.

Before we begin, I repeat something I said earlier.
WE CANNOT AND I MEAN CANNOT GUARANTEE THE WAY THREADS EXECUTE IN OUR PROGRAM.

We can only request the scheduler to run the threads the way we want but that by no means is guarantee. Think of the scheduler as your hard headed boss who ends up irritating you even if you try out of your way to please him. Though it's a bad analogy, that's exactly how the scheduler works. Stubborn and all by itself and not listening to anyone.

Lets get started!!!

Stopping a Thread from Executing

A thread that’s been stopped usually means a thread that’s moved to the dead state. But you should be able to recognize when a thread will get kicked out of running but not be sent back to either runnable or dead.

For the purpose of the exam, we aren’t concerned with a thread blocking on I/O (say, waiting for something to arrive from an input stream from the server). We are concerned with the following:
• Sleeping
• Waiting
• Blocked because it needs an object’s lock

Sleeping

The sleep() method is a static method of class Thread. You use it in your code to “slow a thread down” by forcing it to go into a sleep mode before coming back to runnable. When a thread sleeps, it drifts off somewhere and doesn’t return to runnable until it wakes up.

So why would you want a thread to sleep? Well, you might think the thread is moving too quickly through its code. Or you might need to force your threads to take turns, since reasonable turn-taking isn’t guaranteed in the Java specification.

You do this by invoking the static Thread.sleep() method, giving it a time in milliseconds as follows:
try {
Thread.sleep(5*1000); // Sleep for 5 seconds
} catch (InterruptedException ex) { }

Notice that the sleep() method can throw a checked InterruptedException (you’ll usually know if that is a possibility, since another thread has to explicitly do the interrupting), so you must acknowledge the exception with a handle or declare. Typically, you wrap calls to sleep() in a try/catch, as in the preceding code.

Let’s modify our Rocky, Cena, Triple H code by using sleep() to try to force the threads to alternate rather than letting one thread dominate for any period of time. Where do you think the sleep() method should go?

class NameRunnable implements Runnable {

public void run() {

for (int x = 1; x < 4; x++) {

System.out.println("Run by "

+ Thread.currentThread().getName());

try {

Thread.sleep(1000);

} catch (InterruptedException ex) { }

}

}

}


public class SleepExample {

public static void main (String [] args) {


// Make one Runnable

NameRunnable nr = new NameRunnable();


Thread one = new Thread(nr);

one.setName("Rocky");

Thread two = new Thread(nr);

two.setName("Cena");

Thread three = new Thread(nr);

three.setName("Triple H");


one.start();

two.start();

three.start();

}

}

Running this code shows Rocky, Cena, and Triple H alternating nicely:

% java SleepExample

Run by Rocky

Run by Cena

Run by Triple H

Run by Rocky

Run by Cena

Run by Triple H

Run by Rocky

Run by Cena

Run by Triple H


Just keep in mind that the behavior in the preceding output is still not guaranteed. You can’t be certain how long a thread will actually run before it gets put to sleep, so you can’t know with certainty that only one of the three threads will be in the runnable state when the running thread goes to sleep. In other words, if there are two threads awake and in the runnable pool, you can’t know with certainty that the least recently used thread will be the one selected to run. Still, using sleep() is the best way to help all threads get a chance to run! Or at least to guarantee that one thread doesn’t get in and stay until it’s done. When a thread encounters a sleep call, it must go to sleep for at least the specified number of milliseconds (unless it is interrupted before its wake-up time, in which case it immediately throws the InterruptedException).

Exam Tip: Just because a thread’s sleep() expires, and it wakes up, does not mean it will return to running! Remember, when a thread wakes up, it simply goes back to the runnable state. So the time specified in sleep() is the minimum duration in which the thread won’t run, but it is not the exact duration in which the thread won’t run. So you can’t, for example, rely on the sleep() method to give you a perfectly accurate timer. Although in many applications using sleep() as a timer is certainly good enough, you must know that a sleep() time is not a guarantee that the thread will start running again as soon as the time expires and the thread wakes

Remember that sleep() is a static method, so don’t be fooled into thinking that one thread can put another thread to sleep. You can put sleep() code anywhere, since all code is being run by some thread. When the executing code (meaning the currently running thread’s code) hits a sleep() call, it puts the currently running thread to sleep.

Previous Chapter: Chapter 57 - Thread States & Transitions

Next Chapter: Chapter 59 - Thread Priorities, yield and join