Context Switching and the Dispatcher

Context switching ties process states, the PCB, and scheduling together — interviewers ask "what happens during a context switch?" and "scheduler vs dispatcher?" to test whether you understand the mechanics behind multitasking.

Context switch

A context switch is the OS saving the state of the current process (into its PCB) and loading the saved state of the next process, so the CPU can switch execution. The saved state includes the program counter, CPU registers, and memory-management info.

It is pure overhead — no useful work happens during the switch. Triggers: timer interrupt (preemption), I/O block, or a higher-priority process arriving.

Scheduler vs dispatcher

• Scheduler — decides which process runs next (the policy/algorithm).
• Dispatcher — does the switch: gives CPU control to the chosen process, switching context, switching to user mode, and jumping to the right instruction.

Dispatch latency is the time the dispatcher takes to stop one process and start another.

	Scheduler	Dispatcher
Role	decides who runs (policy)	performs the switch (mechanism)
Output	selects a process	gives it the CPU
Metric	scheduling criteria	dispatch latency

Exam Tricks & Tips

• 🎯 A context switch saves the current PCB and loads the next — the PCB is exactly what makes resumption possible.
• 🎯 Context switching is pure overhead (no useful work) — reducing its frequency/cost improves throughput.
• 🎯 Scheduler decides, dispatcher does — the scheduler picks the process (policy), the dispatcher performs the actual switch (mechanism).
• 🎯 Dispatch latency = time to stop one process and start the next — a metric distinct from waiting/turnaround time.
• 🎯 A same-process thread switch is cheaper than a process switch (no address-space/TLB change).
• ❌ Common mistake: conflating scheduler and dispatcher — the scheduler is the decision-maker, the dispatcher is the executor.

Expected pattern

"What happens during a context switch?", "scheduler vs dispatcher", "what is dispatch latency?", "is a context switch useful work?", and "what triggers a context switch?".

Quick recap

A context switch saves the running process's state to its PCB and restores the next process's — pure overhead triggered by interrupts, I/O, or preemption. The scheduler decides who runs (policy); the dispatcher performs the switch (mechanism), and dispatch latency measures how long that takes.

Cover the answer, recall, then check. 11 cards on context switching and the dispatcher.

Q1. What is a context switch?
A1. Saving the current process's state to its PCB and loading the next process's state, so the CPU can switch execution.

Q2. What state is saved during a context switch?
A2. The program counter, CPU registers, and memory-management information — stored in the PCB.

Q3. Why is context switching considered overhead?
A3. No useful user work happens during the switch; it's pure bookkeeping, so it should be minimized.

Q4. What triggers a context switch?
A4. Timer interrupts (preemption), I/O requests/blocking, system calls, or arrival of a higher-priority process.

Q5. What does the scheduler do?
A5. Decides which process runs next according to the scheduling policy/algorithm.

Q6. What does the dispatcher do?
A6. Performs the actual switch — hands CPU control to the chosen process, switches mode, and jumps to the right instruction.

Q7. Scheduler vs dispatcher in one line?
A7. Scheduler decides (policy); dispatcher executes the switch (mechanism).

Q8. What is dispatch latency?
A8. The time the dispatcher takes to stop one process and start running another.

Q9. Why is a thread switch cheaper than a process switch?
A9. Threads share the address space, so no memory-map/TLB change is needed during the switch.

Q10. What data structure makes resuming a process possible?
A10. The PCB — it holds the saved PC and registers needed to restore execution.

Q11. Does a context switch do useful application work?
A11. No — it is overhead; the goal is to keep switches infrequent/cheap enough to maximize throughput.

Every time the CPU changes which process it runs, it performs a context switch — the invisible machinery that makes multitasking possible. It is pure overhead (no user work happens during it), so understanding its cost is key to reasoning about scheduler performance.

Core idea: a context switch is the act of saving the state of the currently running process into its PCB and loading the saved state of the next process from its PCB, so the CPU can switch execution. The dispatcher is the OS module that performs this switch and hands the CPU to the process the scheduler selected.

How it works

Beginner — what "context" means

A process's context is everything the CPU needs to resume it: the program counter, CPU registers, stack pointer, and memory-management state (page-table base). Switching means: freeze process A's context into A's PCB, thaw process B's context from B's PCB.

Intermediate — scheduler vs dispatcher

These are distinct roles often confused:

• The scheduler decides which Ready process runs next (the policy — FCFS, RR…).
• The dispatcher carries out that decision (the mechanism): it does the context switch, switches to user mode, and jumps to the right instruction in the selected process.
  Dispatch latency is the time the dispatcher takes to stop one process and start another — pure overhead you want small.

Advanced — when and why switches happen

A context switch is triggered by:

• a timer interrupt (time slice expired, in preemptive scheduling),
• a process blocking on I/O (Running → Waiting),
• a higher-priority process becoming Ready (preemption),
• a system call or interrupt requiring the kernel.

Running(A) --interrupt--> kernel saves A's regs -> PCB[A]
           -> scheduler picks B
           -> dispatcher loads PCB[B]'s regs, switches address space
           -> Running(B)

Cost is not just the register copy: switching address spaces flushes the TLB and pollutes the CPU cache, so the new process starts with cold caches. This indirect cost usually dwarfs the direct save/restore.

Worked example — measuring the overhead's impact

Suppose a context switch costs 10 µs and a Round-Robin quantum is 100 µs. Then each 100 µs of user work carries 10 µs of switching → about 9% overhead (10 / 110). Halve the quantum to 50 µs for better responsiveness and overhead jumps to ~17% (10 / 60); the CPU now spends a sixth of its time just switching. This is the concrete trade-off behind "small quantum = responsive but wasteful" — the switch cost is fixed, so shorter slices amortise it over less useful work.

Interview & exam relevance

Common asks: "what happens during a context switch", "difference between scheduler and dispatcher", "what is dispatch latency", and "why is a context switch expensive?" (TLB flush + cache pollution, not just register saves). A frequent point: during a context switch no useful work is done — it is pure overhead.

Tricks & gotchas

• Scheduler = policy (who runs next); Dispatcher = mechanism (perform the switch). Don't conflate them.
• Thread-to-thread switches within one process are cheaper — the address space (and much of the TLB) stays the same.
• The true cost is dominated by cache/TLB effects, not the register copy.
• Mnemonic: "Scheduler chooses, dispatcher changes."

Worked Example

Problem: A round-robin scheduler uses a time quantum of 4 ms. Each context switch costs 1 ms of pure overhead (no useful work). (a) What fraction of CPU time is wasted on switching? (b) If the quantum is dropped to 1 ms to improve responsiveness, what is the new overhead fraction, and what is the trade-off? (c) Name what the dispatcher actually does during a switch.

Solution:
Round robin runs each process for one quantum, then a context switch hands the CPU to the next process. In each cycle the CPU spends (quantum) doing useful work and (switch cost) as overhead.

(a) Quantum = 4 ms, switch = 1 ms. Each 4 ms of work costs 1 ms of overhead, so per cycle the CPU spends 4 + 1 = 5 ms, of which 1 ms is wasted.
Overhead fraction = 1 / (4 + 1) = 1/5 = 20%.
Useful-work efficiency = 4/5 = 80%.

(b) Quantum = 1 ms, switch = 1 ms. Now each cycle is 1 + 1 = 2 ms with 1 ms wasted.
Overhead fraction = 1 / (1 + 1) = 1/2 = 50%.
Efficiency collapses to 50%. Trade-off: a smaller quantum improves responsiveness/interactivity (each process is served sooner) but the fixed switch cost is now a huge share of every cycle, so throughput plummets. A very large quantum, conversely, makes RR degrade toward FCFS. The quantum is chosen well above the switch time (commonly 10–100 ms) so overhead stays small while response stays acceptable.

(c) During a switch the dispatcher: (1) saves the running process's context (program counter, registers, stack pointer) into its PCB; (2) selects the next process from the ready queue (per the scheduling policy); (3) restores that process's context from its PCB; (4) switches to user mode and jumps to the saved PC. The time to do (1)–(4) is dispatch latency — pure overhead because no user work happens meanwhile.

Answer: (a) 1/5 = 20% overhead (80% efficiency). (b) 1/2 = 50% overhead — better responsiveness but far lower throughput. The dispatcher saves the old context to the PCB, picks the next process, restores its context, and resumes it; that time is pure overhead.