Multiple threads

Objects provide a way to divide a program up into independent sections. Often, you also need to turn a program into separate, independently-running subtasks.

Each of these independent subtasks is called a thread, and you program as if each thread runs by itself and has the CPU to itself. Some underlying mechanism is actually dividing up the CPU time for you, but in general, you don't have to think about it, which makes programming with multiple threads a much easier task.

Some definitions are useful at this point. A process is a self-contained running program with its own address space. A multitasking operating system is capable of running more than one process (program) at a time, while making it look like each one is chugging along by periodically providing CPU cycles to each process. A thread is a single sequential flow of control within a process. A single process can thus have multiple concurrently executing threads.

There are many possible uses for multithreading, but in general, you'll have some part of your program tied to a particular event or resource, and you don't want to hang up the rest of your program because of that. So you create a thread associated with that event or resource and let it run independently of the main program. A good example is a "quit" button - you don't want to be forced to poll the quit button in every piece of code you write in your program and yet you want the quit button to be responsive, as if you were checking it regularly. In fact, one of the most immediately compelling reasons for multithreading is to produce a responsive user interface.

Responsive user interfaces

As a starting point, consider a program that performs some CPU-intensive operation and thus ends up ignoring user input and being unresponsive. This one, a combined applet/application, will simply display the result of a running counter:

At this point, the AWT and applet code should be reasonably familiar from Chapter 13. The go( ) method is where the program stays busy: it puts the current value of count into the TextField t, then increments count.

Part of the infinite loop inside go( ) is to call sleep( ). sleep( ) must be associated with a Thread object, and it turns out that every application has some thread associated with it. (Indeed, Java is based on threads and there are always some running along with your application.) So regardless of whether you're explicitly using threads, you can produce the current thread used by your program with Thread. currentThread() (a static method of the Thread class) and then call sleep( ) for that thread.

Note that sleep( ) can throw InterruptedException, although throwing such an exception is considered a hostile way to break from a thread and should be discouraged. (Once again, exceptions are for exceptional conditions, not normal flow of control.) Interrupting a sleeping thread is included to support a future language feature.

When the start button is pressed, go( ) is invoked. And upon examining go( ), you might naively think (as I did) that it should allow multithreading because it goes to sleep. That is, while the method is asleep, it seems like the CPU could be busy monitoring other button presses. But it turns out that the real problem is that go( ) never returns, since it's in an infinite loop, and this means that actionPerformed( ) never returns. Since you're stuck inside actionPerformed( ) for the first keypress, the program can't handle any other events. (To get out, you must somehow kill the process; the easiest way to do this is to press Control-C in the console window.)

The basic problem here is that go( ) needs to continue performing its operations, and at the same time it needs to return so actionPerformed( ) can complete and the user interface can continue responding to the user. But in a conventional method like go( ) it cannot continue and at the same time return control to the rest of the program. This sounds like an impossible thing to accomplish, as if the CPU must be in two places at once, but this is precisely the illusion that threading provides. The thread model (and programming support in Java) is a programming convenience to simplify juggling several operations at the same time within a single program. With threads, the CPU will pop around and give each thread some of its time. Each thread has the consciousness of constantly having the CPU to itself, but the CPU's time is actually sliced between all the threads.

Threading reduces computing efficiency somewhat, but the net improvement in program design, resource balancing, and user convenience is often quite valuable. Of course, if you have more than one CPU, then the operating system can dedicate each CPU to a set of threads or even a single thread and the whole program can run much faster. Multitasking and multithreading tend to be the most reasonable ways to utilize multiprocessor systems.

Inheriting from Thread

The simplest way to create a thread is to inherit from class Thread, which has all the wiring necessary to create and run threads. The most important method for Thread is run( ), which you must override to make the thread do your bidding. Thus, run( ) is the code that will be executed "simultaneously" with the other threads in a program.

The following example creates any number of threads that it keeps track of by assigning each thread a unique number, generated with a static variable. The Thread's run( ) method is overridden to count down each time it passes through its loop and to finish when the count is zero (at the point when run( ) returns, the thread is terminated).

A run( ) method virtually always has some kind of loop that continues until the thread is no longer necessary, so you must establish the condition on which to break out of this loop (or, in the case above, simply return from run( )). Often, run( ) is cast in the form of an infinite loop, which means that, barring some external call to stop( ) or destroy( ) for that thread, it will run forever (until the program completes).

In main( ) you can see a number of threads being created and run. The special method that comes with the Thread class is start( ), which performs special initialization for the thread and then calls run( ). So the steps are: the constructor is called to build the object, then start( ) configures the thread and calls run( ). If you don't call start( ) (which you can do in the constructor, if that's appropriate) the thread will never be started.

The output for one run of this program (it will be different every time) is:

You'll notice that nowhere in this example is sleep( ) called, and yet the output indicates that each thread gets a portion of the CPU's time in which to execute. This shows that sleep( ), while it relies on the existence of a thread in order to execute, is not involved with either enabling or disabling threading. It's simply another method.

You can also see that the threads are not run in the order that they're created. In fact, the order that the CPU attends to an existing set of threads is indeterminate, unless you go in and adjust the priorities using Thread's setPriority( ) method.

When main( ) creates the Thread objects it isn't capturing the handles for any of them. An ordinary object would be fair game for garbage collection, but not a Thread. Each Thread "registers" itself so there is actually a reference to it someplace and the garbage collector can't clean it up.

Threading for a responsive interface

Now it's possible to solve the problem in Counter1.java with a thread. The trick is to place the subtask - that is, the loop that's inside go( ) - inside the run( ) method of a thread. When the user presses the start button, the thread is started, but then the creation of the thread completes, so even though the thread is running, the main job of the program (watching for and responding to user-interface events) can continue. Here's the solution:

Counter2 is now a straightforward program, whose job is only to set up and maintain the user interface. But now, when the user presses the start button, a method is not called. Instead a thread of class SeparateSubTask is created (the constructor starts it, in this case), and then the Counter2 event loop continues. Note that the handle to the SeparateSubTask is stored so that when you press the onOff button it can toggle the runFlag inside the SeparateSubTask object. That thread (when it looks at the flag) can then start and stop itself. (This could also have been accomplished by making SeparateSubTask an inner class.)

The class SeparateSubTask is a simple extension of Thread with a constructor (that stores the Counter2 handle and then runs the thread by calling start( )) and a run( ) that essentially contains the code from inside go( ) in Counter1.java. Because SeparateSubTask knows that it holds a handle to a Counter2, it can reach in and access Counter2's TextField when it needs to.

When you press the onOff button, you'll see a virtually instant response. Of course, the response isn't really instant, not like that of a system that's driven by interrupts. The counter stops only when the thread has the CPU and notices that the flag has changed.

Improving the code with an inner class

As an aside, look at the coupling that occurs between the SeparateSubTask and Counter2 classes. The SeparateSubTask is intimately tied to Counter2 - it must keep a handle to its "parent" Counter2 object so it can call back and manipulate it. And yet the two classes shouldn't really merge together into a single class (although in the next section you'll see that Java provides a way to combine them) because they're doing separate things and are created at different times. They are tightly connected (what I call a "couplet") and this makes the coding awkward. This is a situation in which an inner class can improve the code significantly:

This SeparateSubTask name will not collide with the SeparateSubTask in the previous example even though they're in the same directory, since it's hidden as an inner class. You can also see that the inner class is private, which means that its fields and methods can be given default access (except for run( ), which must be public since it is public in the base class). The private inner class is not accessible to anyone but Counter2i, and since the two classes are tightly coupled it's convenient to loosen the access restrictions between them. In SeparateSubTask you can see that the invertFlag( ) method has been removed since Counter2i can now directly access runFlag.

Also, notice that SeparateSubTask's constructor has been simplified - now it only starts the thread. The handle to the Counter2i object is still being captured as in the previous version, but instead of doing it by hand and referencing the outer object by hand, the inner class mechanism takes care of it automatically. In run( ), you can see that t is simply accessed, as if it were a field of SeparateSubTask. The t field in the parent class can now be made private since SeparateSubTask can access it without getting any special permission - and it's always good to make fields "as private as possible" so they cannot be accidentally changed by forces outside your class.

Anytime you notice classes that appear to have high coupling with each other, consider the coding and maintenance improvements you might get by using inner classes.

Combining the thread
with the main class

In the example above you can see that the thread class is separate from the program's main class. This makes a lot of sense and is relatively easy to understand. There is, however, an alternate form that you will often see used that is not so clear but is usually more concise (which probably accounts for its popularity). This form combines the main program class with the thread class by making the main program class a thread. Since for a GUI program the main program class must be inherited from either Frame or Applet, an interface must be used to paste on the additional functionality. This interface is called Runnable, and it contains the same basic method that Thread does. In fact, Thread also implements Runnable, which specifies only that there be a run( ) method.

The use of the combined program/thread is not quite so obvious. When you start the program, you create an object that's Runnable, but you don't start the thread. This must be done explicitly. You can see this in the following program, which reproduces the functionality of Counter2:

Now the run( ) is inside the class, but it's still dormant after init( ) completes. When you press the start button, the thread is created (if it doesn't already exist) in the somewhat obscure expression:

When something has a Runnable interface, it simply means that it has a run( ) method, but there's nothing special about that - it doesn't produce any innate threading abilities, like those of a class inherited from Thread. So to produce a thread from a Runnable object, you must create a thread separately and hand it the Runnable object; there's a special constructor for this that takes a Runnable as its argument. You can then call start( ) for that thread:

This performs the usual initialization and then calls run( ).

The convenient aspect about the Runnable interface is that everything belongs to the same class. If you need to access something, you simply do it without going through a separate object. The penalty for this convenience is strict, though - you can have only a single thread running for that particular object (although you can create more objects of that type, or create other threads in different classes).

Note that the Runnable interface is not what imposes this restriction. It's the combination of Runnable and your main class that does it, since you can have only one object of your main class per application.

Making many threads

Consider the creation of many different threads. You can't do this with the previous example, so you must go back to having separate classes inherited from Thread to encapsulate the run( ). But this is a more general solution and easier to understand, so while the previous example shows a coding style you'll often see, I can't recommend it for most cases because it's just a little bit more confusing and less flexible.

The following example repeats the form of the examples above with counters and toggle buttons. But now all the information for a particular counter, including the button and text field, is inside its own object that is inherited from Thread. All the fields in Ticker are private, which means that the Ticker implementation can be changed at will, including the quantity and type of data components to acquire and display information. When a Ticker object is created, the constructor requires a handle to an AWT Container, which Ticker fills with its visual components. This way, if you change the visual components, the code that uses Ticker doesn't need to be modified.

Ticker contains not only its threading equipment but also the way to control and display the thread. You can create as many threads as you want without explicitly creating the windowing components.

In Counter4 there's an array of Ticker objects called s. For maximum flexibility, the size of this array is initialized by reaching out into the Web page using applet parameters. Here's what the size parameter looks like on the page, embedded inside the applet description:

The param, name, and value are all Web-page keywords. name is what you'll be referring to in your program, and value can be any string, not just something that resolves to a number.

You'll notice that the determination of the size of the array s is done inside init( ), and not as part of an inline definition of s. That is, you cannot say as part of the class definition (outside of any methods):

You can compile this, but you'll get a strange null-pointer exception at run time. It works fine if you move the getParameter( ) initialization inside of init( ). The applet framework performs the necessary startup to grab the parameters before entering init( ).

In addition, this code is set up to be either an applet or an application. When it's an application the size argument is extracted from the command line (or a default value is provided).

Once the size of the array is established, new Ticker objects are created; as part of the Ticker constructor the button and text field for each Ticker is added to the applet.

Pressing the start button means looping through the entire array of Tickers and calling start( ) for each one. Remember, start( ) performs necessary thread initialization and then calls run( ) for that thread.

The ToggleL listener simply inverts the flag in Ticker and when the associated thread next takes note it can react accordingly.

One value of this example is that it allows you to easily create large sets of independent subtasks and to monitor their behavior. In this case, you'll see that as the number of subtasks gets larger, your machine will probably show more divergence in the displayed numbers because of the way that the threads are served.

You can also experiment to discover how important the sleep(100) is inside Ticker.run( ). If you remove the sleep( ), things will work fine until you press a toggle button. Then that particular thread has a false runFlag and the run( ) is just tied up in a tight infinite loop, which appears difficult to break during multithreading, so the responsiveness and speed of the program really bogs down.

Daemon threads

A "daemon" thread is one that is supposed to provide a general service in the background as long as the program is running, but is not part of the essence of the program. Thus, when all of the non-daemon threads complete the program is terminated. Conversely, if there are any non-daemon threads still running the program doesn't terminate. (There is, for instance, a thread that runs main( ).)

You can find out if a thread is a daemon by calling isDaemon( ), and you can turn the daemonhood of a thread on and off with setDaemon( ). If a thread is a daemon, then any threads it creates will automatically be daemons.

The following example demonstrates daemon threads:

The Daemon thread sets its daemon flag to "true" and then spawns a bunch of other threads to show that they are also daemons. Then it goes into an infinite loop that calls yield( ) to give up control to the other processes. In an earlier version of this program, the infinite loops would increment int counters, but this seemed to bring the whole program to a stop. Using yield( ) makes the program quite peppy.

There's nothing to keep the program from terminating once main( ) finishes its job since there are nothing but daemon threads running. So that you can see the results of starting all the daemon threads, System.in is set up to read so the program waits for a carriage return before terminating. Without this you see only some of the results from the creation of the daemon threads. (Try replacing the readLine( ) code with sleep( ) calls of various lengths to see this behavior.)