CODEWITHSUNDEEP
operating-systemcpusystem-callssleepinterrupt
ballsmahoney
ballsmahoney

Reputation: 151

Does the sleep() function cause a timer interrupt upon completion?

Do the family of sleep functions (sleep(), nanosleep()) cause timer interrupts once they complete (i.e., are done sleeping)? If not, how does the OS know exactly when they are done? If so, I understand timers have a high interrupt priority. Does this mean a program using sleep() once awoken will likely cause another program running on one of the CPUs (in a multi-processor) to be removed in favor of the recently awoken program?

Upvotes: 2

Views: 719

Answers (2)

Chris Dodd
Chris Dodd

Reputation: 126243

The Linux man pages notes:

Portability notes
On some systems, sleep() may be implemented using alarm(2) and SIGALRM (POSIX.1 permits this); mixing calls to alarm(2) and sleep() is a bad idea.

Upvotes: 1

Brendan
Brendan

Reputation: 37232

Does the sleep() function cause a timer interrupt upon completion?

Maybe.

For keeping track of time delays there's 2 common ways it could be implemented:

a) A timer IRQ occurs at a fixed frequency (e.g. maybe every 1 millisecond). When the IRQ occurs the OS checks if any time delays expired and deals with them. In this case there's a compromise between precision and overhead (to get better precision you need to increase the "IRQs per second" which increases the overhead of dealing with all the IRQs).

b) The OS re-configures the timer to generate an IRQ when the soonest delay should expire whenever necessary (when the soonest delay is cancelled, a sooner delay is created, or the soonest delay expires). This has no "precision vs. overhead" compromise, but has more overhead for re-configuring the timer hardware. This is typically called "tickless" (as there's no regular/fixed frequency "tick").

Note that modern 80x86 systems have a local APIC timer per CPU that supports "IRQ on TSC deadline". For "tickless", this means you can normally get better than 1 nanosecond precision without much need for locks (using "per CPU" structures to keep track of time delays); and the cost of re-configuring the timer is very small (as the timer hardware is built directly into the CPU itself).

For "tickless" (which is likely much better for modern systems) you would end up with a timer IRQ when "sleep()" expires most of the time (unless some other delay expires at the same/similar time).

Does this mean a program using sleep() once awoken will likely cause another program running on one of the CPUs (in a multi-processor) to be removed in favor of the recently awoken program?

Whether a recently unblocked task preempts immediately depends on:

a) The scheduler design. For some schedulers (e.g. naive "round robin") it may never happen immediately.

b) The priorities of the unblocked task and the currently running task/s.

c) Optimizations. Task switches cost overhead so attempts to minimize the number of task switches (e.g. postponing/skipping a task switch if some other task switch is likely to happen soon anyway) are practical. There's also complexity involving load balancing, power management, cache efficiency, memory (NUMA, etc) and other things that may be considered.

Upvotes: 4

Related Questions