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 aPPlications. embedded block model is usedin commercialreal-timeexecutives The task-control 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 wellknown commercial operating systems, they are often too bulky and too allpurpose 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 real-timeoperatingsystemsttiat operatingsystem,or use one of the specialized 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 Note also that the terms rar by hardwareor by software.as we shall demonstrate. 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 the tion. In embeddedsystems,this essentiallyrepresents 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.

systems. Figure 6.1 The role of the kemelin operating

.\

Chao. 6 I

Real-Time Kemels

r43

Userinterface Shell Fileanddisksupport lnterorocessor communication andsvnchronization Task scheduling Threadfask control Blockmanagement Hardware Figure 6.2 Kemel hierarchy.

system Operating Executive Kemel Micro-kemel Nanekemel

(same as''flow-of-control") t Nano-kernel-Simple thread-of-execution 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 mailboxes, and other methods. communication via semaphores, 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€rcomputers.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. strategiesemployed in the desigrr of real-time In this chapter we exam_ine kemels.
*IINIX is not an acronym, and therefore need not be capitalized unless referring to the 'Unix' is used throughout this textregisteredtrademark. Generally, the term

144

Chap. 6 I

Real-Time Kerrnl.

LOOPSYSTEMS 6.1 POLLED

Polled loop systemsare the simplest real-time kernel. Polled loops allow for t'as a but response singledevices can't do much else.In a polled loop system, single to whetheror not some is andrepetitivetestin'struction usedto testa flag thatindicates No eventhas occurred.If the eventhas not occulred,then the polling continues. is because only a sinqletask exists or intertaskcommunication scheduling needed

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 begrln if Packet beqin process-data; Packet
I'rlll
ii j -h i
L r - - J

L j < u _ to o r

{

do

forever

}

here=TRUE

then

{

flaq

set?

}
*l-r^
L r I s

q

n L v ece o n rr r r o y rn q e

u

V M q J - s J

nr^^^--^a

u q L C

'l-ts -

here

:=

FALSE

{ reset

flag}

€rrd end

I

p','
{iu,,
! l L ltl

work well when a single processoris dedicatedto Polled loop schernes handiing the I/O for some fast device and when overlappingof events is ncn allowedor is kept to a minimum. I EXAMPLE 6.2
Managerreadsthe applicationqueueusing a polled loop. IBM's OS/2 Presentation

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 change from its OFF condition(e.9.,0 volt) to its ON condition(e.g.,5 vol for A instantaneously. typical response 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
Srn\\ch position

lJ5

On off

Throwswitch Figure 6.3 Switch bounce.

period can be realizedwith a programmabletimer that issuesan interrupt afler a of countdownperiod.In the absence 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 if TF.UE do FLAG = TRUE then begin counter whife
nrn^oec

{t

! r r ! r a r r L g

infinifc

n v n f lv ls o d y r

.r lv a Pn n v

l

i

begin
( ^ --^ ^ t l^ ! ^ ^ ts ^ i I

: = 0; <
.

counter
alranf

{ initialize } { wait
{ I rpsof nr^-oec F\rprr

bounce counrer
f-q 1

'

FLAG : = FALSE
end end The l0-millisecond

}

o1/-nf

intemrpt routine might look like

begin counter end Intemrpts are enabledin an initialization routine Notice that we wait for three trcks of the interrupt I routine in order to ensure that we wait at least 20 milliseconds. := councer+i

146

Chap. I Real-Time 6 Keme

In summary, polled loop systems are simple to write and debug, and th€ polled loops are excellent for responsetime is easy to determine.As suggested, 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.

CODE 6.2 PHASE/STATE.DRIVEN

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 before completign, without loss of critical data. This, in temporarily suspended 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 EXAMPLE 6.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 begin
n:ca f] an af

taski

1:

beqin perf orm3art_L; flag end z= 2
/* dn nh:<a 1 nrnnoc<inn */

2:

begin perf ormJart_2; flag end := 3 /* do phase 2 processing */

s+c.6.2 t

Phase State-Diven Code / 3: begin perf ormjart-3; flag := 1 end

747

/

/*

dn
vv

n rh aeq c r v v

-l

nre-e-<S_:::

end end

T

This simple nested if-then structure is really just a special case of FSAdriven code. 6.5 T EXAMPLE
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-

rl

nh:l-rof

. I i nnrri-'l ^rr2r/
l 1 L r .

, staten) ; , rnputn);
. nrl l r ^ f c f ^ f a c .

{ n ls

# of states

}

f :l-\l a

r^T^7.

-^-'a

f nrr^r:

rd

.

from sLate to state

]

state: states; input : aiphabet; table: array[1..m]

o f tabfe_row;

{

m

iq

qjzc

ol

alnhabec

-atsIinnrrf\.
Y v u \ + r r y s e , t

{

rear'l

one

roke.

f -om

i -nttt

srrean

^ - - - - !

{ transition } s'-ate := cableIord(input )lIstatel; -va.rrf F nrnaoqq ls1-:f e) : execute relevant Process } { { last token read }
" ^ L e u L e J ! v ! r r v g e ! v !

FYF-lf

c

nrn.ess

( sf aLe :

SLateS

) ;

--r^ '

^F I avonrrfo nr6aoqq

: - : * a 1 :-,- t).

n r o e c q q i : nracaqq?'

t execute process

1 i 2 )

.

nTAaFqqn:

I

avonrrfo

nr^aaqq

n

j

148

Chap. I Real-Time 6 Krndl

To summarize,state-drivensystemscan be coded in many lanfuages usins codeLr table-driven For nested if-then or casestatements. more complexsystems, preferable. can be usedin conjunctionwith polled loops,wherethe Such systems dataif the the first statetestssomeflag, and the secondstateprocesses associated is set. flag somearr naturallyto division into states; lend themseives Not all processes 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 and after eachphasr processes codedin the state-drivenfashionjust discussed, are is complete, a call is made to a central dispatcher.The dispatcher holds fte that are executedin round-robin fashim program counter for a list of processes until fu This processthen executes process execute. to the that is, it selects next next phase is complete, and the central dispatcheris called again. via is Ang betweenthe processes achieved global variables. Communication 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 nva d r ru ro veg r v! hoai n v nrnnoqq A. n r a n !a r l rv r sr ! o v s
y ! v

nrn

aac<

R.

wnlle

'I'RUE OO
^ts-ts^n nhacaA'1 nl-racaA?. -L-^^A?. Irrro D snJ , ^€ .

wn11e case

'r'KUE OO stateB
nh:

of
c cP.'l .

1 .

?.

nl.rrcaF.?.

Sec.6.3 I Coroutines
4z 5: phaseA4; phaseA5 enC end end 4: phaseB4

t49

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

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 EXAMPLE 6.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 begin case if state event strace event end; 2: begin state:=1 process-event; end end Such a schemereducesthe amounrof time wasted polling the event flag, and allows for processing I time for other tasks. { reset
f
r

Taskl; of = TRUE then { event
I nhrnna

detected
c f - f-a* a- -

}
f l *r * J -:

: =FALSE

{ reset { call

event exit }

flag

}

state
arrant

fy'ag }
]

nrnnocc
F ! v v v v v

{ call

exit

}

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

for such as Ada and Modula-2 have built-in constructs implementing languages coroutinesin a way that is superior to the somewhatartificial (but more general) given in Examples6.6 and 6.7. implementation 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 cannotalways Finally,processes which is undesirable. involving global variables, be broken easily into uniform size phases,which can adversely affect response time since the minimum size is a function of the longestphase.

DRIVEN SYSTEMS 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 intemrpthandling 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 intemrptcontroller 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 contributimes and is a factor that we strive to minimize. The rule for saving tor to response 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. Contents registers of 2. Contents of the program counter registers 3. Contentsof coprocessor 4. Memory page registers(seeChapter8) I/O location mirror images(seeSection2.3.2) 5. Memory-mapped 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 timeoverloadedcondition. 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 in real-timeoperatingsystemsand is discussed 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 memory areathat can be static,in the caseof a single-intemtpt system, designated or a stack, in the case of a multiple-interrupt system. This type of stack in is management discussed 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
i - f i n i t o

sysLem, -oad incerrupt
l n n n * /

handlers */

, , L i r ^ / n D T T E \ .
r v r r r f s \ ! f \ v ! / ,

r52
void intl (void) /* interrupt handler 1 */

Kernels Chap.6 I Real-Time

c:rra

l nnnf

ovi-

) :

/* /* /*

qave

eontext fask

on

() ; restore (context ) ; taskl

oyc.rrfr restore

stack 1 */ from

*/

context

stack

*/

)
void int2 (void)
/

/*

f

i rn ut ec r r l n t s y v ! r !

handl
rre.r\^&

ef

2

* /

<:rza

I cnnf

ovl-

) :

/*
/* /*

save context
axecnfe rcsf nrtr task

on sLack */
2 */ from stack */

raski( ) ; restore(context); ) void int3 r (void)

ct-)nf.ext

/*

interrupt

handler

3 */

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

*/ */

context

from stack

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

SYstems 6.4.2 Round-Robin
are ln round-robin systemseveralprocesses 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

d p o

Task3 Task2
Task 1 Task 1

Task2

Figure 6.4 Time slicing of three taSks.

PrioritySystems Preemptive
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 with that intemrpt (seeFigure 6.5). of the task associated

Task 2 Task 1 Task 3 Task 2 Task 3 interrupts interrupts compleles comdetes corndetes Flgure 6.5 Preemptive schedulhg of three tasks.

I EXAMPLE 6.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. Fixedyioriry 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 systems. is particularly important in certain types of threat-management 6.10 I EXAMPLE

systems,such as those related Dynamic-priority systemscan be found in many threat-management computer may be able to track up to six enem\ to military aircraft. The aircraft's threat-management 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

can lead to the hogging of lesourcesby higherPreemptivepdority schemes can lead to a lack of available resourcesfor lower-priorin priority tasks. This 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 I ao rectify this problem (see Chapter 14).

6.4.3.1 Rate-Monotonic Systems A special class of fixed-rate pIE include called rate-monotonicsystems, emptive priority intemrpt driven systems, so that the higher tht those real-time systemswhere the priorities are assigned executionfrequency,the higher the priority. This schemeis common in embedde applications, particularly avionics systems, and has been studie extensively [104],[105],U40l' [141]. [54],U031, 6.12 I EXAMPLE

data every 5 miiliseconds br In our aircraft navigation system,the task that gathersaccelerometer 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 I updatesthe pilot's display every secondhas lowest priority.

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. However, 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 occur. inversionmay necessarily There are actually severalkinds of priority inversion.The first occursin ratemonotonic 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 in discussed 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 is time. This sequence called a major cycle.If within the major cycle, smaller also repeat, they are called minor cycles. For example consider the sequences following nonintemrpt driven cyclic executtve:
while(forever) begin process_a; process-b; process_a; proGess_c; process_a; do

156
nrn-6cc h b.

Chap. 6 I

Real-Time Kemels

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, systems. which are widely used in embedded 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 processes that occur in the foreground and background shortly. Foreground/background systems are the most common solution for They involve a setof intemrpt driven or real-timeprocesses embedded applications. called the called theforeground and a collection of nonintemrpt driven processes background..The foreground tasks run in round-robin, preemptive priority, or combinationfashion.The backgroundtask is fully preemptableby any foreground the represents lowest priority task in the system. task and,in a sense,

L

*4

Sec.6.5 I

Systems Foreground/Background

157

All real-time solutions are just special casesof the foreground/background system For example,the polled loop is simply a foreground/background systems. a background. Adding interrupts for with no foreground, and a polled loop as system. synchronizationyields a full foreground/background Phase-drivencode is a foreground/backgroundsystem with no foreground are Coroutinesystems just a complicated codefor a background. andphase-driven systems are foreground/background background process.Finally, intemrpt-only systemswithout a background. of are all It is preciselybecause real-timesolutions just variations foreground/ background systemsthat we study them so extensively. Mastering foreground/ backgroundsystemsallows us to understandall the other real-time kernels.

Processing 6.5.1Background
shouldbe placedin backgroundis an easyone: The questionof what processing The backgroundprocessis the processwith the anything that is not time critical. 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 timeloading factor. That is, if p representsthe time-loading for all the foreground (seeChapter9 to calculatethis), and if e is the executiontime of the processes 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 If which are reset in thoseprocesses. the background of the foregroundprocesses, is not being reset often enough, you can processdetectsthat one of the counters 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 Derformed backeround. in 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
disable intemrpts put interrupt handler addressin location 5 enable interrupts

DPI STORE Ghandler,5 EPI

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] S T O R ER 0 , r e g 0 S T O R ER 1 . r e g l S T O R ER 2 , r e g 2 S T O R ER 3 , r e g 3 S T O R ER 4 , r e g 4 S T O R ER 5 . r e g 5 S T O R ER 6 , r e g 6 S T O R ER 7 , r e g 7 .]U EAPP LOAD R7, regT LOAD R5, reg6 LOAD R5, reqs LOAD R4, reg4 LOAD R3, reg3 LOAD R2, reg2 LOAD R1, regl LOAD R0, rego EPI RT redundantly disable intemrpts save register 0 save register I save register 2 save register 3 save register 4 save register 5 save register 6 save register 7 execute real-time application progrirm restore register 7 restore register 6 restore register 5 restore register 4 restore register 3 restore register 2 restore register I restore register 0 re-enable interrupts 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 space for context variable */ reEli

alfocate

int. reg0, /* decfare

reg1, reg2, reg3, g1oba1 variables

regL, reg5, reg6, here */

other

r60

Chap.6I

Real-TimeKe

init

O ;

/* /*
rnrt 1\
t

initialize

system */ */
i no hcrc * /

while (TRUE)
l-': nlznrnr
v q v r \ Y ! v s r r l 4 \ /

background loop
nan-raa I -t i mo

/ *

nrnccqq

,rii |1,i;'ll

t:

rr i"
ll

: u'!

Foreground/backgroundsystemsrepresenta supersetof all the other re times,sincethey rr They typically havegood response time solutionsdiscussed. 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 implemented when the number of foreground tasks is fixed andknown a prit Although languagesthat support dynamic allocation of memory could handl variable number of tasks, this can be tricky. Finally, as with the intemrpt-o ,system,the foreground/backgroundsystem is vulnerable to timing variatio unanticipatedrace conditions, hardwarefailures, and so on. As mentionedbefo some companiesavoid designs based on intemrpts fbr thesereasons.

i rl,.r l' '

f,.'

F'

REAL-TIME 6.6 FULL.FEATURED SYSTEMS OPERATING

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 for commercial versions of this well-known operating system with specific enhancements 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, which certainprocesses to be mn in a round-robinfashion,and in are dataacquisitionand transaction processing. which the operadngsystemhost is rn used to interfacethe data acquisitionor telecommunications unit.

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 roundrobin 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*

Program counter

Taskstatus
Task lD # ol Contents 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 singleprocessing 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.

block modelsystem. in Figure 6.7 Statetransitions the task-control

Sec.6.6 I

Full-Featured Real-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. it was in the suspended If state,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. where the numberof task-control The dormanl stateis usedonly in systems beforehand, blocks is fixed. (This allows for determiningmemory requirements 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 essence highest the 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 suspended state.It also keeps a tableof resources a tableof resource and requests. Chapter7, we discuss In how 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 suspended list. If a task is suspended a resource,then that task on 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 suspended to the ready list. 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 BUILD BUY? OR

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 clairnabout response times, 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 access and a "lean and mean" systemmay be dominam considerations. For a good review of some currently available commercial real-tirm operatingsystemsand more on the associated pitfalls, see [150].

6.8 POSTX

Much has been made of the POSIX standard (IEEE Portable Operating System Interfacefor ComputerEnvironmerits, IEEE 1003.1-1990). The standard provides 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(sometimes called POSX.1) doesnot specificallysuppor real-time applications(althoughreal-time operatingsystemscan run non-real-tirne applications compliance). new standard. in A POSIX 1003.4hasbeenproposed to 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
T T T I I

165

POSIX.4 POSIX.4a POSIX.4b POSIX.13 POSIX.4c

Many of the featuresthey proposeto provide are discussedin later chaptersof the text. However, for completeness, us summarize them here. let POSIX.4 providesthe basereal-timeextensions POSIX.I such as to 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 enhancements POSIX.I and POSIX.4 such as to r Thread management r Signals I Processscheduling r Condition variables r Thread scheduling r Thread-safereentrant functions. POSIX.4b provides still more enhancements such as Processspawn Time-outs on blocking functions Execution time monitoring 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. I r I r

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 Explain which type of real-time kernel would be most appropriate for the following 2. 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 1 (a) C or C++ (b) Ada or Ada 95 (c) Modula-2 6.7 in system Example in Rewritethe coroutine 10. (a) C or C++ (b) Ada or Ada 95 (c) Modula-2 the Testing polls a discrete signaleyery50 microseconds. 11. A polledloop system

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

time?. interrupt?What is the maximumresponse systemin Example6.8 in foreground/background 12. Rewrite the (a) Pascal (b) Ada or Ada 95 (c) Mqdula.2

Exercises

r67

to time needed complete, The tasksin the system, priority system. 13. Considera preemptive and priority (1 being the highest)are given below. Time Needed(ms) PnontY

Task
Task I Task 2 Task 3

,10 20 30

3 I 2

2? If the tasks arrive in the order 1,2,3, what is the time neededto completetask mean? L4. Should a routine be allowed to interrupt itselfl If it does,what does this 15. What criteria are needed to determine the size of the run-time stack in a multipleare interruptsystem?What safety precautions necessary? worst case fesponse time for the background process in a foreground/ 16. What is the task requires100 millisecondsto complete, backgroundsystemin which the background the foreground task executesevery 50 milliseconds and requires 25 milliseconds to (Recall that complete,and context switching requiresnQ more than 100 microseconds' task can be preempted.) the background