Sleep and Yield.. Am i correct??

[Doit]

Interrupt can be used to make threads eligible to run from sleep() and yield() states.
yield() method does not throw any exception while sleep()
method throws Interrupted Exception.
- Thanks

[Ajith Kallambella]

The fact is, interrupt() stops a running/sleeping thread and moves it into ready state.
Ajith

[Marcela Blei]

I wanna treat this topic deeper because I think I will be considered harder in the new exam.
1 - It�s important to see which are static and which are instance methods of the Thread class. Sleep() and yield() are class methods (static), so they work over the current running thread.
2 - Interrupt() and wait() (last one inherited from object) are instance methods, so you can modify the execution of a running or runnable(wainting for run) thread, you can take an action over a thread that isn�t the current running thread.
3 - Locking and executing are different topics but an InterruptedException may be throw on both, this is a very important point to identify.
4 - Sleep(), yield() and interrupt() work over executing process (I mean by this, the operations that fight for gaining the attention of the processor)
5 - wait() and interrupt() work over locking.
6 - yield() is the most easy method to understand because it is executing on the current thread and gives the processor to other thread for execution, this means: I want to stop running temporaly now, let�s give the processor to other thread for running (you can�t choose what thread will begin to run).
7 - Note that when there is no other thread waiting for taking the processor attention it will pause for a very little time (it gives the processor to other thread, but there�s no other thread requiring the processor, so it returns the attention to the thread that called the yield)
8 - wait() and sleep() are methods that must be put winthin a try-catch statement because they can throw an InterruptException, when you call the interrupt() method for a thread (this may be done within another thread)then you are generating that these methods of the first thread (the thread that calls the wait or sleep), throw the InterruptException.
9 - Notice that you can call the interrupt() method for a thread that could not be executing within a try-catch statement. eg.

public void run() {
   while (true) {
   //...where the code hasn�t got a try -
   catch statement cause you are not   
   calling a sleep or wait
   } 
}

Hope I didn�t confuse you, ask me what you want.
[This message has been edited by Marcela Blei (edited August 25, 2000).]

[Marcela Blei]

Please correct me if I am wrong with any concept, I will like to discuss this further

[Ajith Kallambella]

Here are my two cents worth.
#8 as you wrote "wait() and sleep() are methods that must be put winthin a try-catch statement"
Sorry for being picky, but just like any checked exception, they should either be caught OR the enclosing method can delcare InterruptedException in the throws clause. Either approach is legal.
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.
Ajith

[Anonymous]

What's the relationship between interrupt() and InterruptedException? would every interrupt()call throws an
InterruptedException? or would every InterruptedException come from an interrupte() call? I am confused.

[Doit]

Ajit,
you said interrupt() stops a running/sleeping thread and moves it into ready state...
Does that menas Interrupt can not be used to make any effect on an yielded thread(Presently in Ready to run state),
thread in wait state?
- Thanks
[This message has been edited by Doit (edited August 25, 2000).]

[Ajith Kallambella]

DoIt,
That's a good question.
I presume, in such a case, the next time the thread starts running the InterruptedException is thrown. Infact, when you issue interrupt() on a thread an internal flag is set on the thread to indicate it should stop as soon as possible . This is called "state based" signaling. You can use the methods on the Thread class isInterrupted() and interrupted() to check if the thread has received an interrupt() call.
Lets go too much into this topic as it is most likely to confuse others. You are welcome to discuss this in the Threads Forum. For the SCJP exam, let's say it is necessary and sufficient if you know what happens when an interrupt() call is issued on a running thread and what are the methods that throws InterruptedException.
Hope this helps,
Ajith

[Doit]

Thanks Ajit.
Can you please summarise this by giving one liners for..
What interrupt() does when a thread is
In running state?
In sleeping state?
In yielding state?
In waiting state?
- Thanks.

[Jim Yingst]

Originally posted by Doit:
Thanks Ajit.
Can you please summarise this by giving one liners for..
Sorry, one-liners aren't really possible here.
What interrupt() does when a thread is
In running state?
I don't know if the thread will necessarily move to ready state as Ajith says. Threads can move back and forth from running to ready all the time anyway, so this doesn't make too much difference.
No exception is thrown. However the interrupted flag is set, which means that if you call interrupted() or isInterrupted(), they will return true. If the thread later goes from running state to waiting or sleeping state before interrupted flag is cleared via interrupted() method, then an InterruptedException will be thrown and the flag will be cleared.
In sleeping state?
The thread moves into ready state, and when it next gets a chance to execute an InterruptedException is thrown. No flag is set, so interrupted() returns false.
In yielding state?
There is no yielding state. Thread.yield() moves a thread from running state to ready state. If an interrupt() is called while a thread is in ready state, nothing happens until the thread moves back to running state. [Except, as Ajith says, this move may well occur sooner than it would have if interrupt() hadn't been called. I'm not sure about this part.] Once the thread has moved to running state, then see answer for running state, above.
In waiting state?
Same as for sleeping state above.
- Thanks.

I'm moving this discussion to the Threads topic now...

[This message has been edited by Jim Yingst (edited August 25, 2000).]

[Jim Yingst]

May- short answer: all InterruptedExceptions are caused by interrupt() calls (as far as I know), but not all interrupt() calls cause InterruptedExceptions. It depends on what the interrupted thread was doing - see my last post for details.

[Jim Yingst]

Marcela-
#2: Although wait() is an instance method inherited from Object, the thread it affects is always the current thread. When you have the statement
<code><pre> someObject.wait();</pre></code>
This forces the current thread to go into wait mode. What it's waiting for is a notify() or notifyAll() from someObject. Or an interrupt() from anywhere, of course.
#3-5: I don't know what you mean here; sorry.

[Mapraputa Is]

Marcela, please, explain, what happens if the current thread performs synchronized code: it will be forces to give the processor to other thread immediately (and what about lock?) or after synchronized code is finished?

[Marcela Blei]

#2: Although wait() is an instance method inherited from Object, the thread it affects is always the current thread. When you have the statement
<code><pre> someObject.wait();</pre></code>
This forces the current thread to go into wait mode.

That�s an important thing Jim, thanks for correcting me.

#3-5: I don't know what you mean here; sorry.

I was trying to tell the differences between locking (wait & notify) and threads behaviour. The fighting between for owning the processor and the fighting for owning an object which requires locks (synchronized code).
This are independent tasks, regardless they have a connection between them.
You can have a lock on an object and if you have a high priority you don�t return the processor to other thread until your process ends.
Another point: remember that wait releases the lock on and object.
I put this message on the Certification Forum because in the Beta there where really hard questions about threads.