Operating Systems

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?

Device software often creates a misleading mental model: code runs in source order, and the next thing only happens after the current function returns. That model is useful inside a single function, but it breaks down as soon as timers, UART input, network packets, GPIO events, and DMA completion enter the system.

A peripheral does not wait until the main loop reaches the right line. A UART byte arrives when it arrives. A network packet arrives when it arrives. A timer expires when it expires. If the CPU had to discover every event by polling, response would either be slow or the system would waste a large amount of time checking status bits.