sleep(1) vs. yield()

[sean mcilwain]

I was just wondering what the advantages and disadvantages are between using the sleep(1) vs. yield() methods to allow other threads to execute under non-preemptive systems. Sleep retains any lock from synchronized blocks, right? Is this true for a yielding thread as well?

[Ajith Kallambella]

You're right. sleep will not relinquish the monitor and will continue to consume CPU cycles. The sleeping state is a kind of running state and hence the thread in the "ready to run" state will continue to wait for their chance.
Yield on the otherhand makes the thread move to "ready to run" pool and gives a chance for contending threads to run. If you're doing some intensive processing, it is good to yield at logically viable points during your process. Ofcourse this cannot be followed as a generic rule, especially when your thread owns locks.
I have also heard about implementations where sleep() internally calls yield(). I am not sure how they handle retaining the lock, but in cases where the calling thread doesn't own locks, it is quite simple. That way when a thread sleeps, waiting threads can safely run.

------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.

[Kathy Shkarlet]

I'm not sure I agree with the line "sleep will not relinquish the monitor and will continue to consume CPU cycles". If there're other threads that don't need the sleeping thread's lock - they will run!

[Peter Tran]

I really need to brush up on my Thread knowledge. Is there any monitoring going on with sleep and yield? I thought yield moves a thread from the running state to the ready state and sleep moves a thread from the running state to a sleep state followed by a move to the ready state.
Diagram is better in this case:
yield: running state -> ready state
sleep: running state -> sleep state -> ready state
I thought thread monitors had to do with the methods (notify(), notifyall(), wait()) in the java.lang.Object class. To invoke these methods requires you to be in a synchronized piece of code. It's this synchronization that requires a monitor object.
Am I way off subject?
-Peter

[sean mcilwain]

My original question was based on using Threads in Linux vs. Threads in Windows. Is it true that Windows is on a time-slicing type task-dispatcher while linux requires that the thread "gives up" control before the other threads of the same priority can run?
If this is true, two Threads of the same priority running with no synchronization in Linux would have to give up their "control" via a sleep, or yield method. Synchronization on methods or object would also make competeing threads give up their control when another thread in the synchornized block is waiting to run? Does this make any sense?
Thanks,
Sean McIlwain

[Ajith Kallambella]

I still think "giving up control so that other threads can run" can be achieved only by using yield() and not by using sleep(). This makes logical sence, but honestly, I have to write a program to convince myself
Anyways this is really a discussion for the Threads forum rather than the performance forum. Don't you think?

------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.

[sean mcilwain]

The performance part of the question is whether sleep(1) or yield() would achieve the same effect, and which would run faster if two threads are assumed to run "concurrently". If am guessing that sleep(1) is much more inefficient than yield() since the thread may actually sleep for longer than is required for it to be able to run again. Yield(), according to what people said on this thread, would only place the thread in the waiting to run pool so it can be run as soon as it's turn comes up.
I wanted to say thanks for all the input, it helped clarify some issues that I thought were performance related.
Thanks,
Sean McIlwain

[Jim Yingst]

I think that yield is pretty much equivalent to sleep(0). sleep(1) on the other hand is just a tiny bit more forceful - the JVM may not execute that thread for a full millisecond, so the JVM is more likely to actually find another thread to run in the meantime.
And to complete the answer to another part of the origianl question - neither sleep() nor yield() give up any locks held by the code. Usually you don't want to have any locks to begin with when you call either of these methods - if you do, there's a good chance you're blocking another thread by going to sleep while holding a lock.
And no, this isn't really performance-related so much as thread-related - but at least there's some crossover.

[Jim Baiter]

You're exactly right according to the API docs:
yield:
"Causes the currently executing thread object to temporarily pause and allow other threads to execute."
sleep:
"Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds. The thread does not lose ownership of any monitors."

Originally posted by Ajith Kallambella:
I still think "giving up control so that other threads can run" can be achieved only by using yield() and not by using sleep(). This makes logical sence, but honestly, I have to write a program to convince myself
Anyways this is really a discussion for the Threads forum rather than the performance forum. Don't you think?

[Ajith Kallambella]

I'm still not sure if this behaviour depends on the implementation. I think even sleep should behave like yield in the absence of any locks. That way waiting threads get a chance to run.....
------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.

[Pradeep bhatt]

http://www.jguru.com/faq/view.jsp?EID=425624