RTOS Concepts: Tasks, Scheduling and Semaphores Guide.

A Real-Time Operating System (RTOS) is an operating system that guarantees a response within a strict time limit called a deadline. Unlike Windows or Linux, which are fast on average, an RTOS promises a critical task finishes before its deadline, every single time. An airbag controller that usually reacts in 5 ms but once takes 200 ms has failed — a late answer is as bad as a wrong one.

This timing guarantee is why cars, pacemakers, drones and factory robots run RTOS kernels like FreeRTOS. The three ideas you must master are tasks (independent threads of work), scheduling (deciding which task runs when) and semaphores (how tasks coordinate safely).

Key Concepts

• Task: a thread of execution with its own stack, priority and state — Ready (wants CPU), Running (has CPU), or Blocked (waiting for an event or delay).
• Scheduler: picks the next task to run; usually priority-based and preemptive — the highest-priority Ready task runs immediately, interrupting lower-priority ones.
• Tick and context switch: a hardware timer tick (often 1 ms) drives scheduling; a context switch saves/restores task registers, costing CPU time — too many tasks hurt.
• Rate Monotonic Scheduling (RMS): shortest period gets highest priority. Earliest Deadline First (EDF) instead runs whichever deadline is nearest.
• Semaphore: a signalling counter. A binary semaphore (0/1) signals events, e.g. from an interrupt to a task; a counting semaphore tracks multiple identical resources like free buffers.
• Mutex and priority inversion: a binary semaphore with ownership plus priority inheritance, curing priority inversion — where a medium-priority task blocks a high-priority one via a shared resource.

Formulas

The Liu–Layland bound tests RMS schedulability: utilization U = C1/T1 + C2/T2 + … + Cn/Tn must satisfy U ≤ n(2^(1/n) − 1) — about 0.828 for 2 tasks, 0.780 for 3, approaching 0.693 for many. Assumes independent periodic tasks, deadline equals period, negligible switch cost. The bound is sufficient but not necessary: failing it removes the guarantee without proving unschedulability.

Worked Example

Task A: 2 ms every 10 ms; task B: 5 ms every 25 ms. U = 2/10 + 5/25 = 0.40. Bound for n = 2: 2(√2 − 1) = 0.8284. Since 0.40 ≤ 0.8284, the set is guaranteed schedulable. Priorities follow periods — A outranks B; if both wake together, A runs 2 ms first and B still has 23 ms before its deadline. Timing proven before a line of code runs.

Common Misconceptions

• "An RTOS is just a fast OS." The point is determinism, not speed: a guaranteed 3 ms worst case beats an average 1 ms with 50 ms spikes.
• "Semaphores and mutexes are interchangeable." A mutex has an owner and priority inheritance for protecting shared data; a binary semaphore has no owner and is for signalling, e.g. from an ISR to a task.
• "More tasks = more responsive." Each task adds stack RAM and context-switch overhead — group related work into fewer, well-prioritized tasks.

Real-World Applications

• Automotive ECUs: engine, ABS and airbag controllers run OSEK/AUTOSAR RTOS kernels where missed deadlines are safety failures.
• Medical devices: pacemakers, infusion pumps and monitors need deterministic scheduling.
• Industrial robots: motion-control loops execute every few milliseconds under an RTOS.
• IoT firmware: FreeRTOS powers millions of ESP32 and Cortex-M devices, one task per sensor or network job.

An RTOS trades throughput for timing guarantees: prioritized tasks, preemptive scheduling, semaphores and mutexes. Master the utilization bound and the semaphore/mutex distinction, and you can prove worst-case behaviour — what safety-critical engineering demands.