Multithreading, when to yield versus sleep

The "right" way to code a producer / consumer is to have the consumer wait for the producer's data. You can achieve this by using a synchronization object such as a Mutex. The consumer will Wait on the mutex, which blocks it from executing until data is available. In turn, the producer will signal the mutex when data is available, which will wake up the consumer thread so it can begin processing. This is more efficient than sleep in terms of both:

• CPU utilization (no cycles are wasted), and
• Run Time (execution begins as soon as data is available, not when a thread is scheduled to wake up).

That said, here is an analysis of yield vs sleep that you asked for. You may need to use such a scheme if for some reason waiting for output is not feasible:

It depends how much traffic you are receiving - if data is constantly being received and processed, you might consider doing a yield. However in most cases this will result in a "busy" loop that spends most of its time needlessly waking up the thread to check if anything is ready.

You will probably want to either sleep for a short period of time (perhaps for less than a second, using usleep) OR even better use a synchronization object such as a mutex to signal that data is available.

sleep and yield are not the same. When calling sleep the process/thread gives CPU to another process/thread for the given amount of time.

yield relinquishes the CPU to another thread, but may return immediately if there are no other threads that waits for CPU.

So if you want to throttle, for example when streaming data at regular intervals, then sleep or nanosleep are the functions to use.

If synchronization between producer/consumer is needed, you should use a mutex/conditional wait.

One good reason to sleep instead of yield is when there is too much contention at a specific critical section. Lets say for example you try to acquire two locks and there is a lot of contention on both locks. Here you can use sleep to employ an exponential back off. This would allow each failed attempt to pseudo randomly back off to allow other thread to succeed.

Yielding in this situation doesn't really help as much because the prospect of a random back off can increase likelihood that thread starvation would not occur.

Edit: Though I know this isn't necessarily java specific. Java's implementation of Thread.sleep(0) has the same effect of Thread.yield() At that point its more of a matter of style.