Scheduler

“Switch to another task” sounds light, as if the CPU simply moves from one piece of code to another.

The real operation is more concrete. While the CPU is running an execution flow, registers contain intermediate state, the stack contains the call chain, the program counter points to the next instruction, and the scheduler knows whether the flow is running, ready, or blocked. To run another thread or task, the system must save the current state and restore another one.

Many performance problems first look like “the CPU is too slow”: a button responds late, UART handling misses data, network packets pile up, the UI stalls, or sensor data reaches the application thread late.

But CPU load is only one layer. What often decides responsiveness is when the code gets to run.

Code existing in memory does not mean it can run at any moment. It may not be ready yet. It may be waiting for a lock, queue, or I/O. It may be blocked behind a higher-priority task. It may have just been woken by an interrupt but not yet selected by the scheduler.