In some systems a correct answer delivered too late is a wrong answer. A real-time operating system (RTOS) is built to guarantee timing. This lesson shows how it differs from the general-purpose OS on your laptop.

What makes a system real-time?

A real-time system must respond to events within a fixed deadline. Correctness depends on both the result and when it is produced. Two types:

  • Hard real-time: missing a deadline is a failure with serious consequences. Examples: airbag controller, anti-lock brakes, pacemaker, flight control.
  • Soft real-time: occasional missed deadlines degrade quality but are tolerable. Examples: video streaming, online gaming, audio playback.

Real-time does not mean fast; it means predictable. A system that responds in exactly 5 ms every time can be better than one that averages 1 ms but occasionally takes 200 ms. This predictability is called determinism, and the variation in response time is jitter.

How an RTOS achieves this

A general-purpose OS aims at fairness and throughput. An RTOS aims at meeting deadlines:

  • Priority-based preemptive scheduling: the highest-priority ready task always runs, immediately preempting lower ones.
  • Rate-monotonic scheduling: tasks that repeat more often get higher fixed priority.
  • Earliest deadline first (EDF): the task with the nearest deadline runs next.
  • Low, bounded interrupt latency: the time from a hardware event to the start of its handler has a known maximum.
  • Small footprint: minimal kernel for limited memory; examples include FreeRTOS, Zephyr and VxWorks.
  • Predictable memory use: dynamic allocation is often avoided because it can take unpredictable time.

Tasks, synchronisation and pitfalls

Work is split into tasks (threads) such as read sensor, run control calculation, update display. Tasks communicate through queues, semaphores and mutexes.

Task A (priority 3): every 10 ms read the brake sensor
Task B (priority 2): every 50 ms update the dashboard
Task C (priority 1): log data to storage

A well-known hazard is priority inversion: a low-priority task holds a lock needed by a high-priority task, while a medium-priority task keeps preempting the low one. The high-priority task is effectively blocked by a lower one. A solution is priority inheritance, where the lock-holder temporarily takes the higher priority until it releases the lock.

Designers must also analyse the worst-case execution time of each task to prove that all deadlines can be met.

Check your understanding

1. What is the key requirement of a hard real-time system?

  • High average speed
  • Deadlines must always be met
  • Large memory
  • A graphical interface

Answer: Deadlines must always be met. Missing one can cause serious harm.

2. Which is an example of soft real-time?

  • Airbag deployment
  • Pacemaker pulse
  • Streaming video playback
  • Anti-lock braking

Answer: Streaming video playback. An occasional late frame lowers quality but is not catastrophic.

3. What is priority inversion?

  • A high-priority task blocked because a low-priority task holds a needed resource
  • The scheduler running tasks alphabetically
  • Memory being flipped
  • Tasks having equal priority

Answer: A high-priority task blocked because a low-priority task holds a needed resource. Priority inheritance is a common fix.

4. Why is determinism more important than average speed in an RTOS?

  • Fast systems are illegal
  • Timing guarantees depend on bounded, predictable response times
  • Slow systems use less power
  • Averages are impossible to measure

Answer: Timing guarantees depend on bounded, predictable response times. Rare long delays can break a deadline.

Previous