Threads

“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.

Many concurrency bugs start with one overloaded word: task.

On Linux, people say “start a process.” In application frameworks, they say “create a thread.” In an RTOS, they often say “create a task.” All three sound like “make some code run at the same time,” but their resource boundaries are very different.

If they are only understood as “units of code execution,” engineering judgment quickly goes wrong. Why can one thread crash an entire process? Why can two processes not directly access each other’s variables? Why is sharing global variables between RTOS tasks so common? Why are Linux process switches and thread switches not exactly the same cost?