Real time OS

Over the years, I have heard the "real time OS" phrase many times. In the last week, there was an article describing how some companies are trying to build real-time capabilities into a Linux distribution. Googling it says that a "real time OS" is an environment that allows execution of specified tasks within a given time constraint.

Here's what I am thinking:
1. A real time OS attempts to get all tasks with time constraints done in the specified time.
2. If there are too many tasks, then some with time constraints cannot be finished in time due to the load of other tasks that have similar needs.
3. If such a case exists, then there would need to be a priority system designed to tell the OS which task to run first.

In my opinion, this describes any OS out there:
1. The OS (lets say Windows 2000 for example) tries to execute all tasks (processes) as quickly as possible.
2. If there are many tasks, the OS switches between them, sometimes delaying the execution of other tasks.
3. To determine how much processing power to use, it uses a priority system to determine which gets the bigger slice of the pie.

So how is a real-time OS different from any other OS?

There is a difference. In a real time OS one can determine the amount of time allowed for a task and be guaranteed that the OS will do that task within that time allowance. There is no mechanism in Windows or non-realtime *nix OSs to do that because time slices are relative to the momentary work load.

There is one everyday business application that requires that kind of OS (or a single purpose machine) - sorting MICR encoded paper documents such as checks. Checks are sorted by sending the item along a path with several possible exits or pockets. From the time the check is started down the document path until it reaches the proper pocket, the MICR must be read and evaluated according to the sorting criteria of the moment to determine which pocket to open for the check. A nano second's delay and the task must be aborted. The document goes into the last (error) pocket to be processed again.

Today, most document sorting is done on a single purpose machine rather than as a task on a mainframe with a realtime OS. Realtime OSs are used primarily for science or manufacturing tasks.

Ah, I see. So you tell the OS that "I need 1 nanosecond at 10:42:23.2 AM" and the OS says either yes (time reserved for you) or no (cannot reserve that much time).

As far as I can see, this means that hardware interrupts, delays due to network traffic, etc. (which are common on the average PC) would be very dangerous to a real time OS.

In fact, it looks like only computers with specialized processors/hardware dedicated to real time operations could safely function in a real-time environment.

Generally what happens when there is an interrupt is controlled by the OS. The realtime OS's I worked on years ago (70s & 80s) knew when it was processing a "critical timing" task and when it was running an ordinary task. The task set a flag that the OS understood as "critical timing". The danger was a runaway task could require the system be halted so the runaway could be aborted. Now days there is probably a better way to handle runaways.

*edit* IIRC today most real time OSs are embedded with the hardware they are controlling. Very few are networked other than for command, control and status reporting.