You can distinguish an alligator from a crocodile by paying attention to whether the animal sees you later or in a while.
Alternative to sched_yield()
In case sched_yield()
does not seem to work for you or it is not available, you can try calling usleep(0)
as a workaround.
int sched_yield(void);
from (#include <sched.h>
) causes the calling thread to relinquish the CPU. The thread is moved to the end of the queue for its static priority and a new thread gets to run.
From: man 3 sched_yield
int usleep(useconds_t usec);
from (#include <unistd.h>
) suspends execution of the calling thread for (at least) usec microseconds. The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers.
From: man 3 usleep
Notes
- Do not use
sleep(0)
as a workaround as in some older versions ofglibc
it will not have any effect at all! In those older versions there is a check if the input parameter is set to 0 and if it is then it will do nothing at all. Specifically the code is as follows:if (seconds == 0) return 0;
If you want to review the code changes in
sleep.c
or see howusleep.c
is code, download this archive: [download id=”3897″]
It contains all versions ofsleep.c
up to today and the latest version ofusleep.c
. - If the calling thread is the only thread in the highest priority list at that time, it will continue to run after a call to
sched_yield()
. - Strategic calls to
sched_yield()
can improve performance by giving other threads or processes a chance to run when (heavily) contended resources (e.g., mutexes) have been released by the caller. Avoid callingsched_yield()
unnecessarily or inappropriately (e.g., when resources needed by other schedulable threads are still held by the caller), since doing so will result in unnecessary context switches, which will degrade system performance.