Walk through the task states and what causes transitions.

A task is always in one of a few states. Running means it's currently executing on the core, only one task runs per core at a time. Ready means it could run but a higher-priority task currently has the CPU, so it's waiting its turn. Blocked means it's waiting for an event, a delay to expire, an item to arrive on a queue, a semaphore to be given, and crucially it consumes no CPU while blocked; the scheduler skips it until the event or a timeout wakes it. Suspended means it's been explicitly parked and won't run until resumed. The transitions: a new task starts Ready; the scheduler moves the highest-priority Ready task to Running; a Running task goes back to Ready if it's preempted or time-sliced; it goes Blocked when it calls a blocking API to wait, and returns to Ready when the awaited event or timeout occurs; and it goes Suspended/Ready via explicit suspend/resume calls. The central insight is the Running↔Blocked transition: a task blocks to wait, handing the CPU to other Ready tasks, which is exactly why an RTOS multitasks efficiently, waiting costs nothing.