What is Dispatcher Latency?
Dispatcher latency explained — the mechanical cost of a context switch and why it matters for real-time deadlines — interview question answered.
Expected Interview Answer
Dispatcher latency is the time the OS dispatcher takes to stop one process and start another once the scheduler has decided which task should run next — it covers switching context, flushing or reloading the memory-management state, and jumping to the new task’s instruction stream, and it is a critical component of overall scheduling latency in real-time and interactive systems.
When a scheduling decision is made — a higher-priority task becomes ready, or the current task’s time slice expires — the dispatcher is the low-level kernel code responsible for actually performing the handoff: saving the outgoing task’s CPU registers and program counter into its process control block, switching address spaces if moving between processes (which can involve flushing the TLB), restoring the incoming task’s saved state, and transferring control to it. Dispatcher latency specifically excludes the time spent deciding which task to run — that is the scheduler’s job — and measures only the mechanical cost of the switch itself, which matters enormously for real-time systems because a task meeting an otherwise-guaranteed deadline can still miss it if dispatcher latency is too high or too variable. Sources of dispatcher latency include saving and restoring register state, switching page tables and invalidating the TLB, and in preemptible kernels, waiting for any critical section holding a lock that cannot be safely preempted to finish. Real-time operating systems go to great lengths to bound and minimize dispatcher latency — for example by making more of the kernel preemptible, using per-CPU data structures to avoid lock contention, and keeping critical sections short — because a low and predictable worst-case dispatcher latency is often more important for meeting deadlines than raw average-case throughput.
- Directly bounds how quickly a high-priority task can actually start running
- Distinguishes the mechanical switch cost from the scheduling decision itself
- Critical metric for real-time OS certification and deadline guarantees
- Guides kernel design choices like preemptible critical sections and per-CPU structures
AI Mentor Explanation
Dispatcher latency is like the actual time it takes for a substitute fielder to physically jog onto the ground, take position, and be ready to field, after the captain has already decided the substitution — it is not the captain’s decision time, but the mechanical delay of the handoff itself. If the outgoing fielder has to finish walking off and hand over gear before the substitute can start, that extra delay adds to dispatcher latency. A well-drilled team minimizes this handoff time so decisions translate into action almost instantly, just as a real-time OS minimizes dispatcher latency to meet deadlines.
Step-by-Step Explanation
Step 1
Scheduling decision made
The scheduler determines a new task should run — this decision time is NOT part of dispatcher latency.
Step 2
State save
The dispatcher saves the outgoing task's registers, program counter, and stack pointer into its PCB.
Step 3
Address space switch
If switching processes, the dispatcher updates page tables and may flush the TLB, adding measurable latency.
Step 4
State restore and jump
The dispatcher restores the incoming task's saved state and transfers control — the total elapsed time here is the dispatcher latency.
What Interviewer Expects
- A clear distinction between scheduler decision time and dispatcher latency
- Awareness that dispatcher latency includes register save/restore and TLB/page-table costs
- Understanding why bounded, predictable dispatcher latency matters most for real-time deadlines
- Knowledge of kernel techniques (preemptible kernels, per-CPU structures) used to reduce it
Common Mistakes
- Conflating dispatcher latency with the full scheduling decision time
- Thinking dispatcher latency only matters for throughput, not real-time correctness
- Not knowing that lock-holding critical sections can inflate dispatcher latency in non-preemptible kernels
- Ignoring TLB flush and page-table switch cost as a contributor
Best Answer (HR Friendly)
“Dispatcher latency is the time it actually takes the operating system to switch from one task to another once it has already decided which task should run next — saving the old task’s state, loading the new one, and jumping to it. It matters a lot in real-time systems because even if the scheduler picks the right task instantly, a slow or unpredictable handoff can still make that task miss its deadline.”
Code Example
#include <time.h>
struct timespec decision_time, dispatch_done_time;
void on_scheduling_decision(struct task *next) {
clock_gettime(CLOCK_MONOTONIC, &decision_time);
dispatch(next); /* the actual save/restore/switch happens here */
clock_gettime(CLOCK_MONOTONIC, &dispatch_done_time);
}
long dispatcher_latency_ns(void) {
long sec = dispatch_done_time.tv_sec - decision_time.tv_sec;
long nsec = dispatch_done_time.tv_nsec - decision_time.tv_nsec;
return sec * 1000000000L + nsec; /* time spent purely in the handoff */
}
void dispatch(struct task *next) {
save_registers(current_task());
switch_address_space(next); /* may flush TLB -- adds to latency */
restore_registers(next);
jump_to(next->pc);
}Follow-up Questions
- How does dispatcher latency differ from overall scheduling latency?
- Why do real-time kernels prioritize bounding worst-case latency over average-case throughput?
- How does a preemptible kernel reduce dispatcher latency compared to a non-preemptible one?
- What role does TLB flushing play in dispatcher latency during a process switch?
MCQ Practice
1. Dispatcher latency specifically measures?
Dispatcher latency excludes the scheduling decision itself and measures only the cost of performing the actual context switch.
2. Which of these directly contributes to dispatcher latency during a process switch?
Switching address spaces between processes can require reloading page tables and flushing the TLB, adding real, measurable latency to the switch.
3. Why do real-time operating systems focus heavily on minimizing dispatcher latency?
Even a correct scheduling decision is useless if the mechanical handoff takes too long or varies unpredictably, so RTOS kernels bound and minimize it.
Flash Cards
What is dispatcher latency? — The mechanical time to switch from one task to another after the scheduler has already chosen the next task.
What is excluded from dispatcher latency? — The scheduler's decision-making time — only the handoff/switch cost counts.
Name one contributor to dispatcher latency. — TLB flush and page-table switch when changing address spaces between processes.
Why does dispatcher latency matter most in RTOS? — A bounded, predictable latency is needed to guarantee tasks actually meet their deadlines.