What's the algorithm behind sleep()?

Question

Now there\'s something I always wondered: how is sleep() implemented ?

If it is all about using an API from the OS, then how is the API made ?

Does it all bo

Answer 1

The "update" to question shows some misunderstanding of how modern OSs work.

The kernel is not "allowed" a time slice. The kernel is the thing that gives out time slices to user processes. The "timer" is not set to wake the sleeping process up - it is set to stop the currently running process.

In essence, the kernel attempts to fairly distribute the CPU time by stopping processes that are on CPU too long. For a simplified picture, let's say that no process is allowed to use the CPU more than 2 milliseconds. So, the kernel would set timer to 2 milliseconds, and let the process run. When the timer fires an interrupt, the kernel gets control. It saves the running process' current state (registers, instruction pointer and so on), and the control is not returned to it. Instead, another process is picked from the list of processes waiting to be given CPU, and the process that was interrupted goes to the back of the queue.

The sleeping process is simply not in the queue of things waiting for CPU. Instead, it's stored in the sleeping queue. Whenever kernel gets timer interrupt, the sleep queue is checked, and the processes whose time have come get transferred to "waiting for CPU" queue.

This is, of course, a gross simplification. It takes very sophisticated algorithms to ensure security, fairness, balance, prioritize, prevent starvation, do it all fast and with minimum amount of memory used for kernel data.

Answer 2

I don't know anything about Linux, but I can tell you what happens on Windows.

Sleep() causes the process' time-slice to end immediately to return control to the OS. The OS then sets up a timer kernel object that gets signaled after the time elapses. The OS will then not give that process any more time until the kernel object gets signaled. Even then, if other processes have higher or equal priority, it may still wait a little while before letting the process continue.

Special CPU machine code is used by the OS to do process switching. Those functions cannot be accessed by user-mode code, so they are accessed strictly by API calls into the OS.

Answer 3

Essentially, yes, there is a "special gizmo" - and it's important for a lot more than just sleep().

Classically, on x86 this was an Intel 8253 or 8254 "Programmable Interval Timer". In the early PCs, this was a seperate chip on the motherboard that could be programmed by the CPU to assert an interrupt (via the "Programmable Interrupt Controller", another discrete chip) after a preset time interval. The functionality still exists, although it is now a tiny part of a much larger chunk of motherboard circuitry.

The OS today still programs the PIT to wake it up regularly (in recent versions of Linux, once every millisecond by default), and this is how the Kernel is able to implement pre-emptive multitasking.

Answer 4

glibc 2.21 Linux

Forwards to the nanosleep system call.

glibc is the default implementation for the C stdlib on most Linux desktop distros.

How to find it: the first reflex is:

git ls-files | grep sleep

This contains:

sysdeps/unix/sysv/linux/sleep.c

and we know that:

sysdeps/unix/sysv/linux/

contains the Linux specifics.

On the top of that file we see:

/* We are going to use the `nanosleep' syscall of the kernel.  But the
   kernel does not implement the stupid SysV SIGCHLD vs. SIG_IGN
   behaviour for this syscall.  Therefore we have to emulate it here.  */
unsigned int
__sleep (unsigned int seconds)

So if you trust comments, we are done basically.

At the bottom:

 weak_alias (__sleep, sleep)

which basically says __sleep == sleep. The function uses nanosleep through:

result = __nanosleep (&ts, &ts);

After greppingg:

git grep nanosleep | grep -v abilist

we get a small list of interesting occurrences, and I think __nanosleep is defined in:

sysdeps/unix/sysv/linux/syscalls.list 

on the line:

nanosleep   -   nanosleep   Ci:pp   __nanosleep nanosleep

which is some super DRY magic format parsed by:

sysdeps/unix/make-syscalls.sh

Then from the build directory:

grep -r __nanosleep

Leads us to: /sysd-syscalls which is what make-syscalls.sh generates and contains:

#### CALL=nanosleep NUMBER=35 ARGS=i:pp SOURCE=-
ifeq (,$(filter nanosleep,$(unix-syscalls)))
unix-syscalls += nanosleep
$(foreach p,$(sysd-rules-targets),$(foreach o,$(object-suffixes),$(objpfx)$(patsubst %,$p,nanosleep)$o)): \
        $(..)sysdeps/unix/make-syscalls.sh
    $(make-target-directory)
    (echo '#define SYSCALL_NAME nanosleep'; \
     echo '#define SYSCALL_NARGS 2'; \
     echo '#define SYSCALL_SYMBOL __nanosleep'; \
     echo '#define SYSCALL_CANCELLABLE 1'; \
     echo '#include <syscall-template.S>'; \
     echo 'weak_alias (__nanosleep, nanosleep)'; \
     echo 'libc_hidden_weak (nanosleep)'; \
    ) | $(compile-syscall) $(foreach p,$(patsubst %nanosleep,%,$(basename $(@F))),$($(p)CPPFLAGS))
endif

It looks like part of a Makefile. git grep sysd-syscalls shows that it is included at:

sysdeps/unix/Makefile:23:-include $(common-objpfx)sysd-syscalls 

compile-syscall looks like the key part, so we find:

# This is the end of the pipeline for compiling the syscall stubs.
# The stdin is assembler with cpp using sysdep.h macros.
compile-syscall = $(COMPILE.S) -o $@ -x assembler-with-cpp - \
                   $(compile-mkdep-flags)

Note that -x assembler-with-cpp is a gcc option.

This #defines parameters like:

#define SYSCALL_NAME nanosleep

and then use them at:

#include <syscall-template.S>

OK, this is as far as I will go on the macro expansion game for now.

I think then this generates the posix/nanosleep.o file which must be linked together with everything.

Linux 4.2 x86_64 nanosleep syscall

Uses the scheduler: it's not a busy sleep.

Search ctags:

sys_nanosleep

Leads us to kernel/time/hrtimer.c:

SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp,

hrtimer stands for High Resolution Timer. From there the main line looks like:

• hrtimer_nanosleep
• do_nanosleep
  • set_current_state(TASK_INTERRUPTIBLE); which is interruptible sleep
  • freezable_schedule(); which calls schedule() and allows other processes to run
• hrtimer_start_expires
• hrtimer_start_range_ns
• TODO: reach the arch/x86 timing level
• TODO: are the above steps done directly in the syscal call interrupt handler, or in a regular kernel thread?

A few articles about it:

• https://geeki.wordpress.com/2010/10/30/ways-of-sleeping-in-linux-kernel/
• http://www.linuxjournal.com/article/8144

Answer 5

There's a kernel data structure called the sleep queue. It's a priority queue. Whenever a process is added to the sleep queue, the expiration time of the most-soon-to-be-awakened process is calculated, and a timer is set. At that time, the expired job is taken off the queue and the process resumes execution.

(amusing trivia: in older unix implementations, there was a queue for processes for which fork() had been called, but for which the child process had not been created. It was of course called the fork queue.)

HTH!

Answer 6

there's at least two different levels to answer this question. (and a lot of other things that get confused with it, i won't touch them)

1. an application level, this is what the C library does. It's a simple OS call, it simply tells the OS not to give CPU time to this process until the time has passed. The OS has a queue of suspended applications, and some info about what are they waiting for (usually either time, or some data to appear somewhere).

2. kernel level. when the OS doesn't have anything to do right now, it executes a 'hlt' instruction. this instruction doesn't do anything, but it never finishes by itself. Of course, a hardware interrupt is serviced normally. Put simply, the main loop of an OS looks like this (from very very far away):

   allow_interrupts ();
   while (true) {
     hlt;
     check_todo_queues ();
   }
   

   the interrupt handlers simpy add things to the todo queues. The real time clock is programmed to generate interrupts either periodically (at a fixed rate), or to some fixed time in the future when the next process wants to be awaken.