Short sleeps suffering from slack
Posted Mar 1, 2012 13:12 UTC (Thu) by
farnz (guest, #17727)
In reply to:
Short sleeps suffering from slack by cmccabe
Parent article:
Short sleeps suffering from slack
There are two problem cases where that's a bad implementation:
- sleep(0) where the 0 is not a hard-coded constant, but the result of a time calculation. The application doesn't actually mind that the sleep takes extra time, as it's aiming to do things like "sleep until the next work item is due to start", and can cope if it's late (e.g. a task scheduler aiming to kick off work every 60 seconds - if the work takes more than 60 seconds unexpectedly, it has to cope anyway). Such an application is probably doing a calculation of the form "next start time - current time"[2] to get the sleep time.
- sched_yield in a SCHED_FIFO context. While the POSIX definition of sched_yield doesn't require it to be anything other than a no-op, for the specific case of SCHED_FIFO there's a good reason to implement it as "let any other runnable task of same priority as this task run"; absent such an implementation, there is no way for multiple co-operating SCHED_FIFO tasks to say "I still want the CPU, but if another task of equal priority wants the CPU, let it have it".
Note that the second case is specific to SCHED_FIFO - other scheduling algorithms will preempt a CPU-bound task if something else of same priority needs the CPU. SCHED_FIFO specifically does not allow that to happen, so you need some sensible mechanism for a task to say "I'm still CPU-bound, but this is an appropriate point to preempt me if another task needs to run".
(
Log in to post comments)
