实时操作系统定义

原文链接：http://www.faqs.org/faqs/realtime-computing/faq/

What exactly is meant by real-time?

There are _several_ definitions of real-time, most of them contradictory.
Unfortunately the topic is controversial, and there doesn't seem to be 100%
agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies
mailto:gillies@ee.ubc.ca ), is the following:

"A real-time system is one in which the correctness of the computations not
only depends upon the logical correctness of the computation but also upon
the time at which the result is produced. If the timing constraints of the
system are not met, system failure is said to have occurred."

Others have added:

"Hence, it is essential that the timing constraints of the system are
guaranteed to be met. Guaranteeing timing behavior requires that the system
be predictable. It is also desirable that the system attain a high degree of
utilization while satisfying the timing constraints of the system."

A good example is a robot that has to pick up something from a conveyor
belt. The piece is moving, and the robot has a small window to pick up the
object. If the robot is late, the piece won't be there anymore, and thus the
job will have been done incorrectly, even though the robot went to the right
place. If the robot is _early_, the piece won't be there yet, and the robot
may block it.

Another example is the servo loops in an airplane when on auto-pilot.
The sensors of the plane must continuously supply the control computer with
proper measurements. If a measurement is missed, the performance of the
airplane can degrade, sometimes to unacceptable levels.

David Sonnier  ( mailto:dps@devnull.mpd.tandem.com ) adds the distinction:

In the robot example, it would be hard real time if the robot arriving late
causes completely incorrect operation. It would be soft real time if the
robot arriving late meant a loss of throughput. Much of what is done in real
time programming is actually soft real time system. Good system design often
implies a level of safe/correct behavior even if the computer system never
completes the computation. So if the computer is only a little late, the
system effects may be somewhat mitigated.

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

3. One will occasionally see references to "real-time" systems when what is
meant is "on-line", or "an interactive system with better response time than
we used to have". Often, this is just marketing hype. For instance, although
some have queried whether running "rn" is real-time, it is not, as it is
interacting with a human who can tolerate hundreds of milliseconds of delays
without a problem. Similarly, on-line stock quotation systems interact with
humans.

4. One will also see references to "real-time" systems when what is meant is
just "fast". It might be worth pointing out that "real-time" is not
necessarily synonymous with "fast"; that is, it is not the latency of the
response per se that is at issue (it could be of the order of seconds), but
the fact that a bounded latency sufficient to solve the problem at hand is
guaranteed by the system. In particular, frequently, algorithms that
guarantee bounded latency responses are less efficient overall than
algorithms that don't.

5. One will also occasionally see discussions of "soft" vs. "hard" real-time
systems. In many of these discussions, "hard" real-time means the type of
real-time system discussed above, and "soft" real-time means systems which
have reduced constraints on "lateness" but still must operate very quickly
and repeatably. However, the definition is controversial, as some mean by
"hard" and "soft" the degree of time constraints. For instance, a real-time
process attempting to recognize images may have only a few hundred
microseconds in which to resolve each image, but a process that attempts to
position a servo-motor may have tens of milli-seconds in which to process
its data.

6. Robert Bristow-Johnson adds the following distinction (in the case of
DSP):
In a real-time DSP process, the analyzed (input) and/or generated (output)
samples (whether they are grouped together in large segments or processed
individually) can be processed (or generated) continuously in the time it
takes to input and/or output the same set of samples independent of the
processing delay.

Consider an audio DSP example: if a process requires 2.01 seconds to analyze
or process 2.00 seconds of sound, it is not real-time. If it takes 1.99
seconds, it is (or can be made into) a real-time DSP process.

A common life example I like to make is standing in a line (or queue)
waiting for the checkout in a grocery store. If the line asymtotically grows
longer and longer without bound, the checkout process is not real-time. If
the length of the line is bounded, customers are being "processed" and
outputted as rapidly, on average, as they are being inputted and that
process _is_ real-time. The grocer might go out of business or must at least
lose business if he/she cannot make his/her checkout process real-time (so
it's fundamentally important that this process be real-time).
The last definition (5) is the one used for real-time audio and video, for
phone call over Internet, and so on. It means that the processing time is
less than the time to get a sample. Note that in the case of Internet it is
easy to get starvation because the sample arrivals depend on the bandwidth.