the dispatcher
If the scheduler is the judge who decides who goes next, the dispatcher is the usher who actually walks that person to the stage. Once the short-term scheduler has chosen a process, the dispatcher is the small, low-level piece of the kernel that does the physical work of giving the CPU to it.
Walking through what the dispatcher does, in plain steps: it performs the context switch — saving the registers and program counter of the outgoing process into its process control block, then loading the saved registers and program counter of the chosen process. It switches to user mode (dropping out of the kernel's privileged mode). And it jumps to the right place in the new process's code so execution resumes exactly where that process last left off. After this, the chosen process is running as if it had never stopped.
Why it deserves its own name: the dispatcher is invoked on every single context switch, so it must be lean. The delay it adds — the time from stopping one process to running the next — is called dispatch latency, and it is pure overhead. The more often the OS switches (for example, with a very small time quantum), the more total time is lost to the dispatcher rather than to real work.
The scheduler picks process B. The dispatcher then saves A's registers into A's PCB, loads B's registers from B's PCB, restores B's saved program counter, switches to user mode, and the CPU resumes B mid-instruction-stream. To A and B it is invisible; each just sees itself running continuously.
The dispatcher is the mechanism that turns the scheduler's choice into a running process.
The dispatcher carries out a context switch but is not the same thing — the context switch is the register-saving mechanism (a process-management concept); the dispatcher is the scheduling code that invokes it and resumes the chosen process.