5

Possible Duplicate:
Does thread.yield() lose the lock on object if called inside a synchronized method?

I know Thread.sleep() holds the lock, but Object.wait() releases the lock. Some say yield actually implements sleep(0). Does this mean yield will not release the lock?

Another question. Say the current thread has acquired a lock, and then called anotherThread.join(). Does the current thread release the lock?

Community
  • 1
  • 1
Sicong
  • 315
  • 2
  • 6
  • 1
    The Java [docs][1] say : *Every object has an intrinsic lock associated with it. By convention, a thread that needs exclusive and consistent access to an object's fields has to acquire the object's intrinsic lock before accessing them, and then release the intrinsic lock when it's done with them.* So I feel, since the lock belongs to an object, static methods of `Thread` class should not have any control over the locks. That's why only `Object` class' `wait()` method does. I'm not sure, but this is what I feel. [1]: http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html – Kazekage Gaara Apr 16 '12 at 14:38
  • While yield() is similar to sleep(0) you can find that sleep(0) can take 10-100x longer, so they are not exactly the same. Only wait() on the locked object releases the lock. – Peter Lawrey Apr 16 '12 at 15:40

2 Answers2

4

Unless the javadoc mentions an object's monitor (such as Object.wait()), you should assume that any locks will continue to be held. So:

Does this mean yield will not release the lock?

Yes.

Does the current thread release the lock?

No.

artbristol
  • 32,010
  • 5
  • 70
  • 103
1

sleep puts the thread in a wait state, yield returns the thread directly to the ready pool. (So if a thread yields it could go directly from running to the ready pool to getting picked by the scheduler again without ever waiting.) Neither one has anything to do with locking.

From the Java Language Specification:

Thread.sleep causes the currently executing thread to sleep (temporarily cease execution) for the specified duration, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors, and resumption of execution will depend on scheduling and the availability of processors on which to execute the thread.

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.

For example, in the following (broken) code fragment, assume that this.done is a non-volatile boolean field:

while (!this.done)
     Thread.sleep(1000);

The compiler is free to read the field this.done just once, and reuse the cached value in each execution of the loop. This would mean that the loop would never terminate, even if another thread changed the value of this.done.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276