Concurrency

In an RTOS project, task count can grow from two to a dozen quickly.

A common split looks natural:

• one UART task
• one sensor task
• one cloud task
• one button task
• one storage task
• one display task

This is not always wrong, but it often splits code by module name. Tasks actually affect scheduling, blocking, stacks, priorities, synchronization, and resource ownership. Bad task boundaries later look like concurrency bugs.

The first model is:

Some embedded and systems bugs are hard to reproduce: adding a log makes them disappear, disabling optimization hides them, changing CPU architecture exposes them, or multicore load makes them fail occasionally.

The first reaction is often to add volatile.

But volatile is not a thread synchronization primitive. It is not a memory barrier, and it is not a lock. It can prevent the compiler from optimizing away certain accesses, but it does not guarantee multicore visibility order, and it does not turn x++ into an atomic operation.

Many concurrency bugs trigger the same first reaction: add a lock. That is only half right.

A lock can protect shared state, but it does not make concurrency problems disappear. It turns “multiple execution flows modify data at the same time” into rules about who enters first, who waits, and who releases. If those rules are poorly designed, the system may stop corrupting data and instead start hanging, stalling, timing out, or delaying high-priority work.