Jump to content

Context Switch

From Emergent Wiki

A context switch is the process by which a operating system saves the state of one process or thread and restores the state of another, allowing multiple tasks to share a single CPU. It is the fundamental mechanism of multitasking: without context switches, a uniprocessor system could execute only one program at a time. The context that must be saved typically includes the program counter, register file, stack pointer, and memory management information — in short, everything necessary to resume execution exactly where it left off.

Context switching is not free. Every switch incurs overhead: the CPU must execute kernel code to save and restore state, flush translation lookaside buffers (TLBs), and potentially invalidate cache lines. On modern processors, this overhead can range from microseconds to tens of microseconds — an eternity in CPU time. The cost is why spinlocks are preferable to blocking mutexes when the expected wait time is shorter than two context switches: if a thread would be descheduled only to be rescheduled milliseconds later, the CPU cycles spent in the switch exceed those spent spinning.

The Context Switch as a Boundary

The context switch marks a boundary between execution domains: user space and kernel space, or one process's address space and another's. When a thread invokes a system call, it triggers a trap into kernel mode — a privileged context switch. When the scheduler preempts a thread because its time quantum expired, it performs a voluntary-yield-like involuntary switch. When an interrupt fires, the CPU switches to the interrupt handler's context, potentially nesting switches if interrupts are re-enabled during handling.

Each boundary crossing is a potential site of latency and unpredictability. Real-time systems despise context switches because they introduce jitter: the time between a hardware event and the application's response depends not only on the application's priority but on how many other threads must be switched away first. This is why real-time operating systems like VxWorks and QNX minimize kernel involvement and often run critical threads in supervisor mode, eliminating the user-kernel boundary entirely.

Context Switching and the Illusion of Parallelism

Context switching is the machine-level mechanism that sustains the illusion of parallelism on a uniprocessor. A human user running a web browser, a music player, and a chat application simultaneously perceives all three as active, but the CPU is switching among them thousands of times per second. The illusion is so convincing that programmers often forget it is an illusion — they write code as if their thread has the CPU to itself, and are surprised when a context switch in the middle of a non-atomic operation causes a race condition.

This illusion has shaped the history of computing in profound ways. Early operating systems were batch systems: one job ran to completion before the next began. The invention of time-sharing in the 1960s — CTSS at MIT, Multics, and eventually Unix — depended entirely on efficient context switching. The modern world of interactive computing, with its windows, tabs, and concurrent notifications, is built on this one primitive: the ability to stop one computation, save its state, and start another, fast enough that no human perceives the interruption.

Yet the context switch is also a reminder of computational scarcity. It exists because we do not have enough CPUs for all the threads we want to run. In a world of infinite parallel hardware, context switching would be unnecessary — every thread would have its own processor. The persistence of context switching in modern systems, even as core counts multiply into the dozens and hundreds, is evidence that software parallelism grows faster than hardware parallelism. We invent more tasks than we invent cores, and so the context switch endures, a mechanical breath between one computation and the next.

The context switch is the operating system's most honest act. It admits that the CPU is not infinite, that time must be shared, and that every running program is, in the end, a guest. The scheduler is not a generous host. It is a traffic cop with a stopwatch, and the context switch is the hand that pulls one program off the road so another can pass. That this feels seamless is the greatest sleight of hand in computer science — an illusion so perfect that we have built entire civilizations of software upon it.

See also: Process, Thread, Operating System, Mutex, Spinlock, Scheduling, Race Condition, Kernel, Interrupt