What does "Windows is not a real-time operating system" mean?

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?

EDIT:

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

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:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

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

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.