Scheduling

The most common RTOS priority mistake is assigning priorities by business importance.

For example:

control task is most important -> highest priority
communication is also important -> next priority
logging is not important -> lowest priority

This is intuitive, but not enough. RTOS priority decides which ready task runs first. It is not the same as business value, and it does not guarantee that a high-priority task finishes first.

The first model is:

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:

Engineering code often contains calls like these:

wait_event_timeout(..., 1000);
sleep(1);
select(fd + 1, &rfds, NULL, NULL, &tv);

They all look like “wait for a while.” But waiting inside an operating system does not mean the CPU sits still and counts time.

A timeout usually passes through several steps: the program submits a wait request, the kernel places the current thread on a wait queue, a timer records the latest wakeup time, the scheduler gives the CPU to another thread, hardware clocks or timer interrupts advance time, and the thread is woken when the condition is satisfied or the timeout expires.