Real Time

What exactly is meant by real-time? [Note: more work on this page needed]

Definitions:

Please note that EmbeddedSystems engineers use exactly one definition of real time, and that is this: A real time system employs tasks which execute to completion in a guaranteed amount of time.

This is how real time systems can determine latency and predictive behavior. Without the constraint of completion to schedule no other aspect of a real time system can be predicted reliably. It has nothing to do with speed, nor synchronization to a clock, nor any of the other drivel you will hear from people who don't really know real time systems. Stuff has to get done on time, otherwise you don't have a real time system.

Among the less-than-knowledgeable the topic is controversial and definitions of real time may be contradictory, hazy, incomplete, and unhelpful.

PosixStandard

POSIX Standard 1003.1 defines "real-time" for operating systems as: "the ability of the operating system to provide a required level of service in a bounded response time."
Real-Time versus Interactive

I'm no expert on this, but I believe this to mean that certain events have to be handled within certain strict time limits like streaming video fast enough to refresh the display 60 times per second or responding to an interrupt within a certain amount of time (and never going over the limit). -- AlastairBridgewater
More on delay and wait times

This is the definition I encounter often. It has nothing to do with total throughput per time period, but that the max processing for any given request is known. Most "on-line" systems probably would not qualify because occasionally things like web servers and RDBMS do garbage collection, which may cause a few customers to wait for a little bit.

But something like a nuclear missile cannot stop to wait for garbage collection; it has to have a result by a predetermined time, or (hopefully) trigger a self-destruct.

3 general categories of response expectations:
Intermix of RealTime with Interactive

Are things treated within Time Limits RealTime? Comparisons to language RealTime constraints Qualities of the definition Weather prediction example Brain and its RealTime system capabilities and function Conscious thought priorities MarkAndSweep collection and pausing

Cynical Definition Abstract vs Ad hoc definitions Really fast BugFree?
There seems to be some confusion here between Clearly, if we have a real-time situation, then we need real-time software.

On the other hand, we could use that *same* software in other situations that don't need all that capability. Is it still a RealTimeOperatingSystem if I don't use it in a real-time environment?

If we are writing software for a real-time environment, and we follow the principle of OptimizeLater, we start writing code that logically produces the right results. Then we analyze the worst-case response time of our code. If the worst-case is infinity (such as when there are loops that hang indefinitely waiting for some input), we use some RealTimeTechniques to bound the worst-case time, converting our software from non-real-time to real-time software. If the worst-case time is still longer than the desired time, we keep applying OptimizationPatterns? and other RealTimeTechniques (such as "optimize the worst case, not the common case") to improve things until it works.

Well, at least that's the most common process. The really *smart* people convert the real-time environment into a non-real-time-environment, so that the software merely has to usually respond in a reasonable amount of time. (Is there already a WikiPage about this - something like SimplifyTheRequirements? ForthValues?) Typically this is done by giving the CPU only non-real-time tasks, and somehow handling all other tasks (or at least the crucial real-time parts of them) in external hardware. The external hardware can be as simple as hardware limit switches, or as complicated as dedicated peripheral microcontrollers. (It seems counter-intuitive that the big, expensive, central CPU is doing only the "non-critical" non-real-time stuff, while the cheap microcontrollers and simple hardware do all the critical real-time stuff).

In most of the systems I've worked on it hasn't been practical to do this, because the hard real-time part is too complicated (or needs to be changed too often) for hardware. Instead, there is a pattern that almost always works:
  read inputs
  process inputs, preferably in constant time
  write outputs
  [optional] process a message from soft/non-realtime program in bounded time
This is the MessagePassingConcurrency variant; an alternative is to replace the message processing with a shared parameter area. Either way, I normally use WaitFreeSynchronization (the same library for all projects, since it's not application-dependent at all) to implement a single-message queue or control updates to the parameter area; this allows the periodic interrupt to pre-empt the rest of the program unconditionally, so it's not strictly necessary to have a RealTimeOperatingSystem as such. -- DavidSarahHopwood

Sometimes adding such "extra" hardware is less expensive and uses less power than trying to get the CPU to do everything with a minimum of external hardware (for example, see "Indoor GPS" article by Frank van Diggelen, Charles Abraham, 2001 http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 ). Perhaps this is related to RidiculousSimplicityGivesRidiculousResources.

A mousetrap is a RealTimeSystem? utilizing hardware even cheaper than cheap microcontrollers.
On page WhichColorOfiMac, someone claims However... pre-emptive multitasking is not always a boon. MacOsClassic was used widely within the music industry for sequencing and synthesis because the cooperative multitasking allows very predictable real-time behaviour. Unless MacOsx supports some form of real-time scheduling, musicians could well be tempted to move over to another platform.

This seems totally backwards to me. I thought pre-emptive multitasking gave very predictable real-time behavior, at least compared to cooperative multitasking.

Is this just a typo, or is there some reason cooperative is better than pre-emptive?

-- DavidCary

In the hard real-time environment, absolutely cooperative is better than pre-emptive. In a pre-emptive system, no process knows when it will be paged out, nor how long it will be out for. In a cooperative system, each process has the responsibility for using only as much time as they are given, but they know they will not be interrupted.

Multi-tasking is complex, and that complexity has to go somewhere. Giving it to the operating system and relinquishing control completely makes the programmer's life easier, but makes your life more of an adventure. Keeping control requires you to handle some of the complexity, but lets you know you won't be interrupted.

Cooperative becomes a nightmare when there is a rogue process, and that's why most people are willing to give up the control.

PS: Most people don't actually know what the terms mean. Make sure you have the same definition in your mind as others have in theirs.

Uh, no. Most developers of hard realtime systems consider a hard, realtime pre-emptive kernel to be a necessity for many real-time applications. Note that real-time operating systems (such as VxWorks) have distinctly different characteristics that desktop/server OS's, among them:

Cooperative multitasking is rather lousy at ensuring that the software can respond to an external stimulus within a bounded amount of time (except for the simple case where the processor is in a tight loop with bounded cycle time; and can poll the hardware on a sufficient basis; this is common in many DigitalSignalProcessor applications which are "realtime" in the sense that they have to process incoming datastreams without dropping data).

-- ScottJohnson

To Scott's list, I'd add rate-monotone scheduling, plus a requirement for some mechanism to mitigate priority inversion - at least if tasks of different priority can share resources. -- KevinKenny?

Also note that Scott talks about systems such as DSPs, where each task has a limited amount of work to do to ensure that it executes to completion before the next external event happens. Many microcontroller real time systems are designed this way to make use of a simple time-based task dispatcher scheme that runs tasks according to a schedule. As long as the work load for each task is limited to what can be completed in its allocated time slot then the overall latency and predictability of the system remains intact.
RealTime, n. Here and now, as opposed to FakeTime, which occurs there and then.
See: OperationalReasoning, NearRealTime (a pseudo-discussion)

CategoryRealTime

EditText of this page (last edited July 10, 2011) or FindPage with title or text search