2

Can someone explain the difference between Thread.yield() method and Thread.sleep() method?

How I understand it: Thread.yield() gives up the monitor lock to other thread which JVM decides to execute next, and Thread.sleep() puts the current thread in sleep mode for a given amount of milliseconds without giving away the monitor lock.

syb0rg
  • 8,057
  • 9
  • 41
  • 81
ASingh
  • 475
  • 1
  • 13
  • 24
  • 1
    http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#yield() – Brian Roach Feb 24 '13 at 02:59
  • "Thread.yield() gives up the monitor lock". No it doesn't. Where did you get that idea? – user207421 Feb 24 '13 at 03:02
  • I am just wondering...if Thread.yield does not give up the monitor's lock..den how can any other thread proceed its execution in case the other thread has a high priority..? – ASingh Feb 24 '13 at 03:12
  • Also, is it posible that if a thread has gone into sleep..some other thread may continue execution...I mean other thread may acquire the monitor lock and continue execution and when the thread wakes up..it takes the lock again...I am still confused. – ASingh Feb 24 '13 at 03:13
  • 4
    Why is this marked as duplicate? The linked question is about .NET and this is about Java, a totally different story! – yankee May 12 '16 at 15:32

3 Answers3

11

It depends on what Java version you are using, according to this:

In Java 5, Thread.yield() calls the Windows API Sleep(0). This has the special effect of clearing the current thread's quantum (number of allocated time-slices of CPU) and putting it to the end of the queue for its priority level. In other words, all runnable threads of the same priority (and those of greater priority) will get a chance to run before the yielded thread is next given CPU time. When it is eventually re-scheduled, it will come back with a full quantum, but doesn't "carry over" any of the remaining quantum from the time of yielding. This behavior is a little different from a non-zero sleep where the sleeping thread generally loses 1 quantum value (in effect, 1/3 of a 10 or 15ms tick).

In Java 6, this behavior was changed. The Hotspot VM now implements Thread.yield() using the Windows SwitchToThread() API call. This call makes the current thread give up its current time-slice, but not its entire quantum. This means that depending on the priorities of other threads, the yielding thread can be scheduled back in one interrupt period later.

Thread.sleep() suspends the current thread for a specified time, no matter what Java version you use.

syb0rg
  • 8,057
  • 9
  • 41
  • 81
  • Your answer is much more comprehensive than mine. Kudos. :) I suspect that other operating systems have differences like you described for Windows too. +1 from me. – ATrubka Feb 24 '13 at 03:03
  • Thanks, and on other OS's the system calls are to the same effect, yes. – syb0rg Feb 24 '13 at 03:05
  • 2
    If you're going to copy the words of others, be sure to quote them and add proper attribution. I've done this in your answer above. – Brad Larson Feb 27 '13 at 20:30
0

Thread.sleep() puts your thread to sleep for a period of time or until interrupted. Thread.yield() doesn't put your thread to sleep. Instead, it just pauses the thread temporarily to let other threads do their job.

ATrubka
  • 3,982
  • 5
  • 33
  • 52
-1

Close. Thread.sleep causes the thread to sleep for the specified time, but does not give up the lock.

Thread.yield also does not give up the lock. It just hints to the thread scheduler to give another thread some cycles.

They are really nothing at all alike, they are very different.

Is there a specific problem you are trying to solve?

Victor Grazi
  • 15,563
  • 14
  • 61
  • 94
  • Thanks Victor. I am a beginner to JAVA concurrency so I just wanted to learn the basics. – ASingh Feb 24 '13 at 03:05
  • I am just wondering...if Thread.yield does not give up the monitor's lock..den how can any other thread proceed its execution in case the other thread has a high priority..? – ASingh Feb 24 '13 at 03:14
  • 1
    Why do you assume that thread is holding the lock? If it is holding the lock, then you are right, it would not give up the lock. But it would still hint to the thread scheduler to give some cycles to other threads. Just not to the wait set for this lock. – Victor Grazi Feb 24 '13 at 03:24