Introduction to Threads

Why Threads

The term thread is short-hand for thread of control: an independent section of code within a single program.
The hardware architecture trend is to put multiple CPUs on the chip. Multithreaded applications are critical to make best use of these new processors.
Threads implement asynchrony - Java doesn't have it:
A scenario:

Object A invokes B.aMethod().
B.aMethod(), to do its full job, takes a long time.
A does not want to wait for B to finish processing.
B can encapsulate a separate thread that decouples aMethod() processing from returning control to A.
B.aMethod():

receives the arguments, that is, the work request;
places the work request on another thread's task queue;
returns from aMethod().

The other thread subsequently is:

scheduled for execution
processes the requests in its queue.

Decoupling sending information from processing it makes these actions asynchronous.

It's like receiving email:

it's put into your inbox;
you read it when you are good & ready;
[you do what is asked in the email message;]
[possibly, you reply to the email when you finish the task]

Servers typically are multithreaded, with 1 thread for each active client (a discussion of thread-pools is deferred)
The local variables of a method that a thread is executing are private to that thread.
Each thread has access to the object's instance variables (aka data members).
Do not assume that a thread runs to completion before another is started.
Example:

One account withdrawal thread looks at your account balance, and if it is large enough, allows you to make the withdrawal.

if ( balance >= withdrawalRequest )

balance -= withdrawalRequest;

You might have another withdrawal thread operating.
If the sequence of withdrawal operations of the 2 threads is interleaved (this can happen), you may be able to overdraw your account.

To ensure that threads don't destructively interact, synchronize them: ensure that a thread's atomic sequences of operations are uninterrupted.

Example

ThreadTester

Advantages of threads vs. process-level multitasking

Threads share the same address space (class members), thus context switching between threads is quicker.
Communication between threads also is quicker.

The main thread

The JRE distinguishes between 2 kinds of threads: user & daemon.

User thread:

As long as a user thread is alive, execution does not terminate.

Daemon thread:

Daemon threads serve user threads. If their parent thread, the thread that spawned them, dies, so do they.

The main method is a user thread.
If it spawns threads, then, by default, they are user threads.
If the main thread terminates, but there are living children user threads, the JVM process does not terminate.
To make a thread a daemon thread, set it to daemon with the method setDaemon( boolean ), before the thread starts.
When a GUI application is started, an AWT user thread is created to monitor GUI events.

Thread Creation

Threads are implemented by either:

Extending java.lang.Thread - see example above
Implementing the java.lang.Runnable interface

Implementing the Runnable Interface

public interface Runnable

{

public void run( );

}

Create a thread via the Runnable interface as follows:

Define a class, C, that implements Runnable.
Instantiate a Thread object:

// c is an object of class C
Thread t = new Thread( c ); // Another Thread constructor has a 2nd argument: String threadname

Invoke the start method on the thread:

t.start();

This places t on the thread ready Q.
When t is dispatched, c's run method is invoked.
When c's run method returns, t dies.
t.getName() returns t's name (it is given a name, if the constructor doesn't supply one).

Example

Possible output:

Thread[Counter A,5,main]
Main Thread: 0
Counter A: 0
Counter A: 1
Main Thread: 2
Counter A: 2
Counter A: 3
Main Thread: 4
Counter A: 4
Exit from Counter A.
Main Thread: 5
Exit from Main Thread: Counter = 5

If the try block were removed from Client's main method, then the main method would return before Counter A finished.
Since Counter A is a child thread of the main thread, it is a user thread, and stays alive until it finishes its run method.
What would the output look like in this case?

Extending the Thread Class

Define a class, C, that extends Thread
C implements a run method.
The start method inherited from the Thread class is invoked on the object, t, of the class C, which puts t in the thread ready Q.
Example

Possible output:

Thread[Counter A,5,main]
Exit from Main Thread.
Counter A: 0
Counter A: 1
Counter A: 2
Counter A: 3
Counter A: 4
Exit from Counter A.

Synchronization

To avoid problems like the account withdrawal problem mentioned above, threads are synchronized.

Monitors

A monitor is associated with an object whose access it monitors.
Every Java object has an associated monitor.
Every Java class has a monitor.
Rules of synchronization:

Thread t cannot enter a monitor, if another thread already has acquired the monitor.

When a thread exits a monitor, a waiting thread is given the monitor (i.e., it becomes ready).

Synchronized Methods

If a method is atomic (i.e., should be executed in its entirety or not at all), then synchronize it.

For example, if a data structure is operated on by several threads, you can synchronize them.

One way is to synchronize the data structure's methods.

class StackImpl

{

private Object stackArray[ ];

private int topOfStack;

. . .

public synchronized Object pop( )

{

Object obj = stackArray[topOfStack];

stackArray[topOfStack--] = null; // No underflow check!

return obj;

}

public synchronized void push( Object element )

{

stackArray[++topOfStack] = element; // No overflow check!

}

When a thread is executing a synchronized method:

No other thread may execute any of the class's synchronized methods.
The thread that is executing the synchronized method can invoke other synchronized methods (otherwise, we'd have a tight deadlock).
Non-synchronized methods may be executed by any thread at any time.

You can declare a static method synchronized.

In this case, the class's monitor ensures mutually exclusive access to the method.
non-synchronized static methods may be executed by any thread at any time.
Class EA that extends class A with a synchronized method can override it with another that does not have to be synchronized and vice versa.

Correctness heuristic: In a class intended to be thread safe, all methods are synchronized.

Synchronized Blocks

The synchronized statement looks like

synchronized ( <object reference> )

{ // the braces cannot be omitted

<code block>

}

class SmartClient

{

BankAccount account;

// . . .

public void updateTransaction( )

{

synchronized ( account )

{

account.update( );

}

Thread Transitions

Thread States

Ready - waiting to be scheduled
Running - the thread is executing
Waiting - waiting to be notified
Sleeping - waiting until nap time is over
Blocked - waiting for a resource (e.g., a monitor, I/O operation)
Dead - like the roach motel, once entered, a thread never leaves this state.

When a thread is constructed, it is in the Born state until its start method is invoked.
Invoking its start method puts it in the Ready state.

The successor state function: S(state, action) = state' includes the following

S( Ready, scheduled ) = Running
S( Running, Thread.yield() ) = Ready

Thread.yield() has no testable semantics.

Thread Priorities

Threads are assigned priorities [0 - 10], where 10 is the highest priority.
The default is 5 (Thread.NORM_PRIORITY).
The thread scheduler is supposed to schedule some thread in the Ready state with the highest priority.

Apparently, some JVM implementations ignore this Thread attribute.
If there is more than 1 such Thread, it may not select the one that has been in the Ready state the longest.

A thread inherits its parent's priority.
You can set it with setPriority:

t.setPriority( t.getPriority() + 1 ); // what does this do?

Like Thread.yield(),

do not use thread priorities to ensure correctness or improve performance.
The semantics vary between JVM implementations.
Basically, do not use priorities.

Thread Scheduler

Preemptive scheduling -

then

Time-sliced aka Round-robin scheduling -

Actual implementations are platform-dependent.

Write once, run everywhere, but not necessarily with the same thread scheduling semantics :(

Running & Yielding

Use Thread.yield() to enable the user to interrupt a compute-intensive operation.

public void run()

{

try

{

while ( !done() )

{

doALittleMore();

Thread.yield();

}

} catch (InterruptedException e)

{

doCleaningUp();

}

Use something like this, for example, to enable the user to interleave a long, slow Mandelbrot visualization request with other, equal priority work.
Different JVMs implement yield differently: the resulting performance is not portable.

Sleeping & Waking Up

S( Running, Thread.sleep(long milliseconds ) ) = Sleeping

S( Sleeping, sleep time elapsed ) = Ready

Thread.sleep() often is used to control an animation, although this can be done via the repaint( sleeptime ) method.

Waiting & Notifying

Threads that synchronize on the same object can use the wait & notify methods.
Here are the wait & notify methods:

void wait( long timeout ) throws InterruptedException

Causes current thread to wait until:

another thread invokes the notify() method or the notifyAll() method for this object, or
timeout milliseconds of real time has elapsed.

void wait( long millis , int nanos) throws InterruptedException

This is similar to the wait method of 1 argument, but allows finer control over the amount of time to wait for a notification before giving up.

The amount of real time, measured in nanoseconds, is given by:

1,000,000 * millis + nanos

void wait() throws InterruptedException

Causes current thread to wait until:

another thread invokes the notify() method or the notifyAll() method for this object, or

void notify()
void notifyAll()

Example: StackImpl

The output from one execution:

            Thread[A,5,main]
            Thread[B,5,main]
            Thread[C,5,main]
            Main Thread sleeping.
            Thread[C,5,main]: popping
            Thread[C,5,main]: waiting to pop
            Thread[A,5,main]: pushing
            Thread[A,5,main]: notifying after push
            Thread[A,5,main]: pushing
            Thread[A,5,main]: notifying after push
            Thread[A,5,main]: pushing
            Thread[A,5,main]: notifying after push
            Thread[C,5,main]: notifying after pop
            Thread[B,5,main]: pushing
            Thread[B,5,main]: notifying after push
            Thread[A,5,main]: pushing
            Thread[A,5,main]: notifying after push
            Thread[C,5,main]: popping
            Thread[C,5,main]: notifying after pop
            Thread[B,5,main]: pushing
            Thread[B,5,main]: notifying after push
            Exit from Main Thread.

Important points

wait & notify methods must be executed within a synchronized block. Otherwise, when they are executed, an IllegalMonitorStateException is thrown: It is not caught by the compiler.
The wait while loop is a necessary idiom. The following will not always work, hence never should be used:

...

if ( isEmpty() )

{

wait();

}

// Stack is not empty (Not!)

Eliminate need for volatile modifier by making isEmpty & isFull private methods. Then, topOfStack is always read within a synchronized block that leaves it in a consistent state (this is a post-condition of the method).

Miscellaneous Methods in the Thread Class

boolean isAlive()

This method returns true if and only if the thread is alive (i.e., not dead, not terminated).

void join() throws InterruptedException

Causes invoker to wait until thread has terminated.

Example

Possible output:

           Thread[Counter A,5,main]
            Thread[Counter B,5,main]
            Wait for the child threads to finish.
            Counter A: 0
            Counter B: 0
            Counter A: 1
            Counter B: 1
            Counter A: 2
            Counter B: 2
            Counter A: 3
            Counter B: 3
            Counter A: 4
            Counter B: 4
            Exit from Counter A.
            Exit from Counter B.
            Counter A not alive.
            Counter B not alive.
            Exit from Main Thread.

Document thread-safety

If a class's objects are mutable, but its methods guarantee to leave it in a consistent state regardless of how many threads have references to it, then indicate that the class is thread-safe in its Javadoc.