OS scheduling terms: In a multitasking operating system, what is the role of the dispatcher in relation to getting tasks onto the CPU?

Introduction / Context:
Scheduling is a two-part process: a scheduler chooses which runnable task should execute next based on policy, and a dispatcher performs the low-level context switch to start that task on the CPU. Understanding this distinction is important for OS design and troubleshooting latency.

Given Data / Assumptions:

• The system has a ready queue of runnable tasks.
• The scheduler has selected a next task (according to policy like priority, fairness, deadlines).
• The dispatcher executes the mechanics of switching contexts.

Concept / Approach:

While the high-level decision (“which task next?”) is the scheduler’s responsibility, the dispatcher handles the actual context switch: saving the current context, loading the chosen task’s context, updating CPU registers, and transferring control. In many texts, this concrete act is described as “dispatching” the process to the processor, i.e., actually getting it onto the CPU.

Step-by-Step Reasoning:

Verification / Alternative check:

OS textbooks and kernel code separate pick-next-task (scheduler) and context_switch (dispatcher). Traces show the dispatcher enabling the selected task to run on the CPU.

Why Other Options Are Wrong:

• Puts tasks in I/O wait: I/O wait is a task state change due to I/O, not the dispatcher’s job.
• Is always small and simple: Implementation detail; not universally true.
• Never changes task priorities: Dispatcher does not manage priorities; but “never” statements are risky—policies may interact during dispatch.
• None of the above: Incorrect because the dispatcher does hand tasks to the CPU.

Common Pitfalls:

Conflating the scheduler’s decision-making with the dispatcher’s context-switching; assuming the dispatcher manages priorities or I/O states.

Final Answer:

actually schedules the tasks into the processor