a real-time operating system

A real-time operating system is one whose most important promise is not speed but timing: it guarantees that certain tasks finish before a strict deadline, every time. Think of an air-traffic controller or an anti-lock braking system in a car — being fast on average is useless if it is ever even slightly late at the wrong moment. An ordinary desktop OS tries to feel responsive on average; an RTOS is built so that a critical response provably happens within a bounded, predictable time, even in the worst case.

The defining property is determinism: the time from an event (say, a sensor reading) to the system's response is bounded and known, not just usually small. To achieve this, an RTOS keeps its dispatch latency tiny and predictable, uses priority-based preemptive scheduling so a higher-priority task can immediately push a lower-priority one aside, and takes special care with priority inversion (it commonly uses priority inheritance so a low-priority task holding a needed lock is temporarily boosted). Real-time scheduling theory — rate-monotonic scheduling and earliest-deadline-first — lets engineers prove in advance that, given the task periods and worst-case run times, every deadline can be met. People distinguish hard real-time (missing a deadline is a failure, as in a pacemaker or flight control) from soft real-time (an occasional miss merely degrades quality, as in video playback).

The honest point is that real-time does not mean fast — it means on time and predictable. In fact an RTOS often gives up raw average throughput for predictability: features that make a general-purpose OS quick on average (deep caches, complex schedulers, unbounded queues) can make worst-case timing unpredictable, so an RTOS deliberately keeps things simpler and more analyzable. A very fast desktop computer is not a real-time system, because it cannot guarantee that a given response will never be late.