Chapter 4. Thread Notification
In the previous chapter, we discussed data synchronization. Using
synchronization and explicit locks, threads can interoperate and
safely share data without any race conditions that might corrupt the
state of the data. However, as we shall see, synchronization is more
than avoiding race conditions: it includes a thread-based
notification system that we examine in this chapter.
Thread notification addresses a number of issues in our sample
application. Two of these relate to the random character generator
and the animation canvas. The random character generator is created
when the user presses the Start button; it is destroyed when the user
presses the Stop button. Therefore, the listeners to the random
character generator are reconnected each time the Start button is
pressed. In fact, the entire initialization process is repeated every
time that the Start button is pressed.
A similar problem exists for the animation component. Although the
component itself is not destroyed every time the user restarts, the
thread object that is used for the animation is discarded and
recreated. The component provides a mechanism that allows the
developer to set the done flag, but the component
doesn't use that data to restart the animation: once
the done flag is set to true,
the run() method of the animation canvas exits.
The reason for this has to do with efficiency. The alternative is to
loop forever, waiting for the done flag to be set
to false. This consumes a lot of CPU cycles.
Fortunately, the mechanisms we explore in this chapter can solve all
these problems.
|
