Starting a thread is easy Stopping a thread is harder

11.4.3.1 Starting a thread is easy

To create a thread, you must provide two things: something for the thread to do and a way for the thread to know when its done. These are usually done at the same time, within a single method known as the run method. The run method is either placed in a separate class that implements the Runnable interface, or is defined in a subclass of Thread . In the first case, the code to start a thread running simply looks like: Thread thread = new Threadnew MyRunnable ; thread.start ; and in the second case, the code to start the thread running looks like: Thread thread = new ThreadSubclass ; thread.start ; The first line in both of these cases creates and allocates the thread. The second actually starts the thread running.

11.4.3.2 Stopping a thread is harder

This thread will terminate in either of two cases: • You explicitly terminate the thread by calling the stop method on the instance of Thread that you created. • The run method exits. The first choice here, calling stop , is a rather drastic action. It causes the thread to immediately stop and throw an instance of ThreadDeath . ThreadDeath is a subclass of Error , but not of Exception , and hence, most of your code wont even try to catch it. [ 6] The stack will unwind, which means that all the locks the thread was holding will be released. However, a crucial point should be made: since ThreadDeath usually isnt caught, no finally blocks will be executed, and no cleanup code will run. This has the potential to be really nasty. Consider, for example, the following snippet of code: [ 6] An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.™the JavaDoc. public boolean updateDatabase { try { openConnection ; executeUpdate ; } catch SQLException databaseError { logDatabaseErrrordatabaseError; } finally { closeConnection ; always release database resources } } This is a simple method that tries to update a table in a database. Note that the SQL code has been abstracted out into submethods. Suppose this is running in a thread that gets stopped while in the middle of the executeUpdate method. There are two issues that can arise: • Were not sure what the status of the database is. Did the database get updated? Theres no way to know. • Were not going to ever enter that finally block and release the database connection. This may not be a significant resource drain in the client application, but it may be significant for the database server, especially if we have a database license that allows only a limited number of concurrent connections. For these reasons, Javasoft deprecated stop in JDK1.1 and instead recommended that people use a boolean flag inside their implementation of run . Here, for example, is a simple schema for subclassing Thread : public abstract class StoppableThread extends Thread { ... many constructors, weve only included one public StopppableThreadString threadName, Object arg1, OObject arg2 { superthreadName; use arg1, arg2, ... to initialize thread state start ; } private boolean _shouldStopExecuting; public void setShouldStopExecutingboolean shouldStopExecuting { _shouldStopExecuting = shouldStopExecuting; } public boolean getShouldStopExecuting { return _shouldStopExecuting; } public void run { while _shouldStopExecuting { performTask ; } } protected abstract void performTask ; } This defines an abstract method, performTask , and puts it inside a potentially infinite loop. As long as the instances setShouldStopExecuting method isnt called with a value of true , the loop will continue, and performTask will be executed repeatedly.

11.4.3.3 Using Runnable instead of subclassing Thread