A computer program (process, task, or thread) may sleep, which places it into an inactive state for a period of time. Eventually the expiration of an interval timer, or the receipt of a signal or interrupt causes the program to resume execution.
A typical sleep system call takes a time value as a parameter, specifying the minimum amount of time that the process is to sleep before resuming execution. The parameter typically specifies seconds, although some operating systems provide finer resolution, such as milliseconds or microseconds.
On Windows, the Sleep()
function takes a single parameter of the number of milliseconds to sleep. The Sleep()
function is included in kernel32.dll. [1]
The Sleep()
function has a resolution no higher than the current timer resolution, typically 16ms but at minimum 1ms, adjustable via the timeBeginPeriod()
family of "media timer" APIs. For higher precisions, it is necessary to use a busy loop over QueryPerformanceCounter()
, such as the one used in gnulib. [2]
On Unix-like and other POSIX operating systems, the sleep()
function is called providing a single parameter of type unsigned integer of the number of seconds to sleep. [3] A higher-precision version is the nanosleep()
function and the now deprecated usleep
. [4] POSIX also allows for choosing clock sources via the extended version clock_nanosleep()
. [5]
A version of clock_nanosleep()
was proposed to be part of the C programming language, but was rejected. The UTC time part of the same proposal was added to C11. [6]
In Windows API:
Sleep(2*1000);// Sleep for 2 seconds
In Unix or POSIX system calls:
sleep(2);// Sleep for 2 seconds
Sleep causes the thread or process to give up the remainder of its time slice and stay in the Not Runnable state for the specified duration. While there is generally a guarantee for the minimum time period, there is no strict guarantee that the thread will run immediately or soon, or even at all, once the specified time has passed. It is up to the scheduler's discretion, and dependent on thread priorities and implementation details such as timer resolutions when the sleeping thread will run again.
On POSIX systems, the nanosleep and related syscalls are interruptible by signals, returning the remaining sleep time. The sleep library function, on the other hand, is implemented via the alarm syscall on many older systems, thus it only works by delivering a signal. The Windows Sleep function is non-interruptible due to absence of signals (other than the thread or its process being terminated), although the related SleepEx function can be used to put the thread into an alertable state, allowing APC calls being made while the thread is sleeping. Also, a thread can technically be "interrupted" in case e.g. the process terminates due to an exception in a different thread.
Some system programs that never terminate execute an event loop, going to sleep at the start of each cycle and waiting for some event to awaken them. Once an event is received, the program services the event, then returns to the beginning of the next wait cycle.
Other programs periodically poll for events by going to sleep and resuming execution after a specific interval of time. Once execution is resumed, the program polls for events or status changes, and then services any that occurred while it was asleep. After servicing the events, the program then goes to sleep again for the next time interval. Certain kinds of heartbeat events or keep-alive signals can be generated by these kinds of programs.
The sleep()
function call can be repeatedly called for short periods of time to slow the execution of a running program or code. Throttling code in this manner provides a coarse mechanism for mitigating the effects of overheating hardware [7] or easing timing issues for legacy programs. The downside to cycling sleep and running states rather than leveraging cycle emulation (via an emulator) to control the execution speed of software is that interactive software will acquire a notable stutter if too little time is spent awake, too much time is spent sleeping, or a combination of both. [8]
An uninterruptible sleep state is a sleep state that will not handle a signal right away. It will wake only as a result of a waited-upon resource becoming available or after a time-out occurs during that wait (if specified when put to sleep). It is mostly used by device drivers waiting for disk or network IO (input/output). When the process is sleeping uninterruptibly, signals accumulated during the sleep will be noticed when the process returns from the system call or trap.
In Unix-like systems the command 'ps -l
' uses code "D
" for the uninterruptible sleep state of a process. [9] Such processes cannot be killed even with SIGKILL
and the only non-sophisticated way to get rid of them is to reboot the system. [10] [11]
In computing, a context switch is the process of storing the state of a process or thread, so that it can be restored and resume execution at a later point, and then restoring a different, previously saved, state. This allows multiple processes to share a single central processing unit (CPU), and is an essential feature of a multiprogramming or multitasking operating system. In a traditional CPU, each process - a program in execution - utilizes the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously. For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and the loading of the following running process is called a context switch.
An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs.
The Portable Operating System Interface is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines both the system and user-level application programming interfaces (APIs), along with command line shells and utility interfaces, for software compatibility (portability) with variants of Unix and other operating systems. POSIX is also a trademark of the IEEE. POSIX is intended to be used by both application and system developers.
In computing, a system call is the programmatic way in which a computer program requests a service from the operating system on which it is executed. This may include hardware-related services, creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.
In computing, particularly in the context of the Unix operating system and its workalikes, fork is an operation whereby a process creates a copy of itself. It is an interface which is required for compliance with the POSIX and Single UNIX Specification standards. It is usually implemented as a C standard library wrapper to the fork, clone, or other system calls of the kernel. Fork is the primary method of process creation on Unix-like operating systems.
RTLinux is a hard realtime real-time operating system (RTOS) microkernel that runs the entire Linux operating system as a fully preemptive process. The hard real-time property makes it possible to control robots, data acquisition systems, manufacturing plants, and other time-sensitive instruments and machines from RTLinux applications. The design was patented. Despite the similar name, it is not related to the Real-Time Linux project of the Linux Foundation.
In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.
A child process in computing is a process created by another process. This technique pertains to multitasking operating systems, and is sometimes called a subprocess or traditionally a subtask.
In computing, a parent process is a process that has created one or more child processes.
In computing, POSIX Threads, commonly known as pthreads, is an execution model that exists independently from a programming language, as well as a parallel execution model. It allows a program to control multiple different flows of work that overlap in time. Each flow of work is referred to as a thread, and creation and control over these flows is achieved by making calls to the POSIX Threads API. POSIX Threads is an API defined by the Institute of Electrical and Electronics Engineers (IEEE) standard POSIX.1c, Threads extensions .
Signals are standardized messages sent to a running program to trigger specific behavior, such as quitting or error handling. They are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems.
In computer science, asynchronous I/O is a form of input/output processing that permits other processing to continue before the transmission has finished. A name used for asynchronous I/O in the Windows API is overlapped I/O.
In computing, sigaction
is a function API defined by POSIX to give the programmer access to what should be a program's behavior when receiving specific OS signals.
In computing, sleep is a command in Unix, Unix-like and other operating systems that suspends program execution for a specified time.
A Unix architecture is a computer operating system system architecture that embodies the Unix philosophy. It may adhere to standards such as the Single UNIX Specification (SUS) or similar POSIX IEEE standard. No single published standard describes all Unix architecture computer operating systems — this is in part a legacy of the Unix wars.
In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler. The event loop is also sometimes referred to as the message dispatcher, message loop, message pump, or run loop.
CPU time is the amount of time for which a central processing unit (CPU) was used for processing instructions of a computer program or operating system, as opposed to elapsed time, which includes for example, waiting for input/output (I/O) operations or entering low-power (idle) mode. The CPU time is measured in clock ticks or seconds. Often, it is useful to measure CPU time as a percentage of the CPU's capacity, which is called the CPU usage. CPU time and CPU usage have two main uses.
On many computer operating systems, a computer process terminates its execution by making an exit system call. More generally, an exit in a multithreading environment means that a thread of execution has stopped running. For resource management, the operating system reclaims resources that were used by the process. The process is said to be a dead process after it terminates.
A process is a program in execution, and an integral part of any modern-day operating system (OS). The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronization among processes. To meet these requirements, the OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the OS to exert control over each process.
In computing, a hang or freeze occurs when either a process or system ceases to respond to inputs. A typical example is when computer's graphical user interface no longer responds to the user typing on the keyboard or moving the mouse. The term covers a wide range of behaviors in both clients and servers, and is not limited to graphical user interface issues.