Stopping of Thread

[Shailendra Bade]

Q.1 Can a interupted() stop a running thread?
My answer is NO because IMO interrupted() is used to interupt
a sleeping or waiting thread to come in a ready to run state.
Please correct me if I am wrong.

Q.2) Does a current thread suspends, when a file is opened for reading
and writing ? (TRUE/FALSE)

[Mapraputa Is]

Q1.
Read this nice explanations.
Q2. This is source code for FileInputStream's read() method:

    /**
     * Reads a byte of data from this input stream. This method blocks
     * if no input is yet available.
     *
     * @return     the next byte of data, or <code>-1</code> if the end of the
     *             file is reached.
     * @exception  IOException  if an I/O error occurs.
     */
    public native int read() throws IOException;

My understanding: I/O methods use some functions of underlying OS, which BLOCK a current thread. I read somewhere that in this case other threads can work, but I am not sure.

[geetha]

Hi Marupatha,
can u give me a single word ans for my Question.(yes or no)
can an Interruptedexception stops a thread from executing...?
I had gone through ur nice explanation link but ended up in confusion.pl help regd thos as Iam going to write my exam tomorrow.
geetha

[Anonymous]

Geetha,
Answer is NO!
InterruptedException is thrown by methods sleep() and wait().
When InterruptedException is thrown the sleeping or waiting thready goes into ready-to-run state. Once it gets to run, InterruptedException is thrown. In case we catch this exception then things would resume after that point - in which case the thread does not stop its execution!
Now, in general, if an exception is thrown, we know that it can be caught and execution can be continued from that point. If the exception is not caught, it would traverse up in the heirarchy unless it is caught by exception handler. If there is no handler, then the current thread dies and a stack trace of the exception is displayed.
Hope this helps
Btw, Mapraputa IS, I completely agree with regarding the excelent explanation on this topic here. I had this doubt about what happens when we call interrupt on a running Thread - its not cleared. Thanks everybody!
-sampaths77

[Mapraputa Is]

can an Interruptedexception stops a thread from executing...?
Here is a cite from Ajith Kallambella message:
�Also note that interrupt() is the recommended way to stop a running thread in JDK1.2 onwards. According to people at Sun, it is better than using the depricated method stop() as it is less likely to leave the locks in an inconsistent state as stop() did.�
I think answer is YES.
But if questions were formulated as WILL an Interrupted exception stops a thread from executing...? - then answer would be NO, since there is no guarantee that a thread will be stoped.

[Anonymous]

Mapraputa,
I beg to differ from your opinion :
Let's first get the question correct:
Question 1: can an Interruptedexception stops a thread from executing...?
my ans: As Ajith says that interrupt is the recommended way to stop is thread, but please note that an EXCEPTION IS NOT THROWN when the thread moves from running to ready-to-run-state. (please refer to what Jim says in the discussion you pointed us to)
In fact just an internal flag is set indicating that the thread must be stopped shortly.
So, we have the folloing situations:
In case the thread into one of WAITING or SLEEPING state then an InterruptedException is thrown and the thread moves into ready-to-run-state.
WHEN THE THREAD GETS TO EXECUTE, its excution will resume from exception handler block(if provided).
In case the thread stops without getting into any of the waiting or sleeping state then NO EXCEPTION IS THROWN AND THERE IS NO QUESTION OF AN InterruptedException STOPPING A THREAD.

my Conclusion:
The question stated above cannot be answered with a straight yes or no with the given data. We need to make some assumptions from the exam point of view.
So, I assumed that :
(1) The given question is for a thread that was sleeping or waiting coz it does not make much sense for this question to be asking about a running thread ( But I presume your answer was in this context).
(2)That the caller might have provided some handler for the checked exception - InterruptedException and hence I inclined towards saying NO as an answer.
But your point of view is more valid here: realizing the subtle difference btw CAN & WILL - I would now change my answer to YES.

I just hope that we don't get question worded ambiguously. It seems more to be an English language test rather than Java. Just hope that we don't get things wrong because of the wordings even though we have a clear idea about the concept.
So, what does everybody else say ?
-sampaths77

[Anonymous]

Btw, I just realized that we guys have gone a bit off the track from the main question Shailendra put up.
Q1: YES
Q2: NO, coz the thread maybe blocked if it has to wait for data. So, once again going with analyzing the sentence, I would be inclined to choose NO as an anwser coz it says that a thread will be suspended when reading data.
-sampaths77

[Aru]

Hi All,
Take a look at this question
5-What might cause the current thread to stop executing.

A.An InterruptedException is thrown. - False
B.The thread executes a wait() call. - True (temporary stop)
C.The thread constructs a new Thread. - False
D.A thread of higher priority becomes ready. - False
E.The thread executes a waitforID() call on a MediaTracker.-True
Am I right ?
Thanks,

[Anonymous]

Oh my God ! I guess this is getting into an infinite loop
Aru, the answers I'd opt for are as follows, but I really wish if someone (Ajith or Maha or Tony etc ) give their final word on this:
A.An InterruptedException is thrown.
- debatable. but TRUE for exam
But from the wordings of the question we can see the "what MIGHT".
So, I'd opt for TRUE. For eg, if the exception is not handled the current thread might be stopped and a stack trace will be displayed.
B.The thread executes a wait() call.
-TRUE
C.The thread constructs a new Thread.
-FALSE
D.A thread of higher priority becomes ready.
-debatable but TRUE for exam.
It depends on the actual implementattion of thread scheduling(time-sliced or pre-emptive).But from the exam point of view I'd opt for TRUE coz in theory at some point in the near future, the higher thread of higher priority WILL get to execute and this MIGHT cause the current thread to stop executing.
Just another point:
For the question Shailendra asked:
an a interupted() stop a running thread?
I presume he meant the interrupt() method and not InterruptedException. Under this presumption, I'd opt for TRUE.
-sampaths77
-TRUE may cause the thread to be blocked and hence the thread MIGHT stop executing.

[Mapraputa Is]

Wow, sampaths77, you did a great job, while I was sleeping
I also hope we will not get ambiguous questions on real exam, Actually everybody Certificated said that questions were well worded and not ambiguous, but we should pay special attention to all these �can�, �might�, �will��
BTW, question �what can stop a thread� is especially ambiguous, because the word �stop� can have two meanings: to move a thread to dead state, and to move a thread to one of blocked (waiting) states. In Aru�s questions we see only choices for the second variant, but that�s enough to add f) stop() or g) System.exit() method call and nobody can tell what the word �stop� means now.
I can only hope we will not get such questions on exam�

[Aru]

Sampath,
D.A thread of higher priority becomes ready.
I think this is False bcoz not always when an higher priority thread becomes ready, the current running thread stops....
Aruna

[Ajith Kallambella]

I am transferring this post to Threads and Synchronization forum where it can attract( hopefully ) more attention
Ajith

[mohit joshi]

I was reading a thread book today and could not find how any interrupt() invoking can stop the thread by it self. I think one has to explicitly check for isInterrupted, and return from the run method if you want the thread to stop at this point. This procedure is also not fool proof, because if the thread is blocked in an I/O, then it will not interrupted in response to
the interrupt().There is a work around for this by creating a seperate thread for I/O and another one for handling interrupt().
But after all, is "checking isInterrupted and exiting" preferred mode of stopping threads, or we should use our own variables?
Am i getting it right?
I wrote a small code to check if interrupt() stops a thread. well
it doesnt, whether it is blocked or not.

[Ashik Uzzaman]

Hi all, i m restarting a dead post here. Should we say that--
An interrupted exception will eventually (immediately or after a while) stop a thread excuting or eventually kill it.
------------------
azaman

[Anonymous]

Ashik uzzaman wrote:
>> Hi all, i m restarting a dead post here. Should we say that--
>> An interrupted exception will eventually (immediately or
>> after a while) stop a thread excuting or eventually kill it.
I'm pretty sure that's inaccurate. To explain why, let's first delve into the interrupt method and the InterruptedException.
The Thread.interrupt() method marks a thread as interrupted. This is used to indicate that some operation is taking too long and should be aborted. The wait and sleep methods sporadically check the interrupted flag. If it is set, they abort the operation by throwing an InterruptedException. This, by itself, does not cause the current Thread to stop. It is no different than any other exception (except for the cause).
Eg.
try {
wait();
}
catch(InterruptedException ie) {
// ...
}
In this case, the thread will continue in the handling code. It will not stop the thread.
If the wording of the question really is "what MIGHT cause the current thread to stop executing" a stop is interpretted as moved out of the Ready state, then any of them can be true.
If the question is which WILL cause the current thread to immediately switch out of the running state:
A: false
B: true
C: false
D: false
E: true