You are on page 1of 27

Kernels

Real-Time

KEY POINTS OF THE CHAPTER

1. Real-time multitasking can be achievedwithout intemrpts, and when


feasible, it is preferred becauseit leads to systemsthat ale easier to
analyze.
2. Foreground/background architectures are the most widely used in
embeddedaPPlications.
The task-controlblock model is usedin commercialreal-timeexecutives
and in full-featured operating systems where the number of tasks is
dynamic or indeterminate.
The more featuresa real-time kernel provides, the more complex it is, the
more its performancedegrades,and the more difficult it is to analyze.
5 . A nonintemrpt driven cyclic executive is basedon one or severalmajor
cycles that describe the order in which minor cycles are executed.

In Chapter 1 we noted that a specializedcollection of systemprograms is called


an operating system.Anyone who has used a computer has intdracted with the
computer's opelating systemdirectly or indirectly. Although there are many well-
known commercial operating systems, they are often too bulky and too all-
purpose to be useful in real-time applications that are embedded and hqve
stringent response-timerequirements.
Frequently, the real-time systems designer must design a bare-bones
operatingsystem,or use one of the specializedreal-timeoperatingsystemsttiat
are commerciallyavailable.(For custom computerssuch as thoseused in many

l4l
Chap.6l Real-TimeKem

embedded applications, there are no commercial operating systems available


This chapterwill help you build your own real-time operating system,or at lea
identify desirablefeaturesif you chooseto purchasea real-time operating syste
or use an existing one.
All operatingsystemsmust provide three specific functions: task schedulin
task dispatching, and intertask communication. A scheduler determines whic
task will run next in a multitasking system, while a dispatcher performs tt
necessarybqokkeeping to start that task. These functions can be provided eith
by hardwareor by software.as we shall demonstrate.Note also that the terms rar
andprocess are interchangeable.
A kernel, executive, or nucleus is the smallest portion of the operatin
system that provides for task scheduling,dispatching, and intertask cornmunic
tion. In embeddedsystems,this essentiallyrepresentsthe entire real-time systen
whereas in commercial real-time operating systems this might be all but tt
device drivers.An onion skin diagram such as that given in Figure 6.1 can be use
to depict the role of the kemel in an operating system.
Since the publication of the first edition of this text, new variants of tt
definition of "k€mel" have evolved. They are given here in increasing order r
complexity. Of course, as the complexity decreases,so do the code size an
responsetimes. The hierarchy is also shown in Figure 6.2.

Figure 6.1 The role of the kemelin operatingsystems.

.\
Chao. 6 I Real-Time Kemels r43

Userinterface Operatingsystem
Shell

Fileanddisksupport Executive

lnterorocessor
communication
andsvnchronization Kemel

Taskscheduling Micro-kemel

Threadfaskcontrol
Blockmanagement Nanekemel

Hardware

Figure 6.2 Kemel hierarchy.

t Nano-kernel-Simple thread-of-execution(same as''flow-of-control")


management.It essentially provides only one of the three servrces
provided by a kemel; that is, it providesfor task dispatching.
I Micro-kernel-A nano-kemelthat providesfor task scheduling.

I Kernel-A micro-kemel that provides for intertask synchronizationand


communication via semaphores,mailboxes, and other methods.
Executive-A kemel that includes privatized memory blocks, I/O
services,and other complex features.Most commercial real-time kemels
are really executives.
t Operating system-An executive that provides for a generalized user
interface or commandprocessor,security,and a file managementsystem.
By this definition, the Unix kernel is indeed an operating system.

UNIX*, a registered trademark of AT&T's UNIX System Laboratories, is


the common name for a family of interactive, multiuser operating systems.It is
available in one version or another for virtually any computer, ranging from
degktop personal computers and workstations to the rnost powerful sup€r-
computers.This capablemultitasking systemis ideally suitedfor both stand-alone
and distributed processing configurations. It has powerful, yet easy-to-use,
hardwareinterface mechanisms,and it provides an excellent rneansof organizing
and storing files on a variety of media, including magnetic disks, magnetic tapes,
and optical disks. Unix systemsare available to support individual users, small
groups, or entire departmenKon a wide range of processingplatforms.
In this chapter we exam_inestrategiesemployed in the desigrr of real-time
kemels.

*IINIX is not an acronym, and therefore need not be capitalized unless referring to the
'Unix' is used throughout this text-
registeredtrademark. Generally, the term
144 Chap. 6 I Real-Time Kerrnl.

6.1 POLLEDLOOPSYSTEMS

Polled loop systemsare the simplest real-time kernel. Polled loops allow for t'as
responseto singledevicesbut can't do much else.In a polled loop system,a single
andrepetitivetestin'structionis usedto testa flag thatindicateswhetheror not some
eventhas occurred.If the eventhas not occulred,then the polling continues.No
intertaskcommunicationor schedulingis neededbecauseonly a sinqletask exists

I EXAMPLE 6.1
A software system is neededto handle packets of data that arrive at a rate of no more than I per
second.A flag called "Packet_here" is set by the network, which writes the data into the CPL-*
memory via DMA. The data are available when Packet_here= 1. Using a Pascalcode fragment, ue
can describea polled loop to handle such a system:

wntre L j < u _ to
ro { do forever }
begrln
if Packet here=TRUE then { flaq set? }
beqin
j -h i q *l-r^ 'l-ts -
process-data; ii L r - - J ny Lr vnece oq ne rr r r o u nr^^^--^a
V M q J - s J L r I s u q L C

Packet here := FALSE { reset flag}


I'rlll €rrd
end I

Polled loop scherneswork well when a single processoris dedicatedto


handiing the I/O for some fast device and when overlappingof events is ncn
p',' allowedor is kept to a minimum.
{iu,,
! l L ltl
I EXAMPLE
6.2
IBM's OS/2 PresentationManagerreadsthe applicationqueueusing a polled loop. I

6.1"1PolledLoopwith Interrupts
A variation on the polled loop usesa fixed clock intemrpt to wait a period of t
between when the flag is determined to be TRUE and when the flag is reset
FALSE. Such a systemis used to treat events that exhibit a phenomenon
as switch bounce.
Every elgctrical engineerknows that it is impossible to build r switch
can changefrom its OFF condition(e.9.,0 volt) to its ON condition(e.g.,5 vol
instantaneously. A typical responsefor such a switch is given in Figure 6.3. I
example,eventstriggeredby pickle switches,levers, and keyboardsall exhr
this phenomenon.
If we wait a sufficientamountof time afterthe initial triggeringof the evenL
can avoid interpreting the settling oscillations as events. These are, of
spuriouseventsthat would surely overwhelm our little polled loop handler.A

L.
6.1 I PolledLoop Systems lJ5

Srn\\ch
position

On

off

Throwswitch

Figure 6.3 Switch bounce.

period can be realizedwith a programmabletimer that issuesan interrupt afler a


countdownperiod.In the absenceof suchhardware,a softwareroutinecanbe written
to implementthe delay.To illustratesucha techniqueconsiderthe foilowing.

I EXAMPLE
6.3
A polled loop system is used to handle an event that occurs randomly but no more than once per
second.The event is known to exhibit a switch-bounceeffect that disappearsafter 20 milliseconds.
A 10-millisegond fixed-rate interrupt is available for synchronization.The event is signaled by an
extemal device that sets a memory location FLAG to TRUE.
In Pascal a synchronizedpolled loop would look like:

While TF.UE do {t infinifc


! r r ! r a r r L g n
y vn
r f lv ls o d
.r lv av Pn n i
l

begin
FLAG = TRUE then
(
if ^ --^ ^ t l^ ! ^ ^ ts ^ i I

begin
'
counter : = 0; { initialize bounce counrer
whife counter < { wait }
-q
FLAG : = FALSE { rpsof F\rprr f- }

nrn^oec alranf . I nr^-oec o1/-nf 1

end
end

The l0-millisecond intemrpt routine might look like

begin
counter := councer+i
end

Intemrpts are enabledin an initialization routine Notice that we wait for three trcks of the interrupt
routine in order to ensure that we wait at least 20 milliseconds. I
146 Chap.6 I Real-Time
Keme

In summary, polled loop systems are simple to write and debug, and th€
responsetime is easy to determine.As suggested,polled loops are excellent for
handling high-speeddata channels,especiallywhen the eventsoccur at widely
dispersed intervals and the processor is dedicated to handling the data
channel.
Polled loop systemsmost often fail, however, becausebursting of events
was not taken into account (this is discussedin Chapter 10). Furthermore,polled
loops by themselvesare generally not sufficient to handle complicated systems
Finally, polled loops inherently waste CPU time, especially if the event being
polled occurs infrequently.

6.2 PHASE/STATE.DRIVEN
CODE

Phase-driven or state-driven code uses nested if-then statements,case state


ments, or a finite state automaton to break up the processingof a function into
discrete code segments. The separation of processes allows each to be
temporarily suspendedbefore completign, without loss of critical data. This, in
tum, facilitates multitasking via a scheme such as coroutines, which we will
discuss shortly.
Certain types of processlend themselveswell to FSA implementation. For
example, the compilation process can be regarded as comprising lexical
analysis, parsing, code generation, and optimization. A process implementing
compilation could be interrupted after each of the phases,but not in between
Communicationsprograms such as network packet handlers are often.broken up
into phases.

I EXAMPLE6.4
A simple process consists of three states.At the end of each state a flag is set and the processis
terminated. Upon restarting, the process resumes where it left off. The following Pascal code
fragment illustrates this.

procedure taski

begin
n:ca f] an af

1: beqin
perf orm3art_L; /* dn nh:<a 1 nrnnoc<inn */

flag z= 2
end
2: begin
perf ormJart_2; /* do phase 2 processing */
flag := 3
end
s+c.6.2 t Phase/ State-Diven Code 747

3: begin
-l
perf ormjart-3; /
/* dn
vv nv rh ar eqv c nre-e-<S_:::

flag := 1
end
end
end T

This simple nested if-then structure is really just a special case of FSA-
driven code.

T EXAMPLE
6.5
A finite state automaton can be implemented easily in Pascal or another suitable language.First, a
two-dimensional array is constructed containing the table representationof the FSA. Let states be
the variable type depicting the set of states.alphabet the variable type representing the input
alphabet, and table the transition table.
The following code fragment can then be used to read a streamof inputs using proceduregel
(not shown). At the time the cuffent stateis determined,an appropriateprocessis executed.The code
determinesthe final state of the automata after the last input is read.

-: i::- ct ^Faq. /qt-:fo- , staten) ; { n ls # of states }


rl nh:l-rof . I i nnrri-'l
, rnputn);
f :l-\l a r^T^7. ^rr2r/ l 1r
L . . n
r rl l ^ f c f ^ f a c .

-^-'a f nrr^r: rd . from sLate to state ]

state: states;
input : aiphabet;
m iq qjzc ol alnhabec
table: array[1..m] o f tabfe_row; {

-atsIinnrrf\. { rear'l one roke. f -om i -nttt srrean


Y v u \ + r r y s e , t

s'-ate := cableIord(input )lIstatel; { transition }


-va.rrf F nrnaoqq ls1-:f e) :
" ^ L e u L e J ! v
{ e x e c u te relevant Process }
^ - - - - ! ! r r v g e { l a s t - t oken read }
! v !

FYF-lf c nrn.ess ( sf aLe : SLateS ) ;

--r^ ^F

: - : * a 1 ' n r o e c q q i : I avonrrfo nr6aoqq 1 i


:- -,- t). nracaqq?' t execute process 2 )

. nTAaFqqn: I avonrrfo nr^aaqq n j


148 Chap.6 I Real-Time
Krndl

To summarize,state-drivensystemscan be coded in many lanfuages usins


nestedif-then or casestatements. For more complexsystems,table-drivencodeLr
preferable.Such systemscan be usedin conjunctionwith polled loops,wherethe
first statetestssomeflag, and the secondstateprocessesthe associateddataif the
flag is set.
Not all processeslend themseivesnaturallyto division into states;somearr
thereforeunsuitablefor this technique.In addition, the tablesneededto implemem
the code can becomequite large. Finally, the manual translationprocessfrom tbe
finite state automatonto tabular form is prone to error.

6.3 COROUTINES

Coroutines or cooperativemultitasking systemsrequire disciplined programming


and an appropriate application. These types of kemels are employed rm
conjunction with code driven by finite stateautomata.In this scheme,two or mtrE
processesare codedin the state-drivenfashionjust discussed,and after eachphasr
is complete, a call is made to a central dispatcher.The dispatcher holds fte
program counter for a list of processesthat are executedin round-robin fashim
that is, it selectsthe next processto execute.This processthen executesuntil fu
next phase is complete, and the central dispatcheris called again.
Communicationbetweenthe processes is achievedvia global variables.Ang
data that need to be preservedbetween dispatchesmust be deposited in
variables.
Some surprisingly large and complex applications have been imp
using coroutines;for example, IBM's transactionprocessor,CICS (
Information Control System), was originally constructedentirely via corouti
IBM's OS/2 PresentationManager uses coroutines to coordinate the activ
within the various user windows.

I EXAMPLE
6.6
Consider a system in which two processes are executing "in parallel" and in isolation.
executing phaseAl, process_A retums control to the central dispatcher by executing "exiL"
dispatcher initiates process_B, which executesphaseBl to completion before retuming contmi
the dispatcher.The dispatcher then starts processA, which begins phaseA2 and so on. The
code for such a scheme is depicted below:

n r n nvav de rgrur ro nrnnoqq A. n r a nv !a r l rv rs sr ! o nrn aac< R.


v! v y ! v

hoai n

'I'RUE OO wn11e 'r'KUE OO


wnlle
^ts-ts^n ^€ case stateB of
nhacaA'1 . 1 . nh: c cP.'l .

nl-racaA?.

-L-^^A?. ?. nl.rrcaF.?.
Irrro D snJ ,
Sec.6.3 I Coroutines t49

4z phaseA4; 4: phaseB4
5: phaseA5 end

enC
end

where stateA and stateB are state counters thu are managedby the dispatcher.Such a schemecan
be extended to any number of processes,each broken into any number of phases. I

If eachprogrammerprovides calls to the dispatcherat known intervals, then


the responsetime is easy to determine.We will seehow to do this in Chapter 9.
Notice that this system is written without hardware intemrpts.
A variation of this schemeusesstate-drivencode and statecounters.Another
variation is used when a polled loop must wait for a particular event while other
processingcan continue. This type of system is describedbelow.

I EXAMPLE6.7
A polled loop routine, Taskl, is to monitor an event flag, "event." If the flag is not set, Taskl exits.
If the flag is set, then a processroutine, process-event,is called. "State" is used to keep track of the
state of the polled loop. The Pascal code for this system is

procedure Taskl;
begin
case state of

if event = TRUE then { event detected }

strace I nhrnna -c f-a*f a- - -f l *: r * J


event : =FALSE { reset event flag }
end; { call exit }

2: begin
state:=1 { reset state fy'ag }
process-event; f r
nrnnocc
F ! v v v v v
arrant ]

end { call exit }


end

Such a schemereducesthe amounrof time wasted polling the event flag, and allows for processing
time for other tasks. I

Note that if there is only one coroutine, then it will be rep€ated cycbcally ad
inftnitum. Such a system is called a cyclic executive.
In short, coroutines are the easiesttype of "faimess scheduling" that can be
implemented. In addition, the processes can be written by independent parties,
and the number of processes need not be known beforehand. Finally, certain
Chap. 6 I Real-TimeKernels

languagessuch as Ada and Modula-2 have built-in constructsfor implementing


coroutinesin a way that is superior to the somewhatartificial (but more general)
implementationgiven in Examples6.6 and 6.7.
On the negative side, this is an error-proneapproachthat requires strict
discipline on the part of the programmersbecauseit assumesthat they will
relinquishthe CPU at regularintervals.It also requiresa communicationscheme
involving global variables,which is undesirable.Finally,processescannotalways
be broken easily into uniform size phases,which can adversely affect response
time since the minimum size is a function of the longestphase.

DRIVENSYSTEMS
6.4 INTERRUPT
'Jump-to-self'
In intemrpt driven systems, the main program is a single
instruction.'The various tasks in the system are scheduledvia either hardware
or software intemrpts, whereas dispatching is performed by the intemrpt-
handling routines.
The intemrpts in an interrupt driven system may occur at fixed rates
(periodically), aperiodically, or both. Tasks driven by intemrpts that occur
aperiodicallyare called sporadic taskslll5l. Systemsin which intemrpts occur
only at fixed frequencies are called fixed-rate systems, those with intpmrpts
occurring sporadically are known as sporadic systems,and those with intemrpts
occurring both at fixed frequenciesand sporadically are called hybrid systems.
When hardware scheduling is used, a clock or other extemal device issues
intem.rpt signals that are directed to an intemrpt controller. The intemrpt-
controller issuesintemrpt signals dependingon the order of arrival and priority of
the intemrpts involved. If the computer architecturesupportsmultiple intemrpts,
then the hardware handlesdispatching as well. If only a single interrupt level is
available,then the intemrpt-handling routine will have to read the intemtpt vector
on the intemrpt controller, determine which intemrpt occurred, and dispatch the
appropriate tasks. Some processors implement this in microcode and so the
operating systemsdesigner is relieved of this duty.
In any case, a snapshot of the machine-called the context-must be
preserved upon switching tasks so that it can be restored upon reinitiating the
intemrpted process. The context includes the contents of certain registers, the
program counter, and other entities that could be altered by another process.

6.4.1 ContextSwitching /
The most important part of the real-time operation of the intemrpt driven system
is context switching. Context switching is the process of saving and restoring
sufficient informafion for a real-time task so that it can be resumed after being
intemrpted. The context is ordinarily saved to a stack data structure.
I IntemrptDriven Systems 151

6.4.1.1 Context-savingrule Context switchingtime is a major contribu-


tor to responsetimes and is a factor that we strive to minimize. The rule for saving
context is simple: save the minimum amount of information necessaryto safely
restore any processafter it has been intemrpted.
What information could this be? The following are usually consideredpart
of the context of a process.

l. Contentsof registers
2. Contents of the program counter
3. Contentsof coprocessorregisters
4. Memory page registers(seeChapter8)
5. Memory-mappedI/O location mirror images(seeSection2.3.2)
6. Specialvariables.

Normally, within the intemrpt handlers, intemrpts are disabled during the
critical context-switchingpenod. Sometimes,however, aftet sufficient context
has been saved,intemrptsmay be enabledafter a partial contextswitch in order
to handlea burst of intemrpts,to detectspuriousintenupts,or to handlea time-
overloadedcondition.

6.4.1.2 Stack Model The stack model for context switching is used
mostly in embeddedsystemswhere the number of real-time or intem-rpt-driven
tasks is fixed. In this case,context is savedby the intemrpt handler.Contrast this
schemewith the task-control block model, which is used in more complicated
real-timeoperatingsystemsand is discussedin a later section.
In the stack model, each intemrpt handler is associatedwith a hardware
intemrpt and is invoked by the CPU, which vectors to the instruction storedat the
appropriate intemrpt-handler location. The context is then saved to a specially
designatedmemory areathat can be static,in the caseof a single-intemtpt system,
or a stack, in the case of a multiple-interrupt system. This type of stack
managementis discussedin Chapter8.

I EXAMPI.E 6.8
Consider the following code for a partial real-time system, writted in C and consisting of a simple
jumpto-self and three interrupt handlers,which savescontext using the siack model. The interrupt
handlers' starting addressesshould be loaded into the appropriate interrupt vector location upon
inirialization. Alternatively, this can 6e performed at link time by the link editor or linker control file.

-.-oiC main (void)

inil() ; /* initialize sysLem, -oad incerrupt handlers */


, , L i r ^ / n D T T E \ . / * i - f i n i t o l n n n * /
r v r r r f s \ ! f \ v ! / ,
r52 Chap.6 I Real-TimeKernels

void intl (void)


/* interrupt handler 1 */

c:rra l nnnf ovi- ) : /* qave eontext on stack */

taskl () ; /* oyc.rrfr fask 1 */


*/
restore (context ) ; /* restore context from stack

void int2 (void)


/* i n * /
/ f r r ut ec! r r l n
! ts y v handl
rre.r\^& ef 2

<:rza I cnnf ovl- ) : /* save context on sLack */


/* axecnfe task 2 */
raski( ) ;
/* rcsf nrtr ct-)nf.ext stack */
restore(context); from

void int3 r (void)


/* interrupt handler 3 */

t
save context on stack */
save(context); /*
task3 O ; /* execute task 3 */
restore context from stack */
restore(conEext); /*
{

Thg procedure "save" involves the saving of certain registers to a stack area, whereas "restore"
resto;es those registers from the stack. I

6.4.2 Round-RobinSYstems

ln round-robin systemseveralprocessesare executedsequentiallyto completion"


often in conjunction with a cyclic executive. In round-robin systemswith time-.
slicing, each executabletask is assigneda fixed-time quantum called a time slice
in which to execute.A fixed-rate clock is used to initiate an interrupt at a raQ
corresponding to the time slice. The task executes until it completes or its
execution time expires, as indicated by the clock interrupt. If the task does not
execute to completion, its context must be saved.The task is then placed at tlrc
end of the executablelist. The context of the next executabletask in the list is
restored, and it resumesexecution. Figure 6.4 illustrates the process.
str. 6.4 I IntemrptDriven Systems 153

pd Task3
o

Task2 Task2

Task 1 Task 1

Figure 6.4 Time slicing of three taSks.

PreemptivePrioritySystems
A higher-priority task is said to preempt a lower-priority task if it interrupts the
Iower-priority task. That is, the lower-priority task is still running while the
higher-priority task is about to begin. Systems that use preemption schemes
insteadof round-robin or first-come-first-servescheduling are called preemptive
priority systems.The priorities assignedto eachintemrpt are basedon the urgency
of the task associatedwith that intemrpt (seeFigure 6.5).

Task 2 Task 3 Task 3 Task 2 Task 1


interrupts interrupts compleles comdetes corndetes

Flgure 6.5 Preemptive schedulhg of three tasks.

I EXAMPLE6.9
The nuclearpower station monitoring systemrepresentsa fixed-prioriry system.While the handling
cd intruder events is critical, nothing is more important than processirg the core over-temPerature
T

Prioritized intemrpts can be either fixed priority or dynamic priority. Fixed-


yioriry systems are less flexible in that the task priorities cannot be changed.
r54 Chap. 6 I Real-Time Kemels

Dynamic-priorify systemscan allow the priorities of tasksto change.This feature


is particularly important in certain types of threat-managementsystems.

6.10
I EXAMPLE
Dynamic-priority systemscan be found in many threat-managementsystems,such as those related
to military aircraft. The aircraft's threat-managementcomputer may be able to track up to six enem\
aircraft. Each of theseis tracked by a processin a dynamic-priority multitasking computer' At sorn€
fixed rate, the relative threat of each enemy aircraft is recomputedbasedon proximity, posture, and
other factors. The priority of each of the tasks managing the individual threats is then readjusted
I

Preemptivepdority schemescan lead to the hogging of lesourcesby higher-


priority tasks. This can lead to a lack of available resourcesfor lower-priorin
iasks. In this case,the lower-priority tasks are said to be facing a problem called
starvatton.

I EXAMPLE 6.11
Consider the Unix operating system. In Unix, any task that makes a system call cannot tu
preemptetl;that is, the set of Unix system servicesprovided has highest priority. This is a problen"
iince a low-priority task-making system call cannot be preempted.Real-time Unix solutions striyt
ao rectify this problem (see Chapter 14). I

6.4.3.1 Rate-Monotonic Systems A special class of fixed-rate pIE


emptive priority intemrpt driven systems,called rate-monotonicsystems,include
those real-time systemswhere the priorities are assignedso that the higher tht
executionfrequency,the higher the priority. This schemeis common in embedde
applications, particularly avionics systems, and has been studie
[54],U031,[104],[105],U40l' [141].
extensively

6.12
I EXAMPLE
In our aircraft navigation system,the task that gathersaccelerometerdata every 5 miiliseconds br
the highest priority. The task that collects gyro data, and compensates these data and fu
accelerometerdata every 40 milliseconds, has the second highest priority. Finally, the task fu
updatesthe pilot's display every secondhas lowest priority. I

An extremely important paper by Liu and Layland t1041 demonstraE


that rate-monotonic systems are the optimal fixed-priority scheduling method
This means that if a successful schedule cannot be found for the rn
monotonic system, then no other fixed-priority scheduling system will atd
Rate-monotonic systemsare the most highly citdd class of real-time systemi
the literature. Although numerous theoretical results exist, most are basedq
assumptions that ale impractical. For examplg, in rate-monotic systems, u
deadline will be missed if the cPU utilization is <70vo' (The number i
actually /n(2), which is derived by constructing and then analyzing an ertl
ffee.) Even if the cPU utilization is above 70vo, a schedule may still h

_----1
I InterruptDriven Systems 155

feasible, although no guaranteesabout missed deadlines can be made. How-


ever, these observations (and the basic theory itselfl do not take into account
practical issues such aS context switch time, resourcecontention,and clock
variation. Numerous atternptshave been made to addressthese problems, but
to the practicing engineer, most of the solutions are impossible to implement.
Despite these drawbacks,many systemshave been built using rate-monotonic
analysis(RMA) as a sanity check.
However, rate-monoticsystemsare not a panacea.In particular,priority
inversionmay necessarilyoccur.
There are actually severalkinds of priority inversion.The first occursin rate-
monotonic systemswhere in order to enforce rate-monotonicity, a low-priority
processwith a high frequencyof executionis assigneda higher priority than a task
with higher criticality but lower execution rate. One solution is to exchange
execution rates, where possible. Otherwise, the high criticality routine can be
placedin the fastercycle, but a countercan be usedto control its rate of execution.
Another type of priority inversion occurs when a lower priority routine holds
a resource (e.g., using a semaphore)that a higher priority routine needs' One
commonly cited, but difficult-to-implement solution to this problem is called the
priority ceiling protocol (PCP). This protocol statesthat a task blocking a higher
priority task inherits the higher priority for the duration of that task. Apparently,
Ada 95 is capable of implementing the PCP utilizing the three new pragmas
discussedin Chapter3.
A third type of priority inversion occurs in object-orientedsystemsin which
attribute inheritancecausesa subclassto inherit priorities that are in conflict with
its intent. The solution is careful assignmentof attributes.

Majorand MinorCycles
Some common terminology applies when tasks are assignedto run at specific
frequencies (usually in periodic systemsbut also in nonintemrpt driven cyclic
executives).If a time line is drawn showing the scheduling of tasks and if the
assignment uses rate-monotonic discipline or is a nonintemrpt driven cyclic
executive, then the scheduling sequencerepeats itself after a certain period of
time. This sequenceis called a major cycle.If within the major cycle, smaller
sequencesalso repeat, they are called minor cycles. For example consider the
following nonintemrpt driven cyclic executtve:

while(forever) do
begin
process_a;
process-b;
process_a;
proGess_c;
process_a;
156 Chap. 6 I Real-Time Kemels

nrn-6cc b
h.

d .

end

Notice how pr:ocess-a runs four times more often than process-c or
process_d and twice as often as process-n. Here the major cycle is given by the
process sequence abacabad with minor cycles abad, abac, ab, ac, and ad.

6.4.5 HybridSystems
Hybrid systemsinclude intemrpts that occur at both fixed rates and sporadically.
The sporadic intemrpts may be used to handle a critical error that requires
immediate attention, and thus have highest priority. This type of system is
common in embeddedapplications.
Another type of hybrid system found in commercial operating systemsis a
combination of round-robin and preemptive systems. In this system, tasks of
higher priority can always preempt those of lower priority. However, if two or
more tasks of the samepriority are ready to run simultaneously,then they run in
round-robin fashion.
To summarize,intemrpt-only systemsare easy to write and typically have
fast responsetimes becauseprocess scheduling can be done via hardware.
Interrupt-only systems are a special case of foreground/backgroundsystems,
which are widely used in embeddedsystems.
One weaknessof intemrpt-only systems,however, is the time wasted in the
jump-to-self loop and the difficulty in providing advanced services. These
services include device drivers and interfaces tc multiple layered networks.
Another weaknessis vulnerability to malfunctions owing to timing variations.
unanticipated race conditions, hardware failures, and so on. Some companies
avoid designsbasedon intemrpts for this reason.

SYSTEMS
6.5 FOREGROUND/tsACKGROUND

Foreground/backgroundsystems are an improvement over the intemrpt-only


systemsin that the polled loop (which was really a dummy backgroundprocess)
is replacedby code that performs useful processing.We will discussthe kinds of
processesthat occur in the foreground and background shortly.
Foreground/background systems are the most common solution for
embeddedapplications.They involve a setof intemrpt driven or real-timeprocesses
called theforeground and a collection of nonintemrpt driven processescalled the
background..The foreground tasks run in round-robin, preemptive priority, or
combinationfashion.The backgroundtask is fully preemptableby any foreground
task and,in a sense,representsthe lowest priority task in the system.

L *4
Sec.6.5 I Systems
Foreground/Background 157

All real-time solutions are just special casesof the foreground/background


systems.For example,the polled loop is simply a foreground/background system
with no foreground, and a polled loop as a background. Adding interrupts for
synchronizationyields a full foreground/backgroundsystem.
Phase-drivencode is a foreground/backgroundsystem with no foreground
andphase-drivencodefor a background.Coroutinesystemsarejust a complicated
background process.Finally, intemrpt-only systems are foreground/background
systemswithout a background.
It is preciselybecauseall real-timesolutionsarejust variationsof foreground/
background systemsthat we study them so extensively. Mastering foreground/
backgroundsystemsallows us to understandall the other real-time kernels.

6.5.1BackgroundProcessing
The questionof what processingshouldbe placedin backgroundis an easyone:
anything that is not time critical. The backgroundprocessis the processwith the
lowest priority. This task will alwaysexecuteto completion,unlessthe systemis
time-overloaded(all processingtime is spent in the foreground). But the rate at
which the backgroundwill be executedcan be very low and dependson the time-
loading factor. That is, if p representsthe time-loading for all the foreground
processes(seeChapter9 to calculatethis), and if e is the executiontime of the
background process,then the background processexecution period, /, is

(6.1)
I - p

What kind of processesare not time-critical and can be performed in


background?It is common, for instance,to incrementa counterin the background
in order to provide a measure of time-loading or to detect if any foreground
processhas hung up. For example, you can provide individual countersfor each
of the foregroundprocesses,which are reset in thoseprocesses.If the background
processdetectsthat one of the countersis not being reset often enough, you can
assumethat the correspondingtask is not being executedand, that some kind of
failure is indicated. This is a form of "softwate watchdog timet "
Certain types of low-priority self-testing can also be performed in
background. For example, in many systems, a complete test of the CPU
instruction set is performed. This kind of test could never be performed in
foreground,but should be part of a robust systemdesign.The design and coding
of theseCPU instruction tests require careful planning.

6.13
T EXAMPLE
Ir the space shuttle inertial measurementunit computer, a process known as RAM scrubbint is
performed[95]. The memory card of this system is equipped with a Hamming code error correction
and detection schemewhich, for a l6-bit word, can detect l-, 2-, and some 3-bit erron, and correct
all 1- and some 2-bit errors. The device corrects these enon on the data bus, however, and not in
158 Chap.6I Real-TimeKer

memory. By consecutivelyreading and then writing back each memory location, the correctedd
are restored in RAM. This process helps to reduce errors perpetrated against RAM by charl
particles present in space, or in the presenceof a nuclear event (such as in our nuclear pol
station), called single event upsets (see Chapter 11). RAM scrubbing is not suggestedas
foreground process.

Finally, low-priority display updates, logging ro pnnters, or other interfi


to slow devicescan be Derformedin backeround.

6.5.2 Initialization
Initialization of the foreground/backgroundsystem consists of the followj
steps:

1. Disable intemrpts.
2. Set up intemrpt vectors and stacks.
3. Perform self-test.
4. Perform system initialization.
5. Enable intemrpts.

Initialization is actually the first part of the background process.Here,


immediately disable intemrpts becausemany systems come up with intemr
{
enabled,ready, and waiting, and we still need time to set things up. This se
consistsof placing the appropriateintemrpt vector addresses,setting up stack
we have a multiple-level intemrpt system, and initializing any data, count€
zurays, and so on. In addition, we perform any self-diagnostic tests befi
enabling any intemrpts. Typical diagnostic tests are discussedin Chapter
Finally, we begin real-timeprocessing.

6.5.3 Real-Time
Operation
The real-time or foreground operation for the foreground/backgroundsystem
the same as that for the intemrpt-only system.

I EXAMPLE 6.14
Supposeyou wish to implement an interrupt handler for a 2-addresscomputer architecturewit
single intemrpt. The EPI and DPI instructions can be used to enable and disable the inten
explicitly, and we will assumethat upon receiving an intem.rpt, the CPU will hold off all ot
intemrpts until explicitly re-enabled with an EPI instruction.
For context-switching purposes,we wish to save the eight general registers,R0-R7, on
stack. Note that context switching involves saving the status of the machine as it is used by
background process.The foreground process will run to completion so its context is never sav
Further assume that the CPU will save the prografr counter at the time of intemrptior
memory location 6, and the address of the intemrpt-handler routine (the intemrpt vector) is sto
in memory location 5.
The foilowing code should be used to initialize the foreground/backgroundsystem:
Sec. 6.5 I Foreground/BackgroundSystems 159

DPI disable intemrpts


STORE Ghandler,5 put interrupt handler addressin location 5
EPI enable interrupts

Of course other initialization, such as initializing flags and other data, should be performed
before enabling intemrpts.
If symbolic memory locations reg0 through regT are used to save the registers, then the
interrupt handler, coded in 2-addresscode, might look as follows:

DP] redundantly disable intemrpts


S T O R ER 0 , r e g 0 save register 0
S T O R ER 1 . r e g l save register I
S T O R ER 2 , r e g 2 save register 2
S T O R ER 3 , r e g 3 save register 3
S T O R ER 4 , r e g 4 save register 4
S T O R ER 5 . r e g 5 save register 5
S T O R ER 6 , r e g 6 save register 6
S T O R ER 7 , r e g 7 save register 7

.]U EAPP execute real-time application progrirm


LOAD R7, regT restore register 7
LOAD R5, reg6 restore register 6
LOAD R5, reqs restore register 5
LOAD R4, reg4 restore register 4
LOAD R3, reg3 restore register 3
LOAD R2, reg2 restore register 2
LOAD R1, regl restore register I
LOAD R0, rego restore register 0

EPI re-enable interrupts


RT retum from interrupt

In many computers,block save and restore instructions are available tq save and restore a set
of registers to consecutive memory locations.
AIso note that our interrupt handler does not permit the interrupt to interrupt itself. If this is
to be accomplished, or if more than one interrupt routine existed, a stack rather than just static
memory would be needed to save context.
The background program would include the initialization procedure and any processing that
was not time-critical and would be hrinen in the high-order language.If the program were to b€
written in C, it might look like this:

void main(voior

/* alfocate space for context variable */


int. reg0, reg1, reg2, reg3, regL, reg5, reg6, reEli

/* decfare other g1oba1 variables here */


r60 Chap.6I Real-TimeKe

init O ; /* initialize system */

while (TRUE) /* background loop */


l-': nlznrnr rnrt 1\ / * nan-raa I -t i mo nrnccqq i no hcrc * /
v q v r \ Y ! v s r r l 4 \ / t

Foreground/backgroundsystemsrepresenta supersetof all the other re


time solutionsdiscussed.They typically havegood responsetimes,sincethey rr
on hardwareto perform scheduling.They are the solution of choice for embed
real-time systems.
But foreground/background systems have at least one major drawba
interfaces to complicated devices and networks must be written. This proced
can be tedious,and prone to error. In addition, these types of systemsare b
,rii implemented when the number of foreground tasks is fixed andknown a prit
|1,i;'ll
Although languagesthat support dynamic allocation of memory could handl
t: variable number of tasks, this can be tricky. Finally, as with the intemrpt-o
rr ,system,the foreground/backgroundsystem is vulnerable to timing variatio
i" unanticipatedrace conditions, hardwarefailures, and so on. As mentionedbefo
ll

some companiesavoid designs based on intemrpts fbr thesereasons.


: u'!

i
rl,.r
l' '
REAL-TIME
6.6 FULL.FEATURED
f,.' OPERATINGSYSTEMS
F'
Fr,-
We can extend the foreground/backgroundsolution into an operating system
adding additional functions such as network interfaces, complicated der
drivers, and complex debugging tools. These types of systems are read
available as commercial products.
Such systems rely on a complex operating system using round-rob
preemptive priority, or a combination of both schemesto provide scheduling;t
operating system represents the highest priority task, kemel, or supervi
Commercial real-time operating systems are most often of this type. The ta
control block model is most often used in these types of systems becauset
nurnber of real-time tasks is indeterminate and dynamic.

6.15
T EXAMPLE
Real-time Unix representsan example of such a full-featured operating system. There are sar
commercial versions of this well-known operating system with specific enhancementsfor reak
operation, most notably, kernel preemption.
In standard Unix, a process that makes system calls is not preemptable.Even if the c{
processis of low priority, it continues executing until it is stoppedor completed. In real-time Li
I Full-Featured Real-Time Operating Systems 161

preemption points have been built into the kemel so that system calls can be preempted without
running to completion. This radically reduces responsetimes.
Real-time Unix includes all the standard Unix device drivers and network interfaces, and
usually includes other features-such as memory locking and contiguous file allocation-to
improve real-time performance (see Chapter 8). For an excellent study of the real-time Unix, the
reader is refened to [58]. t

Other applicationsfor full-featuredcommercialoperatingsystemsinclude


simulators,in which certainprocessesare to be mn in a round-robinfashion,and
dataacquisitionand transactionprocessing.rn which the operadngsystemhost is
used to interfacethe data acquisitionor telecommunicationsunit.

Task-Control
Block Model
The task-control block model is the most popular method for implemenring
commercial, full-featured, real-time operating systems because the number of
real-time taskscan be variable. This is useful in interactive on-line systemswhere
tasks (users)come and go. This techniquecan be used in round-robin, preemptive
priority, or combination systems,although it is generally associatedwith round-
robin systemsin which a single fixed intemrpt or clock tick is used.In preemptive
systems,however, it can be used to facilitate dynamic task prioritization. The
main drawback of the task-control block model is that when a large number of
tasks are created, the overhead of the scheduler can become significant. what
follows is only a sketch of the technique. To fully implement it, you need to
consult a text that is devotedto the technique,such as [134].

6.6-l.l rhe Model In this technique, we associatewith each task a


context (e.g., program counter and register contents); an identification string or
number; a status;and a priority if applicable.Theseitems are storedin a structure
called a task-control block (or TCB), and the collection is stored in one or more
data structures,such as a linked list. Figure 6.6 depicts a sample TCB.

6.6.1.2 Task states The operating system manages the task-control


blocks by keeping track of the statusor stateof each task.A task can typically be
in any one of the following states:

1. Executing
2. Ready
3. Suspended
4. Dormant

Figure 6.7 summarizesthe relationship of the different states.


L62 Chap.6l Real-TimeKer*

Programcounter

Taskstatus

Task lD #

Contentsol register0

Pointerto next TCB

Contentsof registern

Other context
Figure 6.6 A typical task-control blocl

Th.rcexecutilrg task is the one that is actually running, and in a single-


processing system there can be only one executing task. A task can enter the
ixecuting state when it is created(ifno other tasks are leady), or from the ready
state (if it is eligible to run basedon its priority or its.position in the round-robin
ready list). When a task is completed, it retums to the suspendedstate.

Figure 6.7 Statetransitionsin the task-controlblock modelsystem.


Sec.6.6 I Full-FeaturedReal-TimeOperatingSystems 163

Tasks in the ready state are those that are ready to run but are not running.
A task enters the ready stateif it was executingand its time slice runs out, or if
it was preempted.If it was in the suspendedstate,then it can enterthe ready state
if an eventthat initiatesit occurs.If the taskwas in the dormantstate.thenit enters
the ready stateupon creation(if anothertask is executing).
Tasks that are waiting on a particular resource,and thus are not ready, are
said to be in the suspendedor blocked state.
The dormanl stateis usedonly in systemswhere the numberof task-control
blocks is fixed. (This allows for determiningmemory requirementsbeforehand,
but limits availablesystemmemory.)This stateis best descnbedas a task that
existsbut is unavailableto the operatingsystem.Once a task has been created,it
can becomedormantbv deletineit.

6.6.1.3 Task Management The operatingsystemis in essencethe highest


priority task. Every hardware interrupt and every system level call (such as a
request on a resource) invokes the real-time operating system. The operating
systemis responsiblefor maintaining a linked list containing the TCBs of all the
ready tasks,and a secondlinked list of those in the suspendedstate.It also keeps
a tableof resourcesand a tableof resourcerequests.In Chapter7, we discusshow
these tables are managed and how they can be used to facilitate intertask
synchronization and communication.
When it is invoked, the operating system checks the ready list to see if the
next task is eligible for execution. If it is eligible, then the TCB of the currently
executing task is moved to the end of the ready list, and the eligible task is
removed from the ready list and made the executing state.
In addition to rescheduling, the operating system checks the status of all
resourcesin the suspendedlist. If a task is suspendedon a resource,then that task
can enter the ready state.The list structure is used to arbitrate two tasks that are
pending on the sameresource.If a resourcebecomesavailable to a pending task,
then the resource tables are updated and the eligible task is moved from the
suspendedlist to the ready list.
Commercially available real-time operating systems are wide-ranging in
features and performance, and can support many standarddwices and network
protocols. Often these systems come equipped with useful development and
debugging tools, and they can run on a variety of hardWareand environments.
In short, commercial real.time systems are best used when they can satisfy
responserequirements at e reasonableprice, and if the system must run on a
variety of platforms.
On the negative side, however, writing these types of real-time operating
systemsis a large undertaking.Using cirmmercially available operating systemsis
an advantage, but these may have undesirable features and response times.
Finally, these systems are often too large for embedded applications and are
overkill for simple systems.
r64 Chap" 6 I Real-Time Kemel

6.7 BUILDOR BUY?

One of the most commonly askedquestionsis "should a commercialreal-time


kernel be used,or shouldone be built from scratch?"While the answerdepend
on the situation, the following key points should be remembered.Commercia
kernels are the choice in most nonembedded environments because ther
generally

r Provide robust services.


r Are easyto use.
r Are portable.

Remember,however, that commercial solutions are often slower than necessaq


becausetremendousoverheadis incurred in implementing the task-control block
model. Furthermore, commercial solutions tend to suffer from "featuritis." That
is, in an attempt to make the largest pool of potential customershappy, a large
number of featuresare included in the systemthat are of no interest to the genera
user. The run-time and storage costs associated with these features may be
excessive" Finally, users should beware of manufacturers' misleading clairn-
about responsetimes, which are given as best or averagecase-the worst cas€
responsetimes can generally not be known!
In embeddedsystems,when the per-unit charge for commercial productsis
too high, or when desired features are unavailable, you will have to write yow
own kernel. Doing so is often difficult and costly, and the system will not be
portable.However,code accessand a "lean and mean" systemmay be dominam
considerations.
For a good review of some currently available commercial real-tirm
operatingsystemsand more on the associatedpitfalls, see [150].

6.8 POSTX

Much has been made of the POSIX standard (IEEE Portable Operating System
Interfacefor ComputerEnvironmerits,IEEE 1003.1-1990).The standardprovides
for standardcompliance criteria for operating system servicesand is designedto
allow applications programs to write applications that can easily port across
operating systems.At this writing, systernscan be certified as compliant with the
1003.1standard.
However, 1003.1(sometimescalled POSX.1) doesnot specificallysuppor
real-time applications(althoughreal-time operatingsystemscan run non-real-tirne
applicationsin compliance).A new standard.POSIX 1003.4hasbeenproposedto
rernedi the lack of real-time support. Standard 1003.4 includes five sectionsthar
are,at this writing, in various stagesof approval.Thesesectionsare

.:- -_<
Sec.6.8 | POSIX 165

T POSIX.4
T POSIX.4a
T POSIX.4b
I POSIX.13
I POSIX.4c

Many of the featuresthey proposeto provide are discussedin later chaptersof the
text. However, for completeness,let us summarize them here.
POSIX.4 providesthe basereal-timeextensionsto POSIX.I such as

r Synchronousand Asynchronous I/O


r Semaphores
r Memory locking
r Sharedmemory
r Execution scheduling (priority, round-robin)
r Clocks and timers
r Messagepassing.

POSIX.4a provides further enhancementsto POSIX.I and POSIX.4 such as

r Thread management
r Signals
I Processscheduling
r Condition variables
r Thread scheduling
r Thread-safereentrant functions.

POSIX.4b provides still more enhancementssuch as

I Processspawn
r Time-outs on blocking functions
I Execution time monitoring
r Sporadic server scheduling
r Device conftol
r Inrcrrupt conffol.

Frnally, POSIX.I3 proposesto provide four prbfiles of systemscorrespondingb


various levels of real-time functionality frorn embedded to full-functioned
operating systems.Currently,.severalcommercial implementations that conform
n his standardare availabld.
Chap. 6 I Real-Time Kemels

EXERCISES
For the real-time systems below, described in Chapter l, discuss which real-time
architectureis most appropnate.
(a) Navigation system
(b) Airline reservation system
(c) Nuclear power station
2. Explain which type of real-time kernel would be most appropriate for the following
systems,and why:
(a) An air traffic control sYstem
(b) A batch uFate system
(c) A video arcade game
3. Using whatever assumptionsyou feel necessary,discuss the differences and similarities
in performing a context switch in O-, l-,2-, and 3-addressmachines.
4. Rewrite the polled loop code in Example 6.1 in
(a) C or C++
(b) Ada or Ada 95
(c) Modula-2
5. Using pseudocode,describe the coffee machine in Example 5.4. Imagine now that a
super coffee machine is built which can serve two cups of coffee simultaneously.
Describe such a machine using coroutines and phase-drivencode. Use the fact that there
is a fixed time to brew coffeeltea,to pour milk and sugar.Also assumethere is only one
brewer and one pourer for sugar and milk.
6. Rewrite the synchronizedpolled loop code in Example 6.3 in
(a) C or C++
(b) Ada or Ada 95
(c) Modula-2
7. Rewrite the statc-driven code in Example 6.4 in
(a) C or C++
(b) Ada or Ada 95
(c) Modula-2
8. Rewrite the table-driven finite state automaton in Example 6.5 in C, using pointers to
functions.
9. Rewrite the coroutine system Example 6.6 in
(a) C or C++ 1
(b) Ada or Ada 95
(c) Modula-2
10. Rewrite the coroutinesystemin Example6.7 in
(a) C or C++
(b) Ada or Ada 95
(c) Modula-2
Testingthe
11. A polledloop systempolls a discretesignaleyery50 microseconds.
and vectoring to the intemrpt-processingroutine takes 40 microseconds.If it takes 6t
milliseconds to pJocess the intemrpt, what is the minimum resPonse time for
interrupt?What is the maximumresponsetime?.
systemin Example6.8 in
12. Rewrite the foreground/background
(a) Pascal
(b) Ada or Ada 95
(c) Mqdula.2
Exercises r67

13. Considera preemptivepriority system.The tasksin the system,time neededto complete,


and priority (1 being the highest)are given below.

Task Time Needed(ms) PnontY

Task I ,10 3
Task 2 20 I
Task 3 30 2

2?
If the tasks arrive in the order 1,2,3, what is the time neededto completetask
L4. Should a routine be allowed to interrupt itselfl If it does,what does this mean?

15. What criteria are needed to determine the size of the run-time stack in a multiple-
interruptsystem?What safety precautionsare necessary?
16. What is the worst case fesponse time for the background process in a foreground/
backgroundsystemin which the backgroundtask requires100 millisecondsto complete,
the foreground task executesevery 50 milliseconds and requires 25 milliseconds to
(Recall that
complete,and context switching requiresnQ more than 100 microseconds'
the background task can be preempted.)