Real-Time System

A real-time system is a computational system whose correctness depends not only on the logical result of its computation but on the time at which the result is produced. A correct answer delivered too late is, by definition, incorrect. This is not a statement about performance — it is a statement about specification. A real-time system is not "fast"; it is predictable. The deadline is not a suggestion or a target; it is a boundary between correct and incorrect behavior, as rigid as a type constraint or a memory bound.

The distinction between hard real-time and soft real-time is often presented as a matter of degree, but this framing obscures a categorical difference. In a hard real-time system, a missed deadline is a system failure — the kind that crashes spacecraft, stalls engines, or stops a heart monitor. In a soft real-time system, a missed deadline degrades quality but does not violate correctness: a video frame dropped, a voice packet delayed, a sensor reading slightly stale. The distinction is not quantitative but ontological: hard real-time systems are defined by what they must not do, while soft real-time systems are defined by what they prefer to do.

Scheduling and Predictability

The central engineering problem of real-time systems is not speed but predictability. A real-time scheduler must guarantee, before the system runs, that every task will meet its deadline under all admissible conditions. This is a radically different goal from the throughput-oriented schedulers of general-purpose operating systems, which optimize for average-case performance and tolerate occasional starvation. Real-time scheduling demands worst-case execution time (WCET) analysis — the determination of the longest time a task could possibly take, not the time it usually takes. WCET is notoriously difficult to compute for modern processors with caches, pipelines, and branch prediction, all of which make execution time data-dependent and therefore unpredictable.

The canonical scheduling algorithm for hard real-time systems is rate-monotonic scheduling, which assigns higher priorities to tasks with shorter periods. It is optimal in the sense that if any fixed-priority assignment can meet all deadlines, rate-monotonic assignment can. But this optimality is narrow: it assumes tasks are independent, deadlines equal periods, and execution times are known and bounded. In real systems — where tasks share resources, where priority inversion lurks, where interrupts arrive asynchronously — these assumptions fail, and the elegant proof becomes a liability.

Real-Time as a Systems Philosophy

The real-time perspective recasts many familiar computing concepts. A context switch is not overhead to be minimized but a potential deadline miss. An interrupt is not a convenience but a preemption that must be bounded. Concurrency is not parallelism for performance but a necessity imposed by the need to handle multiple independent event streams within finite time windows. Even the concept of determinism takes on a specific meaning: not that the system is predictable in the sense of a deterministic automaton, but that its temporal behavior is bounded and verifiable.

The Mars Pathfinder incident is the paradigmatic real-time failure not because the system was slow but because its temporal guarantees were violated by a mechanism — priority inheritance disabled — that had nothing to do with the meteorological task's own code. The failure was architectural: the system was correct in every dimension except time, and time was the dimension that mattered.

The fetishization of "real-time" in marketing — real-time analytics, real-time chat, real-time bidding — has diluted the term beyond recognition. Most of what is sold as real-time is merely fast, and fast is not the same thing as guaranteed. A system that usually responds in a millisecond but occasionally takes a second is not a real-time system; it is a probabilistic system with good marketing. The true real-time system is the one that responds in exactly the time it promised, every time, because it was designed to do so, not because it happens to be fast enough today. Real-time is not a performance class. It is a proof obligation.