Runnable revisited

Runnable revisited

Earlier in this chapter, I suggested that you think carefully before making an applet or main Frame as an implementation of Runnable. If you take that approach, you can make only one of those threads in your program. This limits your flexibility if you decide that you want to have more than one thread of that type.

Of course, if you must inherit from a class and you want to add threading behavior to the class, Runnable is the correct solution. The final example in this chapter exploits this by making a Runnable Canvas class that paints different colors on itself. This application is set up to take values from the command line to determine how big the grid of colors is and how long to sleep( ) between color changes. By playing with these values you'll discover some interesting and possibly inexplicable features of threads:

ColorBoxes is a typical application with a constructor that sets up the GUI. This constructor takes an argument of int grid to set up the GridLayout so that it has grid cells in each dimension. Then it adds the appropriate number of CBox objects to fill the grid, passing the pause value to each one. In main( ) you can see how pause and grid have default values that can be changed if you pass in command-line arguments.

CBox is where all the work takes place. This is inherited from Canvas and it implements the Runnable interface so each Canvas can also be a Thread. Remember that when you implement Runnable, you don't make a Thread object, just a class that has a run( ) method. Thus, you must explicitly create a Thread object and hand the Runnable object to the constructor, then call start( ) (this happens in the constructor). In CBox this thread is called t.

Notice the array colors, which is an enumeration of all the colors in class Color. This is used in newColor( ) to produce a randomly-selected color. The current cell color is cColor.

paint( ) is quite simple - it just sets the color to cColor and fills the entire canvas with that color.

In run( ), you see the infinite loop that sets the cColor to a new random color and then calls repaint( ) to show it. Then the thread goes to sleep( ) for the amount of time specified on the command line.

Precisely because this design is flexible and threading is tied to each Canvas element, you can experiment by making as many threads as you want. (In reality, there is a restriction imposed by the number of threads your JVM can comfortably handle.)

This program also makes an interesting benchmark, since it can show dramatic speed differences between one JVM implementation and another.

Too many threads

At some point, you'll find that ColorBoxes bogs down. On my machine, this occurred somewhere after a 10 x 10 grid. Why does this happen? You're naturally suspicious that the AWT might have something to do with it, so here's an example that tests that premise by making fewer threads. The code is reorganized so that a Vector implements Runnable and that Vector holds a number of color blocks and randomly chooses ones to update. Then a number of these Vector objects are created, depending roughly on the grid dimension you choose. As a result, you have far fewer threads than color blocks, so if there's a speedup we'll know it was because there were too many threads in the previous example:

In ColorBoxes2 an array of CBoxVector is created and initialized to hold grid CBoxVectors, each of which knows how long to sleep. An equal number of Cbox2 objects is then added to each CBoxVector, and each vector is told to go( ), which starts its thread.

CBox2 is similar to CBox: it paints itself with a randomly-chosen color. But that's all a CBox2 does. All of the threading has been moved into CBoxVector.

The CBoxVector could also have inherited Thread and had a member object of type Vector. That design has the advantage that the addElement( ) and elementAt( ) methods could then be given specific argument and return value types instead of generic Objects. (Their names could also be changed to something shorter.) However, the design used here seemed at first glance to require less code. In addition, it automatically retains all the other behaviors of a Vector. With all the casting and parentheses necessary for elementAt( ), this might not be the case as your body of code grows.

As before, when you implement Runnable you don't get all of the equipment that comes with Thread, so you have to create a new Thread and hand yourself to its constructor in order to have something to start( ), as you can see in the CBoxVector constructor and in go( ). The run( ) method simply chooses a random element number within the vector and calls nextColor( ) for that element to cause it to choose a new randomly-selected color.

Upon running this program, you see that it does indeed run faster and respond more quickly (for instance, when you interrupt it, it stops more quickly), and it doesn't seem to bog down as much at higher grid sizes. Thus, a new factor is added into the threading equation: you must watch to see that you don't have "too many threads" (whatever that turns out to mean for your particular program and platform). If you do, you must try to use techniques like the one above to "balance" the number of threads in your program. If you see performance problems in a multithreaded program you now have a number of issues to examine:

Do you have enough calls to sleep( ), yield( ), and/or wait( )?

Are calls to sleep( ) long enough?

Are you running too many threads?

Have you tried different platforms and JVMs?

Issues like this are one reason that multithreaded programming is often considered an art.