ch8.htm

JAVA Developing Professional JavaApplets

            throw
new StackEmptyException();<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Otherwise, return the top
item and decrement the top...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Integer I = s[top];<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s[top] = null;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-top;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return I;<BR>
&nbsp;&nbsp;&nbsp;}<BR>
<BR>
&nbsp;&nbsp;&nbsp;// List the contents of the stack...<BR>
&nbsp;&nbsp;&nbsp;public void list() {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for (int i = 0; i &lt;= top;
++i)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(i
+ &quot;: &quot; + s[i]);<BR>
&nbsp;&nbsp;&nbsp;}<BR>
}</TT>
</BLOCKQUOTE>
<HR>
<P>
It is important to note that threads generally function by <I>time-slicing</I>.
What occurs in an environment that supports time-slicing is that
threads share CPU time while executing their respective code.
In effect, although the threads are said to be running simultaneously,
there is really only one thread executing at a given moment in
time. It just <I>seems</I> like the threads are running simultaneously.
The speed of the computer and the small increments of time make
it possible for the threads to look like they're performing simultaneously.
<P>
Suppose there are two threads, A and B. If thread A is executing
a method, thread B could get a slice of time before A is finished
with its method. If the method is thread-safe, it won't matter
to thread A that one or more threads interrupts its processing.
Regardless of the time-slicing sequence, a thread-safe thread
A will get the desired results.<BR>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD><B>Note</B></TD></TR>
<TR VALIGN=TOP><TD>
<BLOCKQUOTE>
Java works best in environments designed to support <I>preemptive</I> time scheduling. A preemptive scheduler gives running tasks (processes or threads) small portions of time to execute by using time-slicing, discussed in this section. UNIX and Windows 95 are two operating systems that support some form of preemptive scheduling. However, some platforms, such as Windows 3.1, support a more primitive form of scheduling, called <I>nonpreemptive</I>. In this form of scheduling, one task doesn't give another task a chance to run until it's finished or has manually yielded its time. This makes writing cooperative programs fairly difficult-especially those with long CPU-intensive operations. You basically have to code your application around the system being nonpreemptive; in certain portions of the code, you need to call some kind of yield method to let other threads execute. In preemptive scheduling environments, this kind of manual coding is not necessary.
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
With time-slicing in mind, it isn't difficult to expose the problem
with the TestStack class. Think about what would happen if the
<TT>push()</TT> and <TT>pop()</TT>
code shared time slices in the following manner:
<BLOCKQUOTE>
<TT>PUSH: ++top;<BR>
POP: Integer I = s[top];<BR>
POP: s[top] = null;<BR>
POP; -top;<BR>
PUSH: s[top] = item;</TT>
</BLOCKQUOTE>
<P>
In this case, the <TT>pop()</TT> call
would be in error because it would return a stack top that hasn't
been assigned a value yet. In short, if the <TT>push()</TT>
and <TT>pop()</TT> operations share
slices of time, they will probably not work properly. The operations
with the <TT>top</TT> variable need
to be <I>atomic</I>, which effectively means that another thread
cannot interrupt the execution of the operation until it's finished.
<P>
This issue of operations causing undesired behavior because of
concurrency is often referred to as the <I>producer/consumer</I>
<I>problem</I>. This problem is characterized by one thread producing
data (in this case, pushing an item onto the stack), while a concurrent
thread is consuming the data (popping the stack). The problem
is one of <I>synchronization</I>: Consuming and producing operations
cannot be interleaved indiscriminately; rather, the operations
need to be synchronized to guarantee thread-safe behavior.<BR>

<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1  WIDTH=80%>
<TR VALIGN=TOP><TD><B>Note</B></TD></TR>
<TR VALIGN=TOP><TD>
<BLOCKQUOTE>
Although a stack class was used in this example, note that there is a stack class available in the java.util package. The stack class written in this chapter is used strictly to illustrate problems with multithreading. Also note that the Exception classes associated with the stack code of this section give you a good example of how to create a subhierarchy of Exception classes. In this case, a new hierarchy of stack exceptions was created, with StackException as the root.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
Listing 8.5 provides Applet and Thread classes that use the TestStack
class appearing throughout this discussion on synchronization.
The Applet class, StackApplet, pushes an element onto the stack
whenever you click the mouse. It follows this push with a listing
of the current stack contents. The Thread class, called StackThread,
loops indefinitely, looking for items on the stack. If one is
found, its integer value is displayed to standard output. If not
(indicated by a StackEmptyException object being thrown), the
thread sleeps a little and tries again. The synchronization problem
can be seen by clicking the mouse rapidly. The <TT>push()</TT>,
<TT>pop()</TT>, and <TT>list()</TT>
methods can then be interleaved. It is likely you'll see the listing
appearing incorrectly if you click fast enough. In fact, the problem
will be blatant: The output from the <TT>pop()</TT>
method-which changes the <TT>top</TT>
variable also used in <TT>list()</TT>-will
occur in the middle of the <TT>list()</TT>
method, thus undermining its results.
<HR>
<BLOCKQUOTE>
<B>Listing 8.5. Applet and Thread classes that use the TestStack
class.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>import java.awt.*;<BR>
import java.lang.*;<BR>
import java.applet.Applet;<BR>
<BR>
public class StackApplet extends Applet&nbsp;&nbsp;{<BR>
&nbsp;&nbsp;&nbsp;TestStack s;<BR>
&nbsp;&nbsp;&nbsp;int counter = 0;&nbsp;&nbsp;// For stack test
data...<BR>
&nbsp;&nbsp;&nbsp;Thread t; // The stack thread...<BR>
&nbsp;&nbsp;&nbsp;// Create the stack at initialization...<BR>
&nbsp;&nbsp;&nbsp;// Make a thread to read the stack...<BR>
&nbsp;&nbsp;&nbsp;public void init() {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s = new TestStack(20);<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t = new StackThread(s);<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.start();<BR>
&nbsp;&nbsp;&nbsp;}<BR>
<BR>
&nbsp;&nbsp;&nbsp;// Add an item to the stack whenever you click
<BR>
&nbsp;&nbsp;&nbsp;// on the mouse...<BR>
&nbsp;&nbsp;&nbsp;public boolean mouseDown(Event ev, int x, int
y) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s.push(new
Integer(++counter));<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s.list();
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;catch (StackFullException
e) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(&quot;Stack
full!&quot;);<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return true;<BR>
&nbsp;&nbsp;&nbsp;};<BR>
<BR>
&nbsp;&nbsp;&nbsp;// Kill the stack thread when leaving...<BR>
&nbsp;&nbsp;&nbsp;public void destroy() {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.stop();<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t.join();
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;catch (InterruptedException
e) { }<BR>
&nbsp;&nbsp;&nbsp;}<BR>
}<BR>
<BR>
// Thread that constantly reads the stack and prints out<BR>
// the current top...<BR>
class StackThread extends Thread {<BR>
&nbsp;&nbsp;&nbsp;TestStack s;<BR>
&nbsp;&nbsp;&nbsp;public StackThread(TestStack s) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.s = s;<BR>
&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;// Loop forever, looking at the top of the stack...
<BR>
&nbsp;&nbsp;&nbsp;public void run() {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Integer Top;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (true) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Print
out top of stack, if stack isn't empty...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Top
= s.pop();<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(&quot;Thread:
Read &quot; + Top);<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Sleep
some if stack is empty...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;catch (StackEmptyException
se) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try
{<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sleep(250);
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;catch
(InterruptedException e) { }<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;}<BR>
}</TT>
</BLOCKQUOTE>
<HR>
<H3><A NAME="IntroducingtheSynchronizedModifier">Introducing the
Synchronized Modifier</A></H3>
<P>
The developers of Java are aware of the synchronization problem
described in the preceding section. They also know that synchronization
is often dealt with by issuing many lines of code. Fortunately
for Java developers, the Java architects took advantage of programming
constructs introduced over 20 years ago that make creating thread-safe
classes relatively easy. Java synchronization is based on the
concept of <I>monitors</I>. The idea is that each class and object
has its own monitor that functions as a lock on the item. For
example, if one thread locks an object's monitor, then another
thread cannot access that object until the monitor is released.
A monitor can make a code fragment behave like a <I>critical section</I>,
with a piece of code that should only have one thread in it at
a given time.
<P>
The Java language's <I>synchronized</I> modifier is used to implement
a monitor. The modifier can be applied on a method or a block
of code. If a method is declared as synchronized, then a thread
that invokes the method owns the monitor of the object or class
until it leaves the method. If another thread tries to invoke
the method while the other thread owns the monitor, then that
calling thread will have to wait until the first thread is finished.
When this occurs, the monitor is released, and the next thread
can execute the method.
<P>
Placing the synchronized modifier in just three areas of the TestStack
class is all that's needed to  make that class thread-safe. To
do this, the three method declarations of the class need to be
redeclared, as follows:
<BLOCKQUOTE>
<TT>public synchronized void push(Integer
item) throws StackFullException<BR>
public synchronized Integer pop() throws StackEmptyException<BR>
public synchronized void list()</TT>
</BLOCKQUOTE>
<P>
With that simple change, the TestStack class is now thread-safe!
<P>
Another way of using the synchronized modifier is to apply it
to blocks of code. Specifically, the critical sections of code
should be synchronized. The TestStack class can be modified to
do this, as shown in Listing 8.6. The same methods from the previous
declaration are modified to have blocks of the structure
<BLOCKQUOTE>
<TT>synchronized(this) {<BR>
}</TT>
</BLOCKQUOTE>
<P>
around their critical sections of code. The <TT>this</TT>
of the synchronized statement refers to the instance of the TestStack
class. The effect in this case is similar to that of synchronizing
methods; no thread can enter synchronized code while another thread
holds the monitor of the object. As in synchronizing methods,
this version of the TestStack class is thread-safe. Note, however,
that the code is a little more cumbersome and harder to read.
In general, synchronizing methods is preferred over synchronizing
code blocks for both readability and ease of use. Furthermore,
method-based synchronization is considered more object-oriented
because it more <BR>
effectively &quot;hides&quot; the fact that the code is executing
as a thread, thus allowing you to focus on the object's behavior
and not on how it works in a concurrent atmosphere. On the other
hand, synchronizing blocks is more efficient because the monitors
are held for shorter periods of time. If your code has only a
small section of code that is critical, then it might be best
to synchronize that block of code. However, classes such as TestStack
are probably best implemented with synchronized methods.
<HR>
<BLOCKQUOTE>
<B>Listing 8.6. The TestStack class with synchronized code blocks.
<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>// This class implements a simple stack
as<BR>
// an array of integers...<BR>
class TestStack {<BR>
&nbsp;&nbsp;&nbsp;Integer s[];&nbsp;&nbsp;// The stack array of
integer objects...<BR>
&nbsp;&nbsp;&nbsp;int top; // The current top of the stack. Next
item to place.<BR>
&nbsp;&nbsp;&nbsp;// Construct a stack of the specified size...
<BR>
&nbsp;&nbsp;&nbsp;public TestStack(int size) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s = new Integer[size];<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;top = -1;&nbsp;&nbsp;&nbsp;//
Empty stack...<BR>
&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;// Push an item onto the stack...<BR>
&nbsp;&nbsp;&nbsp;public void push(Integer item) throws StackFullException
{<BR>
&nbsp;&nbsp;&nbsp;&nbsp;synchronized(this) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Throw exception if stack
is full...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (top == s.length)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw
new StackFullException();<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Otherwise increment the
top and add the item...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;++top;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s[top] = item;<BR>