Control without voluntary yielding
Cooperative execution depends on tasks returning control through calls, waits, or explicit yielding. A loop that never does so can prevent other work from receiving a timely turn.
A hardware timer can interrupt execution and return control to the kernel. The system can then suspend current work and select another ready task. Preemption supplies this capability; scheduling policy determines when and how to use it.
References: [1]
Time slices serve different objectives
Round-robin scheduling gives ready tasks successive slices. Short slices can reduce the wait for an initial turn but increase switching frequency; longer slices amortize switch costs over more work.
Response time, completion time, and fairness can conflict. Blocking for I/O also changes which tasks are ready. A preemptive system therefore need not assign every task an identical fixed share at all times.
References: [2]
Execution opportunities do not supply synchronization
Alternating tasks on one processor supports concurrent progress without requiring simultaneous execution of their ordinary instructions. Multiple cores can provide physical parallelism, subject to available resources and scheduling.
A task may be paused during a shared-state update. Programs still need synchronization to protect multi-step invariants. Preemption alone provides neither automatic data consistency nor a fixed worst-case response bound; those require additional constraints.