Can an RTOS be really real-time?

• RTOS
• Software Development

Ask the question What is an RTOS? and you will almost always get a definition along the lines of: "A real-time operating system (RTOS) is a software platform for real-time computing applications that process events and data with well-defined time constraints."

It sounds reassuring. But how can you actually know that RTOS applications process data within "well-defined time constraints" when most of them are written using the dominant shared-state concurrency with blocking model?

As the picture above illustrates, a typical thread function performs some computation interspersed with calls to RTOS services. Many of these services are blocking: time delays, waiting on semaphores or mutexes, receiving from message queues, or waiting on event flags. Worse, these blocking calls are rarely confined to the top-level thread loop. They often appear deep inside call chains, scattered across multiple layers of the codebase. This kind of ad hoc blocking makes it inherently difficult to guarantee that processing completes "with well-defined time constraints".

In other words, even if the RTOS itself is deterministic, the applications built on top of it usually are not. Which leads to the real question: under what conditions can RTOS applications be deterministic and genuinely real-time?

The practical answer is that threads must drastically restrict blocking. The essential structure for this is the event loop, in which blocking is allowed only at a single, well-defined point at the top of the loop. Everything downstream of that point must execute in a non-blocking, run-to-completion manner. For example:

void thread_function(...) {
  ...
  while (1) { // event-loop
    RTOS_block(); // blocking, e.g., message queue receive
    process_event(...); // NON-BLOCKING run-to-completion step
  }
}

In other words, really real-time (RRT) threads must be organized around the event-driven principle [1]. Because blocking is not allowed inside these RRT threads, they also cannot rely on shared resources protected by blocking mutual-exclusion mechanisms such as mutexes. If resource sharing is required, it must be achieved through explicit ownership transfer rather than mutexes.

This architectural discipline is what restores analyzability, bounded execution, and deterministic timing. Without it, an RTOS may be real-time, but the application running on it is not.

[1] David M. Cummings, "Managing Concurrency in Complex Embedded Systems"

Sign in