Incomputing, acontext switch is the process of storing the state of aprocess orthread, so that it can be restored and resumeexecution at a later point, and then restoring a different, previously saved, state.[1] This allows multiple processes to share a singlecentral processing unit (CPU), and is an essential feature of a multiprogramming ormultitasking operating system. In a traditional CPU, each process – a program in execution – uses 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.[2] 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 loads the following running process is called a context switch.
The precise meaning of the phrase "context switch" varies. In a multitasking context, it refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of aninterrupt, such as when a task needs to accessdisk storage, freeing up CPU time for other tasks. Some operating systems also require a context switch to move betweenuser mode andkernel mode tasks. The process of context switching can have a negative impact on system performance.[3]: 28
Context switches are usually computationally intensive, and much of the design of operating systems is to optimize the use of context switches. Switching from one process to another requires a certain amount of time for doing the administration – saving and loading registers and memory maps, updating various tables and lists, etc. What is actually involved in a context switch depends on the architectures, operating systems, and the number of resources shared (threads that belong to the same process share many resources compared to unrelated non-cooperating processes).
For example, in theLinux kernel, context switching involves loading the correspondingprocess control block (PCB) stored in the PCB table in the kernel stack to retrieve information about the state of the new process. CPU state information including the registers,stack pointer, andprogram counter as well as memory management information likesegmentation tables andpage tables (unless the old process shares the memory with the new) are loaded from the PCB for the new process. To avoid incorrect address translation in the case of the previous and current processes using different memory, thetranslation lookaside buffer (TLB) must be flushed. This negatively affects performance because every memory reference to the TLB will be a miss because it is empty after most context switches.[4][5]
Furthermore, analogous context switching happens betweenuser threads, notablygreen threads, and is often very lightweight, saving and restoring minimal context. In extreme cases, such as switching betweengoroutines inGo, a context switch is equivalent to acoroutine yield, which is only marginally more expensive than asubroutine call.
There are three potential triggers for a context switch:
Most commonly, within somescheduling scheme, one process must be switched out of the CPU so another process can run. This context switch can be triggered by the process making itself unrunnable, such as by waiting for anI/O orsynchronization operation to complete. On apre-emptive multitasking system, the scheduler may also switch out processes that are still runnable. To prevent other processes from being starved of CPU time, pre-emptive schedulers often configure a timer interrupt to fire when a process exceeds itstime slice. This interrupt ensures that the scheduler will gain control to perform a context switch.
Modern architectures areinterrupt driven. This means that if the CPU requests data from a disk, for example, it does not need tobusy-wait until the read is over; it can issue the request (to the I/O device) and continue with some other task. When the read is over, the CPU can beinterrupted (by a hardware in this case, which sends interrupt request toPIC) and presented with the read. For interrupts, a program called aninterrupt handler is installed, and it is the interrupt handler that handles the interrupt from the disk.
When an interrupt occurs, the hardware automatically switches a part of the context (at least enough to allow the handler to return to the interrupted code). The handler may save additional context, depending on details of the particular hardware and software designs. Often only a minimal part of the context is changed in order to minimize the amount of time spent handling the interrupt. Thekernel does not spawn or schedule a special process to handle interrupts, but instead the handler executes in the (often partial) context established at the beginning of interrupt handling. Once interrupt servicing is complete, the context in effect before the interrupt occurred is restored so that the interrupted process can resume execution in its proper state.
When the system transitions betweenuser mode andkernel mode, a context switch is not necessary; amode transition is not by itself a context switch. However, depending on the operating system, a context switch may also take place at this time.
The state of the currently executing process must be saved so it can be restored when rescheduled for execution.
The process state includes all the registers that the process may be using, especially theprogram counter, plus any other operating system specific data that may be necessary. This is usually stored in a data structure called aprocess control block (PCB) orswitchframe.
The PCB might be stored on a per-processstack in kernel memory (as opposed to the user-modecall stack), or there may be some specific operating system-defined data structure for this information. Ahandle to the PCB is added to a queue of processes that are ready to run, often called theready queue.
Since the operating system has effectively suspended the execution of one process, it can then switch context by choosing a process from the ready queue and restoring its PCB. In doing so, the program counter from the PCB is loaded, and thus execution can continue in the chosen process. Process and thread priority can influence which process is chosen from the ready queue (i.e., it may be apriority queue).
The details vary depending on the architecture and operating system, but these are common scenarios.
Considering a general arithmetic addition operation A = B+1. The instruction is stored in theinstruction register and theprogram counter is incremented. A and B are read from memory and are stored in registers R1, R2 respectively. In this case, B+1 is calculated and written in R1 as the final answer. This operation as there are sequential reads and writes and there's no waits forfunction calls used, hence no context switch/wait takes place in this case.
Suppose a process A is running and a timer interrupt occurs. The user registers — program counter, stack pointer, and status register — of process A are then implicitly saved by the CPU onto the kernel stack of A. Then, the hardware switches to kernel mode and jumps into interrupt handler for the operating system to take over. Then the operating system calls theswitch() routine to first save the general-purpose user registers of A onto A's kernel stack, then it saves A's current kernel register values into the PCB of A, restores kernel registers from the PCB of process B, and switches context, that is, changes kernel stack pointer to point to the kernel stack of process B. The operating system then returns from interrupt. The hardware then loads user registers from B's kernel stack, switches to user mode, and starts running process B from B's program counter.[6]
Context switching itself has a cost in performance, due to running thetask scheduler, TLB flushes, and indirectly due to sharing theCPU cache between multiple tasks.[7] Switching between threads of a single process can be faster than between two separate processes because threads share the samevirtual memory maps, so a TLB flush is not necessary.[8]
The time to switch between two separate processes is called theprocess switching latency. The time to switch between two threads of the same process is called thethread switching latency. The time from when a hardware interrupt is generated to when the interrupt is serviced is called theinterrupt latency.
Switching between two processes in asingle address space operating system can be faster than switching between two processes in an operating system with private per-process address spaces.[9]
Context switching can be performed primarily by software or hardware. Some processors, like theIntel 80386 and its successors,[10] have hardware support for context switches, by making use of a special data segment designated thetask state segment (TSS). A task switch can be explicitly triggered with a CALL or JMP instruction targeted at a TSS descriptor in theglobal descriptor table. It can occur implicitly when an interrupt or exception is triggered if there is atask gate in theinterrupt descriptor table (IDT). When a task switch occurs, the CPU can automatically load the new state from the TSS.
As with other tasks performed in hardware, one would expect this to be rather fast; however, mainstream operating systems, includingWindows andLinux,[11] do not use this feature. This is mainly due to two reasons:
TS bit is automatically turned on in theCR0control register, resulting in a fault when executing floating-pointinstructions and giving the OS the opportunity to save and restore the floating-point state as needed).Context switching lies at the heart of the process juggling act. It consists of stopping the current computation, saving enough information so it may be restarted later, and restarting another process.