What is the difference between preemptive and cooperative scheduling?

In preemptive scheduling, the RTOS can forcibly suspend a running task at any tick interrupt or event and switch to a higher-priority task. The running task does not need to voluntarily give up the CPU — the kernel takes it away. This is the default mode in most RTOS kernels (FreeRTOS, Zephyr, VxWorks) and ensures that the highest-priority ready task always runs with bounded latency.

In cooperative scheduling, a task runs until it explicitly yields the CPU (by calling a blocking API, taskYIELD(), or a delay function). No tick-based preemption occurs. This is simpler (fewer race conditions, since task switches only happen at known points) but dangerous: a single task that forgets to yield or enters a long computation starves all other tasks. Cooperative scheduling is sometimes used in very simple systems or in combination with preemptive scheduling (e.g., tasks at the same priority time-slice cooperatively in FreeRTOS when configUSE_TIME_SLICING is enabled).

Most embedded interviews expect you to advocate for preemptive scheduling and explain its trade-offs: it requires more careful synchronization (critical sections, mutexes) because a task can be preempted at any point, but it provides guaranteed responsiveness. A useful comparison: cooperative scheduling guarantees mutual exclusion between points where you yield (no need for mutexes if you never yield inside a critical section), but it cannot guarantee response time because any task can hog the CPU indefinitely.