Real-Time Operating Systems (RTOS)

A real-time operating system (RTOS) guarantees that critical tasks complete within specified time constraints. Time is the most important resource in these systems, and the OS is designed from the ground up to provide deterministic behavior rather than average-case throughput.

Hard vs. Soft Real-Time

Hard Real-Time

Missing a deadline is system failure:

• Examples: Airbag deployment, anti-lock brakes, pacemaker, flight control
• Consequence: Death, injury, catastrophic damage
• Required: Deterministic, provable timing guarantees

Soft Real-Time

Missing a deadline is degraded performance:

• Examples: Video streaming, VoIP, online gaming
• Consequence: Quality drop, not system failure
• Required: Statistical timing guarantees

Firm Real-Time

Missing occasional deadlines is tolerable, but too many is failure:

• Examples: Industrial control, robotics
• Consequence: Product defects, rejected (not destroyed)

The distinction between hard and soft real-time shapes every design decision, from scheduling algorithm selection to kernel configuration and hardware choice. Hard real-time systems require worst-case execution time (WCET) analysis, while soft real-time systems can rely on average-case performance with appropriate safety margins.

RTOS Scheduling

Rate-Monotonic Scheduling (RMS)

Static priority based on period — shorter period = higher priority:

Task    Period   Priority
Task A  10ms     Highest (shortest period)
Task B  20ms     Middle
Task C  50ms     Lowest

Analysis: A set of tasks is schedulable if utilization ≤ n(2^(1/n)-1). For large n: ~69%.

Earliest Deadline First (EDF)

Dynamic priority — the task with the earliest deadline runs next:

• Higher utilization (up to 100%)
• More complex (priority changes at runtime)
• Can overload unpredictably

Fixed-Priority Preemptive

The most common RTOS scheduler:

1. Each task has a fixed priority
2. Highest-priority ready task always runs
3. A higher-priority task preempts a lower-priority one
4. Tasks of equal priority run in round-robin

Response Time Analysis

For fixed-priority scheduling, calculate worst-case response time for each task:

R = C + B + Σ(C of higher-priority tasks)

Where C is computation time, B is blocking time (lower-priority task holding a resource), and the sum covers all preemptions. The task set is schedulable if R ≤ deadline for every task.

Priority Inversion

A high-priority task is blocked by a lower-priority task holding a shared resource:

Time
  │ Task H (high) tries to lock resource → blocked
  │ Task M (medium) runs (not using resource) ←!
  │ Task L (low) has resource, running slowly
  ▼ H is blocked by L, and M runs instead of H

Solution: Priority Inheritance

When a low-priority task holds a resource needed by a high-priority task, the low-priority task temporarily inherits the higher priority:

Time
  │ Task H tries to lock resource → blocked
  │ Task L inherits H's priority, runs
  │ Task L finishes → releases resource
  │ Task H runs
  ▼

Solution: Priority Ceiling Protocol

A task can only lock a resource if its priority is higher than the ceiling of all currently locked resources. Prevents deadlock and chained blocking. The ceiling is defined as the highest priority of any task that might lock that resource. This protocol ensures that a task can be blocked at most once, eliminating chained blocking entirely.

RTOS Kernel Features

Deterministic Timing

• Constant-time system calls (O(1) scheduling, not O(n))
• Bounded interrupt latency
• No dynamic memory allocation in critical paths
• No virtual memory (no page faults)

Interrupt Handling

Interrupt latency:
  Hardware latency + OS latency + ISR execution time
  └──── Must be bounded and predictable

Two-stage interrupt handling:

1. ISR (Interrupt Service Routine): Quick, runs at interrupt level
2. Task: Deferred processing, runs at task level

Tickless Operation

Traditional RTOS uses a periodic timer interrupt (tick). Tickless mode eliminates idle ticks — the CPU sleeps until the next scheduled event or interrupt.

Benefit: Power saving (critical for battery-powered devices). In tickless mode, the CPU may stay in deep sleep states for extended periods, dramatically extending battery life in wearable and IoT devices.

Memory Management

RTOS kernels typically use static memory allocation to guarantee predictability. Tasks, queues, semaphores, and timers are created at compile time or during initialization. Dynamic allocation is avoided in critical paths because malloc/free have non-deterministic execution times. When dynamic allocation is needed, fixed-block memory pools provide O(1) allocation with predictable behavior.

Popular RTOS

FreeRTOS Example

void vTaskFunction(void *pvParameters) {
    for (;;) {
        // Task code
        vTaskDelay(pdMS_TO_TICKS(100));  // Wait 100ms
    }
---

int main(void) {
    xTaskCreate(vTaskFunction, "Task1", 1024, NULL, 1, NULL);
    xTaskCreate(vTaskFunction, "Task2", 1024, NULL, 2, NULL);
    vTaskStartScheduler();  // Never returns
---

Common RTOS Problems

Jitter Analysis

Jitter — the variation in task response time — is often more damaging than raw latency. In audio processing, 100μs of jitter causes audible artifacts even if average latency is low. Techniques to reduce jitter include locking instruction and data caches, using interrupt coalescing, pinning tasks to specific cores, and disabling CPU frequency scaling.

RTOS vs. GPOS

Safety-Critical Systems

Standards for hard real-time systems:

These standards require traceability from requirements to code, comprehensive testing coverage including MC/DC coverage for the highest levels, and formal methods for the most critical systems. Certification costs often exceed the software development costs, especially for DO-178C Level A and ISO 26262 ASIL D.

WCET Analysis

Worst-case execution time analysis is mandatory for hard real-time systems. Three approaches exist: static analysis (analyzing control flow without running the code), measurement-based (running the code on representative inputs), and hybrid methods. Modern tools like aiT and Otawa provide static WCET analysis by examining binary code paths, cache behavior, and pipeline effects.

Development Tools

RTOS development requires oscilloscopes and logic analyzers alongside traditional debuggers. Timing behavior cannot be understood from code alone — you must measure it on the actual hardware under worst-case conditions.

Architecture Decision Records

Architecture Decision Records (ADRs) document significant architectural decisions and their rationale. Each ADR captures: the context (why the decision was needed), the decision (what was chosen), the alternatives considered (what was rejected and why), and the consequences (tradeoffs and implications). ADRs are stored in version control alongside the code, creating a historical record of design evolution. Benefits include: onboarding new team members faster, preventing repeated debates about past decisions, and providing rationale for future architects questioning why things are the way they are. Start an ADR repository with a lightweight template. Write ADRs for significant decisions that affect system architecture, technology choices, or design patterns. Review ADRs as a team before implementation.

Conway’s Law in Practice

Conway’s Law states that organizations design systems that mirror their communication structures. Teams that communicate frequently will produce tightly coupled components. Teams that communicate infrequently will produce loosely coupled components that communicate through well-defined interfaces. Use this law deliberately: align team boundaries with service boundaries (inverse Conway maneuver). If you want microservices, structure your teams around services. If you want a monolith, have one team. The organization chart and the architecture diagram should be congruent.

FAQ

What is the difference between an RTOS and a general-purpose OS? An RTOS guarantees task completion within deadlines, while a general-purpose OS optimizes average throughput. RTOS kernels are smaller (2-500 KB), use static memory allocation, and have deterministic worst-case timing.

Can Linux be used as an RTOS? Yes, with the PREEMPT_RT patch set. It reduces kernel latency from milliseconds to tens of microseconds. However, the full Linux kernel with RT patches still has a larger footprint and more complex timing behavior than a dedicated RTOS like FreeRTOS.

What is the most popular RTOS? FreeRTOS is the most widely used, with over 30 billion deployments across microcontrollers, IoT devices, and consumer products. It is open source, MIT-licensed, and supported by major microcontroller vendors.

How do you measure RTOS performance? Key metrics include interrupt latency (time from hardware interrupt to ISR start), context switch time, task response time, and jitter (variation in response time). Tools like cyclictest and Tracealyzer measure these on running systems.

What is priority inheritance and why is it important? Priority inheritance temporarily raises a low-priority task’s priority when it holds a resource needed by a higher-priority task. This prevents priority inversion, where medium-priority tasks can indirectly block high-priority tasks from running.

Real-time systems require a different mindset: prove it will meet deadlines, don’t just hope.

Kernel Architecture Guide — Device Drivers Guide — Distributed OS Guide