Cooperative vs Preemptive Multitasking
Cooperative vs preemptive multitasking explained — voluntary yield vs timer-interrupt preemption — with an OS interview question answered.
Expected Interview Answer
Cooperative multitasking relies on each running task voluntarily yielding the CPU back to the scheduler, while preemptive multitasking lets the OS forcibly interrupt a running task at any time via a timer interrupt, so no single task can monopolize the CPU or hang the whole system.
Under cooperative multitasking, a task keeps the CPU until it explicitly calls a yield function, blocks on I/O, or finishes, which means a well-behaved set of tasks can share the CPU efficiently with very low switching overhead, but a single buggy or infinite-looping task can freeze the entire system because nothing forces it to give up control. Preemptive multitasking removes that risk: a hardware timer fires a periodic interrupt, the OS scheduler runs regardless of what the current task is doing, and it can suspend the task mid-instruction-stream to hand the CPU to something else, which is essential for responsiveness and fairness in general-purpose and multi-user systems. The cost of preemption is that it introduces more frequent context switches and requires the OS and application code to handle being interrupted at arbitrary points, which is why critical sections need locks or interrupt-disabling to stay correct. Nearly all modern general-purpose operating systems — Linux, Windows, macOS — use preemptive scheduling, while cooperative multitasking survives in constrained contexts like older Windows 3.x era systems, some embedded RTOS configurations, and single-threaded event loops such as Node.js or classic JavaScript in a browser tab.
- Preemptive: guarantees fairness — no task can starve others indefinitely
- Preemptive: system stays responsive even if one task hangs or loops forever
- Cooperative: lower context-switch overhead when tasks are well-behaved
- Cooperative: simpler reasoning about shared state since yield points are explicit
AI Mentor Explanation
Cooperative multitasking is like a batter deciding for themselves when to declare an innings closed, trusting them to hand the bat over at a sensible time — but if they refuse to declare, the game never moves on and the other team never gets to bat. Preemptive multitasking is like the umpire enforcing a hard overs limit that ends the innings automatically regardless of what the batting side wants, guaranteeing both teams get their fair share of overs. The umpire’s timer-driven cutoff is exactly what a hardware timer interrupt does to a running process.
Step-by-Step Explanation
Step 1
Cooperative: task runs
A task keeps the CPU indefinitely, running until it voluntarily calls yield, blocks on I/O, or exits.
Step 2
Cooperative: voluntary yield
The task explicitly hands control back to the scheduler, which then picks the next task to run.
Step 3
Preemptive: timer interrupt
A hardware timer fires at a fixed interval regardless of what the running task is doing.
Step 4
Preemptive: forced context switch
The interrupt handler invokes the scheduler, which can suspend the current task and dispatch another, whether the task agreed or not.
What Interviewer Expects
- A clear contrast: voluntary yield vs forced timer-interrupt preemption
- Understanding that cooperative multitasking risks one task freezing the whole system
- Awareness that preemption requires locking/critical-section discipline
- Real-world examples of where each model is used today
Common Mistakes
- Claiming all modern OSes still use cooperative multitasking
- Not explaining the hang risk of cooperative scheduling
- Forgetting that preemption increases context-switch overhead
- Confusing preemptive multitasking with multi-core parallelism
Best Answer (HR Friendly)
“Cooperative multitasking means each running program is trusted to give up the CPU on its own when it is ready, which works well if every program behaves but can freeze the whole system if one program never lets go. Preemptive multitasking means the operating system forcibly interrupts a running program on a timer, so it can always give other programs a turn — that is why a hung app on a modern computer usually does not freeze everything else.”
Code Example
/* Cooperative model: task must call this itself */
void cooperative_yield(void) {
save_current_task_state();
schedule_next_task(); /* only runs if the task chooses to call this */
}
/* Preemptive model: fired automatically by hardware, task has no say */
void timer_interrupt_handler(void) {
save_current_task_state(); /* forced, regardless of what task is doing */
if (time_slice_expired()) {
schedule_next_task(); /* scheduler decides, not the task */
}
restore_next_task_state();
}Follow-up Questions
- What real risk does cooperative multitasking carry that preemptive avoids?
- How does a timer interrupt actually trigger a context switch?
- Why do critical sections need locks under preemptive scheduling but not always under cooperative?
- Where does cooperative-style scheduling still show up in modern software?
MCQ Practice
1. In cooperative multitasking, who decides when a running task gives up the CPU?
Cooperative multitasking relies on each task explicitly yielding, blocking, or exiting — the OS never forces it off the CPU.
2. What is the biggest risk of cooperative multitasking?
Since no mechanism forces a task off the CPU, one task that never yields can starve every other task indefinitely.
3. What mechanism enables preemptive multitasking?
A hardware timer fires interrupts at regular intervals, letting the OS scheduler forcibly reclaim the CPU from the running task.
Flash Cards
Cooperative multitasking in one line? — Tasks voluntarily yield the CPU; nothing forces them off.
Preemptive multitasking in one line? — The OS forcibly interrupts a running task via a timer interrupt to reclaim the CPU.
Main risk of cooperative multitasking? — A task that never yields can freeze the whole system.
Which model do Linux, Windows, and macOS use today? — Preemptive multitasking.