WEBINAR:On-demand webcast

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
RunnableCanvas
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
Vectorimplements
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
gridCBoxVectors,
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.