1

I have some doubt regarding the yield method in java. Because when we are using it like Thread.yield() then the thread goes to the runnable state and give chance to the other thread to run but the thread which call yield is not releasing the lock. So , only threads except those who are waiting for the lock to release will run . So , when and in which scenario this yield method is useful.

Sahil
  • 96
  • 11
  • 1
    I would suggest reading through this post:http://stackoverflow.com/questions/6979796/what-are-the-main-uses-of-yield-and-how-does-it-differ-from-join-and-interr – SpaceCowboy Apr 30 '14 at 12:28
  • "the lock": which lock ? – Zoyd Apr 30 '14 at 12:29
  • @Zoyd the lock which is hold by thread and the one which is calling the yield() method – Sahil Apr 30 '14 at 12:33
  • @Sahil yield is a static method, it has no access to non-static fields. But since stop() is also static, it might be possible to implement it in this way. – Zoyd Apr 30 '14 at 12:35
  • Besides the fact that `Thread.yield()` always was a hint rather than a means of control, consider that today with SMP machines it makes even lesser sense. It might be the case that there is no runnable thread to take over the core of the thread calling `yield` because they all are currently assigned to other cores. – Holger Apr 30 '14 at 17:00

2 Answers2

4

Thread.yield() is useful in an environment that provides co-operative rather than pre-emptive threading. In other words, if the OS will not suspend your thread to let another run. In such an environment, you should regularly call yield() when performing a CPU-intensive operation.

I don't know of any modern operating systems that support Java but don't support pre-emptive threading, so it has little/no use in modern Java programs.

Thread.yield() has nothing to do with locks, is not documented to affect locks in any way, and should not be used in the assumption that it will release a lock.

Edit: this SO answer has much more information on how Thread.yield() is implemented (at least as-of JDK 1.6).

Community
  • 1
  • 1
kdgregory
  • 38,754
  • 10
  • 77
  • 102
  • It's also used under the assumption that the thread will give up its remaining timeslice in preemptive OSes. Although whether that actually works is another question - rather black magic the whole thing and the JVM really only makes a best-effort. – Voo Apr 30 '14 at 13:22
1

I agree with @kdgregory, Thread.yield() probably should not be used in modern Java programs. But, it's not because allowing one thread to yield to others is a bad idea: It's just because, if you really need to yield(), then you probably are re-inventing an algorithm that is already implemented in java.util.concurrent.

One thing's for sure: If you're going to yield(), don't do it inside a synchronized block. The whole point of yield() is to let other threads run. The whole point of a synchronized block is "I want to finish this bit before any other thread gets to start it."

Your goal should always be to make sure your program spends as little time in synchronized blocks as possible. The more time it spends in synchronized blocks, the less it will benefit from multiple processors. Every synchronized block is a bottleneck. Even a small one can make a big difference. Read about Amdahl's Law.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57