preemptive vs non-preemptive scheduling
Imagine two ways to share a microphone at a meeting. In one, whoever is speaking holds it until they voluntarily hand it back — that is cooperative, and one long-winded speaker can block everyone. In the other, a moderator can cut someone off mid-sentence to let an urgent point through — that is preemptive. CPU scheduling has exactly these two styles, and the difference shapes how fair and responsive a system can be.
Precisely: under non-preemptive (also called cooperative) scheduling, once a process gets the CPU it keeps it until it either finishes or voluntarily gives it up by blocking on I/O. The OS cannot forcibly take the CPU back. Under preemptive scheduling, the OS can stop a running process at any moment — typically when a timer interrupt fires or a higher-priority process becomes ready — save its state, and give the CPU to another process. Preemption requires hardware support (a timer) and careful handling of shared kernel data, because a process can now be interrupted in the middle of updating it, which can cause race conditions if not guarded.
Why it matters: preemption is what makes time-sharing and good interactive response possible — no single process can freeze the machine. The cost is overhead (more context switches) and the need for synchronization in the kernel. Non-preemptive scheduling is simpler and switch-cheap, and is fine for some embedded or batch settings, but it is fragile: a buggy or greedy process that never yields can starve everything else. Nearly all general-purpose desktop and server operating systems today are preemptive.
Non-preemptive FCFS: a 1000 ms job starts, and a 1 ms job that arrives just after must wait the full second. Preemptive round-robin with a 10 ms quantum: after 10 ms the timer interrupts, the long job is paused, the short job runs and finishes almost immediately, then the long job resumes.
Preemption lets a short, late-arriving job jump in instead of waiting behind a long one.
Preemption is not free safety: because a process can be interrupted while modifying shared kernel data, a preemptive kernel must use synchronization (locks, disabling preemption in critical sections) to avoid race conditions.