I came across an application called LatencyMon, that apparently does latency monitoring.

I have always understood that the more of a load you put on the processor, the less responsive, or more latent, the system becomes. However, in the second section of the LatencyMon page, the first sentence says, "Windows is not a real-time operating system" (RTOS). That got me thinking. I mean, is this any different from any other operating system like Linux, Unix, or Mac OS X?

Are there any "real-time" operating systems? Or is it merely a marketing scheme to get you to buy their product?


Also, are there any examples of RTOS's out there?

  • 4
    QNX is real-time, for example. – new123456 Mar 31 '12 at 1:54

Wikipedia actually has a surprising wealth of info here.

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests.

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. An RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.

An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

This is something that very few operating systems actually do, because for a lot of workloads it's simply less efficient. None of the major consumer operating systems are now (or to my knowledge have ever been) real-time. Unfortunately, it does mean that sometimes things in a non-real-time environment do have to sit around waiting on other things. This only becomes a problem when something's not yielding in a reasonable amount of time, generally.

Currently the best known, most widely deployed, real-time operating systems are:

Windows CE

See the list of real-time operating systems for a comprehensive list.

  • 6
    Real-time OSs are normally used in very dedicated roles such as extremely precise control systems where a decision/calculation/etc must be completed in a very exacting timeframe. – Lamar B Mar 30 '12 at 21:04
  • Are there any examples of RTOS's? Updating the question to this respect. – Chad Harrison Mar 30 '12 at 21:11
  • What @ta.speot.is said - there's some in the article already linked. I'll edit some in, though. – Shinrai Mar 30 '12 at 21:17
  • I didn't make to the bottom of the Wiki page... Sorry bout that :/ – Chad Harrison Mar 30 '12 at 21:26

Real Time operating systems are often used for embedded systems, where they might be responsible for something like guidance or system monitoring. The key thing to remember about a real time system (and what differentiates it from a non real-time system) is that in a real time system, if an answer is late, it's wrong. You can easily see how this works by thinking about adding up a series of figures in Excel (where if the operation is delayed, there's no real impact) versus applying a brake in a car (where a delay could be catastrophic).


Basically, a RTOS can guarantee it can service an IRQ (interrupt request) in a specific (usually low) timeframe. Standard operating systems do not have such a guarantee.

In most modern systems, most devices can generate an IRQ. This causes the CPU to stop (i.e. be interrupted of) what it's doing and run an interrupt service program. The idea is that this service program does whatever the device needs, i.e. gets data off of the device and into RAM, tells the device what to do next, etc.

On x86, since it has only 1 IRQ line on the CPU, when it receives an interrupt, further interrupts are automatically disabled (except for NMI, RESET, and SMI) until the CPU acknowledges the interrupt source and reenables them. So good device drivers under standard i386/amd64 Windows will do minimal processing in this state, just enough so that it's OK to reenable interrupts, and then defer complete processing of the interrupt until later (because the system can technically only service 1 interrupt per CPU core at a time). I'm not sure but I believe Linux does the same. Nonetheless, there is no hard guarantee made of the time that the interrupt will be serviced under.

For most PC devices, such as disks, keyboards, NICs, if there is a slight delay servicing their IRQ, nothing bad will happen other than a loss in performance. This can be more of a problem for devices such as audio and video input, where the device doesn't buffer anything and the PC really needs to keep up with the incoming stream of data.

  • Could you explain what you mean by "x86 has only 1 IRQ line"? Last time I wire-wrapped an 80186 computer (admittedly decades ago), I seem to recall that the 8259 PIC has 8 channels, and the nominal PC at the time had a second one cascaded, for a total of 15 channels, not including the NMI? – Glenn Slayden Jan 19 '17 at 9:49
  • You need the PIC precisely because the x86 only has one IRQ line But if x86 interrupts are disabled then the PIC can only wait until the CPU re-enables them, and IIRC it does just that. IIRC other CPUs like the 68000 had 3 interrupt pins and expected a coded priority level 0-7 right on the CPU itself. Though now that I actually consider it, maybe the 68000 disables all interrupts upon receiving any IRQ as well - I never programmed the 68000. – LawrenceC Jan 19 '17 at 11:39
  • Ah yes, now I remember. And IIRC the 'priority' aspect of the 8259 chip design--by allowing nested IRQ handling--was supposed to encourage the OS to disable interrupts as little as possible or not at all, but the PC interrupt lines were assigned haphazardly, defeating that approach? Either way, surely calling any substantial amount of code under CLI...STI was never the intention. – Glenn Slayden Jan 19 '17 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.