Mani,
The situations at which InterruptedException is thrown 1. InterruptedException is checked Exception right? So all the Thread related methods which have to be kept inside a try-catch-InterruptedException have to be considered. If you take the Thread class there are
sleep(..) ,join(..) are the only methods which throw Interrupted Exception. Since Thread class is direct subclass of Object class we have to verify in Object class's methods also since they too are inherited to Thread class.
In Object class there is
only one method which is wait(...) which has to be kept inside a try-catch-InterruptedException block. So now we have totally 3 methods in our hand which may throw InterruptedException when called on an object.
1. sleep(..) when you call myT.sleep(..) this means the thread myT just sleeps for so much (arg) secs doing nothing. Also remember it still hold the locks if it has any tightly
. Also note that in order to sleep(..) , the myT doesn't need to obtain the objects lock first. It is the wait(..)/notify()/notifyAll() set of methods which have to obtain the lock first. So this sleeping thread is in
waiting state and it may come out of the sleep mode in 2 ways. one, it wakes up on its own.
The other, some other thread , say it is
otherT ,interrupts its sleep
by invoking myT.interrupt() in one of its methods inside otherT's class. For the 2nd case, if the sleeping thread is in fact interrupted, then an
InterruptedException is thrown and this sleeping thread comes out of waiting state and goes directly to Ready state. The next time when the Thread scheduler schedules this woke up thread for execution, then only the catch(InterruptedException e) { } block will be executed. So this is one situation where an InterruptException may be thrown by a thread.
2. The other method is
join(..) . This method also has to be kept inside try-catch-InterruptedException block , and when this method is called on a thread object, say mtT.join(..), then myT waits for the death of its own upto so much secs. When you put myT.join(1000) , it means myT thread waits for a second of there is any chance of death of the thread , if not, it continues. During this wait mode if some other thread interrupts by calling interrupt() on this thread, then InterruptedException will be thrown. join() without arg means wait forever for this thread to die.
Try this
<pre>
class
Test extends Thread {
public void run() {
for(int i=0; i<100; i++) {
System.out.println("i="+i);
if(i==50) {
try {
this.join(1000);
//Thread.currentThread().join(1000);
}catch(InterruptedException e) {
System.out.println(e);
}
}
}
}
public static void main(
String[] args) {
new Test().start();
}
}
</pre>
3. The 3rd method is wait(..)
This again has to be inside try-catch-Inter...Excep.. block. A thread myT ,which called wait(..) may throw InterruptedException in 3 occations.
(i) When another thread calls myT.interrupt()
(ii) When another thread calls myT.notify()
(iii)When another thread calls myT.notifyAll()
Also note that the myT thread which called wait() had immediately released all the locks which it obtained on this object. The outsider thread which calls notify()/notifyAll() MUST have the SAME OBJECT'S LOCK which the waiting thread had released before. Also note that there is a pool of waiting threads for each object which are just waiting to somhow obtain the lock and want someone to notify. In order to notify the correct set of waiting pool of threads , the notifying thread mUST have the SAME LOCK which the waiting threads expect. Then only there will be synchronization in talk. No miss communication.
The other case which is through calling the interrupt() on a waiting thread also can throw InterruptedException.
wait() causes InterruptedException when some other Thread's notify() or notifyall() is called. This statement of yours slightly has to be changed. It is NOT when some other
Thread's notify or notifyAll() is called. It is when some other
Thread calls notify/notifyAll()
sleep() causes interrupt to be called on the Thread which causes InterruptedException. sleep() on its own does not cause any exception. It is when some other thread interrupts this sleeping thread.
So I think whenever InterruptedException is thrown,Thread is stopped. No. It is not correct. There is no direct connection between InterruptedException and a thread being stopped. IT is those three methods sleep(..)/wait(..)/join(..) which causes the thread to stop.
Other than all these possiblities, a thread may be stopped when its stop()/suspend()/ is called. Also when the thread is blocked on something to happen. For example reading a block of data over the internet from a far-away remote server. One more possiblity is When another thread of higher priority thread comes to the Ready state. All these discussion , I assumed stop() means either temporary or permanent stop of a thread.
Satya,
interrupt() causes SecurityException means, the outsider thread which invokes the interrupt on our poor thread myT
only throws SecurityException. THis does not mean our interrupted myT thread ,throws the SecurityException. Do you get the point?. Any thread can't interrupt any other thread just like that. The thread which is going to interrupt() another thread , first has to undergo some security checks by JVM. If it does not pass this check,
then the outsider thread has no rights to interrupt our myT thread.
regds
maha anna
[This message has been edited by maha anna (edited April 27, 2000).]
