Introduction to Real-time

Mark Vitale
mvitale@dc.net
January 19, 1999

Introduction
As most of you already know, Amiga Inc. recently
forged a partnership with QNX Software Systems to use
portions of the QNX real-time operating system (RTOS) as
the basis for the kernel of the new AmigaOS version 4 and
5. The purpose of this article is to introduce you to the
basics of real-time systems. By the time we are done, you
will understand why Amigans can be glad their new
operating system will have a real-time "heart"!

Keep it real
In common usage, the term "real-time" describes a
process which can produce its output at the same rate as
its "live" input without any pauses or slowdowns. For
example, a modern TV weather tracking system can show
you not only what happened yesterday or an hour ago, but
can display live Doppler radar storm tracks and lightning
strikes in real-time, as they happen.

"Real-time" also has a technical meaning in computing,
and the meaning is similar to the common usage. Here's
a definition from the Frequently Asked Questions (FAQ)
file for the newsgroup comp.realtime:

"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." ...

"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."

In other words, a real-time system is designed to
deliver a predictable, guaranteed minimum response time
(usually sub-second or even millisecond) to multiple
concurrent time-critical tasks. Granted, all modern
operating systems (including AmigaOS) can multitask
applications (NOT in real-time!) while handling certain
critical operating system tasks such as clock updates,
screen refreshes, and keyboard interrupts in real-time.
But a true real-time system goes beyond mere
multitasking; it extends fast and predictable support to
applications so that their time-critical tasks can also
complete on time.

How do they do that?
Real-time systems consist of three ingredients: 1)
applications written using concurrent programming
techniques, 2) a real-time operating system, and 3)
hardware that is fast enough. Let's consider these three
pieces in reverse order.

Size doesn't matter
First of all, the hardware must be fast enough to meet
any specified application time requirements. I say fast
enough because many real-time systems are not general
purpose computers at all, but very small control systems
embedded in commercial equipment or cost-sensitive
consumer products. They often run on ancient or cheap
hardware such as a 2 Mhz 6802 or a 100 Mhz ARM.
Although they may be laughably slow when compared to a
modern desktop computer, they're more than adequate to
run a 2K real-time microkernel and a 2K control program.
So, the only thing that matters in real-time systems is not
the horsepower but the application response time. This
leads us to the next component, the real-time operating
system.

A kernel of truth
A real-time operating system is designed to allow
programmers to write applications with guaranteed
response times and provably predictable behavior for
time-critical control systems. To accomplish this difficult
goal, most real-time operating systems have the following
features in common: time-slicing, pre-emptive multitasking,
prioritized task scheduling, low worst-case dispatch
latency and low interrupt service latency.

Time-slicing means that the operating system controls
the length of time ("slice", usually measured in
milliseconds) each task is permitted to run before it is
interrupted. Pre-emptive means that the current running
task can be preempted (stopped and put back in the
queue) so that another task can run. Depending on the
design of the operating system, it may pre-empt the
running task when its time slice expires or when a timer or
I/O interrupt awakens another task with a higher priority.
This latter case is where prioritized task scheduling
becomes important.

Latency is a fancy word for an unavoidable delay in
response. For instance, disk drive response time is limited
by two mechanical latencies: the average time to move the
head to the desired track (seek time), and the average
time for the data to spin under the head (spin or rotational
latency). In real-time operating systems, there are two
critical software latencies: the maximum or worst-case
time between a hardware interrupt and the dispatch of its
interrupt service routine (interrupt latency), and the
maximum or worst-case time it takes to switch from a
preempted task to a new task (dispatch latency). In some
operating systems, these latencies can be lumped
together as maximum "context-switch" time. Of course, a
software delay depends on both the software instruction
path length and the speed of the hardware. Therefore,
real-time operating system vendors will usually specify the
hardware when quoting numbers for interrupt latency,
dispatch latency, or context-switching.

Summary and conclusion
Every day, programs written to run on real-time
operating systems are safely and reliably controlling
multiple concurrent time-critical tasks: in nuclear power
plants, chemical and food factories, fly-by-wire aircraft,
and automobile engines, just to name a few examples.

As you can see, a real-time kernel at the heart of the
new AmigaOS will give developers the power and control
they need to write software for real-time multimedia
production, active web content, embedded systems, and
other high performance time-critical applications.

Next month we'll use the example of an automobile
computer to take a closer look at the third component of a
real-time system - the application program - including
some real-time programming techniques. If you have any
questions or comments, why not send me an email?