Embedded Linux
Page 18
Most of the time, it's not very important exactly how long a specific task takes to complete on a
computer. For instance, when someone hits a key on the keyboard, they expect a letter to appear
"instantly"—but how fast is "instantly"? It could be anywhere from a few tens of milliseconds to a
couple of hundred milliseconds. You're probably not going to notice the difference between any two
timings under 50 milliseconds (about 1/20th of a second). However, the timing of some operations in
some computer applications is crucial. For instance, if your application moves a robotic arm to a precise
location so that it can pick up a chip from a stack, then to another location so it can lay down the chip at
a precise location on a PC board, the timing of the movement operations must be exact. This is when
you need a real-time OS.
For instance, most modern cars have antilock braking systems. In these systems, special sensors detect
when one or more wheels begin to "lock up"—a dangerous situation that can cause the vehicle (and its
occupants!) to slide. In these situations, it's imperative that when the sensors detect a wheel beginning to
lock, the braking on that wheel be reduced immediately. Have you ever worked on a computer system
where you started a new program and the entire computer became unresponsive for several seconds?
Imagine what would happen if the computer controlling your antilock brakes was similarly busy and
unresponsive—right when a deer jumped in front of your car! This is a situation where you need what's
called hard real time .
A hard real-time OS guarantees that, without fail, no matter what else happens, a response to an event
will occur within a specified fixed time. For example, when wheel lockup is detected, braking for that
wheel must be reduced within a certain number of milliseconds. In this example, a hard limit exists on
how long the system can take to respond to the wheel lockup condition. This hard limit means that this is
a hard real-time task—first, because there's an absolute limit on the amount of time available for a
response, and second, because bad things will happen if the system fails to respond within the specified
time limit. These two features of the task to be performed make it clear that the task requires a hard real-
time operating system.
When working with a soft real-time OS, on the other hand, when an event occurs the system will try its
best to service the event within an average response time. For example, when playing a game of Quake
III, when a player fires a rocket at another player there's an expectation that the game program will draw
a fiery explosion onscreen, make explosion noises, and dutifully subtract health from your opponent.
With all of this complexity added to the existing events in the game, it's very likely that the frame rate of
the game may drop slightly while rendering the explosion and playing back the additional audio, since
these tasks require additional CPU time. If the frame rate should drop from 50 frames per second (fps)
to, say, 40 fps for the duration of the explosion, no harm is done—the player continues to enjoy her
game, since the system is still "fast enough." Being "fast enough" is a defining characteristic of soft
realtime systems. In this case, no fixed frame rate is required of the system, and no harm occurs should
the frame rate decrease slightly.
Both hard and soft real-time systems are useful, but they have distinctly different uses. In fact, a hard
real-time OS usually accommodates tasks requiring both hard and soft real-time response.
Several attributes differentiate a real-time operating system from a standard operating system, as shown
in the following list.