9

I understand that Thread.currentThread().yield() is a notification to thread scheduler that it may assign cpu cycle to some other thread of same priority if any such is present. My question is: If current thread has got lock on some object and calls yield(), will it loses that lock right away? And when thread scheduler finds out there is no such thread to assign cpu cycle, then the thread which has called yield() will again be in fight to get lock on the object which it has lost earlier??

I couldn't find it in javadoc and forums [http://www.coderanch.com/t/226223/java-programmer-SCJP/certification/does-sleep-yield-release-lock] have 50-50 answers.

I think yield() (lets say thread1) should release lock because if some thread (lets say thread2) of same priority wants to operate on same object, then it can have chance when thread scheduler eventually assign cup to thread2.

Gray
  • 115,027
  • 24
  • 293
  • 354
Amaresh
  • 331
  • 2
  • 5
  • 14

3 Answers3

14

No. Thread.yield() is not like Object.wait(). It just gives up control to allow a thread switch. It will have no effect on the concurrency of your program.

There is no guarantee which thread the scheduler will run after a yield.

Francis Upton IV
  • 19,322
  • 3
  • 53
  • 57
  • 2
    Should we conclude then that asking for a thread to yield while running a piece of synchronized code is not a good idea? After all, to minimize the time the lock is held, you would like your currently running thread to finish the block as soon as possible, and yield, even being a hint, if taken into account, would only delay the release of the lock. – Edwin Dalorzo May 21 '12 at 05:15
  • 1
    @edalorzo Agreed. It is futile. Why claim the lock only to courteously defer to other thread? – user207421 May 21 '12 at 05:17
  • It really depends on your application, but in general, yield() is not necessary. I mean if there was work required by another thread in the lock, then it's going to have to get done. – Francis Upton IV May 21 '12 at 05:17
  • What I meant was that supposing I am running on a single-CPU JVM implementation that do not use time-sliced pre-emptive scheduling, if I yield a thread holding a lock, then other threads not waiting for the same lock could benefit of getting some CPU time, as long as the JVM implementation takes into account the hint. But the lock will prevent other threads waiting on it to run, because it would still be held by the yielded thread. As such, yielding in these circumstances, even if possible, sounds like a bad idea, a code smell, IMHO. – Edwin Dalorzo May 21 '12 at 05:23
  • Yes of course in that scenario you are right. But the locking all depends on how you have structured your app. – Francis Upton IV May 21 '12 at 06:07
  • 1
    @Amaresh You're over-thinking this. The JVM will schedule other threads anyway. You don't need to help it, not since the demise of green threads and Windows 3 anyway ;-) – user207421 May 21 '12 at 06:51
10

In Java Language specification
17.3 Sleep and Yield
It is important to note that neither Thread.sleep nor Thread.yield have any synchronization semantics. In particular, the compiler does not have to flush writes cached in registers out to shared memory before a call to Thread.sleep or Thread.yield, nor does the compiler have to reload values cached in registers after a call to Thread.sleep or Thread.yield.

My comment:

In java's early days, when it did not really supported parallel executions, but only concurrent (green threads), yield() was suspending the current thread, and the jvm was picking up another thread to resume. Now-days, yield does not have much meaning as usually the tread scheduling is on OS level.

So, yield is just a hint to the JVM that current thread wants to take a rest and nothing else, it is up to the thread scheduler to decide what to do. yield does not have any synchronization semantic. If thread holds lock, it will continue to hold it.

Op De Cirkel
  • 28,647
  • 6
  • 40
  • 53
  • I'm currently working on my SCJP 1.6 and did a test as required for the certification where there is a yield call within a Synchronized function and it does yield execution to another thread. – Salsero69 Feb 27 '14 at 21:37
  • @Op De Cirkel Thanks! what about join? This also behave in the same way? – Kanagavelu Sugumar Jun 02 '16 at 05:59
0

Only wait methods of the Object class release the intrinsic lock of the current instance (the thread may have other locks acquired, they don't get released). Yield, sleep, join do not bother about locks. However, join is a little more special, you are guaranteed to see all the changes made by the thread you're waiting for to finish.

Bax
  • 4,260
  • 5
  • 43
  • 65