Don't really understand Thread.yield()

[qjzhu]

Gurus,

The SDK Document reads the following for Thread.yield():

* Causes the currently executing thread object to temporarily pause
* and allow other threads to execute.

I don't really understand what this sentence says. What's happening
if a thead calls yield()? Will the thread be hung up instantly?
When will the thread continue to excute? What's the difference between
sleep() and yield()?

The Thinking In Java 3rd is describing yield() like this:

* If you know that you¡¯ve accomplished what you need to in your
* run() method, you can give a hint to the thread scheduling
* mechanism that you¡¯ve done enough and that some other thread
* might as well have the CPU.

What does the "done enough" mean? Any real examples?
And it continues to say:

* yield( ) is useful only in rare situations, and you can¡¯t
* rely on it to do any serious tuning of your application

What's the real usage in those so called 'rare situations'? Why does
anyone feel like to use yield() if you can't rely on it?

Sorry I totally don't understand the context of yield(), could anyone
explain the whole history of it? Thank you very much and sorry for such
a newbie question.

 

[Alexey Dmitriev]

qjzhu wrote:

Gurus,

The SDK Document reads the following for Thread.yield():

* Causes the currently executing thread object to temporarily pause
* and allow other threads to execute.

I don't really understand what this sentence says. What's happening
if a thead calls yield()? Will the thread be hung up instantly?
When will the thread continue to excute? What's the difference between
sleep() and yield()?

If you want to learn more thoroughly about threads I to you strongly
recommend to buy to gain the book "Java Threads, 2nd edition", Scott
Oaks&Henry Wong. O'Reilly has published it.
For example, in it there is an answer to your answer.
....
What actually happens when a thread yields?
======================================================================
In terms of the state of the thread, nothing happens:
the thread remains in the runnable state. But logically, the thread is
moved to the end of its priority
queue, so the Java virtual machine picks a new thread to be the
currently running thread, using the
same rules it always has. Clearly, there are no threads that are higher
in priority than the thread that
has just yielded, so the new currently running thread is selected among
all the threads that have the
same priority as the thread that has just yielded. If there are no other
threads in that group, the
yield() method has no effect: the yielding thread is immediately
selected again as the currently
running thread. In this respect, calling the yield() method is
equivalent to calling sleep(0).
If there are other threads with the same priority as the yielding
thread, then one of those other threads
becomes the currently running thread. Thus, yielding is an appropriate
technique provided you know
that there are multiple threads of the same priority. However, there is
no guarantee which thread will
be selected: the thread that yields may still be the next one selected
by the scheduler, even if there are
other threads available at the same priority.
....

 

[Brian S O'Neill]

I often use yield in tight server loops after an exception is caught.
This temporarily lowers the priority of the thread, so that if the loop
is in an "infinte errors" state, the server doesn't hog resources.

 

[Roedy Green]

yield just says, end my timeslice prematurely, look around for other
threads to run. If there is nothing better than me, continue.

Sleep says I don't want to run for x milliseconds. Even if no other
thread wants to run, don't make me run.

see http://mindprod.com/jgloss/thread.html