While we see that starting a thread is easy, stopping one is a
bit less straightforward. A thread stops in three ways:
- It returns smoothly from run().
- The thread's stop()
method is called. (Now deprecated.)
- Interrupted by an uncaught exception.
The first method is the best way. If the run()
method contains a long or endlessly running loop, a common way to
stop the looping is to have it on each pass check a variable that
can be changed by the main process. For example, it could be a boolean
value that is set to false or a reference variable that is set to
null
when we want the loop to finish.
In the code snippet below, the fMyThread
variable is set to null
in the applet's stop()
method and this will then cause the thread process to jump out of
the loop in run().
public
class MyApplet extends java.awt.Applet implements Runnable
{
Thread fMyThread;
/** Initialize the applet. **/
public void init () {
...
}
/** Use the applet's start() method to create
and
* start the thread. **/
public void start () {
if (fMyThread != null) {
fMyThread.start();
} else
fMyThread = new
Thread (this)
}
/** Use the applet's stop() method to set the
thread variable
* to
null. As we see below in the run() method, this will cause
* the loop to finish. When the thread process
returns from the
* run() method, the thread dies and cannot
be resurrected.
**/
public void stop () {
fMyThread = null;
}
/** The run() method is the key method of a thread
process.**/
void run () {
// Use the fMyThread variable as a
flag to stop the loop.
while (fMyThread != null) {
... repetitive
task such as drawing animation frames...
}
// When loop finishes, returning from
run() kills the thread.
}
} // class MyApplet |
Do not use the Thread
class's stop()
method to kill a thread. The stop()
method has been deprecated. That is, it still exists in the
class definition but is officially marked as a method to be avoided.
The stop()
method causes the thread to cease what it is doing and to throw
a ThreadDeath
exception. This releases the lock so that other threads could now
come in and, for example, read a parameter whose calculation had
not been finished, resulting in an erroneous value.
This kind of error will be difficult to track down since the effect
may not be seen until the processing reaches another part of the
program. For single thread programs this is not a big worry but
it is best to get in the habit of properly stopping a thread.
Note, as we mentioned
previously for the Applet
class start()
method, the stop()
in the Applet
class has nothing to do with the stop()
in the Thread
class. The browser calls the applets stop method whenever the browser
replaces the applet page (just as init()
is called whenever the browser loads the page holding the applet.)
However, the applet's stop()
is a fine place to stop a thread along with other housecleaning
tasks before the applet is unloaded.
Always explicitly stop your threads in applets when the applet
stop() is
called. Otherwise, the threads may continue running even when the
browser loads a new web page.
Pause
Note that for the Runnable
case, you can start a new thread with the variable settings still
at the values they had at the point the previous thread stopped.
So in this case, stopping a thread and starting a new one acts just
like pause/start actions. (You can also do this with
a Thread
subclass if you can set the variables in the new thread to those
of the old one but this is less convenient.)
(The Thread
class suspend()
and resume()
methods were deprecated to avoid deadlock problems.)
Latest update: Nov. 5, 2004
|