9

I know one difference:

If we say thread.sleep(1000), that thread will sleep for 1000 milliseconds for sure, whereas with yield() there is no such guarantee. This is useful for thread scheduling, since the thread which calls yield() may very well selected immediately again for running.

What else?

Bhushan
  • 18,329
  • 31
  • 104
  • 137
  • "If we say th.sleep(1000), that thread will sleep for 1000 milliseconds" -- No. `sleep` is a static method, and calling it always causes the *current* thread to sleep, not `th` (unless `th` happens to be the current thread). Your compiler/IDE should give you a warning if you write `th.sleep`. – Tyler Sep 01 '11 at 00:04

4 Answers4

17

Thread.sleep()

  1. The current thread changes state from Running to Waiting/Blocked as shown in the diagram below.
  2. Any other thread with reference to the thread currently sleeping (say t) can interrupt it calling t.interrupt()
    • the call to sleep has to be encapsulated to catch the checked exception of InterruptedException
  3. After the time period for which the thread was set to sleep it goes to the Runnable state and might not run immediately! It has to wait for the Thread Scheduler to schedule it for its time slice.

Thread.yield()

  1. Calling it may cause the Thread Scheduler to move the current thread from Running to Runnable state and execute another same priority thread which was in Runnable state. This transition of state takes place only if there is some other thread of same priority in Runnable state. Hence the no guarantee that the thread will stop execution as the criteria of another same priority thread might not be met.
  2. .yield() is much based on the Thread Priorities concept. (All thread are assigned priorities and when a thread of higher priority is in Runnable state it ususally preempts / stops execution of lower priority threads depending on implementation of ThreadScheduler.)

enter image description here Note:

  • both Thread.sleep() and Thread.yield() are static functions and affect the current thread executing it.
  • both the functions will not let go the synchronized locks they hold.
frictionlesspulley
  • 11,070
  • 14
  • 66
  • 115
13

yield merely says: now is a good time to let another thread run and is a hint to the scheduler. sleep really does that: sleep at least the given time.

DarkDust
  • 90,870
  • 19
  • 190
  • 224
  • @DarlDust: do the threads return to different waiting pools after calling these methods? – Bhushan Mar 15 '11 at 13:09
  • No, they are not the same. `yield` may immediately return and continue to run or sometime later. `sleep` may only return after waiting *at least* the given timespan. How the thread scheduler is working and when your thread is given time again is dependent on platform/implementation and thread settings (priorities etc.) and something you shouldn't care about. – DarkDust Mar 15 '11 at 13:40
  • @Pacerier Imagine a thread/process scheduler that lets each thread/process run for a fixed time (say 20ms), then switches to the next. Now if your thread wakes up and notices there's no important work to do right now, it can tell the scheduler "Let someone else do some work now" through yield. Sleep wouldn't work, as the caller would need to know exactly how long one scheduling slot is and how much time it has left of that slot or when it would get scheduled next. In other words: with sleep, the caller would need to know implementation details of the scheduler, but not with yield. – DarkDust Mar 08 '12 at 09:14
  • @DarkDust So what's the difference between yield vs Object.wait + Object.notify pattern? We can tell the scheduler "Let someone else do some work now" using Object.wait and then the scheduler would Object.notify our lock when he has free-time again right? So why do we ever need yield for? – Pacerier Mar 08 '12 at 12:10
  • Object.wait + .notify require explicit listening + notification. Someone must *explicitly* wake the waiting thread up, if nobody wakes the waiting thread up it blocks forever. Not so with yield: here it simply sleeps until the thread scheduler deems it appropriate to run the thread again, nobody needs to do something explicitly or even *know* that some thread yielded. – DarkDust Mar 08 '12 at 12:53
  • @DarkDust ok I get your point, but if we wrote that scheduler ourself using Java, then we wouldn't ever need Thread.yield, right? – Pacerier Mar 09 '12 at 02:21
  • No, the *concept* would still be needed. It serves a purpose that no other mechanism can provide. It's not just that Java has this concept, BTW. AFAIK most multithreaded OSs have this as well (POSIX defines `sched_yield()`). – DarkDust Mar 09 '12 at 06:04
4

yield() pauses momentarily the current thread, allowing the Thread Scheduler to execute other threads with the same priority. If there are no other threads waiting or their priority is lower, the yielded thread returns to its execution at once.

sleep() forces the current thread to halt its execution for a defined slot of time. Other waiting threads will start executing by taking advantage of this pause, that is, following the Thread Scheduler policy - whose implementation is vendor dependent.

Reynaldo
  • 630
  • 1
  • 7
  • 19
2

It's not "for sure" -- it could even take an hour for your thread to get another chance to run, depending on the operating system's thread scheduling algorithm, and the presence of higher-priority threads.

The only thing yield() does is say, "Okay, I'm kind of done, so feel free to end my time slice and continue executing something else." sleep, on the other hand, says "Wake me up in X milliseconds". sleep is used for waiting, the other one for giving others a chance to run. They're not alternatives.

user541686
  • 205,094
  • 128
  • 528
  • 886