The One-Sentence Answer
A real-time operating system is an OS whose scheduler guarantees that the highest-priority ready task runs within a bounded, predictable time. Not fast. Predictable. A desktop OS optimizes for average throughput and will happily pause your task to index files. An RTOS makes a contract: when the interrupt fires, your handler runs, every time, within a latency you can measure and rely on.
That distinction sounds academic until you own a device that misses deadlines. A doorbell camera that drops the frame with the intruder in it. A motor controller that fires the gate driver a millisecond late and cooks a MOSFET. Deadlines are the product.
Deterministic Means Bounded, Not Quick
The core mechanism is preemptive priority scheduling. Every task gets a priority. The scheduler's rule is brutally simple: the highest-priority task that's ready to run, runs, immediately, even if that means yanking the CPU away from something mid-sentence. Per the FreeRTOS kernel documentation, the kernel guarantees this preemption within a bounded window, and that bound is the number you design against.
A general-purpose OS like Linux makes no such promise out of the box. Its scheduler is fair, clever, and utterly nondeterministic. Most of the time a Linux task wakes in microseconds. Occasionally it wakes in tens of milliseconds because the kernel was reclaiming memory. "Occasionally" is fatal in a control loop.
Hard real-time means a missed deadline is a system failure: airbags, pacemakers, flight control. Soft real-time means a missed deadline degrades quality: a dropped video frame, a stuttering audio buffer. The engineering rigor scales accordingly.
The Players You'll Actually Meet
FreeRTOS is the default. MIT-licensed, stewarded by AWS, created by Richard Barry, and running on an enormous share of shipping MCUs, its kernel fits in 4-9 KB of flash. If you've used an ESP32, you've used FreeRTOS whether you knew it or not: Espressif's ESP-IDF is built on it. (Choosing between the ESP32 and its rivals is its own decision, and our STM32 vs ESP32 vs RP2040 comparison walks the whole tree.)
Zephyr is the Linux Foundation's vendor-neutral contender, with Devicetree hardware abstraction and 1,000-plus supported boards. It behaves more like a small Linux than a bare kernel, with networking, filesystems, and Bluetooth in-tree.
Eclipse ThreadX (formerly Azure RTOS) reports over 12 billion device deployments and carries pre-qualified safety certification artifacts, MIT-licensed since Microsoft donated it to the Eclipse Foundation in 2024.
QNX is the microkernel aristocrat, BlackBerry-owned, dominant in automotive digital cockpits. VxWorks from Wind River is the one that literally runs on Mars: NASA JPL flew it on Pathfinder and the rovers that followed.
What an RTOS Actually Gives You Beyond a Scheduler
Queues, semaphores, mutexes, timers, and event groups: the concurrency primitives that let an interrupt hand data to a task without corrupting shared state. This is where real projects live and die. The classic failure mode is priority inversion, where a low-priority task holding a mutex blocks a high-priority one, and it famously froze the Mars Pathfinder lander in 1997. We tell that full story, and the fix, in the Pathfinder article.
The other thing you get is a tick: a periodic timer interrupt, typically 1 kHz, that drives timeouts and time-slicing. Tickless modes exist for battery-powered designs that need to sleep between events.
When You Don't Need One
Honest answer: often. A thermostat reading a sensor once a second and updating a display is a superloop, and adding an RTOS to it adds failure modes, not value. I've reviewed plenty of firmware where the RTOS existed because the template project shipped with it. If your system is one logical task, bare metal is simpler to write, test, and certify.
You need an RTOS when independent activities with different deadlines share one processor: a control loop that cannot jitter, plus a network stack that stalls, plus a UI that's allowed to lag. The moment you find yourself hand-rolling a task switcher inside a superloop, stop. That program has been written, debugged, and certified already, and it's called a kernel.
And at the other end: if you need a display server, a browser engine, or gigabit networking, you've outgrown the class. That's embedded Linux territory, and the RTOS vs Linux decision deserves its own analysis.
Frequently Asked Questions
Is an RTOS faster than Linux? No, and that's the wrong question. A modern Cortex-A running Linux crushes a Cortex-M running FreeRTOS on throughput. The RTOS wins on worst-case latency: its slowest response is measurable and bounded, while Linux's slowest response is a statistical tail you can't fully control. Real-time is about the worst case, never the average.
Is bare metal more reliable than an RTOS? For one task, usually yes, less code, fewer failure modes. For concurrent tasks, no: a hand-rolled scheduler is an unaudited RTOS written by one tired engineer. The commercial kernels have decades of field exposure and, in the certified variants, actual proof artifacts.
Can I run an RTOS and Linux together? That's increasingly the mainstream architecture: a heterogeneous SoC with Linux on the application cores and an RTOS on a Cortex-M companion core handling the hard deadlines. The two halves talk over shared memory. You keep Linux's ecosystem and the RTOS's determinism, and pay for it in inter-processor plumbing.
