Context switching
A computer feels like it's running many programs at once, but a single CPU core can only work on ONE thing at any instant. So the OS makes it take turns super fast: run process A for a sliver of time, pause it, run process B, pause it, back to A… The clever bit is the pause-and-resume. To pause A and come back to it later without losing a thing, the OS has to save everything A was doing, and later load it all back. That save-and-load is a CONTEXT SWITCH.
The chef putting away one recipe to start another
Picture one chef in a kitchen who's cooking two dishes by switching between them. They can't stir two pots at once, so they take turns. Before the chef walks away from dish A to work on dish B, they carefully write down where they were: 'I just added the salt, the timer says 3 minutes left,' and they tuck dish A's recipe card and ingredients aside. Then they pull out dish B's card and ingredients, read 'I was about to chop the onions,' and pick up right there. A context switch is the OS doing exactly this for the CPU. Process A's 'where I was' lives in the CPU's tiny scratchpads called REGISTERS (the current numbers it's juggling) and in a marker for which instruction it was about to run. To pause A, the OS copies all of that out of the CPU into A's own storage. To start B, it copies B's saved values back INTO the CPU. Now the CPU is, in every way, in the middle of B — and B has no idea it was ever paused.
Save, then load — and nobody notices the pause
Here's the step-by-step the OS runs every single switch: • SAVE: copy A's register values and its instruction marker out of the CPU into A's save area (a little record the OS keeps for every process). • LOAD: copy B's saved register values and instruction marker from B's save area back into the CPU. • RESUME: the CPU now continues B from the exact instruction it stopped on last time. It's just like a save file in a video game. When you quit, the game writes down your level, health, and where you stood. Load it tomorrow and you reappear exactly there — you don't restart from the beginning. Each process gets its own save file, so the CPU can hop between dozens of them and every one always resumes precisely where it left off. That's why your music keeps playing smoothly while you type: they're taking turns thousands of times a second, each resuming perfectly.
The catch: switching itself isn't free
Saving and loading all that state takes a little time — and here's the painful part: during a switch, NO real work gets done. The CPU isn't running your music or your typing; it's busy shuffling state in and out. A context switch is pure OVERHEAD, like the chef spending time wiping the counter and swapping recipe cards instead of actually cooking. For one switch that cost is tiny. But if the OS switches TOO often — tiny turns, constant swapping — it can spend a noticeable chunk of its time just switching instead of doing work. Imagine a chef who swaps dishes after every single stir: they'd spend all day putting cards away and pulling them out, and barely cook. So there's a balance. Switch often and every program feels snappy and responsive (no one waits long for a turn), but you pay more overhead. Switch rarely and you waste almost no time switching, but a program might have to wait a while for its turn, so things feel laggy. Deciding how long each turn should be is the job of the SCHEDULER — a topic of its own.
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| Switch often (short turns) | Every program gets the CPU soon, so everything feels responsive and snappy — nothing is stuck waiting long. | More switches means more time spent just saving and loading state — more overhead, less real work done. |
| Switch rarely (long turns) | Hardly any time wasted switching, so almost all the CPU's effort goes to real work — efficient. | A program may wait a long time for its turn, so the computer can feel laggy and unresponsive. |
Questions you might have
▸What exactly gets saved during a context switch?
The process's 'context' — mainly the values in the CPU's registers (the little scratchpads holding the numbers it's working with right now) and a marker pointing to which instruction it was about to run. Saving those is enough to perfectly rebuild where the process was, so it can resume as if it never stopped.
▸If the CPU pauses my program, does it lose what it was doing?
No — that's the whole point of saving. Before the CPU is handed to another process, your program's state is copied safely into its own save area. When your program's turn comes back, that state is loaded back in and it continues exactly where it left off. It never even knows it was paused.
▸Why is switching called 'overhead'? Isn't it doing something?
It's doing bookkeeping, not your actual work. During a switch the CPU is busy copying state in and out, not running your music or your game. No useful progress happens in that moment — it's a cost you pay for the ability to share the CPU. That's why we call it overhead.
▸Then why not just never switch, to avoid the cost?
Because then only one program could ever run — everything else would freeze until it finished. Switching is what lets your computer juggle many programs at once. The goal isn't zero switching; it's switching often ENOUGH to feel responsive without switching so much that the overhead piles up.
▸Does a context switch happen between threads too?
Yes. The CPU switches between threads the same way — save the current thread's registers and instruction marker, load the next one's. Switching between two threads of the same process can be a bit cheaper, because they share memory so less needs to change, but it's the same save-and-load idea.
Best read after: Process vs. program