Exception Handling and multi threading

Posted Date: 29 Mar 2008 Resource Type: Articles/Knowledge Sharing Category: E-Books

Posted By: Hawre mohommed iqbal abdul kayyum Member Level: Bronze
Rating:

Points: 5

Chap 04 Multithreaded Programming and Exception
Handling (hrs: 8 marks: 16)
4.1 Managing Errors and Exceptions:

An exception is an abnormal condition that arises in a code sequence at run time. In other words, an exception is a run-time error. Before you learn how to handle exceptions in your program, it is useful to see what happens when you don’t handle them. This small program includes an expression that intentionally causes a divide-by-zero error.
class Error1
{
public static void main(String args[])
{
int d = 0;
int a = 42 / d;
}
}
When the Java run-time system detects the attempt to divide by zero, it constructs a new exception object and then throws this exception. This causes the execution of Error1 to stop, because once an exception has been thrown, it must be caught by an exception handler and dealt with immediately. In this example, we haven’t supplied any exception handlers of our own, so the exception is caught by the default handler provided by the Java run-time system. Any exception that is not caught by your program will ultimately be processed by the default handler. The default handler displays a string describing the exception, prints a stack trace from the point at which the exception occurred, and terminates the program.
Here is the output generated when this example is executed.
java.lang.ArithmeticException: / by zero
at Exc0.main(Error1.java:4)

4.1 .1Types of errors,
4.2.2 Exception,
A Java exception is an object that describes an exceptional (that is, error) condition that has occurred in a piece of code.
When an exceptional condition arises, an object representing that exception is created and thrown in the method that caused the error.That method may choose to handle the exception itself, or pass it on. Either way, at some point, the exception is caught and processed. Exceptions can be generated by the Java run-time system, or they can be manually generated by your code. Exceptions thrown by Java relate to fundamental errors that violate the rules of the Java language or the constraints of the Java execution environment. Manually generated exceptions are typically used to report some error condition to the caller of a method. Java exception handling is managed via five keywords: try, catch, throw, throws, and finally. Briefly, here is how they work. Program statements that you want to monitor for exceptions are contained within a try block. If an exception occurs within the try block, it is thrown. Your code can catch this exception (using catch) and handle it in some rational manner. System-generated exceptions are automatically thrown by the Java run-time system. To manually throw an exception, use the keyword throw. Any exception that is thrown out of a method must be specified as such by a throws clause. Any code that absolutely must be executed before a method returns is put in a finally block.
The general form of an exception-handling block is shown below:

try {
// block of code to monitor for errors
}
catch (ExceptionType1 exObj) {
// exception handler for ExceptionType1
}
catch (ExceptionType2 exObj) {
// exception handler for ExceptionType2
}
// ..
finally {
// block of code to be executed before try block ends
}
Here, ExceptionType is the type of exception that has occurred.

Using try and catch
Making the program to handle an exception itself provides two benefits. First, it allows you to fix the error. Second, it prevents the program from automatically terminating.
To guard against and handle a run-time error, simply enclose the code that you want to monitor inside a try block. Immediately following the try block, include a catch clause that specifies the exception type that you wish to catch. To illustrate how easily this can be done, the following program includes a try block and a catch clause which processes the ArithmeticException generated by the division-by-zero error:

class Exception1 {
public static void main(String args[]) {
int sum, dino;
try { // monitor a block of code.
dino = 0;
sum = 42 / dino;
System.out.println("This will not be printed.");
} catch (ArithmeticException e) { // catch divide-by-zero error
System.out.println("Division by zero is not allowed ");
}
System.out.println("After catch statement.");
}
}

Here the call to println( ) inside the try block is never executed. Once an exception is thrown, program control transfers out of the try block into the catch block. Put differently, catch is not “called,” so execution never “returns” to the try block from
a catch. Thus, the line “This will not be printed.” is not displayed. Once the catch
statement has executed, program control continues with the next line in the program
following the entire try/catch mechanism.
A try and its catch statement form a unit. The statements that are protected by try must be surrounded by curly braces. (That is, they must be within a block.) You cannot use try on a single statement.
The goal of most well-constructed catch clauses should be to resolve the
exceptional condition and then continue on as if the error had never happened.
For example, in the next program each iteration of the for loop obtains two random
integers. Those two integers are divided by each other, and the result is used to divide
the value 12345. The final result is put into a. If either division operation causes a
divide-by-zero error, it is caught, the value of a is set to zero, and the program
continues.
// Handle an exception and move on.
import java.util.Random;
class HandleError {
public static void main(String args[]) {
int a=0, b=0, c=0;
Random r = new Random();
for(int i=0; i<32000; i++) {
try {
b = r.nextInt();
c = r.nextInt();
a = 12345 / (b/c);
} catch (ArithmeticException e) {
System.out.println("Division by zero.");
a = 0; // set a to zero and continue
}
System.out.println("a: " + a);
}
}
}
Displaying a Description of an Exception
Throwable overrides the toString( ) method (defined by Object) so that it returns a
string containing a description of the exception. You can display this description in a
println( ) statement by simply passing the exception as an argument. For example, the
catch block in the preceding program can be rewritten like this:
catch (ArithmeticException e) {
System.out.println("Exception: " + e);
a = 0; // set a to zero and continue
}
When this version is substituted in the program, and the program is run, each
divide-by-zero error displays the following message:
Exception: java.lang.ArithmeticException: / by zero
While it is of no particular value in this context, the ability to display a description
of an exception is valuable in other circumstances—particularly when you are
experimenting with exceptions or when you are debugging.
4.2.3 Multiple catch statement,
In some cases, more than one exception could be raised by a single piece of code. To
handle this type of situation, you can specify two or more catch clauses, each catching
a different type of exception. When an exception is thrown, each catch statement is
inspected in order, and the first one whose type matches that of the exception is
executed. After one catch statement executes, the others are bypassed, and execution
continues after the try/catch block. The following example traps two different
exception types:
// Demonstrate multiple catch statements.
class MultiCatch {
public static void main(String args[]) {
try {
int a = args.length;
System.out.println("a = " + a);
int b = 42 / a;
int c[] = { 1 };
c[42] = 99;
} catch(ArithmeticException e) {
System.out.println("Divide by 0: " + e);
} catch(ArrayIndexOutOfBoundsException e) {
System.out.println("Array index oob: " + e);
}
System.out.println("After try/catch blocks.");
}
}
This program will cause a division-by-zero exception if it is started with no commandline
parameters, since a will equal zero. It will survive the division if you provide a
command-line argument, setting a to something larger than zero. But it will cause an
ArrayIndexOutOfBoundsException, since the int array c has a length of 1, yet the
program attempts to assign a value to c[42].
Here is the output generated by running it both ways:
C:\>java MultiCatch
a = 0
Divide by 0: java.lang.ArithmeticException: / by zero
After try/catch blocks.
C:\>java MultiCatch TestArg
a = 1
Array index oob: java.lang.ArrayIndexOutOfBoundsException
After try/catch blocks.
When you use multiple catch statements, it is important to remember that
exception subclasses must come before any of their superclasses. This is because a
catch statement that uses a superclass will catch exceptions of that type plus any of
its subclasses. Thus, a subclass would never be reached if it came after its superclass.
Further, in Java, unreachable code is an error. For example, consider the following
program:
/* This program contains an error.
A subclass must come before its superclass in
a series of catch statements. If not,
unreachable code will be created and a
compile-time error will result.
*/
class SuperSubCatch {
public static void main(String args[]) {
try {
int a = 0;
int b = 42 / a;
} catch(Exception e) {
System.out.println("Generic Exception catch.");
}
/* This catch is never reached because
ArithmeticException is a subclass of Exception. */
catch(ArithmeticException e) { // ERROR - unreachable
System.out.println("This is never reached.");
}
}
}
If you try to compile this program, you will receive an error message stating that
the second catch statement is unreachable because the exception has already been
caught. Since ArithmeticException is a subclass of Exception, the first catch statement
will handle all Exception-based errors, including ArithmeticException. This means
that the second catch statement will never execute. To fix the problem, reverse the
order of the catch statements.
Nested try Statements
The try statement can be nested. That is, a try statement can be inside the block of
another try. Each time a try statement is entered, the context of that exception is
pushed on the stack. If an inner try statement does not have a catch handler for a
particular exception, the stack is unwound and the next try statement’s catch handlers
are inspected for a match. This continues until one of the catch statements succeeds, or
until all of the nested try statements are exhausted. If no catch statement matches, then
the Java run-time system will handle the exception. Here is an example that uses
nested try statements:
// An example of nested try statements.
class NestTry {
public static void main(String args[]) {
try {
int a = args.length;
/* If no command-line args are present,
the following statement will generate
a divide-by-zero exception. */
int b = 42 / a;
System.out.println("a = " + a);
try { // nested try block
/* If one command-line arg is used,
then a divide-by-zero exception
will be generated by the following code. */
if(a==1) a = a/(a-a); // division by zero
/* If two command-line args are used,
then generate an out-of-bounds exception. */
if(a==2) {
int c[] = { 1 };
c[42] = 99; // generate an out-of-bounds exception
}
} catch(ArrayIndexOutOfBoundsException e) {
System.out.println("Array index out-of-bounds: " + e);
}
} catch(ArithmeticException e) {
System.out.println("Divide by 0: " + e);
}
}
}
As you can see, this program nests one try block within another. The program
works as follows. When you execute the program with no command-line arguments, a
divide-by-zero exception is generated by the outer try block. Execution of the program
by one command-line argument generates a divide-by-zero exception from within the
nested try block. Since the inner block does not catch this exception, it is passed on
to the outer try block, where it is handled. If you execute the program with two
command-line arguments, an array boundary exception is generated from within
the inner try block. Here are sample runs that illustrate each case:
C:\>java NestTry
Divide by 0: java.lang.ArithmeticException: / by zero
C:\>java NestTry One
a = 1
Divide by 0: java.lang.ArithmeticException: / by zero
C:\>java NestTry One Two
a = 2
Array index out-of-bounds:
java.lang.ArrayIndexOutOfBoundsException
Nesting of try statements can occur in less obvious ways when method calls are
involved. For example, you can enclose a call to a method within a try block. Inside
that method is another try statement. In this case, the try within the method is still
nested inside the outer try block, which calls the method. Here is the previous program
recoded so that the nested try block is moved inside the method nesttry( ):
/* Try statements can be implicitly nested via
calls to methods. */
class MethNestTry {
static void nesttry(int a) {
try { // nested try block
/* If one command-line arg is used,
then a divide-by-zero exception
will be generated by the following code. */
if(a==1) a = a/(a-a); // division by zero
/* If two command-line args are used,
then generate an out-of-bounds exception. */
if(a==2) {
int c[] = { 1 };
c[42] = 99; // generate an out-of-bounds exception
}
} catch(ArrayIndexOutOfBoundsException e) {
System.out.println("Array index out-of-bounds: " + e);
}
}
public static void main(String args[]) {
try {
int a = args.length;
/* If no command-line args are present,
the following statement will generate
a divide-by-zero exception. */
int b = 42 / a;
System.out.println("a = " + a);
nesttry(a);
} catch(ArithmeticException e) {
System.out.println("Divide by 0: " + e);
}
}
}
The output of this program is identical to that of the preceding example.
throw
So far, you have only been catching exceptions that are thrown by the Java run-time
system. However, it is possible for your program to throw an exception explicitly,
using the throw statement. The general form of throw is shown here:
throw ThrowableInstance;
Here, ThrowableInstance must be an object of type Throwable or a subclass of
Throwable. Simple types, such as int or char, as well as non-Throwable classes, such
as String and Object, cannot be used as exceptions. There are two ways you can obtain
a Throwable object: using a parameter into a catch clause, or creating one with the new
operator.
The flow of execution stops immediately after the throw statement; any subsequent
statements are not executed. The nearest enclosing try block is inspected to see if it has
a catch statement that matches the type of the exception. If it does find a match, control
is transferred to that statement. If not, then the next enclosing try statement is
inspected, and so on. If no matching catch is found, then the default exception handler
halts the program and prints the stack trace.
Here is a sample program that creates and throws an exception. The handler that
catches the exception rethrows it to the outer handler.
// Demonstrate throw.
class ThrowDemo {
static void demoproc() {
try {
throw new NullPointerException("demo");
} catch(NullPointerException e) {
System.out.println("Caught inside demoproc.");
throw e; // rethrow the exception
}
}
public static void main(String args[]) {
try {
demoproc();
} catch(NullPointerException e)
System.out.println("Recaught: " + e);
}
}
}
This program gets two chances to deal with the same error. First, main( ) sets up an
exception context and then calls demoproc( ). The demoproc( ) method then sets up
another exception-handling context and immediately throws a new instance of
NullPointerException, which is caught on the next line. The exception is then
rethrown. Here is the resulting output:
Caught inside demoproc.
Recaught: java.lang.NullPointerException: demo
The program also illustrates how to create one of Java’s standard exception objects.
Pay close attention to this line:
throw new NullPointerException("demo");
Here, new is used to construct an instance of NullPointerException. All of Java’s
built-in run-time exceptions have at least two constructors: one with no parameter
and one that takes a string parameter. When the second form is used, the argument
specifies a string that describes the exception. This string is displayed when the object
is used as an argument to print( ) or println( ). It can also be obtained by a call to
throws
If a method is capable of causing an exception that it does not handle, it must specify
this behavior so that callers of the method can guard themselves against that exception.
You do this by including a throws clause in the method’s declaration. A throws clause
lists the types of exceptions that a method might throw. This is necessary for all
exceptions, except those of type Error or RuntimeException, or any of their subclasses.
All other exceptions that a method can throw must be declared in the throws clause. If
they are not, a compile-time error will result.
This is the general form of a method declaration that includes a throws clause:
type method-name(parameter-list) throws exception-list
{
// body of method
}
Here, exception-list is a comma-separated list of the exceptions that a method can throw.
getMessage( ), which is defined by Throwable.
Following is an example of an incorrect program that tries to throw an exception
that it does not catch. Because the program does not specify a throws clause to declare
this fact, the program will not compile.
// This program contains an error and will not compile.
class ThrowsDemo {
static void throwOne() {
System.out.println("Inside throwOne.");
throw new IllegalAccessException("demo");
}
public static void main(String args[]) {
throwOne();
}
}
To make this example compile, you need to make two changes. First, you need to
declare that throwOne( ) throws IllegalAccessException. Second, main( ) must define
a try/catch statement that catches this exception.
The corrected example is shown here:
// This is now correct.
class ThrowsDemo {
static void throwOne() throws IllegalAccessException {
System.out.println("Inside throwOne.");
throw new IllegalAccessException("demo");
}
public static void main(String args[]) {
try {
throwOne();
} catch (IllegalAccessException e) {
System.out.println("Caught " + e);
}
}
}
Here is the output generated by running this example program:
inside throwOne
caught java.lang.IllegalAccessException: demo
4.2.4 using finally statement,
finally
When exceptions are thrown, execution in a method takes a rather abrupt, nonlinear
path that alters the normal flow through the method. Depending upon how the
method is coded, it is even possible for an exception to cause the method to return
prematurely. This could be a problem in some methods. For example, if a method
opens a file upon entry and closes it upon exit, then you will not want the code that
closes the file to be bypassed by the exception-handling mechanism. The finally
keyword is designed to address this contingency.
finally creates a block of code that will be executed after a try/catch block has
completed and before the code following the try/catch block. The finally block will
execute whether or not an exception is thrown. If an exception is thrown, the finally
block will execute even if no catch statement matches the exception. Any time a
method is about to return to the caller from inside a try/catch block, via an uncaught
exception or an explicit return statement, the finally clause is also executed just before
the method returns. This can be useful for closing file handles and freeing up any other
resources that might have been allocated at the beginning of a method with the intent
of disposing of them before returning. The finally clause is optional. However, each try
statement requires at least one catch or a finally clause.
Here is an example program that shows three methods that exit in various ways,
none without executing their finally clauses:
// Demonstrate finally.
class FinallyDemo {
// Through an exception out of the method.
static void procA() {
try {
System.out.println("inside procA");
throw new RuntimeException("demo");
} finally {
System.out.println("procA's finally");
}
}
// Return from within a try block.
static void procB() {
try {
System.out.println("inside procB");
return;
} finally {
System.out.println("procB's finally");
}
}
// Execute a try block normally.
static void procC() {
try {
System.out.println("inside procC");
} finally {
System.out.println("procC's finally");
}
}
public static void main(String args[]) {
try {
procA();
} catch (Exception e) {
System.out.println("Exception caught");
}
procB();
procC();
}
}
In this example, procA( ) prematurely breaks out of the try by throwing an
exception. The finally clause is executed on the way out. procB( )’s try statement is
exited via a return statement. The finally clause is executed before procB( ) returns. In
procC( ), the try statement executes normally, without error. However, the finally
block is still executed.
If a finally block is associated with a try, the finally block will be executed upon
conclusion of the try.
Here is the output generated by the preceding program:
inside procA
procA’s finally
Exception caught
inside procB
procB’s finally
inside procC
procC’s finally
Chained Exceptions
Java 2, version 1.4 added a new feature to the exception subsystem: chained exceptions.
The chained exception feature allows you to associate another exception with an exception.
This second exception describes the cause of the first exception. For example, imagine a
situation in which a method throws an ArithmeticException because of an attempt to
divide by zero. However, the actual cause of the problem was that an I/O error occurred,
which caused the divisor to be set improperly. Although the method must certainly throw
an ArithmeticException, since that is the error that occurred, you might also want to let
the calling code know that the underlying cause was an I/O error. Chained exceptions
let you handle this, and any other situation in which layers of exceptions exist.
To allow chained exceptions, Java 2, version 1.4 added two constructors and two
methods to Throwable. The constructors are shown here.
Throwable(Throwable causeExc)
Throwable(String msg, Throwable causeExc)
In the first form, causeExc is the exception that causes the current exception. That is,
causeExc is the underlying reason that an exception occurred. The second form allows
you to specify a description at the same time that you specify a cause exception. These
two constructors have also been added to the Error, Exception, and RuntimeException
classes.
The chained exception methods added to Throwable are getCause( ) and initCause( ).
These methods are shown in Table 10-3, and are repeated here for the sake of discussion.
Throwable getCause( )
Throwable initCause(Throwable causeExc)
The getCause( ) method returns the exception that underlies the current exception.
If there is no underlying exception, null is returned. The initCause( ) method associates
causeExc with the invoking exception and returns a reference to the exception. Thus, you
can associate a cause with an exception after the exception has been created. However, the
cause exception can be set only once. Thus, you can call initCause( ) only once for each
exception object. Furthermore, if the cause exception was set by a constructor, then you
can’t set it again using initCause( ).
In general, initCause( ) is used to set a cause for legacy exception classes which
don’t support the two additional constructors described earlier. At the time of this
writing, most of Java’s built-in exceptions, such as ArithmeticException, do not define
the additional constructors. Thus, you will use initCause( ) if you need to add an
exception chain to these exceptions. When creating your own exception classes you
will want to add the two chained-exception constructors if you will be using your
exceptions in situations in which layered exceptions are possible.
Here is an example that illustrates the mechanics of handling chained exceptions.
// Demonstrate exception chaining.
class ChainExcDemo {
static void demoproc() {
// create an exception
NullPointerException e =
new NullPointerException("top layer");
// add a cause
e.initCause(new ArithmeticException("cause"));
throw e;
}
public static void main(String args[]) {
try {
demoproc();
} catch(NullPointerException e) {
// display top level exception
System.out.println("Caught: " + e);
// display cause exception
System.out.println("Original cause: " +
e.getCause());
}
}
}
The output from the program is shown here.
Caught: java.lang.NullPointerException: top layer
Original cause: java.lang.ArithmeticException: cause
In this example, the top-level exception is NullPointerException. To it is added
a cause exception, ArithmeticException. When the exception is thrown out of
demoproc( ), it is caught by main( ). There, the top-level exception is displayed,
followed by the underlying exception, which is obtained by calling getCause( ).
Chained exceptions can be carried on to whatever depth is necessary. Thus, the
cause exception can, itself, have a cause. Be aware that overly long chains of exceptions
may indicate poor design.
Chained exceptions are not something that every program will need. However, in
cases in which knowledge of an underlying cause is useful, they offer an elegant solution.
Java’s Built-in Exceptions
Inside the standard package java.lang, Java defines several exception classes. A few
have been used by the preceding examples. The most general of these exceptions
are subclasses of the standard type RuntimeException. Since java.lang is implicitly
imported into all Java programs, most exceptions derived from RuntimeException
are automatically available. Furthermore, they need not be included in any method’s
throws list. In the language of Java, these are called unchecked exceptions because the
compiler does not check to see if a method handles or throws these exceptions. The
unchecked exceptions defined in java.lang are listed in Table 10-1. Table 10-2 lists those
exceptions defined by java.lang that must be included in a method’s throws list if that
method can generate one of these exceptions and does not handle it itself. These are
called checked exceptions. Java defines several other types of exceptions that relate to its
various class libraries.

4.2.5 Using Exception for Debugging
Creating Your Own Exception Subclasses
Although Java’s built-in exceptions handle most common errors, you will probably want
to create your own exception types to handle situations specific to your applications.
This is quite easy to do: just define a subclass of Exception (which is, of course, a subclass
of Throwable). Your subclasses don’t need to actually implement anything—it is their
existence in the type system that allows you to use them as exceptions.
The Exception class does not define any methods of its own. It does, of course,
inherit those methods provided by Throwable. Thus, all exceptions, including those
that you create, have the methods defined by Throwable available to them. They are
shown in Table 10-3. Notice that several methods were added by Java 2, version 1.4.
You may also wish to override one or more of these methods in exception classes that
you create.
Method Description
Throwable fillInStackTrace( ) Returns a Throwable object that contains
a completed stack trace. This object can be
rethrown.
Throwable getCause( ) Returns the exception that underlies the
current exception. If there is no underlying
exception, null is returned. Added by Java 2,
version 1.4.
String getLocalizedMessage( ) Returns a localized description of the
exception.
String getMessage( ) Returns a description of the exception.
StackTraceElement[ ] getStackTrace( ) Returns an array that contains the stack
trace, one element at a time as an array of
StackTraceElement. The method at the top
of the stack is the last method called before
the exception was thrown. This method
is found in the first element of the array.
The StackTraceElement class gives your
program access to information about each
element in the trace, such as its method
name. Added by Java 2, version 1.4
Throwable initCause(Throwable
causeExc)
Associates causeExc with the invoking
exception as a cause of the invoking exception.
Returns a reference to the exception. Added
by Java 2, version 1.4
void printStackTrace( ) Displays the stack trace.
void printStackTrace(PrintStream
stream)
Sends the stack trace to the specified stream.
void printStackTrace(PrintWriter
stream)
Sends the stack trace to the specified stream.
void setStackTrace(StackTraceElement
elements[ ])
Sets the stack trace to the elements passed
in elements. This method is for specialized
applications, not normal use. Added by Java 2,
version 1.4
String toString( ) Returns a String object containing a
description of the exception. This method
is called by println( ) when outputting a
Throwable object.
The following example declares a new subclass of Exception and then uses that
subclass to signal an error condition in a method. It overrides the toString( ) method,
allowing the description of the exception to be displayed using println( ).
// This program creates a custom exception type.
class MyException extends Exception {
private int detail;
MyException(int a) {
detail = a;
}
public String toString() {
return "MyException[" + detail + "]";
}
}
class ExceptionDemo {
static void compute(int a) throws MyException {
System.out.println("Called compute(" + a + ")");
if(a > 10)
throw new MyException(a);
System.out.println("Normal exit");
}
public static void main(String args[]) {
try {
compute(1);
compute(20);
} catch (MyException e) {
System.out.println("Caught " + e);
}
}
}
This example defines a subclass of Exception called MyException. This subclass
is quite simple: it has only a constructor plus an overloaded toString( ) method that
displays the value of the exception. The ExceptionDemo class defines a method
named compute( ) that throws a MyException object. The exception is thrown when
compute( )’s integer parameter is greater than 10. The main( ) method sets up an
exception handler for MyException, then calls compute( ) with a legal value (less
than 10) and an illegal one to show both paths through the code. Here is the result:
Called compute(1)
Normal exit
Called compute(20)
Caught MyException[20]

4.1 Multi Threading:
4.1.1Creating Thread
4.1.2Extending a thread class
4.1.3Stopping and Blocking a thread
4.1.4 Life cycle of thread,
4.1.5 Using thread method,
4.1.6 Thread exceptions,
4.1.7Thread priority,
4.1.8 Synchronization,
4.1.9 Implementing a ‘Runnable’‘ Interface

INTRODUCTION:
A multithreaded program contains two or more parts that can run concurrently. Each part of such a program is called a thread, and each thread defines a separate path of execution.
Multithreading enables you to write very efficient programs that make maximum use of the CPU, because idle time can be kept to a minimum. This is especially important for the interactive, networked environment in which Java operates, because idle time is common. For example, the transmission rate of data over a network is much slower than the rate at which the computer can process it. Even local file system resources are read and written at a much slower pace than they can be processed by the CPU. And, of course, user input is much slower than the computer. In a traditional, single-threaded environment, your program has to wait for each of these tasks to finish before it can proceed to the next one—even though the CPU is sitting idle most of the time. Multithreading lets you gain access to this idle time and put it to good use.
The Java Thread Model
Threads exist in several states. A thread can be running. It can be ready to run as soon as it gets CPU time. A running thread can be suspended, which temporarily suspends its activity. A suspended thread can then be resumed, allowing it to pick up where it left off. A thread can be blocked when waiting for a resource. At any time, a thread can be terminated, which halts its execution immediately. Once terminated, a thread cannot be resumed.(fig from OS book)
4.1 Multi Threading:
4.1.1Creating Thread
We can create a thread by instantiating an object of type Thread. Java defines two ways in which this can be accomplished:
¦ You can implement the Runnable interface.
¦ You can extend the Thread class, itself.
4.1.2Extending a thread class

The Thread can be created through a new class that extends Thread, and then to create an instance of that class. The extending class must override the run( ) method, which is the entry point for the new thread. It must also call start( ) to begin execution of the new thread. The following program illustrates this.

4.1.3Stopping and Blocking a thread
Sometimes, suspending execution of a thread is useful. For example, a separate thread can be used to display the time of day. If the user doesn’t want a clock, then its thread can be suspended. Whatever the case, suspending a thread is a simple matter. Once suspended, restarting the thread is also a simple matter.
The mechanisms to suspend, stop, and resume threads differ between Java 2 and earlier versions. Although you should use the Java 2 approach for all new code, you still need to understand how these operations were accomplished for earlier Java environments. For example, you may need to update or maintain older, legacy code. You also need to understand why a change was made for Java 2. For these reasons, the
next section describes the original way that the execution of a thread was controlled,
followed by a section that describes the approach required for Java 2.
Suspending, Resuming, and Stopping Threads Using
Java 1.1 and Earlier
Prior to Java 2, a program used suspend( ) and resume( ), which are methods defined by Thread, to pause and restart the execution of a thread. They have the form shown below:
final void suspend( )
final void resume( )
The following program demonstrates these methods:
// Using suspend() and resume().
class NewThread implements Runnable {
String name; // name of thread
Thread t;
NewThread(String threadname) {
name = threadname;
t = new Thread(this, name);
System.out.println("New thread: " + t);
t.start(); // Start the thread
}
// This is the entry point for thread.
public void run() {
try {
for(int i = 15; i > 0; i--) {
System.out.println(name + ": " + i);
Thread.sleep(200);
}
} catch (InterruptedException e) {
System.out.println(name + " interrupted.");
}
System.out.println(name + " exiting.");
}
}
class SuspendResume {
public static void main(String args[]) {
NewThread ob1 = new NewThread("One");
NewThread ob2 = new NewThread("Two");
try {
Thread.sleep(1000);
ob1.t.suspend();
System.out.println("Suspending thread One");
Thread.sleep(1000);
ob1.t.resume();
System.out.println("Resuming thread One");
ob2.t.suspend();
System.out.println("Suspending thread Two");
Thread.sleep(1000);
ob2.t.resume();
System.out.println("Resuming thread Two");
} catch (InterruptedException e) {
System.out.println("Main thread Interrupted");
}
// wait for threads to finish
try {
System.out.println("Waiting for threads to finish.");
ob1.t.join();
ob2.t.join();
} catch (InterruptedException e) {
System.out.println("Main thread Interrupted");
}
System.out.println("Main thread exiting.");
}
}
Sample output from this program is shown here:
New thread: Thread[One,5,main]
One: 15
New thread: Thread[Two,5,main]
Two: 15
One: 14
Two: 14
One: 13
Two: 13
One: 12
Two: 12
One: 11
Two: 11
Suspending thread One
Two: 10
Two: 9
Two: 8
Two: 7
Two: 6
Resuming thread One
Suspending thread Two
One: 10
One: 9
One: 8
One: 7
One: 6
Resuming thread Two
Waiting for threads to finish.
Two: 5
One: 5
Two: 4
One: 4
Two: 3
One: 3
Two: 2
One: 2
Two: 1
One: 1
Two exiting.
One exiting.
Main thread exiting.
The Thread class also defines a method called stop( ) that stops a thread. Its signature
is shown here:
final void stop( )
Once a thread has been stopped, it cannot be restarted using resume( ).
Suspending, Resuming, and Stopping Threads Using
Java 2
While the suspend( ), resume( ), and stop( ) methods defined by Thread seem to be a
perfectly reasonable and convenient approach to managing the execution of threads,
they must not be used for new Java programs. Here’s why. The suspend( ) method
of the Thread class is deprecated in Java 2. This was done because suspend( ) can
sometimes cause serious system failures. Assume that a thread has obtained locks on
critical data structures. If that thread is suspended at that point, those locks are not
relinquished. Other threads that may be waiting for those resources can be deadlocked.
The resume( ) method is also deprecated. It does not cause problems, but cannot be
used without the suspend( ) method as its counterpart.
The stop( ) method of the Thread class, too, is deprecated in Java 2. This was done
because this method can sometimes cause serious system failures. Assume that a thread
is writing to a critically important data structure and has completed only part of its
changes. If that thread is stopped at that point, that data structure might be left in a
corrupted state.
Because you can’t use the suspend( ), resume( ), or stop( ) methods in Java 2 to
control a thread, you might be thinking that no way exists to pause, restart, or terminate
a thread. But, fortunately, this is not true. Instead, a thread must be designed so that the
run( ) method periodically checks to determine whether that thread should suspend,
resume, or stop its own execution. Typically, this is accomplished by establishing a flag
variable that indicates the execution state of the thread. As long as this flag is set to
“running,” the run( ) method must continue to let the thread execute. If this variable is
set to “suspend,” the thread must pause. If it is set to “stop,” the thread must terminate.
Of course, a variety of ways exist in which to write such code, but the central theme will
be the same for all programs.
The following example illustrates how the wait( ) and notify( ) methods that are
inherited from Object can be used to control the execution of a thread. This example is
similar to the program in the previous section. However, the deprecated method calls
have been removed. Let us consider the operation of this program.
The NewThread class contains a boolean instance variable named suspendFlag,
which is used to control the execution of the thread. It is initialized to false by the
constructor. The run( ) method contains a synchronized statement block that checks
suspendFlag. If that variable is true, the wait( ) method is invoked to suspend the
execution of the thread. The mysuspend( ) method sets suspendFlag to true. The
myresume( ) method sets suspendFlag to false and invokes notify( ) to wake up the
thread. Finally, the main( ) method has been modified to invoke the mysuspend( ) and
myresume( ) methods.
// Suspending and resuming a thread for Java 2
class NewThread implements Runnable {
String name; // name of thread
Thread t;
boolean suspendFlag;
NewThread(String threadname) {
name = threadname;
t = new Thread(this, name);
System.out.println("New thread: " + t);
suspendFlag = false;
t.start(); // Start the thread
}
// This is the entry point for thread.
public void run() {
try {
for(int i = 15; i > 0; i--) {
System.out.println(name + ": " + i);
Thread.sleep(200);
synchronized(this) {
while(suspendFlag) {
wait();
}
}
}
} catch (InterruptedException e) {
System.out.println(name + " interrupted.");
}
System.out.println(name + " exiting.");
}
void mysuspend() {
suspendFlag = true;
}
synchronized void myresume() {
suspendFlag = false;
notify();
}
}
class SuspendResume {
public static void main(String args[]) {
NewThread ob1 = new NewThread("One");
NewThread ob2 = new NewThread("Two");
try {
Thread.sleep(1000);
ob1.mysuspend();
System.out.println("Suspending thread One");
Thread.sleep(1000);
ob1.myresume();
System.out.println("Resuming thread One");
ob2.mysuspend();
System.out.println("Suspending thread Two");
Thread.sleep(1000);
ob2.myresume();
System.out.println("Resuming thread Two");
} catch (InterruptedException e) {
System.out.println("Main thread Interrupted");
}
// wait for threads to finish
try {
System.out.println("Waiting for threads to finish.");
ob1.t.join();
ob2.t.join();
} catch (InterruptedException e) {
System.out.println("Main thread Interrupted");
}
System.out.println("Main thread exiting.");
}
}
The output from this program is identical to that shown in the previous section.
Later in this book, you will see more examples that use the Java 2 mechanism of thread
control. Although this mechanism isn’t as “clean” as the old way, nevertheless, it is the
way required to ensure that run-time errors don’t occur. It is the approach that must be
used for all new code.
Sample output from this program is shown here:
New thread: Thread[One,5,main]
One: 15
New thread: Thread[Two,5,main]
Two: 15
One: 14
Two: 14
One: 13
Two: 13
One: 12
Two: 12
One: 11
Two: 11
Suspending thread One
Two: 10
Two: 9
Two: 8
Two: 7
Two: 6
Resuming thread One
Suspending thread Two
One: 10
One: 9
One: 8
One: 7
One: 6
Resuming thread Two
Waiting for threads to finish.
Two: 5
One: 5
Two: 4
One: 4
Two: 3
One: 3
Two: 2
One: 2
Two: 1
One: 1
Two exiting.
One exiting.
Main thread exiting.
4.1.4 Life cycle of thread,

4.1.5 Using thread method,
Java’s multithreading system is built upon the Thread class, its methods, and its
companion interface, Runnable. Thread encapsulates a thread of execution. Since
you can’t directly refer to the ethereal state of a running thread, you will deal with it
through its proxy, the Thread instance that spawned it. To create a new thread, your
program will either extend Thread or implement the Runnable interface.
The Thread class defines several methods that help manage threads. The ones
that will be used in this chapter are shown here:

Method name
Description
getName
getPriority
isAlive
join
run
sleep
start
Obtain a thread’s name.
Obtain a thread’s priority.
Determine if a thread is still running.
Wait for a thread to terminate.
Entry point for the thread.
Suspend a thread for a period of time.
Start a thread by calling its run method.

Thus far, all the examples in this book have used a single thread of execution. The
remainder of this chapter explains how to use Thread and Runnable to create and
manage threads, beginning with the one thread that all Java programs have: the
main thread.
4.1.6 Thread exceptions,
4.1.7Thread priority,
Java assigns to each thread a priority that determines how that thread should be treated with respect to the others. Thread priorities are integers that specify the relative priority of one thread to another. As an absolute value, a priority is meaningless; a higher-priority thread doesn’t run any faster than a lower-priority thread if it is the only thread running. Instead, a thread’s priority is used to decide when to switch from
one running thread to the next. This is called a context switch. The rules that determine when a context switch takes place are simple:
¦ A thread can voluntarily relinquish control. This is done by explicitly yielding, sleeping, or blocking on pending I/O. In this scenario, all other threads are examined, and the highest-priority thread that is ready to run is given the CPU.
¦A thread can be preempted by a higher-priority thread. In this case, a lower-priority thread that does not yield the processor is simply preempted—no matter what it is doing—by a higher-priority thread. Basically, as soon as a higher-priority thread wants to run, it does. This is called preemptive multitasking.
In cases where two threads with the same priority are competing for CPU cycles, the
situation is a bit complicated. For operating systems such as Windows 98, threads of equal priority are time-sliced automatically in round-robin fashion. For other types of operating systems, threads of equal priority must voluntarily yield control to their peers.If they don’t, the other threads will not run. Problems can arise from the differences in the way that operating systems context-switch threads of equal priority.
4.1.8 Synchronization
Because multithreading introduces an asynchronous behavior to your programs, there
must be a way for you to enforce synchronicity when you need it. For example, if you
want two threads to communicate and share a complicated data structure, such as a
linked list, you need some way to ensure that they don’t conflict with each other. That
is, you must prevent one thread from writing data while another thread is in the
middle of reading it. For this purpose, Java implements an elegant twist on an age-old
model of interprocess synchronization: the monitor. The monitor is a control mechanism
first defined by C.A.R. Hoare. You can think of a monitor as a very small box that can
hold only one thread. Once a thread enters a monitor, all other threads must wait until
that thread exits the monitor. In this way, a monitor can be used to protect a shared
asset from being manipulated by more than one thread at a time.
Most multithreaded systems expose monitors as objects that your program must
explicitly acquire and manipulate. Java provides a cleaner solution. There is no class
“Monitor”; instead, each object has its own implicit monitor that is automatically entered
when one of the object’s synchronized methods is called. Once a thread is inside a
synchronized method, no other thread can call any other synchronized method on
the same object. This enables you to write very clear and concise multithreaded code,
because synchronization support is built in to the language.
4.1.9 Implementing a ‘Runnable’‘ Interface
Implementing Runnable
The easiest way to create a thread is to create a class that implements the Runnable
interface. Runnable abstracts a unit of executable code. You can construct a thread on
any object that implements Runnable. To implement Runnable, a class need only
implement a single method called run( ), which is declared like this:
public void run( )
Inside run( ), you will define the code that constitutes the new thread. It is
important to understand that run( ) can call other methods, use other classes, and
declare variables, just like the main thread can. The only difference is that run( )
establishes the entry point for another, concurrent thread of execution within your
program. This thread will end when run( ) returns.
After you create a class that implements Runnable, you will instantiate an object of
type Thread from within that class. Thread defines several constructors. The one that
we will use is shown here:
Thread(Runnable threadOb, String threadName)
In this constructor, threadOb is an instance of a class that implements the Runnable
interface. This defines where execution of the thread will begin. The name of the new
thread is specified by threadName.
After the new thread is created, it will not start running until you call its start( )
method, which is declared within Thread. In essence, start( ) executes a call to run( ).
The start( ) method is shown here:
void start( )
Here is an example that creates a new thread and starts it running:
// Create a second thread.
class NewThread implements Runnable {
Thread t;
NewThread() {
// Create a new, second thread
t = new Thread(this, "Demo Thread");
System.out.println("Child thread: " + t);
t.start(); // Start the thread
}
// This is the entry point for the second thread.
public void run() {
try {
for(int i = 5; i > 0; i--) {
System.out.println("Child Thread: " + i);
Thread.sleep(500);
}
} catch (InterruptedException e) {
System.out.println("Child interrupted.");
}
System.out.println("Exiting child thread.");
}
}
class ThreadDemo {
public static void main(String args[]) {
new NewThread(); // create a new thread
try {
for(int i = 5; i > 0; i--) {
System.out.println("Main Thread: " + i);
Thread.sleep(1000);
}
} catch (InterruptedException e) {
System.out.println("Main thread interrupted.");
}
System.out.println("Main thread exiting.");
}
}
Inside NewThread’s constructor, a new Thread object is created by the following
statement:
t = new Thread(this, "Demo Thread");
Passing this as the first argument indicates that you want the new thread to call the
run( ) method on this object. Next, start( ) is called, which starts the thread of execution
beginning at the run( ) method. This causes the child thread’s for loop to begin. After
calling start( ), NewThread’s constructor returns to main( ). When the main thread
resumes, it enters its for loop. Both threads continue running, sharing the CPU, until
their loops finish. The output produced by this program is as follows:
Child thread: Thread[Demo Thread,5,main]
Main Thread: 5
Child Thread: 5
Child Thread: 4
Main Thread: 4
Child Thread: 3
Child Thread: 2
Main Thread: 3
Child Thread: 1
Exiting child thread.
Main Thread: 2
Main Thread: 1
Main thread exiting.
As mentioned earlier, in a multithreaded program, often the main thread must
be the last thread to finish running. In fact, for some older JVMs, if the main thread
finishes before a child thread has completed, then the Java run-time system may
“hang.” The preceding program ensures that the main thread finishes last, because
the main thread sleeps for 1,000 milliseconds between iterations, but the child thread
sleeps for only 500 milliseconds. This causes the child thread to terminate earlier than
the main thread. Shortly, you will see a better way to wait for a thread to finish.

Responses

Author: Hawre mohommed iqbal abdul kayyum 29 Mar 2008

Member Level: Bronze Points : 2

I am prof Hawre M.A working as lecturer in pune. My aim is to make a dedicated site for students to solve their all sort of problems.if u have any queries plz ask

Author: Chithra 24 May 2008

Member Level: Gold Points : 2

nice information

Author: kondapalli 28 May 2008

Member Level: Gold Points : 2

good information for learners

Feedbacks

Popular Tags

What are tags ?

Search Tags

(No tags found.)

Post Feedback

This is a strictly moderated forum. Only approved messages will appear in the site. Please use 'Spell Check' in Google toolbar before you submit.
You must Sign In to post a response.

	Next Resource: The Ultimate House Training Guide!
	Previous Resource: Free E-books
	Return to Discussion Resource Index
	Post New Resource
	Category: E-Books

Post resources and earn money!

Related Resources

Fresher Jobs

Resources

Colleges

Exception Handling and multi threading

Responses

Post Feedback