stop a thread (help Rahul M. )

[Anonymous]

which of the following methods can stop a thread ?
1. stop()
2. wait()
3. MediaTracker.waitForID()
4. interrupt()
5. interrupted()
6. sleep()
7. yield()
8. suspend()
I am confused about interrupt() and interrupted(). what is the difference and do they stop a thread?
Thanx,
Padmanabh

[Serge Plourde]

Hi Padmanabh,
If you mean "end" the thread, then there is only one method
that does this: stop()!
The thread could stop() itself, or another thread could invoke
this thread's stop() method.
Finally, all threads will "stop" (end) on "exit"ing the application.
Have a look at:
http://java.sun.com/docs/books/jls/html/javalang.doc18.html#2658
Now, if you talk about changing a thread state from running to
either waiting or ready, then you can also use the methods that
you mentioned: 2, 6, 7.
I don't currently remember about the others right now.

[Rahul Mahindrakar]

I think you are looking out for a difference between
public void interrupt()
public static boolean interrupted()
and whether they stop a thread.
BOTH these do not stop a thread.
interrupt() is a means to stop a thread but does not stop a thread by itself. A thread maintains a boolean variable. This variable is set to true when the thread is interrupted by interrupt(). The run method must check in its loop whether this has been set to true like the code below to stop the run method from undertaking any more loops.
public void run(){
while(Thread.isInterrupted()){
// work done here stops when interrupt() is called
}
}
the interrupt method is defined as
"An interrupt request is posted for this thread. This thread does not necessarily react immediately to the interrupt, however. If this thread is waiting, it is awakened and it then throws an InterruptedException. "
public static boolean interrupted()
The result is true if and only if an interrupt request has been posted for the current thread. This method is used to check up whether interrupt() has been called on this thread and to stop execution of the while loop when the next loop is undertaken.

------------------
Regds.
Rahul P. Mahindrakar

[Anonymous]

1. <code>stop()</code> does stop the thread, through a rather interesting mechanism. But it's deprecated; don't use it.
2. <code>wait()</code> and its timed variants move the thread to the "waiting" state. The thread stops running. When it moves out of "waiting" it will have to reacquire the lock of the object on which <code>wait()</code> was called and will then be eligible to run again.
3. <code>MediaTracker.waitForID()</code> - see below
4, 5, 5a. <code>interrupt()</code>, <code>interrupted()</code>, and <code>isInterrupted()</code> do not stop the thread. If the thread is in "ready" or "running", <code>interrupt()</code> merely sets the thread's interrupted flag. The thread may check the status of this flag with either of the other two methods. A call to <code>interrupted()</code> returns the interrupted flag value and resets the flag to <code>false</code>. <code>isInterrupted()</code> returns the interrupted flag value but does not reset its value. If the thread is in "sleeping", then

<code>interrupt()</code> sets the interrupted flag

the thread leaves "sleeping" and enters "ready"

as soon as the thread begins "running" it throws an <code>InterruptedException</code> and the flag is cleared

note that calls to the query methods will never return <code>true</code> in this case - the flag is cleared before you can test it.

If the thread is in "waiting", then the behavior is the same as if it were "sleeping", but the thread must contend for the monitor's lock before reentering "ready".
6. <code>sleep()</code> does not stop the thread. The thread leaves "running" and enters "sleeping". When the sleep expires or the thread is interrupted, it will reenter "ready" and therefore be eligible to run again.
7. <code>yield()</code> does not stop the thread. The thread leaves "running" and enters "ready". It remains eligible to run.
8. <code>suspend()</code> moves the thread from "running" to "suspended" without releasing any locks. This thread's <code>resume()</code> method must be called from some other thread to move the thread back to "ready". If the other thread needs a lock held by this thread, deadlock results. <code>suspend()</code> is deprecated; don't use it.
To see a more visual representation of these thread states, look at my recent post on Thread States.
Whew. Answering your question made me realize I've got a couple of blank spots (thanks):
1. Does anyone know what happens if <code>interrupt()</code> is called when a thread is not waiting or sleeping but is contending for a lock?
2. I've never used the <code>MediaTracker.waitXXX</code> methods. Does anyone know whether they're like <code>wait()</code> or like <code>sleep()</code>? Does the thread relinquish any locks when using these methods?

[Rahul Mahindrakar]

7. yield() does not stop the thread. The thread leaves "running" and enters "ready". It remains eligible to run.

The question was which of these can stop a thread.
yield may stop a thread or may not. This depends upon other threads running and their priorities.

------------------
Regds.
Rahul P. Mahindrakar

[Marcela Blei]

1. Does anyone know what happens if <code>interrupt()</code> is called when a thread is not waiting or sleeping but is contending for a lock?
Maha Anna gave a detail explanation in the Certification Forum. Resumming: When interrupt is called and a thread is not waiting or sleeping you have to called the interrupted() or isInterrupted() methods for checking that the interrupt flag was set on, in other words: you have to take mannually the control of the situation. I understand that if a thread is contending for a lock and is in a running state you could do nothing.
2. I've never used the <code>MediaTracker.waitXXX</code> methods. Does anyone know whether they're like <code>wait()</code> or like <code>sleep()</code>? Does the thread relinquish any locks when using these methods?[/B]
This topic was treated in the Certification Forum too, waitForID() blocks the thread, the same behaviour as when you use IO classes.

[Anonymous]

Marcela;
Regarding my question #1: got it, thanks.
Re #2: So I take it the thread blocks and the <code>MediaTracker</code> object uses itself as a monitor, and the thread does not relinquish any locks it holds on other objects. Let me know if that's not right. TIA, jply.
Rahul;
But it's still eligible to run, so it's not really stopped. I was taking the viewpoint that "stop" meant the same thing as the result of calling <code>stop()</code>, i.e. the thread dies. If you take the viewpoint that "stop" means simply to cease execution temporarily then <code>yield()</code> will definitely "stop" the thread. The scheduler may run it again immediately depending on relative priorities, but <code>yield()</code> always moves the thread from the "running" to the "ready" state. If you take this meaning of "stop" then it could be said that <code>wait()</code>, <code>sleep()</code>, <code>suspend()</code>, and entering <code>synchronized</code> code also "stop" the thread.
[This message has been edited by jply (edited September 08, 2000).]

[Rahul Mahindrakar]

jply,
You are right when about the word "stop". It has two meanings. the thread terminates
the thread stops execution temporarily or permanently.
In the first case only stop() method stops a thread. that is why it has been deprecated. But since it is a multichoice question i think he means the second case. Hence the answer to yield(). As you said

"If you take this meaning of "stop" then it could be said that wait(), sleep(), suspend(), and entering synchronized code also "stop" the thread."

Note also that entering a synchronized code does not necessarily stop a thread. It is only if some other thread is already holding a lock does the current thread stop.

------------------
Regds.
Rahul P. Mahindrakar

[Marcela Blei]

Re #2: So I take it the thread blocks and the <code>MediaTracker</code> object uses itself as a monitor, and the thread does not relinquish any locks it holds on other objects. Let me know if that's not right. TIA, jply.

I want to make an important difference between lock and block. Lock belongs to all the actions performed with the synchronized blocks/methods and wait() mechanisms.
Block applies when actions involve SO resources like IO actions, for example: when you have to read a file from a hard disk drive, then the thread is blocked until the file is read. You have no control about the blocking state there. MediaTracker works like IO classes. Look that when a thread is blocked the processor could preempted another thread. The blocked thread will still be blocked until it�s IO action finishes.
[This message has been edited by Marcela Blei (edited September 11, 2000).]