hard versus soft real-time
Two systems both promise to respond 'on time', but they mean very different things by it. Think of a car's airbag controller versus a video streaming app. The airbag MUST deploy within milliseconds of a crash — being late is not 'slow', it is a catastrophic failure. The video app should show the next frame on time, but if one frame is a little late you get a momentary glitch and life goes on. That contrast — when does missing the deadline cause failure versus mere annoyance — is the difference between hard and soft real-time.
A deadline is the latest time by which a response must complete. In a HARD real-time system, missing ANY deadline is a system failure, possibly dangerous: think airbags, engine ignition timing, pacemakers, industrial motor control. Correctness is defined to INCLUDE timing — a right answer delivered late is a wrong answer. These systems must be designed and analyzed so that every deadline is provably met even in the worst case, which is why hard real-time work leans on worst-case execution time analysis, deterministic scheduling, and bounded interrupt latency. In a SOFT real-time system, deadlines are goals: missing one degrades quality (a dropped video frame, a slightly laggy menu) but the system is still useful, and an occasional miss is acceptable. There is also an in-between term, FIRM real-time, where a result that arrives after its deadline has no value (you just discard it) but missing some is tolerable. The labels describe the CONSEQUENCE of lateness, not the speed: a hard real-time system can have a deadline of one whole second.
It matters because it tells you how much rigor your timing analysis needs and what guarantees your design must provide. The honest, frequently-muddled points: 'real-time' (hard or soft) is about PREDICTABILITY and meeting deadlines, NOT about being fast — a fast system that occasionally and unpredictably stalls is NOT hard real-time. Most consumer software (media playback, games, UIs) is soft real-time at most. And true hard real-time guarantees usually require a hard real-time OS or careful bare-metal design plus worst-case analysis; running a deadline-critical task on top of a general-purpose OS like ordinary Linux generally does NOT give a hard guarantee, because the OS can introduce unbounded delays.
Deadline = 5 ms after a trigger. HARD : airbag fire pulse. Miss it once -> system failure (unsafe). Must be PROVEN to meet 5 ms in the worst case. FIRM : a frame in a live render. Late frame -> discarded, no value. SOFT : a UI animation step. Late -> a tiny visible stutter, still OK. Note: 'fast on average' is NOT enough for hard — the worst case matters.
The same numeric deadline, three consequences for missing it: failure (hard), discarded result (firm), degraded quality (soft).
Hard real-time is about guaranteed worst-case timing, not speed: a system that is fast on average but occasionally stalls is not hard real-time. Plain Linux generally cannot give hard guarantees because it can introduce unbounded delays.