A Survey of Fitting Device-Driver Implementations into Real-Time TheoreticalSchedulability Analysis

Mark StanovichFlorida State University, USA

Contents

1 Introduction 2

2 Scheduling Theory 32.1 Workload Models . . . . . . . . . . . . . . 32.2 Scheduling . . . . . . . . . . . . . . . . . 4

2.2.1 Static Schedulers . . . . . . . . . . 42.2.2 Priority Scheduling . . . . . . . . . 5

2.2.2.1 Fixed-Priority Scheduling 52.2.2.2 Dynamic-Priority

Scheduling . . . . . . . . 62.3 Schedulability Tests . . . . . . . . . . . . . 6

3 Basic Scheduling 73.1 Threads . . . . . . . . . . . . . . . . . . . 73.2 Scheduler . . . . . . . . . . . . . . . . . . 7

3.2.1 Switching Among Threads . . . . . 83.2.2 Choosing Threads . . . . . . . . . 8

3.2.2.1 Thread States . . . . . . 83.2.2.2 Fairness . . . . . . . . . 83.2.2.3 Priorities . . . . . . . . . 8

3.2.3 Regaining Control . . . . . . . . . 83.2.3.1 Voluntary Yield . . . . . 83.2.3.2 Forced Yield . . . . . . . 8

4 Basic Requirements for RT Implementation 94.1 Time Accounting . . . . . . . . . . . . . . 9

4.1.1 Variabilities in WCET . . . . . . . 94.1.1.1 Context Switching . . . . 94.1.1.2 Input and Output Opera-

tions . . . . . . . . . . . 104.1.1.3 Caching and Other Pro-

cessor Optimizations . . 104.1.1.4 Memory . . . . . . . . . 10

4.1.2 System Workloads . . . . . . . . . 114.1.2.1 Scheduling Overhead . . 11

4.2 Temporal Control . . . . . . . . . . . . . . 114.2.1 Scheduling Jitter . . . . . . . . . . 114.2.2 Nonpreemptible Sections . . . . . . 114.2.3 Non-unified Priority Spaces . . . . 11

4.2.4 Temporal Isolation . . . . . . . . . 124.3 Conveyance of Task/Scheduling Policy Se-

mantics . . . . . . . . . . . . . . . . . . . 12

5 Device Drivers 125.1 CPU Time . . . . . . . . . . . . . . . . . . 12

5.1.1 Execution . . . . . . . . . . . . . . 125.1.2 Accounting . . . . . . . . . . . . . 165.1.3 Control . . . . . . . . . . . . . . . 17

5.2 I/O Scheduling . . . . . . . . . . . . . . . 185.2.1 Device Characteristics . . . . . . . 185.2.2 Device Timings . . . . . . . . . . . 195.2.3 Backlogging of Work . . . . . . . . 20

5.3 Global Scheduling . . . . . . . . . . . . . 21

6 Conclusion 22

1

Abstract

General purpose operating systems (GPOSs) are com-monly being used in embedded applications. These appli-cations include cellphones, navigations systems (TomTom),routers, etc. While these systems may not be is consid-ered “hard” real-time, they have timing constraints. Thatis, missing a deadline may not be catastrophic, but at thesame time missed deadlines should not occur frequently.

Recently there have been many enhancements in GPOS’sreal-time characteristics. These include standardized inter-faces (e.g. POSIX), more precise processor scheduling, andincreased control over system activities. While these en-hancements have improved the ability for real-time appli-cations to meet timing constraints, there is still much left tobe desired. In particular, improper management of devicedriver activities can cause extreme difficulties for a systemto meet timing constraints.

Device drivers consume processor in competition withother real-time activities. Additionally, device drivers actas I/O schedulers, meaning that timeliness of activities suchas network and storage device I/O are directly affected bythe operation of the device drivers. In order to guaranteedeadlines, these factors (processor time and I/O schedul-ing) must be properly managed. This requires understand-ing device driver characteristics and performing abstractanalysis (on their operations) to ensure timing constraintswill be met.

This survey will first provide a brief introduction to real-time scheduling theory, which provides the foundation forensuring timeliness of a system. We will then cover somebasic attributes of an operating system that affect the abil-ity of a system to adhere to the theoretical schedulabilitymodels. Finally, this paper will survey the approaches thathave been developed to deal with the impact device drivershave on the timeliness of an implemented system.

1 Introduction

A real-time system has constraints on when activitiesmust be performed. Some examples of such systemsinclude audio/video devices (e.g., mp3 players, mobilephones), control systems (e.g., anti-lock braking systems),and special devices (e.g., navigation systems, pacemakers).The correctness of the system not only depends on the cor-rect output for a given input, but also depends on the time atwhich the output is provided. If the output arrives too earlyor too late, the system may fail. This failure could be assimple as a visual glitch when watching a movie, or couldbe as severe as an explosion at a chemical plant. These tim-ing constraints are an integral part of the system, and guar-

anteeing that they will always be met is one of the mainchallenges of building such a system.

Traditional real-time systems have typically been em-bedded devices. These devices have limited resources, usespecialized hardware and software, and provide only a fewfunctions. Traditional real-time systems have the advantageof simplicity, which makes the challenge of validating thesystem’s timing correctness tractable. Timing constraints ofthe system are guaranteed to be met without great difficultybecause mapping the theoretical models to the implemen-tation is generally straight-forward and the slight variationsfrom the theoretical models introduced by the implementa-tion can be compensated by minor adjustments to the theo-retical model.

Over time embedded computing systems have becomemore prevalent and more integrated into the world aroundus. Embedded systems are now expected to perform nu-merous, complex functions. One illustration of this evolu-tion toward greater complexity is the mobile phone. Whenthese devices first emerged on the market, the only func-tionality expected was to allow voice communication. Now,if we look at any of the new “smartphones” we will see amuch different device, not only capable of voice commu-nication, but resembling a desktop system with services in-cluding gaming, email, playing music, taking pictures, webbrowsing, and navigational support. These additional func-tionalities require much more complex hardware and soft-ware, compared to traditional embedded systems.

While many real-time applications still run on special-ized hardware and software, it is becoming much morecommon to see real-time systems utilizing off-the-shelfhardware and software. In particular, general purpose oper-ating systems (GPOSs) have found their way into the real-time domain. One recent example of this is the develop-ment of the Android platform [21]. The Android platformutilizes a modified version of the popular Linux kernel andother readily available applications.

Using a GPOS has numerous advantages, includingwide-spread familiarity, lower cost, reduction in main-tenance, and availability of many software components.However, GPOSs are much more complicated, making itvery difficult to analyze them, and thereby guarantee timingconstraints.

These GPOSs were never designed for real-time envi-ronments. In fact, a common goal of a GPOS is to improveaverage-case performance and maximize throughput, manytimes at the cost of increasing the range of execution timesbetween the best-case and worst-case behavior. In contrastto explicitly designed real-time systems, most GPOSs werenot designed to consistently provide low-latency responsetimes, predictable scheduling, or explicit allocation of re-sources. The lack of these attributes can significantly hinderthe ability of a system to meet deadlines.

Fortunately, significant progress has been made towardproviding real-time capabilities in GPOSs. For example,Linux kernel improvements have reduced non-preemptiblesections [51], added high-resolution timer support [19,20], and included application development support throughPOSIX real-time extensions [25].

On the other hand, the device-driver components ofGPOSs have been generally overlooked as a concern forsystems that must meet deadlines. Device drivers are anintegral part of the overall system, allowing interaction be-tween applications and hardware through a common inter-face. These device drivers allow an OS to support a widerange of devices without requiring a substantial rewrite ofthe OS code. Instead, if a new piece of hardware is added,one can just write a new device driver that provides theneeded abstraction, without ever touching any of the appli-cation software that uses the device.

Device drivers can have a considerable effect on the tim-ing of a system. They typically have complete access to theraw hardware functionalities, including the entire processorinstruction set, physical memory, and hardware schedulingmechanisms. Worse, device drivers are often developed bythird parties whose primary concern is ensuring their de-vices meet timing constraints, without regard for other real-time activities [34].

Numerous theoretical techniques exist to guaranteegiven activities will be scheduled to complete by their as-sociated timing constraints [67]. These theoretical tech-niques generally rely on the real-world activities adheringto some abstract workload models and the system schedul-ing this work according to a specified scheduling algorithm.The difficulties emerging are that many of the device driverworkloads do not adhere to known workload models. Fur-ther, the scheduling of this work on GPOSs tends to be adhoc and deviates significantly from the theoretical schedul-ing algorithms that have been analyzed, thereby makingmany analysis techniques unusable for such systems.

Other difficulties with device drivers are that the schedul-ing of their CPU time is commonly performed throughhardware schedulers. These hardware schedulers are typ-ically not configurable and the scheduling policy is prede-termined. This inflexibility in allocating CPU time meansthat workload models that provide better system schedula-bility may not be usable. Therefore, activities may not meettheir timing constraints due to inappropriate allocation ofthe CPU, even though they logically should be able to be-cause the amount of CPU time is available, just not at theright time.

This paper is organized as follows: Section 2 will coversome of the basic aspects of scheduling theory. Section 3will provide an overview of how scheduling of the CPU iscommonly performed on computer systems. Section 4 willprovide an idea of what is required in order to implement

a real-time system. Finally, Section 5 will provide some ofthe more important problems and developments with fittingdevice drivers into a real-time system.

2 Scheduling Theory

Scheduling theory provides techniques to abstractly ver-ify that real-world activities will complete within their as-sociated timing constraints. That is, scheduling theory pro-vides the ability to guarantee that a given abstract workloadwill be scheduled on a given abstract set of processing re-sources by a given scheduling algorithm in a way that willsatisfy a given set of timing constraints.

There exists a substantial amount of theoretical researchon analyzing real-time systems, much of which traces backto a seminal paper published by Liu and Layland in 1973[41]. In this section we will review a small portion of thistheoretical research.

2.1 Workload Models

One aspect of a system that must be modeled is the workto be completed. An example is some calculation to be per-formed based on sensor inputs. If one were to think in termsof a gasoline engine in an automobile,1 a calculation may beused to determine the amount of fuel to inject into a cylin-der. This calculation would use the sensor readings suchas air temperature, altitude, throttle position, and others asinputs. Given the inputs, a sequence of processor instruc-tions would be used to determine the output of the calcula-tion. Then, the appropriate signal(s) would be sent to thefuel injection mechanism. Execution of these processor in-structions are the work for the processor resource. The termtypically used for one instance of processor work (e.g. onecalculation) is a job.

Typically, to provide an ongoing system function such asfuel injection, a job must be performed over and over again.We can think of performing some system functionality as apotentially endless sequence of jobs. This sequence of jobsperforming a particular system function is known as a task.

10 15 20 25 30 35 40 50 55 60 654550

Figure 1. Gantt chart representing execution of work overtime.

One way to visualize the work being performed on agiven resource over time is through a Gantt chart. In Fig-

1The automobile engine used throughout this section is imaginary andused only as an illustrative analogy. The actual design of an automobileengine is at best more complicated than this and most likely much different.

3

ure 1, each shaded block represents a job using a given re-source for 5 units of time. So, one job executes over thetime interval between 0 and 5, another executes over thetime interval between 25 and 30, etc. The amount of workperformed by a given job will be referred to as the job’s ex-ecution time. This is the amount of time the given job usesa resource. Note that all jobs of a given task may not havethe same execution time. For instance, different code pathsmay be taken for a different sensor input values. One in-put may require fewer processor instructions, while anothermay require more, thereby varying the execution time fromjob to job.

Each job has a release time, the earliest time when thejob is allowed to begin execution. This release time maydepend on data being available from sensors, another jobbeing completed, or other reasons. This is not necessarilythe point in time when the job begins execution, since itmay be delayed if another job is already using a requiredresource and the newly released job cannot acquire the re-source immediately.

Another term used in the abstract workload model isdeadline, which is the point in time when a job’s work mustbe completed. In an automobile engine, a deadline may beset so that the fuel must be injected before the piston reachesa certain position in its cylinder. At that position a sparkwill be produced and if the fuel is not present, no combus-tion will take place. This point in time when the job mustbe completed may be represented in several different ways.One is known as a relative deadline, which is specified assome number of time units from the release of the job. Theother is an absolute deadline, which is in relation to timezero of the time keeping clock. For example, a job with arelease time of t = 12 and relative deadline of 5 would havean absolute deadline of 17.

One commonly used abstract workload model used todescribe a recurring arrival of work is the periodic taskmodel. In the periodic task model, the next job is separatedfrom the previous job by a constant amount of time. An ex-ample for the use of the periodic task model can be thoughtof in terms of an engine running at a constant number of rev-olutions per minute (RPM). The calculation for the amountof fuel to inject must be performed some constant amountof time from the previous calculation. While this modeldoes not work if the RPMs of the engine change (this willbe taken into account later), this does characterize many ap-plications that are used to monitor and respond to events.To express a periodic task denoted as τi, where i identifiesa unique task on a system that contains multiple tasks. Atask has a period, Ti defining the inter-arrival time of jobsof the task. To represent the kth job of task i, the notation,ji,k is used. Therefore, a task τi can be represented as asequence of jobs ji,0, ji,1, ..., ji,k, ji,k+1, ... where the timebetween the arrival or release of any job ji,k+1 is Ti time

units from job ji,k. A task also has an execution or compu-tation time, Ci, that is the maximum execution time of allthe jobs for a given task. This is referred to as the task’sworst-case execution time (WCET). Each job also has a rel-ative deadline from its release time. This relative deadlineis the same for every job of a given task and is denoted asDi. At this point we can describe a periodic workload as τicomprised of three parameters: Ci, Ti, and Di.

r i,k

di,k

ri,k+1

Di

i≥Τ

Ci

≤

i,k

completes

j

Figure 2. Representation of sporadic task τi.

The periodic task model has the constraint that the inter-arrival times between tasks must be equal to the period (Ti).A task that treats the period only as a lower bound betweeninter-arrival times is known as a sporadic task. So, if wehave a sporadic task τi and we denote the release time ofjob k of task τi as ri,k, then ri,k+1 − ri,k ≥ Ti. Figure 2illustrates the sporadic task model. In this figure, di,k rep-resents the deadline of job ji,k. With this relaxed model,an engine that runs at a varying RPMs can now be repre-sented. The period using the sporadic task model would bethe minimum time between the execution of the fuel amountcalculation, which would happen at the maximum RPM theengine could possibly run. This time between arrivals at themaximum RPM would give us the period for our sporadictask.

2.2 Scheduling

In order to allow multiple tasks on a system at one time,we must determine how to control access to the resource(s)to resolve contention. In the case where the processor isthe resource, more than one job may want to use a singleprocessor to perform computations. Similarly, one job maybe using a resource when another job arrives and thereforecontends for use of the processor. A scheduling algorithmis used to determine which job(s) can use what resource(s)at any given time.

2.2.1 Static Schedulers

One desirable characteristic of a scheduling algorithm is theability to adapt as the arrival pattern changes. This charac-

4

j1

j2

j1

j2

arrivals

time

(a) Example of preemptive scheduling.

j1

time

j2

j1

j2

arrivals

(b) Example of non-preemptive scheduling.

Figure 3. Comparison of preemptive and non-preemptive scheduling.

teristic distinguishes between static (non-adaptive) versusdynamic (adaptive) schedulers. Since dynamic schedulersare the common case, we will only briefly describe staticschedulers.

Static scheduling algorithms precompute when each jobwill execute. Therefore, applying these algorithms requiresknowledge of all future jobs’ properties, including releasetimes, execution times, and deadlines. The static schedulerwill then compute the schedule to be used at runtime. Dur-ing runtime, the exact schedule is known. So, once one jobcompletes or a given point in time is reached the next jobwill begin execution.

One type of static scheduler is known as the cyclic exec-utive, in which a sequence of jobs is executed one after theother in a recurring fashion. The jobs are not preemptibleand are run to completion. A cyclic executive is typicallyimplemented as an infinite loop that executes a set of jobs[42].

The cyclic executive model is simple to implement andvalidate, concurrency control is not necessary, and depen-dency constraints are taken into account by the scheduler.However, this model does have the drawback of being veryinflexible [10, 43]. For instance, if additional work is addedto the loop, it is likely that the time boundaries for portionsof the original work will be different. These changes willrequire additional, extensive testing and verification to en-sure the original timing requirements are still guaranteed.Ideally one would like the system to automatically adapt tochanges in the workloads.

2.2.2 Priority Scheduling

A priority scheduler uses numeric priority values as the pri-mary attribute to order access to a resource. In most priorityscheduling policies, priority values are assigned at the joblevel. When multiple jobs contend to use a given resource(e.g. processor) this contention is resolved by allocating theresource to the job with the highest priority.

It is generally desired to provide the resource to thehighest- priority job immediately. However, this is not al-ways possible. This characteristic of being able to provide aresource immediately to a job is known as preemption. Forinstance, consider Figure 3a. Here we have two jobs, 1 and2 sharing a resource. The subscripts indicate the job’s pri-ority and the lower the number indicates a higher priority.So, 1 has higher priority than 2. On the arrival of 1, 2is stopped and execution of 1 is started. This interruptionof one job to start another job is known as a preemption.In this case, the higher priority job is able to preempt thelower priority job. If, 1 is unable to preempt 2 when it ar-rives as in Figure 3b, then 2 is said to be non-preemptible.A non-preemptible job or resource means that once a jobbegins executing with the resource it will run to completionwithout interruption.

Preemption may not always be desired if an operation(e.g., section of code) is required to be mutually exclusive.To inhibit preemption some form of locking mechanism istypically used (e.g., monitors, mutexes, semaphores). How-ever, preventing preemption can result in a violation of pri-ority scheduling assumptions known as priority inversion.Priority inversion is a condition where a lower-priority taskis executing, but at the same time a higher-priority task isnot suspended but is also not executing. Using an exam-ple from [39], consider three tasks τ1, τ2, and τ3, wherethe subscript indicates the priority of the task. The largerthe numeric priority, the higher the task’s priority. Further,consider a monitor M by which τ1 and τ3 use for commu-nication. Suppose τ1 enters M and before τ1 leaves M, τ2preempts τ1. While τ2 is executing, τ3 preempts τ2 and τ3attempts to enter M, but is forced to wait (τ1 is currentlyin M) and therefore is suspended. The next highest-prioritytask will be chosen to execute which is τ2. Now, τ2 willexecute, effectively preventing τ3 from executing, resultingin priority inversion.

2.2.2.1 Fixed-Priority Scheduling Fixed-task-priorityscheduling assigns priority values to tasks and all jobs of

5

τ1

τ2

0 5 10time

(a) fixed priority (RM) scheduling

τ1

τ2

0 5 10time

(b) dynamic priority (EDF) scheduling

Figure 4. Fixed vs. dynamic priority scheduling.

a given task are assigned the priority of their correspondingtask. The assignment of priorities to tasks can be performedusing a number of different policies. One widely knownpolicy for assigning priorities for periodic tasks is what Liuand Layland termed rate-monotonic (RM) scheduling [41].Using this scheduling policy, the shorter the task’s periodthe higher the task’s priority. One assumption of this pol-icy is that the task’s period is equal to its deadline. In or-der to generalize for tasks where the deadline may be lessthan the period, Audsley, et. al [3] introduced the deadline-monotonic scheduling policy. Rather than assigning priori-ties related to the period of the task, this approach schedulespriorities according to the deadline of the task. Similar toRM scheduling, deadline-monotonic assigns a priority thatis inversely proportional to the length of a task’s deadline.

2.2.2.2 Dynamic-Priority Scheduling As in fixed-task-priority scheduling the priority of a job does notchange, however, with dynamic-priority scheduling jobs ofa given task may have different priority values.

One of the best known dynamic-priority scheduling al-gorithms is known as earliest deadline first (EDF), in which,the highest priority job is the job that has the earliest dead-line.

To illustrate the dynamic-priority vs fixed-priorityscheduling, consider Figure 4. τ1 and τ2 are periodic tasksassigned priority values using either EDF (dynamic) or RM(fixed) priorities. τ1 has an execution time of 2 and pe-riod/deadline of 5. τ2 has an execution time of 4 and pe-riod/deadline of 8. So, at time 0 the job of τ1 has a higherpriority than the job of τ2 in both EDF and RM. At time5, for RM, τ1’s job still has higher priority, however, forEDF, τ2’s job now has a higher priority than τ1’s, hence thepriority assignment for jobs of a single task can change dy-namically.

2.3 Schedulability Tests

The tests used to determine whether timing constraintsof given abstract workload models, scheduled on a given setof abstract resources using a given scheduling algorithm canbe guaranteed are termed schedulability tests, or schedula-bility analyses.

In a real-time system one expects to guarantee the timingconstraints for a given set of tasks are always met. In orderto guarantee these timing constraints the work to be per-formed on the system, the resources available to performthis work, and the schedule of access to the resources allmust considered. One possible conclusion from a schedula-bility analysis is that the set of tasks is schedulable, meaningthat every job will complete by its associated deadline. Inthis case, the schedule produced is said to be feasible. An-other possible conclusion from the schedulability test is thatthe schedule is not feasible, meaning that it is possible thatat least one job will not meet its deadline.

schedulable task setsunschedulable task sets

necessary­and­sufficient(guranteed unschedulable/schedulable)

necessary­only(guaranteed

unschedulable)

sufficient­only(guaranteedschedulable)

Figure 5. Guarantees made by various schedulabilitytests.

A schedulability test will typically report either a posi-tive result, indicating that the task set is guaranteed to beschedulable, or a negative result, indicating the one or morejobs of the given task set may miss their deadlines. How-ever, depending on the given schedulability test, the resultmay not be definite in either the positive or negative result.The terms sufficient-only, necessary-only, and sufficient-and-necessary are commonly used to distinguish betweenthe different types of tests as described below and illustratedin Figure 5. A schedulability test where a positive resultmeans the task set is guaranteed to be schedulable, but anegative result means that there is still a possibility that thetask set is schedulable is termed a sufficient-only test. Sim-ilarly, a test where the negative result means that the taskset is certainly unschedulable, but the positive result meansthere is still a possibility that the task set is unschedulableis a necessary-only test. Ideally one would always strive

6

for tests that are necessary-and-sufficient, or exact, wherea positive result means that all jobs are guaranteed to meettheir deadlines and a negative result means that there is atleast one scenario where a job may miss its deadline.

Liu and Layland published one of the first works onfixed-priority scheduling [41]. In their work, the critical in-stant theorem was formulated. The critical instant is theworst-case scenario for a given periodic task, which Liuand Layland showed occur when the task is released withall tasks that have an equal or higher priority. This createsthe most difficult scenario for the task to meet its deadlinebecause the task will experience the largest amount of inter-ference, thereby maximizing the job’s response time.

Liu and Layland used the critical instant to develop theCritical Zone Theorem which states that for a given set ofindependent periodic tasks, if τi is released with all higherpriority tasks and meets its first deadline, then τi will meetall future deadlines, regardless of varying the task releasetimes [41]. Using this theorem a necessary-and-sufficienttest is developed by simulating all tasks at their critical in-stant to determine if they will meet their first deadline. If alltasks meet their first deadline, then the schedule is feasible.A naive implementation of this approach must consider alldeadline and release points between the critical instant andthe deadline of the lowest priority task. Therefore, for eachtask τi, one must consider dDn/Tie such points, resultingin a complexity of O(

∑n−1i=0

Dn

Ti) [67].

While schedulability analyses like the one above are use-ful for determining whether a particular task set is schedu-lable, it is sometimes preferable to think of task sets inmore general terms. For instance, we may want to thinkof task parameters in terms of ranges rather than exact val-ues. One approach that is particularly useful is known asmaximum schedulable utilization, where the test to deter-mine the schedulability of a task set is based on its totalprocessor utilization. Utilization of a periodic task is thefraction of processor time that the task can demand from aresource. Utilization is calculated by dividing the computa-tion time by the period, Ui = Ci

Ti. The utilization of the task

set, or total utilization, is then the sum of utilization of theindividual tasks in the set, Usum =

∑n−1i=0 Ui, where n is

the number of tasks in the set. Now to determine whether atask set is schedulable, one need only compare the utiliza-tion of the task set with that of the maximum schedulableutilization. As long as total utilization of the task set is lessthan maximum schedulable utilization then the task set isschedulable.

The maximum schedulable utilization varies dependingon the scheduling policy. Considering a uniprocessor sys-tem with preemptive scheduling and tasks assigned pri-orities according to the RM scheduling policy, the max-imum schedulable utilization is n(2

1n − 1), and referred

to as the RM utilization bound (URM ) [41]. As long as

Usum ≤ n(21n −1) the tasks are guaranteed to always meet

their deadlines. This RM utilization bound test is sufficient,but not necessary (failure of the test does not mean the taskset is necessary unschedulable). Therefore, a task set satis-fying the RM utilization test will always be schedulable, buttask sets with higher utilization cannot be ensured schedu-lability.

While the RM utilization bound cannot guarantee anytask sets above URM , one particularly useful class of tasksets which can guarantee higher utilizations are those whosetask periods are harmonic. These task sets can be guaran-teed for utilizations up to 100% [67].

Preemptive EDF is another commonly used schedulingalgorithm. The schedulability utilization bound providedfor this scheduling policy is 100% on a uniprocessor [41].This means that as long as the utilization of the task setdoes not exceed 100% then the task set is guaranteed to beschedulable. In fact, for a uniprocessor, the EDF schedulingalgorithm is optimal, in the sense that if any feasible sched-ule exists than EDF can also produce a feasible schedule.

Many other scheduling algorithms and analyses exist toprovide guarantees of meeting deadlines. This is especiallytrue for the area of multiprocessor scheduling. However, thebasic principles are essentially the same, given a workloadmodel and scheduling algorithm, a schedulability test candetermine whether timing constraints of a given system willbe met.

3 Basic Scheduling

In this section we will cover basic terminology and meth-ods used to allow multiple applications to reside on a sin-gle processor system. The major concern is managementof resources to allow work to be performed in a flexible yetrelatively predictable and analyzable manner.

3.1 Threads

A sequence of instructions executing on a processor isreferred to as a thread. On a typical system, many threadscoexist; however, a processor may be allocated to only onethread at a time2. Therefore, for many threads to use oneprocessor, the allocation of a processor must be rotatedamong the available threads.

3.2 Scheduler

Granting access to the processor is performed by theOS’s scheduler, sometimes called the dispatcher. Thescheduler decides which thread at a given time will executeon the CPU.

2This is only considering a single CPU system with one processing coreand no hyper-threading.

7

3.2.1 Switching Among Threads

To control access to the processor, the scheduler must havea way to start, stop, and resume the execution of threadson a processor. This mechanism is known as a contextswitch. The thread that is removed from the processor willbe known as the outgoing thread and the thread that is beinggiven the processor will be called the incoming thread.

The first step in a context switch involves saving all theinformation or context that will be needed to later resumethe outgoing thread. This information must be saved sincethe incoming thread is likely to overwrite much of the con-text of the outgoing thread. Next the incoming thread’s con-text will be restored to the original state when it was paused.At this point, processor control will be turned over to the in-coming thread.

3.2.2 Choosing Threads

Each time the scheduler is invoked, it decides which threadto run next based on a number of criteria.

ready(competing forexecution time)

blocked

running(executing)

Figure 6. State diagram of a thread.

3.2.2.1 Thread States One scheduling consideration iswhether a thread can use the processor. At any given time,a thread is in one of three states (Figure 6). To explain thesestates, we will start with a thread that is not running butis ready to execute. At this point, the thread waits in the“ready queue” for the processor, and the thread is in a readystate and considered runnable. Once the scheduler selectsthe thread to execute, a context switch will occur. The cho-sen incoming thread will transition from the ready state tothe running state. The thread will then execute on the pro-cessor. While the thread is executing, the processor maybe taken away from the thread even though the thread hasnot completed all its work. This means that the thread willtransition back to the ready state. In a different scenario, a

thread in the running state may request some service, suchas, reading from a file, sending a network packet, etc. Someof the requests cannot be fulfilled immediately and the sys-tem must wait for a subsystem to complete the request.While the thread is waiting, the processor can be used byother threads. So, if the current thread cannot continue un-til the service is completed, the thread will transition to theblocked state. Once in the blocked state, the thread will notexecute. It is the job of the OS to change the thread from theblocked state to the ready state when the event for which itis blocked occurs.

3.2.2.2 Fairness With multiple threads on a system, onereasonable policy is to expect each thread to make similarprogress. The scheduler may attempt to provide fairnessamong the ready threads by choosing the one that receivedthe least amount of execution time in the recent past.

3.2.2.3 Priorities Providing fairness between allthreads is not appropriate when one thread is more im-portant or urgent than others. So, priorities are generallyutilized in real-time scheduling policies.

Under simple priority scheduling the highest prioritythread will occupy the processor for as long as it desires.This means that one thread can ‘lock up’ the system, caus-ing the system to be unresponsive to other lower priority,ready threads. Therefore, threads scheduled with prioritiesmust be programmed with caution.

When two threads have the same priority, the schedulercan choose a thread based on which thread arrived first. Un-der fifo scheduling, earlier arriving threads have higher pri-ority. Alternatively, with the use of round-robin schedul-ing, each thread at a given priority will be allotted a specificamount of time, known as a time slice. All threads at a givenpriority level will receive one time slice before any threadof that level receives additional time slices.

3.2.3 Regaining Control

The scheduler is the component that decides which threadswill be allocated the CPU. However, a question may ariseas to how the scheduler gets scheduled to obtain the CPU.

3.2.3.1 Voluntary Yield As mentioned earlier, a threadmay call the OS and request services. These calls, amongother things, allow a thread to become blocked and yieldthe processor to other threads. When the current thread be-comes blocked, the scheduler code will execute and chooseanother thread to use the processor.

3.2.3.2 Forced Yield If a thread does not voluntarilyyield the processor, we need to rely on other mechanismsfor the scheduler to regain control of the processor.

8

The typical way is through the use of interrupts. Inter-rupts are used to communicate between devices and the pro-cessor. The interrupts signal the processor that some eventhas taken place. When an interrupt is raised by some device,the processor that handles the interrupt transfers executionto the corresponding interrupt handler, or interrupt serviceroutine (ISR). An ISR can be thought of as similar to an-other thread on the system.

timer interrupt

thread A

thread B

time

Figure 7. Periodic timer interrupt.

To control the processor at some time in the future, theOS can program a timer interrupt, which is sent by a hard-ware component on the system. The timers are typically ca-pable of at least two modes of operation. The legacy mech-anism is periodic mode, where the timer will send interruptsrepetitively at a specified interval. Figure 7 shows an exam-ple of periodic mode. The periodic timer interrupt allowsthreads A and B to share the processor through the inter-vention of the scheduler. The other timer interrupt mode issometimes referred to as one-shot mode. In one-shot modethe timer is set to arrive some OS-specified time in the fu-ture. Once the timer expires and the interrupt is sent, the OSmust reset the timer in order for another timer interrupt tobe produced.

4 Basic Requirements for RT Implementa-tion

Using appropriate real-time scheduling analysis one canprovide a guarantee that timing constraints of a set of con-ceptual activities (e.g. tasks) will be met. This assump-tions that the analysis relies upon, must also be true froman implemented system. If the assumptions do not holdtrue for an implemented system, the guarantees made bythe scheduling analysis may no longer be valid. Whethera system can support a given theoretical model relies onthe system’s ability to perform accurate accounting of time,control the behavior of tasks, and to properly communicatetiming parameters as detailed in this section.

4.1 Time Accounting

The validity of schedulability analysis techniques de-pends on there being an accurate mapping of usage of theprocessor to the given workload in the theoretical model.We will refer to this mapping as time accounting. Dur-ing execution of the system, all execution time must staywithin the bounds of the model. For example in the peri-odic task model, if some time is used on the processor, thistime should correspond to some given task. Further, thistime should not exceed the task’s WCET. The proper ac-counting of all the time on a system is difficult. This sectionwill cover some of the more common problems that hindera system from performing proper time accounting.

4.1.1 Variabilities in WCET

The task abstraction requires that one know the WCET ofeach task. To determine the WCET of a task, one approachwould be to enumerate all possible code paths that a taskmay take and use the time associated with the longest exe-cution time path as the WCET. In simple system such as thatof a cyclic executive, this approach may work, but using aGPOS, this WCET would unlikely reflect the true WCETsince tasks on such systems could have additional complex-ities such as context switching, caching, blocking due to I/Ooperations, and so on. We will go over some common casesthat cause variabilities in a task’s WCET.

4.1.1.1 Context Switching Context switch overhead istypically small compared to the intervals of time a threadexecutes on a processor. However, if context switches oc-cur often enough, this overhead becomes significant andmust be accounted for in the analysis. Consider a job-levelfixed-priority system where jobs cannot self suspend. If thetime to perform a context switch is denoted as CS, then oneneeds to add 2CS to the WCET of each job of a task [42].The reason is that each job can preempt at most one otherjob, and each job can incur at most two context switches:one when starting and one at its completion. Similar rea-soning can be used to allow for self-suspending jobs whereeach self suspension adds two additional context switches.Therefore, if Si is the maximum number of self-suspensionsper job for task i, then the WCET should be increased by2(Si + 1)CS [42].

To include context switches in the analysis, one mustalso determine the time to perform a context switch. Ouster-hout’s empirical method [54] measures two processes com-municating through a pipe. A process will create a pipeand fork off a child. Then the child and parent will switchbetween one and other each repeatedly performing a readand a write on the created pipe. Doing this some number

9

of times provides an estimate on the cost of performing acontext switch.

Ousterhout’s method not only includes the cost of a con-text switch but also the cost of a read and a write systemcall on the pipe which in itself can contribute a significantamount of time. To factor out this time, McVoy and Staelin[48], measured the time of a single process performing thesame number of write and read sequences on the pipe asperformed by both processes previously. This measuredtime of only the system calls are subtracted from the timemeasured via Ousterhout’s method, thereby leaving only thecost of the context switches. This method is implementedin the benchmarking tool, lmbench [49].

4.1.1.2 Input and Output Operations Performing in-put and output operations during the time critical path of areal-time activity can create large variations in its servicetime. For example, accessing hard drives can last anywherefrom few hundred microseconds to more than one second.Determining the blocking time for accessing the device isnot only difficult, but can increase the worst-case comple-tion time (WCCT) of a task to such a point that the sys-tem becomes unusable. Further, the analysis of combin-ing I/O scheduling and processor scheduling becomes ex-tremely complex and starts to reach the limits of real-timescheduling theory [5].

Since large timing variances cannot typically be toleratedfor a real-time activity, it is common to ensure that these I/Ooperations do not occur in the time critical path. One wayis to perform I/O in a separate server thread. This allowsthe actions that deal with the I/O devices to be scheduledwith little interference on the real-time activities. Anotherapproach is to perform I/Os as asynchronous operations, al-lowing the real-time threads to continue without blockingwhile the submitted I/O operations are performed.

One must also be aware of indirect causes of I/O opera-tions. For example, the use of virtual memory allows a sys-tem to use more than the physical RAM on the system bystoring or swapping out currently unused portions of mem-ory on secondary storage (e.g. hard disk). However, this cancause large increases in the WCCT of a real-time activity bydelaying access to data stored in the memory. If this WCCTis exceeded, the timing guarantees of the scheduling the-ory will be invalidated. Fortunately, many GPOSs realizethe consequences of these swapping effects on time- criticalactivities and therefore provide APIs that prevent memoryfrom being relocated to secondary storage (e.g., POSIX’smlock set of APIs [29]).

Even when memory pages are not swapped to secondarystorage, virtual memory address translation still takes someamount of time. This concern is addressed by Bennett andAudsley [8] by providing time bounds for using virtual ad-dressing.

While it is not common for real-time systems to allowswapping, Puaut and Hardy [57] have provided support topermit the use of swapping real-time pages. At compiletime, they select page-in and page-out points that providebounded delays for memory access. The drawback is thathardware and software support is required in order to pro-vide the implementation, which may not be available.

4.1.1.3 Caching and Other Processor OptimizationsThe number of instructions, the speed to execute these in-structions, caching, processor optimizations, etc. can in-troduce extremely large variabilities in the time to exe-cute a piece of code. As processors become increasinglycomplicated, the difficulty in determining accurate WCETsalso becomes more complicated. Many difficulties arisefrom instruction-level parallelism in the processor pipeline,caching, branch prediction, etc. These developments makeit difficult to discover what rare sequence of events inducesthe WCET.

Given code for an application, there are generally threemethods used to determine the WCET [53, 79]: compilertechniques [2, 26], simulators [52], and measurement tech-niques [40]. These methods can be effectively used togetherto take advantage of the strengths of each. For example,RapiTime [44, 45], a commercially available WCET analy-sis tool, combines measurement and static analysis. Staticanalysis is used to determine the overall structure of thecode, and measurement techniques are used to establish theWCETs for sections of code on an actual processor.

4.1.1.4 Memory Theoretical analysis generally relieson the WCET of one task not being affected by another task.In practice, this affect on WCET is typically not true due tocontention for memory bus access. With a uniprocessor thecaching effects between one application and another mayaffect the execution time when context switching; however,this is typically taken into account in the WCET. Now asthe trend is toward more processors per system, not onlyis caching an issue, but also the contention for access tothe memory bus. What processes are concurrently access-ing which regions of memory can greatly affect the time tocomplete an activity. When one process accesses a region ofmemory this can effectively lock out another process, forc-ing that process to idle its processor until the particular re-gion of memory becomes available. Further, processes arenot the only entities competing for memory accesses, pe-ripheral devices also access memory, increasing the mem-ory interference and making WCETs even more uncertain[56, 66].

10

4.1.2 System Workloads

When implementing tasks on top of a GPOS, system work-loads may be created in order to support applications. Theseworkloads contribute to the proper operation of the system,but do not directly correspond to work being performed.Further, since they may not be the result of any particulartask, they do not fit into any of the task’s execution timesand can be easily overlooked. The problem is that the pro-cessor time used by the system competes with the time usedby the tasks. Without properly accounting for this time inthe abstract model, these system workloads can ‘steal’ ex-ecution time from other activities on the system, therebycausing missed deadlines.

4.1.2.1 Scheduling Overhead The scheduler deter-mines the mapping of tasks to processors. In order toperform this task, it uses processor time. In a GPOS,the change of task assignments to CPUs occurs when thescheduler is invoked from an interrupt or when a task self-suspends/blocks. The timer hardware provides interrupts toperform time slicing between tasks as well as other timedevents. Katcher et. al [37] describe two types of schedulinginterrupts, timer-driven and event-driven.

Tick scheduling [11] occurs when the timer periodicallysends an interrupt to the processor. The interrupt handlerthen invokes the scheduler. From here, the scheduler willupdate the run queue by determining which tasks are avail-able to execute. Any task that has release times at or beforethe current time will be put in the run queue and able tocompete for the CPU at its given priority level. Perform-ing these scheduling functions consumes CPU time whichshould be considered in the schedulability analysis. Over-looking system code called from a timer can be detrimentalto the schedulability of a system because timer handlers canpreempt any thread, regardless of the thread’s priority ordeadline.

4.2 Temporal Control

Temporal control ensures that the enforcement mecha-nisms in the implementation correctly adhere to the real-time models used in the analysis. For the processor, thisincludes the system’s ability to allocate the processor to agiven activity in a timely manner. For example, when a jobwith a higher priority than that of the one currently execut-ing on the processor is released (arrives), the preemptivescheduling model says the system should provide the pro-cessor to the higher priority job immediately. However, inpractice this is not always possible.

4.2.1 Scheduling Jitter

Scheduling points are events where the scheduler evaluateswhat tasks should be assigned to which CPU. In an idealscheduling algorithm scheduling actions take place at theexact points in time when some state in the system changescausing the mapping of threads to CPUs to change. In aGPOS, the scheduling points are the points in time when theCPU scheduler is invoked, such as when a task completesone of its jobs and therefore self-suspends, or the systemreceives an interrupt.

The difference between the ideal scheduling points in anabstract scheduling algorithm and that of the CPU scheduleris commonly called scheduling jitter. If a job is set to arriveor become runnable at time τ1, but is not recognized by thesystem until time τ2, the scheduling jitter is τ2 − τ1.

Minimizing scheduling jitter is important in real-timesystems. Generally, the smaller the scheduling jitter, thebetter the theoretical results can be trusted to hold on theimplemented system.

4.2.2 Nonpreemptible Sections

Another common problem in real-world systems is that ofnonpreemptible sections. A nonpreemptible section is afragment of code that must complete execution before theprocessor may be given to another thread. Clearly, a longenough nonpreemptible section can cause a real-time taskto miss its execution time window. While accounting fornonpreemptible sections in the schedulability analysis isnecessary for guaranteeing timing guarantees, it is gener-ally preferable to design such that nonpreemptible sectionsare avoided as much as possible. The reason is that non-preemptible sections increase the amount of interference agiven task may encounter, potentially making the systemunschedulable.

4.2.3 Non-unified Priority Spaces

When a device wishes to inform the CPU of some event, thedevice will interrupt the CPU, causing the execution of aninterrupt handler. The interrupt handler is executed imme-diately without consulting the system’s scheduler, creatingtwo separate priority spaces: the hardware interrupt prior-ity space and the OS scheduler’s priority space, of which,the hardware interrupt scheduler always has the higher pri-ority. Therefore, any interrupt handler, regardless of prior-ity, may preempt an OS schedulable thread. The fact thatall interrupts have higher priority than all OS schedulablethreads, must be modeled as such in the theoretical analy-sis. The more code that runs at interrupt priority the greaterthe amount of interference an OS schedulable thread mayexperience, potentially causing OS threads to become un-schedulable.

11

4.2.4 Temporal Isolation

Exact WCETs can be extremely difficult to determine inmany cases, therefore, only estimated WCETs may be spec-ified. If a given task overruns their allotted time budgetdue to their exact WCET being longer than the specifiedWCET, one or more other tasks may also miss their dead-lines. Rather than all tasks missing their deadlines, it is gen-erally preferable to isolate the failure of one task from othertasks on the system. This property is known as temporalisolation.

4.3 Conveyance of Task/Scheduling Policy Se-mantics

For an implemented system to adhere to a given theoreti-cal model, one must be able to convey the characteristics ofthis model to the implemented system. To perform this ina GPOS, it is common to provide a set of system interfacesthat inform the system of a task’s parameters.

For example, consider the periodic task model sched-uled with fixed-priority preemptive scheduling. Each taskis released periodically and competes at its specified prior-ity level until its activity is completed. If a periodic taskabstraction were available directly in a given OS, then thetheoretical model could easily be implemented. However,in GPOSs such interfaces typically do not exist.

However, many systems adhere to the POSIX operat-ing systems standards, which support real-time primitivesto allow for implementation of a periodic task model sched-uled using fixed-priority preemptive scheduling. These in-terfaces include functions for setting a fixed priority to athread and allowing a thread to self-suspend when a job iscompleted, which map from the task model to the imple-mentation.

These types of interfaces are critical for applications toconvey their intentions and constraints to the system. Theyinform the OS of the abstract model parameters in orderfor the OS scheduler to make decisions that match the idealscheduler. Lacking this information, the OS may make im-proper decisions, resulting in tasks missing their deadlines.

5 Device Drivers

Devices are used to provide system services such assending and receiving network packets, managing storagedevices, displaying video, etc. The number of these ser-vices is small compared to the variety of hardware compo-nents, which are produced by a multitude of vendors, eachwith many distinct operating characteristics. For instance,sound cards provide a means to produce audio signals. Theuser will typically provide the audio signal in a digital for-mat to the sound card and the sound card will output ananalog audio signal that can be converted to sound waves

through a speaker. However, to produce sound from anapplication, interaction between the system and the soundcard must occur. Due to the many different features, com-ponents, and designs of the different cards, specifics (e.g.,timings, buffers, commands) by which communication withthese cards occurs is typically different depending on themanufacturer or even model. To ease the use of devicessuch as sound cards, OSs abstract much of the hardwarecomponent complexity into software components known asdevice drivers, which are typically provided by the devicemanufacturer. Therefore, instead of having to know the par-ticulars of a given device, the application or OS can com-municate generically with the device driver and the devicedriver, having knowledge of the device specifics, can com-municate with the actual device.

Using device drivers in a real-time system complicatesthe process of guaranteeing deadlines. These devices sharemany of the same resources used by the real-time tasks andcan cause interference when contending for these resources.Further, many device drivers are used in the critical path ofmeeting deadlines. Therefore, device driver activity mustbe included in the schedulability analysis. The difficulty isthat the device driver workloads generally do not conformto well understood real-time workload models.

5.1 CPU Time

The CPU usage of device drivers tends to be differentfrom other real-time application tasks, and therefore fittingthe usage of CPU time into known, analyzable real-timeworkload models can be awkward. Trying to force usageinto these models tends either be invalid due to lack of OScontrol over scheduling, inefficient due to the limited num-ber of implementable scheduling algorithms, or impracti-cal due to large WCETs being used for the analysis eventhough average case execution times may be much smaller.Further, many of the scheduling mechanisms created foruser-space applications do not extend to the device drivers.That is, the explicit real-time constructs such as pre-emptivepriority-driven resource scheduling, real-time synchroniza-tion mechanisms, etc. are not typically available to or usedby device drivers.

This section will enumerate some of the temporal effectsassociated with device drivers and show why these can hin-der the proper functioning of a real-time system. We willsee how using I/O devices in a system increases the time ac-counting errors, reduces the amount of control over systemresources, and leads to incompatibility with existing work-load models.

5.1.1 Execution

Device drivers consume system resources and, therefore,compete with other activities on the system, including real-

12

time tasks. The contended-for system resources includeCPU time, memory, and other core components of the sys-tem. For example, consider a network device driver. Theend user expects a reliable, in-order network communi-cation channel. The sending and receiving of basic datapackets is handled by the card. However, execution onthe processor is required to process the packets, whichincludes communicating with the network card, handlingpacket headers, and dealing with lost packets.

Since device driver CPU usage competes with real-timetasks, the CPU time consumed must be considered in theschedulability analysis. The CPU usage due to devicedrivers may seem negligible for relatively slow devices suchas hard disks. The speed differences between the processorand the hard disk should mean that only small slivers of timewill be taken from the system. Unfortunately, the competi-tion from some other device drivers for CPU time signifi-cantly impacts the timeliness of other activities on the sys-tem. The device driver overhead can be especially large forhigh bandwidth devices such as network cards. Accordingto [40], the CPU usage for a Gigabit network device drivercan be as high as 70%, which is large enough to interferewith a real-time task receiving enough CPU time before itsdeadline.

The problem of device drivers interfering with real-timetasks is not likely to diminish over time. Devices are be-coming faster and utilizing more system resources. One ex-ample is the replacement of solid-state storage for hard diskdrives. The solid-state devices are much faster and can cre-ate significantly more CPU interference for other activitieson the system.

To better understand the problems with device drivers inthe context of real-time scheduling, we will first look at themanner in which these components consume CPU time andhow this can affect the ability of a system to meet timingconstraints.

Stewart [75] lists improper accounting for the use of in-terrupt handlers as a common pitfall when developing em-bedded real-time software. Interrupt handlers allow devicedrivers to obtain CPU time regardless of the OS’s schedul-ing policy. While scheduling of application threads is car-ried out using the OS scheduler, the scheduling of interrupthandlers is accomplished through interrupt controllers typi-cally implemented in hardware. Interrupts effectively createa hierarchy of schedulers, or two priority spaces, where allinterrupts have a priority higher than other OS schedulablethreads on the system.

Interrupts prevent other activities from running on thesystem until they have completed. While an interrupt is be-ing handled, other interrupts are commonly disabled. Thisproduces a blocking effect for other activities that may ar-rive on the system. Until interrupts are re-enabled, no otherthreads can preempt the currently executing interrupt han-

dler. Therefore, if a high-priority job arrives while inter-rupts are disabled, this job will have to wait until the in-terrupt completes, effectively reducing the time window thehas to complete its activities.

Since device drivers typically use interrupts, some, if notall, of the device driver processor time is out of the controlof the OS scheduler. [62] pointed out that device drivers canin effect “steal” processor time from real-time tasks. Thistime stolen by device drivers can cause real-time tasks tomiss their deadlines. In order to illustrate and quantify thisstolen time, Regehr [60] describes how an application-levelthread can monitor its own execution time without specialOS support, in the implementation of a benchmark appli-cation program called Hourglass. In Hourglass, a syntheticreal-time thread, which we call an hourglass thread, moni-tors the amount of processor time it consumes over a giventime interval. The thread needs to measure the amount ofprocessor time it receives, without the help of any OS in-ternal instrumentation. This is difficult because processorallocation is typically broken up due to time slicing, inter-rupt processing, awakened threads, etc., and the endpointsof these intervals of execution are not directly visible to athread. An hourglass thread infers the times of its transitionsbetween executing and not executing, by reading the clockin a tight loop. If the time between two successive clock val-ues is small, no preemption occurred. However, if the differ-ence is large, then the thread was likely preempted. Usingthis technique to determine preemption points, an hourglassthread can find the start and stop times of each executioninterval, and calculate the amount of processor time it re-ceives in that interval. Knowing the amount of executiontime allows hourglass threads to emulate various real-timeworkload models. For example, periodic workloads can beemulated by having the hourglass threads alternate betweenstates of contention for the processor and self-suspension.More specifically, a periodic hourglass thread contends forthe processor until it receives its nominal WCET, and thensuspends itself until the beginning of its next period. Thethread can also observe whether its deadlines are met ormissed.

Given that interrupts interfere with real-time applica-tions, interrupt service time must be included in the analysisof schedulability. [65] considered the problem of includ-ing interrupt executions whose arrival times are not knownin advance with other tasks scheduled by a static scheduleconstructed offline. The naive approach pointed out by [65]is to include the interrupt WCET into the execution timesof all tasks on the system. However, using this mechanismis typically pessimistic and can reduce the ability to provethat a system is schedulable. Instead of adding the WCETto each task, [65] considers only adding the WCET to a taskchain, which is a number of tasks that are always executedsequentially. The WCET of the interrupts is considered as

13

that of a higher-priority task which is considered to arrive atthe start time of the chain. The point where the task chain isreleased is a critical instant and schedulability can then becalculated for all tasks in the chain.

Another way to include device driver CPU time inschedulability analysis is to consider interrupt execution asa task. To do this in a fixed-priority system, one couldmodel the interrupt as a sporadic task, with the executiontime being the interrupt handler’s WCET and the period be-ing the smallest time between the arrivals of two subsequentinterrupts. The priority of this interrupt task would need tobe modeled as higher than any other task on the system,due to the nature of the built-in hardware scheduling mech-anisms of interrupts. However, modeling the interrupts as atask with highest priority in the system may not be consis-tent with all scheduling algorithms. For instance, in an EDFscheduled system the work performed by the handler for theinterrupt may have a logical deadline further in the futurethan other jobs. Therefore, according to the EDF schedul-ing policy, the interrupt should logically have a lower prior-ity than jobs with earlier deadlines, but in fact will have ahigher priority, violating the rules of the scheduling policy.Further, executing interrupts at a real-time priority may notbe required. If the interrupts are not needed by any real-time task on the system, it may make sense, if possible, toschedule the interrupt execution as the lowest priority on thesystem, or with other non-realtime tasks.

One possibility to gain some control over interrupts isthrough interrupt enabling and disabling. This can be ac-complished by disabling interrupts whenever a logicallyhigher-priority task begins execution and re-enabling inter-rupts when no higher-priority tasks exist. This provides onepossibility for interrupt priorities to be interleaved with thereal-time task priorities.

However some interrupt handlers have hard real-time re-quirements of their own, which demand a high priority. Forexample, some devices require service from the CPU in abounded amount of time and without acknowledgment fromthe CPU, the device may enter an unstable state or eventsmay be lost. Other effects such as idling the device mayoccur. This can greatly reduce the utilization of certain de-vices. Consider the hard disk device. Once a request tothe hard disk is completed, new requests, if any, should bepresented to the hard disk to prevent idling. Idling a harddisk is normally unacceptable due to the relatively long ser-vice times. If the hard disk is unable to query the processorabout another request via interrupts, the disk may becomeidle, wasting time that could be used to service requests.

The OS scheduler is not always able to provide con-trolled access to shared resources (e.g. data structures) usedinside interrupt handlers, therefore other mechanisms areneeded to ensure proper access of these shared resources.One common protection mechanism is to disable the in-

terrupt that may violate the access restrictions to sharedresources, thereby preventing the interrupt handler execut-ing. Disabling a single interrupt rather than all interrupts isknown as interrupt masking and is typically accomplishedby setting a bit in the corresponding interrupt controller reg-ister [30]. This approach, if done correctly, can be usedto provide correct mutually exclusive access to shared re-sources, but introduces the issue of priority inversion due tolocking [39, 69].

Interrupt masking introduces CPU overhead, since ma-nipulating the registers of the interrupt controller typicallyinvolves off-chip access and cause effects such as pipelineflushes. Given that very few interrupt attempts occur duringthe periods of masked interrupts, [76] proposed optimisticinterrupt protection, which does not mask the interrupts us-ing the hardware. To maintain critical sections, a flag isset that indicates a critical section is being entered, and itis cleared at the end of the critical section. If a hardwareinterrupt occurs during the critical section, an interrupt han-dler prologue will note that an interrupt has occurred, savethe necessary system state, and update the hardware inter-rupt mask. The interrupted code will then continue. At theend of the critical section, a check will be performed forany deferred interrupts. If one does exist, the correspondinginterrupt routine will then be executed.

In addition to maskable interrupts, systems may alsocontain non-maskable interrupts (NMIs) which must be in-cluded in the schedulability analysis. To complicate mat-ters, some NMIs are handled by the BIOS firmware and donot travel through the OS. The most common form of NMIshandled by the BIOS are known as System ManagementInterrupts (SMI) and can cause added latency to activitieson the system [82]. It is important in a real-time system thatone be aware of, and account for if necessary, the time takenby SMI activities.

Discretion must be used when performing computationsinside interrupt handlers. For instance, Jones and Saroiu[34] provided a study of a soft modem. This study showsthat performing the signal processing required for the softmodem in interrupt context is unnecessary and can preventother activities on their system from meeting their dead-lines. Therefore, one should minimize the amount of pro-cessing time consumed by interrupts and consider otherpossibilities.

Interrupts are not the only way to synchronize a periph-eral device and the CPU. Instead, the processor can pollthe device to determine whether an event has occurred. In-terrupts and polling each have their own merits which arediscussed below.

Interrupts allow the processor to detect events such asstate changes of devices without constantly having to usethe processor to poll the device. Further, with interruptnotification the time before detecting an event is generally

14

shorter than with polling, since the delay is only due to thesignal transmission from the device to the CPU (assumingthe interrupt is enabled). While this delay is non-zero, it isvery small and generally intrinsic to the hardware design.With polling the elapsed time for noticing an event can beas much as the largest interval between polls.

On the other hand, with polling, the processor communi-cates with the device at a time of the processor’s choosing.The querying of the device can occur at a time that does notinterfere with higher-priority tasks. The task that queries thedevice can be under the direct control of the system’s sched-uler, thereby providing much more flexibility for schedulingdevice-CPU synchronization activities.

Interrupt execution can potentially consume all of theCPU time. This phenomenon, known as interrupt over-load, is pointed out by Regehr and Duongsaa [61]. Inter-rupt overload occurs when interrupts arrive at such a ratethat the interrupt processing time used starves other activ-ities on the system (including the OS scheduler). Severalsituations may cause an unexpectedly high interrupt rate.One is a faulty device continuously sending interrupts, alsoknown as a stuck interrupt. Another is a device that canlegitimately send interrupts at high rates. In either case, ser-vicing each interrupt as it arrives can starve other activitieson the system.

One device with a high maximum arrival rate of inter-rupts is the network card. When a packet arrives, the sys-tem would like to be informed in order to wake up and/orpass packets to threads waiting for information from the net-work. A low response time for noticing this event is desiredbecause there may be high-priority tasks awaiting the data,and delaying the delivery will increase the tasks’ responsetime, possibly causing missed deadlines.

As long as interrupts are infrequent, and their handlerstake a small amount of time, the impact on the system maybe considered negligible. However, the increase in perfor-mance of the newer gigabit and higher ethernet cards hasthe side effect of also increasing the maximum number ofinterrupt arrivals to a rate that can consume significant por-tions of CPU time. This means that the danger of interruptoverload is present on systems with these devices. For in-stance, the interrupt arrival rate of a gigabit ethernet devicecan be nearly 1.5 million per second [36, 61]. This arrivalrate can overwhelm the processor with handling interruptsand leaves little or no time to perform other activities on thesystem.

To address the problem of interrupt overloads, [61] pro-posed to rate-limit interrupts via intelligently enabling anddisabling interrupts. This mechanism will either delay in-terrupts or shed the interrupt load by dropping excessiveinterrupts to ensure that thread-level processing can makeprogress and not be blocked for extended periods of timedue to a malfunctioning hardware device. The first ap-

proach enforces a minimum interarrival time between sub-sequent interrupts. The second approach caps the maximumnumber of interrupts in a given time interval. These so-lutions only count the number of interrupts arriving ratherthan calculating the actual amount of processor time the in-terrupts use, since counting incurs lower overhead. Also,for simple systems, the execution time of any given inter-rupt handler is nearly constant. On systems where the exe-cution time of interrupt handlers can vary widely or wherethe execution time depends on the state of the processor,counting interrupts alone may be insufficient.

In the context of network cards, [50] provides anothersolution to throttle interrupts. One key observation is thatwhen the first receive interrupt arrives (signaling a packethas been received), the second receive interrupt is not usefuluntil the first packet has been processed. Therefore, withoutcompletion of the first packet, the second interrupt and fur-ther interrupts are only informing the system of somethingit already knows, that is, the device needs attention. There-fore, [50] proposes to switch between interrupt and pollingmodes dynamically, so, once one interrupt arrives from thenetwork device, interrupts are disabled. The work requiredto service the network device will then be performed out-side the interrupt handler, typically in a schedulable thread.That thread will poll, querying the network device for workto perform once the previous unit of work has been com-pleted. Once the network device has no further work toperform, the interrupts for the network device will be re-enabled and the receive thread will suspend itself, perform-ing the transition back to interrupt mode and out of pollingmode.

To provide some control over hardware interrupts, hard-ware platforms such as the Motorola 68xxx series and someof the newer x86 microprocessors [31], provide the abilityto set priorities for interrupt handlers within the same pri-ority space as the system’s schedulable threads. The OS isable to set a priority value for each interrupt. The OS thensets a priority value for the currently running thread. Whenan interrupt arrives to the interrupt controller, if the inter-rupt priority value is greater than that of the currently exe-cuting thread, then the processor will be interrupted. Other-wise, the interrupt processing must wait until the currentlyrunning thread’s priority drops to a value below that of theinterrupt. Assigning priorities for interrupts does alleviatesome of the problems with interrupts. However, this mech-anism is not available on all hardware platforms and doesrequire OS support.

While servicing a particular interrupt it is common todisable other interrupts, preventing any other task or inter-rupt handler from executing. To schedule the work of the in-terrupt handlers more effectively, it would be advantageousto put their execution under the control of the OS’s sched-uler [38], rather than allowing them to execute in a separate

15

priority space. This can be accomplished if the interrupthandlers are made into OS schedulable threads, thereby re-moving the restriction of interrupts being modeled as thehighest-priority threads on the system. While this approachdoes simplify the scheduling of activities on the system,it typically increases the system’s overhead. Further, it iscommon for the interrupt mechanisms to be highly opti-mized due to hardware support for switching into and outof interrupt-level processing, so that the dispatching of in-terrupt handlers can happen much faster than dispatchingof a user-space thread. For that reason, [27] proposes toconvert all threads into interrupts, thereby allowing the in-terrupt hardware to handle all the scheduling. This seems towork well on embedded systems with a limited number ofthreads. However, it is unclear whether this approach wouldscale to systems with larger number of threads.

5.1.2 Accounting

Another challenge of scheduling device driver CPU time isproper time accounting, or attributing consumed CPU timeto a given entity. This entity commonly corresponds to atask in the theoretical models. A thread is typically used toimplement a task in a real-time system. This thread con-sumes CPU time in order to accomplish its given activi-ties. Ideally, only the time the thread logically uses shouldbe charged to the thread. Accurate accounting allows thescheduler to make correct scheduling decisions. If a threadis undercharged, this may result in one thread getting morethan its correct share of the CPU resource, potentially caus-ing missed deadlines for other threads. Conversely, if thethread is overcharged, this may result in the overchargedthread not receiving its required CPU time needed to com-plete necessary activities by a given deadline.

Without improper time accounting, device driver timemay be charged to the unlucky process that happened tobe executing when the device driver begins execution. Oneproposed solution provided by [62] uses fine-grained timeaccounting in order to ascertain the amount of stolen time.This time can then be provided to the OS scheduler, allow-ing it to ensure that the affected threads are compensatedand receive their allocated time.

Device driver activity occurs in many different contexts.In one context an application invokes the device driver, byrequesting service from the OS through the system call in-terface. For example, sending a network packet will typ-ically involve a system call, which, in turn, will call thedevice driver that will send the packet. This call to the de-vice driver consumes processor time, but since the call orig-inates from a thread’s context this time can be legitimatelyattributed to the application thread that sent the packet, andmodeled for the purposes of schedulability analysis as partof the same task as that thread. So, such user-initiated de-

vice driver activity does not require the introduction of anyadditional tasks to the workload model or special time ac-counting.

However, device driver activity may also occur in con-texts that do not have any immediate association with a par-ticular user-level thread. For instance, upon arrival of data ata network interface, the received packet must be processedby the network device driver and network protocol stackbefore the system can determine the user-level thread thatshould receive the packet. This device-driver execution istypically triggered by a hardware interrupt. It is not obvi-ous how to map such device-initiated device-driver activityto the tasks of a workload model for the purpose of timeaccounting and schedulability analysis. Most logically, itought to be attributed to conceptual sender tasks. Alterna-tively, it might be modeled by a system I/O server task, or bya mapping to the application-level tasks that are the ultimaterecipients of the packets (if the recipient is known). Thesesolutions present various difficulties for schedulability anal-ysis, and none of them matches very well the way thatdevice-initiated device-driver activities are typically sched-uled and accounted for within operating systems today.

For received network packets, determining the destina-tion process as early as possible can improve the properallocation of CPU time to all processes on the system, asdescribed in [16]. Determining the destination as early aspossible allows CPU and memory resources to be allocatedfairly between processes on the system. In order to demulti-plex early, it is ideal for this processing to take place on thenetwork interface card, thereby acquiring enough informa-tion to ensure that any further processing takes place in thecontext of the thread waiting on the packet, and is chargedto the correct thread. Unfortunately this functionality is notavailable in many network cards and so CPU time must beconsumed to determine the destination thread. [16] pro-poses to perform demultiplexing of packets in the interrupthandler, allowing the recipient to be determined early andallowing further processing to be charged to the receivingthread.

For the purpose of schedulability analysis, it is prefer-able to schedule the execution of all device driver activitiesin a way that allows them to be attributed to applicationthreads. Zhang and West [83] sought to associate the pro-cessor time consumed by device-initiated device-driver ac-tivities with threads that utilize the device-driver services.A logical consequence is that the device-driver processingshould take place at the priority of an associated receiverthread, and be charged to that thread. However, in the pre-vious example of receiving a network packet, at the timethat device driver activity occurs, it is often not yet clearwhat thread will be receiving the service. The receiver canonly be determined after processor time has been consumedto demultiplex the packet. To solve this problem, [83] ex-

16

ecutes the device-driver code at the highest priority of allthe threads waiting on its services. Then, once the receivingthread has been determined, the time used by the device-driver is back-charged to that process. This allows moreaccurate accounting and control of device-driver execution.However, device-driver execution time is not always relatedor attributable to any application thread. For instance, de-vice driver execution may be due to system maintenanceoperations or external events that turn out to not have anyappropriate recipient thread. Further, even if an appropriaterecipient thread is found, back-charging processor time af-ter a thread has already executed can potentially violates theassumptions of scheduling theory (e.g. a low priority threadpreempting a higher priority thread).

Lewandowski et al. [40] proposed a way to character-ize the worst-case processor workload generated by a net-work device driver. This characterization of the proces-sor usage provided a workload model that could then beused in schedulability analysis. The device driver work-load is characterized by an empirically derived demand-bound function. Demand is the amount of processor timea given task can consume over a given sized time interval.To determine the worst-case demand of a device driver, onepresents the system with an I/O workload that is believedto cause the device driver to consume the maximum pos-sible amount of processor time. Then, using a techniquesimilar to Hourglass (described above), one measures theobserved maximum amount of processor time consumed bythe device driver over a time intervals of size ∆ over multi-ple experiments, for various values of ∆. These data pointscan then be used to approximate a demand bound function.To provide a simple and more intuitive measure of proces-sor usage, the concept of load was introduced. If f(∆) is aprocessor demand bound function the corresponding load isf(∆)/∆. In other words, the load of a device driver is themaximum percentage of the processor required to servicethe device driver over a given interval length. Therefore,determining the schedulability of a task for a uniprocessorsystem involves ensuring for a ∆ equal to the deadline, thatthe load of all higher-priority tasks plus the task itself doesnot exceed 100%. This provides a technique to includedevice-driver workloads into schedulability analysis. Thetechnique addresses the two limitations mentioned for theZhang and West [83] approach above, but has its own limi-tations. In particular, it is based on empirical estimation ofworst-case processor demand of a device driver, measuredunder the conditions of a synthetic benchmark application.

The problem of characterizing the processor workloadsof device-initiated device-driver activities, in a way thatsupports whole-system schedulability analysis, continues tobe a challenge.

Many other issues arise when trying to account for re-sources consumed by device drivers. These include cases

where multiple processes are responsible for a single devicedriver’s activity. In these cases it becomes unclear whichprocess should be charged for the device driver CPU timeconsumption. Further, it may be that device driver process-ing occurs at a higher priority than is permitted by the the-oretical model being used to analyze the system schedula-bility. In this instance, charging the particular thread for thetime may be an accurate reflection of reality, but it may stillbreak the theoretical assumptions, meaning the timelinessguarantees made by the theoretical analysis are no longervalid.

5.1.3 Control

Even with accurate CPU time accounting there may still beissues related to matching an implemented system to a the-oretical model. Since device driver activity can be aperi-odic and bursty (e.g., packet interrupt arrival times), it canbe difficult matching this activity to any known, analyzableworkload model.

Fortunately, a class of algorithms known as aperiodicservers have been developed for these aperiodic and burstyworkloads. Aperiodic servers force the service of unwieldyworkloads into common simple workload abstractions. Infixed-priority systems, the periodic (polling) server [68],deferrable server [77], and sporadic server [70] all provideways to bound and characterize the service demands of ape-riodic workloads. Similarly for deadline-based schedulingaperiodic servers exists such as deadline sporadic server[18], constant bandwidth server [1], and total bandwidthserver [71]. Using these servers allows one to take exe-cution workload arrival patterns that may have no apparentor viable abstract model and schedule their service in a waythat allows the workload to be analyzed as a periodic task.

Lewandowski et al. [40] proposed to use the sporadicserver scheduling algorithm to schedule device driver activ-ity. Using sporadic server scheduling provides a mechanismto bound the maximum amount of CPU time that a givendevice driver is able to consume within any given time in-terval. That is, if one is able to obtain an estimate of themaximum execution time over a given time interval the de-vice driver can consume, the sporadic server can be usedto force the device driver activity to never exceed the thisestimate. This is especially important for job-level fixed-priority systems since high-priority device driver activitycan potentially consume all the available CPU time.

Using aperiodic servers to schedule device-driver activ-ity works well on systems that have precise scheduling con-trol. Control here is the degree of precision with which thescheduling mechanisms are able to start and stop threadson the system. For instance, many OSs operate on a tick-driven mechanism where the scheduler is invoked on a peri-odic basis. Therefore, the scheduler can only be guaranteed

17

request a

request b

request c

(a) disk requeststime

da db dc

(b) EDF scheduling of disk requeststime

da db dc

(c) improved scheduling of disk requests

Figure 8. Scheduling disk requests.

to start and stop threads when the tick occurs. This tickpreempts the running code allowing the scheduler to reeval-uate and decide the subsequent task that should be runningon the CPU. When the tick’s period is relatively large, thecontrol of the scheduler is very coarse. Imagine a threadreleased just after the scheduler returns from being invokedby the tick and that this thread has a higher priority thanthe currently running thread. In this instance, if the cur-rently running thread does not voluntarily yield, then thehigher-priority thread will have to wait until the next tick toarrive in order to begin execution on the CPU. This delaysthe higher-priority task’s execution and shortens the time toits deadline.

Without the proper control, the effectiveness of aperiodicservers is limited. Further, without precise control it is pos-sible that a given thread can overrun its allocated CPU time,or budget. Several papers have addressed this problem.Ghazalie and Baker [18] present a mechanism whereby thisoverrun time is charged against future time that the serverwill receive. This mechanism was also adapted in [73] tohandle overruns in the POSIX’s version of sporadic server.

CPU control aids in forcing the execution patterns of im-plementations to adhere to the theoretical models. This isimportant because these theoretical models are what pro-vide the foundation for timeliness guarantees. While itmay be difficult for implementations to provide exact com-pliance with a given theoretical model, it is important tocome as close as possible. Minor discrepancies can be ac-counted for by tweaking the theoretical model (e.g., task pa-rameters). However, if the discrepancies get too large, theamount of tweaking may lead to a significant reduction inthe number of tasks that can be assured schedulable becauseof additional tweaking terms that must be added or will cre-ate a system that deviates from the theoretical assumptionsand therefore meeting deadlines will not be guaranteed.

5.2 I/O Scheduling

Ensuring that the device driver CPU time consumption ismodeled correctly is important, but is not the only consid-eration in order to provide timely services. Another impor-tant aspect of device drivers is that they arbitrate access toa given device and therefore act as I/O schedulers. There-

fore, to ensure timely service the scheduling of the device’sresource by the device driver must be properly handled.

5.2.1 Device Characteristics

Scheduling I/O devices is different than scheduling CPUs.I/O devices tend to be non-preemptible, have service timesthat vary substantially between the worst-case and the aver-age case, and have physical characteristics that make pre-dicting I/O service times difficult. These characteristicsmake it problematic to guarantee timing constraints fortasks that use I/O devices.

As an example consider a hard disk scheduled using theEDF scheduling algorithm. The EDF scheduling algorithmworks well on a uniprocessor, providing a 100% CPU uti-lization bound for guaranteeing timing constraints of tasksets. However, using EDF scheduling on a hard disk de-vices tends to provide results far from optimal in terms ofboth efficiency and meeting timing constraints. Figure 8 il-lustrates the difficulty of scheduling disk requests with EDF.In this figure, we will assume a very simplified disk wherethe time to read one track takes one time unit and the time tomove to an adjacent track takes one time unit. Requests a, b,and c each read one track and have corresponding deadlinesda, db, and dc as shown in figure 8b. Scheduling the diskrequests according to the EDF scheduling policy results inpoor throughput of the disk, as well as, a missed deadline.Scheduling requests in the order of a, c, b, achieves betterthroughput and no missed deadlines as shown in figure 8c.Based on the poor performance of EDF to schedule diskrequests, various modifications to the EDF scheduling algo-rithm have been proposed.

SCAN-EDF [59] is a variant on the EDF scheduling al-gorithm. This algorithm first services requests in EDF or-der and services requests with the same deadline accordingto the a SCAN elevator algorithm. The SCAN algorithmservices all requests in one direction (e.g. lowest addressto highest address) and then services the remaining requestsin the other direction (e.g. highest address to lowest ad-dress). Using the SCAN algorithm reduces the amount ofseek time required to service a batch of requests. The ef-fectiveness of SCAN-EDF relies on many requests havingthe same deadline to increase the efficiency of the hard disk

18

service. Without having requests with the same deadline,the throughput provided by SCAN-EDF is poor.

To overcome the deficiency that the throughput is de-pendent on requests having the same deadline, [13] pro-poses Deadline-Modification-SCAN (DM-SCAN). DM-SCAN first orders requests in EDF order as in SCAN-EDF.However, to maximize the number of requests with the samedeadline, DM-SCAN creates groups of tasks that can be ser-viced in SCAN order without missing any deadlines and as-signs modified deadlines to each task in the group so eachtask has the same deadline.

The guarantees for both DM-SCAN and SCAN-EDFrely on being given a task set that is verified to be schedu-lable using the EDF scheduling policy. The problem is thatfor a single non-preemptive resource (e.g., hard disk, pro-cessor), determining schedulability for tasks tends to be NP-hard in general [14, 72].

Jeffay [33] proposed a pseudo-polynomial time algo-rithm to determine schedulability for EDF scheduled tasks.This test involves two conditions. The first condition en-sures the utilization is less than or equal to one. The secondcondition verifies that the demand for processor time doesnot exceed any task’s interval L, where L begins at the in-vocation of the task and ends before its first deadline. Thatis, the second part of the schedulability test essentially sim-ulates the execution of the tasks until a given task reachesmeets or misses its first deadline. This simulation is per-formed for each task.

[4] provided two schedulability tests that are O(1) byplacing restrictions on the periodic tasks. The first schedula-bility test requires that the computation times of all tasks areequal and that the periods are integral multiples of the com-putation time. The second schedulability test requires thatall tasks have equal periods, but may have arbitrary compu-tation times. Both tests guarantee such task sets scheduledusing EDF scheduling are schedulable as long as the sum ofall tasks’ utilizations is less than or equal to one.

Others [17, 28] have attempted to provide better non-preemptive EDF scheduling by inserting idle time in theschedule. Inserting idle time allows certain jobs to be post-poned that could otherwise cause missed deadlines.

5.2.2 Device Timings

Knowing the timing characteristics of devices is critical forproviding good schedules, both in terms of schedulabilityanalysis and good utilization of I/O devices. For instance,to provide guaranteed service of I/O requests, schedulabilityanalysis typically requires the worst-case time to service re-quests be known, which can be very difficult to extract. De-vices are also difficult to model due to asynchronous eventsthat are not directly related to I/O requests and proprietaryalgorithms in firmware. In this section we will look at some

common methods to extract and control I/O device servicetimes.

Hard disks are one of the more complicated devices, andpredicting precise service times can be difficult. Therefore,simplified models have been developed to provide good es-timations of service times for hard disk I/O requests. Forexample, [63] uses the following formula for worst-case ser-vice time for one disk request:

tseek + n ∗ trotation +m ∗ tsector + tovh + v ∗ tskew

In the formula, the terms have the following meaning:tseek is the time to move the disk head(s) from one end ofthe disk (e.g. outermost cylinder) to the other end, that is,the time for a full sweep of a disk head across the disk plat-ter; trotation is the time for the platter to spin one revolution;n signifies that more than one rotation may be required tostabilize the disk head on a track in order to perform dataoperations in the worst case; tsector is the time to accessone sector, for most modern disks, this time will vary due tozone-bit recording (ZBR) [24], where the outer tracks havemore sectors than the inner tracks, for disks with ZBR, theworst-case service time for the inner track should be takenas tsector; tovh is the time for disk controller processingand data transfer between the disk controller and the hostsystem, tovh is assumed to be constant; tskew is the time toswitch to a new cylinder and new head, depending on therequest size, this may occur more than once, indicated bythe parameter v. These parameters will typically vary fromhard disk to hard disk and must be determined for each harddisk.

While obtaining worst-case service times (WCSTs) fordisk I/O requests is important for ensuring timing con-straints will be met, it is also important for providing goodservice times for non-real-time requests. Since these non-real-time requests do not have explicit timing constraintsthey are commonly referred to as best-effort requests.

To provide service to best-effort requests, the ∆L sched-uler [9] uses the WCST for real-time disk I/O requests todetermine slack time in the schedule. Slack time is eitheridle time or the remaining time before the latest time thatreal-time requests must be serviced so that no deadlines aremissed. Whenever the remaining slack time in the scheduleis greater than the time to service a best-effort request, thebest-effort request is given priority over the next real-timerequest to service.

Reuther and Pohlack [63] developed a hard disk schedul-ing technique known as Dynamic Active Subset (DAS)where at each time a new request is chosen to be servicedby the disk, a subset of requests is constructed so that noservice guarantees will be violated for the subset. Any re-quest can be chosen from this subset without the possibilityof violating any deadlines. The choice of the next request to

19

execute can then be picked from the DAS based on the re-quest that can be serviced most efficiently. Therefore, topick the next request from the DAS, the shortest-access-time-first (SATF) [32] algorithm is used, which orders re-quest in order to lower mean response time and maximizethroughput. In order to create the DAS and perform SATFscheduling, a detailed model of the hard disk must be cre-ated, which involves gathering detailed timing characteris-tics of the hard drive that is to be modeled.

Gathering detailed timing characteristics for individualhard disks can be very time-consuming and challenging[46, 47, 80]. The difficulty in extracting timing character-istics is that much of the inner workings of a hard disk areproprietary and therefore must be empirically determined.Further, many events such as bad block remapping, ther-mal recalibration, read errors, etc. are difficult to predictand subject to change over the lifetime of each individualdisk, making the utility of fine-grained external schedulingof hard disks questionable.

Recognizing the trend of increased complexity and au-tonomy of modern disk drives, rather than attempting fine-grained hard disk scheduling, Wu and Brandt [81] proposeda more coarse grained approach that provides support forsoft real-time applications. Their basic idea is to controlthe rate of non-real-time requests in order to give real-timerequests the best chance of meeting deadlines. The rateof non-real-time requests is controlled through an adaptedtraffic shaping mechanism originally designed for network-ing known as Token Bucket Filter (TBF) [15]. To use theTBF mechanism, information about the allocation to thenon-real-time requests needs to be given. This is providedthrough a mechanism known as Missed Deadline Notifica-tion (MDN) [6] where real-time requests inform the OS thata deadline is missed. When a MDN is received, the ser-vice rate for non-real-time requests is decreased. As timepasses with no MDN received, the allocation to non-real-time requests is increased. While this traffic-shaping ap-proach does not provide hard real-time guarantees, it doesprovide good support for applications that are able to handlesome missed deadlines.

Many I/O devices have internal queues that can hold out-standing requests waiting to be serviced [78]. The order inwhich these requests are processed varies and can signif-icantly increase the variability in request service time. Inparticular, the hard disk drives have internal queues that al-low a disk to service requests in a throughput optimized or-der (with heuristics to prevent starvation). Without intimateknowledge of the scheduling mechanisms used in these diskdrives, meeting timing constraints becomes very challeng-ing. Stanovich et al. [74] developed a technique that allowsone to use the optimized scheduling of the hard disk driveswhile still meeting request deadlines. Their approach is tomaximize the number of outstanding requests that are sent

to the hard disk in order to allow the best chance for opti-mizations and therefore increase throughput. At the sametime, new requests to be sent to the hard disk are throttledso that real-time requests already issued will not be in jeop-ardy of missing their deadlines if the real-time request(s)happen to be serviced last. Empirical techniques were de-veloped to invoke worst-case or near worst-case behaviorin order to extract service times. These times were used todetermine whether new requests would jeopardize alreadyissued real-time requests.

Rather than guaranteeing some amount of service timeon a particular I/O device, requirements for most devices aretypically in terms of data throughput rather than time uti-lization. For example, an application may need to read 1MBevery 30msec. Guaranteeing data throughput can be muchharder than guaranteeing service time. However, Kaldeweyet al. [35] have shown that in many situations, guaran-teeing time utilization for real-time applications providesbetter control, isolation, and efficient use of hard disk re-sources in comparison with guaranteeing bandwidth or I/Orates. The approach is to provide each application with avirtual disk, which is a fractional share of a physical harddisk. Each application is allowed to reserve a percentage ofthe hard disk’s time utilization, where the maximum sum of100% time utilization is enforced to ensure feasibility. Animportant goal of the virtual disk abstractions is that its per-formance should be independent of any other virtual diskusing the same physical hard disk. This is performed bycharging each application for time used. This charging isdone by first estimating the service time of an I/O request toensure the request has enough budget and then charging theapplication once the I/O request returns, the point at whichthe actual service time can be computed.

5.2.3 Backlogging of Work

Since I/O device operations tend to be much slower thanCPU operations, in many cases requests are cached in orderto speed up performance. For example, when write requeststo hard disks are sent, this data will typically be cached inmain memory and actually written to the hard disk later.This caching can create problems later on by causing anavalanche of data being written to the hard disk at the sametime a real-time request is attempting to send requests tothe hard disk. Due to file system and journaling order de-pendencies, these real-time requests may be forced to waituntil previous request are written to the hard disk. If toolarge a backlog of cached requests has accumulated, the de-lay to service the real-time request may be enough to causea missed deadline.

Flash memory is a type of non-volatile storage whichunlike hard disks has no moving parts, thereby providingmuch more predictable timings for simple operations. This

20

predictability makes flash memory much more suitable foruse in real-time systems. However, flash memory has itsown challenges due to the requirement that storage blocksmust be erased before data can be written to them. Thismeans that directly overwriting of old data is not possible.Additionally, storage blocks can only be erased a limitednumber of times.

A component called the garbage collector is typicallyused to provide pre-erased, or free blocks of storage for newwrites. The garbage collector tries to spread the number oferases uniformly across the flash storage to prolong the lifeof the storage media. This process called wear leveling.

Flash-based storage also has the characteristic that theerase granularity (i.e., flash block) is larger than the writegranularity (i.e., flash page). Therefore, when an erase oc-curs, all pages within a block to be erased must not hold us-able data. If there are no such erasable blocks, the garbagecollector must move data from an erasable block before theerase operation takes place.

Reading from flash storage tends to be very predictable,however write performance can vary substantially [55].This unpredictability is due to the possibility of blockingwhile the garbage collector creates free pages. To addressthe unpredictable write time of flash, [12] provides a real-time garbage collection mechanism to provide guaranteedwrite times to flash storage. The basic idea is to ensure thatfree pages are immediately available for real-time tasks, re-moving any blocking times that otherwise may need to beincluded in the schedulability analysis. To do this, a real-time garbage-collector task is created for every real-timetask that writes to the flash storage. This garbage collector iscreated to reclaim enough free pages to supply to the real-time task. To determine schedulability the real-time taskand its associated garbage collector task are included in theanalysis. The access to the flash based storage is assumedto be programmed I/O, meaning that the processor is oc-cupied during any operations being performed on the flashmemory. Processor scheduling is stated to be EDF and onlyone processor is used. Verification of schedulability is per-formed by summing the utilizations for all real-time tasksand their associated garbage collectors plus the worst-caseblocking time due to nonpreemptive operations is less thanor equal to one. The worst-case blocking term is definedto be the time for an erase operation (the longest operationon flash memory) over the minimum period of all real-timeand garbage collecting tasks.

5.3 Global Scheduling

Many real-time applications use multiple resources.These resources provide the necessary services that allowan application to complete some given activity. When con-sidering a real-time application, this activity will have tim-ing constraints associated with it. Each resource along the

critical path of the real-time application affects the timeli-ness of the entire application. To guarantee that the appli-cation meets its end-to-end timing constraints, coordinatedscheduling between the different resources must occur.

Guaranteeing end-to-end timing constraints involvingmultiple resources and multiple applications tends to be in-tractable as one single problem. To simplify the problem,the resource decoupling approach is proposed in [58]. Re-source decoupling takes the larger problem involving multi-ple resources and breaks it into a series of smaller problems,where each smaller problem involves the scheduling of onlyone resource. That is, each job is broken into multiple sub-jobs, where each job involves only one resource and eachresource is scheduled independently. This allows the calcu-lation of the end-to-end delay to be equal to the sum of thedelays of each job, thereby providing a mechanism to deter-mine whether a given end-to-end timing constraint will bemet.

However, the resource decoupling approach [58] is onlyvalid if the resources are independent of one another. Aproblem is that scheduling I/O resources generally also re-quires the processor, breaking the independence require-ment. That is, if we consider devices such as the networkor disk, both require some of the CPU processing time inorder to provide their service (e.g. device driver code). Thismeans that managing or scheduling each resource indepen-dently of any other resource does not occur. [64] uses a co-operative scheduling server (CSS) which reserves both I/Oand processor time in order to guarantee end-to-end tim-ing requirements. The CSS approach divides the end-to-end operation into multiple jobs, pre-processing, I/O deviceservice time, and post-processing. Each sub-job is then as-signed a deadline that guarantees the end-to-end deadline ismet. These deadlines are assigned on a fixed slack sharingscheme where the slack in the schedule is divided propor-tionally between the different sub-jobs. Initially, deadlinesare set to equal the execution time. Then, a fixed percent-age of the total slack is given to the I/O service to extendits deadline. The remaining slack is then divided betweenthe pre- and post-processing sub-jobs proportional to the re-served processor time of the two sub-jobs.

The mechanism in which end-to-end slack time is di-vided between the different sub-jobs can affect the totalnumber of tasks that can be admitted to the system. Sinceeach resource is scheduled independently of other resourceson the system, the more slack time given to one sub-job de-creases its utilization and thereby increases the likelihood ofa given sub-job being schedulable. Further, this additionalslack time means that the total utilization of that resourcewill be less, increasing the number of tasks that can be ac-cepted in the future. To provide better deadline assignment,[22] proposed to assign deadlines based on resource utiliza-tions. For instance, if a disk resource were 25% utilized and

21

the CPU resource were 75% utilized, rather than equally di-viding the slack between the two resources, a more sensibleassignment would be to divide the slack based on the totalutilization of a given resource. So, if the total slack were100ms, the deadline assignment of the disk would be in-creased by 250ms and the deadline for the CPU usage dead-line would be increased by 750ms.

Decoupling the resources from one other simplifies thescheduling, however, it removes some valuable informationthat can potentially provide better scheduling. [23] men-tions the problem of non-preemptive scheduling and meet-ing end-to-end deadlines. With inter-scheduler coordina-tion, the scheduler of each resource makes locally optimalsolutions, however, due to precedence constraints releasetimes for future jobs may be known and releasing a non-preemptible job may interfere with the end-to-end deadlineof an already released job. To partially solve this problem[23] proposes inter-scheduler coordination that informs re-sources of future job arrivals and deadlines. This advancenotification allows resources to insert place holders for up-coming real-time jobs, thereby, preventing any interferingjobs from starting that may jeopardize upcoming deadlines.However, this solution is only partial because it cannot pre-vent cases such as long non-preemptible jobs starting beforethe real-time job arrives.

The theoretical task or job abstraction typically maps toa process (or thread) in an implemented system. This al-lows the process to be the accountable entity for resourceusages. This accounting can then be used to make futurescheduling decisions. However, many real-world jobs donot map exclusively to one process. If we consider a webserver, a common scenario is for a request to arrive throughthe network interface, be handled by the server’s connectionmanager, be served by another process (to isolate and pro-tect the system from unruly applications), and then returnedto the client again through network interface. In this sce-nario, any single process is not the accountable entity. Tosolve this problem, Banga et al. [7] proposed the resourcecontainer abstraction. Resource containers provide an ac-countable entity that is used to track processor and resourceusages. Therefore, each activity (job) on the system has as-sociated with it a resource container. When an activity trav-els through different processes, the resource container willtravel along as well. This allows proper scheduling deci-sions to take place based on the activities (jobs) rather thanprocesses.

6 Conclusion

Real-time systems guarantee that activities are com-pleted within specified timing constraints. To provide theseguarantees, real-time scheduling theory provides a foun-dation. For an implemented system to benefit from these

theoretical guarantees, the system workload and schedulingmust adhere closely to the theoretical models.

In the past real-time systems have typically been devel-oped on specialized hardware and software that were simpleand mapped easily to theoretical models. Recently, moresystems with real-time requirements have been built withoff-the-shelf hardware and software components. Thesecomponents were not designed for use in a real-time sys-tem and therefore composing a real-time system with thesecomponents is challenging.

In particular, GPOSs have found their way into manyreal-time systems. While there are many benefits of usingGPOSs, one major drawback is that they do not conformwell to uses where timeliness is a concern. For GPOSs tobe a viable component of a real-time system, the obstaclesthat prevent the theoretical models from being implementedmust be addressed.

One class of OS components that causes difficulties forGPOSs to follow real-time theoretical models is devicedrivers. These components have many characteristics thatviolate the assumptions of scheduling theory. In this paper,a number of these characteristics have been enumerated, aswell as some of the more prominent solutions that have beenproposed in the literature. While these solutions do addressportions of the problem, many of the challenges remain.

References

[1] L. Abeni and G. Buttazzo. Integrating multimedia applica-tions in hard real-time systems. In Proc. 19th IEEE Real-Time Systems Symposium, pages 4–13, Madrid, Spain, Dec.1998.

[2] R. Arnold, F. Mueller, D. Whalley, and M. Harmon. Bound-ing worst-case instruction cache performance. In Real-TimeSystems Symposium, 1994., Proceedings., pages 172–181,Dec. 1994.

[3] N. C. Audsley, A. Burns, M. Richardson, and A. J. Wellings.Hard real-time scheduling: the deadline monotonic ap-proach. In Proc. 8th IEEE Workshop on Real-Time Oper-ating Systems and Software, pages 127–132, Atlanta, GA,USA, 1991.

[4] Y.-C. Baek and K. Koh. Real-time scheduling of non-preemptive periodic tasks for continuous media retrieval.In TENCON ’94. IEEE Region 10’s Ninth Annual Interna-tional Conference. Theme: Frontiers of Computer Technol-ogy. Proceedings of 1994, pages 481–485, Aug. 1994.

[5] T. P. Baker, A. A.-I. Wang, and M. Stanovich. Fitting linuxdevice drivers into an analyzable scheduling framework. InOSPERT 2007, the Workshop on Operating Systems Plat-forms for Embedded Real-time Applications, pages 1–9, July2007.

[6] S. Banachowski, J. Wu, and S. A. Brandt. Missed deadlinenotification in best-effort schedulers. In SPIE, Multimedia

22

Computing and Networking (MMCN), San Jose, CA, USA,Jan. 2004.

[7] G. Banga, P. Druschel, and J. C. Mogul. Resource con-tainers: A new facility for resource management in serversystems. In Proc. 3rd USENIX Symposium on OperatingSystems Design and Implementation, pages 45–58, New Or-leans, Louisiana, Feb. 1999.

[8] M. Bennett and N. Audsley. Predictable and efficient vir-tual addressing for safety-critical real-time systems. In Real-Time Systems, 13th Euromicro Conference on, 2001., pages183–190, June 2001.

[9] P. Bosch and S. J. Mullender. Real-time disk schedulingin a mixed-media file system. In RTAS ’00: Proceedings ofthe Sixth IEEE Real Time Technology and Applications Sym-posium (RTAS 2000), pages 23–32, Washington, DC, USA,May–June 2000. IEEE Computer Society.

[10] A. Burns. Preemptive priority-based scheduling: an appro-priate engineering approach. In Advances in real-time sys-tems, pages 225–248, Upper Saddle River, NJ, USA, 1995.Prentice-Hall, Inc.

[11] A. Burns, A. J. Wellings, and A. Hutcheon. The impactof an ada run-time system’s performance characteristics onscheduling models+, 1993.

[12] L.-P. Chang, T.-W. Kuo, and S.-W. Lo. Real-time garbagecollection for flash-memory storage systems of real-timeembedded systems. ACM Trans. Embed. Comput. Syst.,3(4):837–863, 2004.

[13] R.-I. Chang, W.-K. Shih, and R.-C. Chang. Deadline-modification-scan with maximum-scannable-groups formultimedia real-time disk scheduling. In Real-Time SystemsSymposium, 1998. Proceedings., The 19th IEEE, pages 40–49, Madrid, Spain, Dec. 1998.

[14] S. Cheng, J. A. Stankovic, and K. Ramamritham. Schedul-ing algorithms for hard real-time systems–a brief survey.Technical report, University of Massachusetts, Amherst,MA, USA, 1987.

[15] D. D. Clark, S. Shenker, and L. Zhang. Supporting real-time applications in an integrated services packet network:architecture and mechanism. ACM SIGCOMM ComputerCommunication Review, 22(4):14–26, Oct. 1992.

[16] P. Druschel and G. Banga. Lazy receiver processing (LRP):a network subsystem architecture for server systems. InProc. 2nd USENIX symposium on operating systems designand implementation, pages 261–275, Oct. 1996.

[17] C. Ekelin. Clairvoyant non-preemptive edf scheduling. InECRTS ’06: Proceedings of the 18th Euromicro Conferenceon Real-Time Systems, pages 23–32, Dresden, Germany,July 2006.

[18] T. M. Ghazalie and T. P. Baker. Aperiodic servers in a dead-line scheduling environment. Real-Time Systems, 9(1):31–67, 1995.

[19] T. Gleixner. ktimers subsystem. http://lwn.net/Articles/152363/, Sept. 2005.

[20] T. Gleixner and D. Niehaus. Hrtimers and beyond: Trans-forming the linux time subsystems. In In Proceedings of theOttawa Linux Symposium, Ottawa, Canada, July 2006.

[21] What Is Andriod? http://developer.android.com/guide/basics/what-is-android.html,2010. [Online; accessed 14-February-2010].

[22] K. Gopalan and T. Chiueh. Multi-resource allocation andscheduling for periodic soft real-time applications. In Proc.Multimedia Computing and Networking, San Jose, CA,USA, Jan. 2002.

[23] K. Gopalan and K.-D. Kang. Coordinated allocation andscheduling of multiple resources in real-time operating sys-tems. In Proc. of Workshop on Operating Systems Plat-forms for Embedded Real-Time Applications (OSPERT),Pisa, Italy, June 2007.

[24] T. P. Guide. Zoned Bit Recording. http://www.pcguide.com/ref/hdd/geom/tracksZBR-c.html. [Online; accessed 20-August-2010].

[25] M. G. Harbour. Real-time posix: an overview. In VVConex93 International Conference, Moscow, June 1993.

[26] C. Healy, R. Arnold, F. Mueller, D. Whalley, and M. Har-mon. Bounding pipeline and instruction cache performance.Computers, IEEE Transactions on, 48(1):53–70, Jan 1999.

[27] W. Hofer, D. Lohmann, F. Scheler, and W. Schroder-Preikschat. Sloth: Threads as interrupts. Real-Time SystemsSymposium, IEEE International, 0:204–213, 2009.

[28] R. R. Howell and M. K. Venkatrao. On non-preemptivescheduling of recurring tasks using inserted idle times. In-formation and Computation, 117(1):50–62, Feb. 1995.

[29] IEEE Portable Application Standards Committee (PASC).Standard for Information Technology - Portable OperatingSystem Interface (POSIX) Base Specifations, Issue 7. IEEE,Dec. 2008.

[30] Intel. 82093AA I/O advanced programmable interrupt con-troller (IOAPIC). http://download.intel.com/design/chipsets/datashts/29056601.pdf,1996.

[31] Intel. Intel 64 architecture (x2APIC) specification.http://www.intel.com/Assets/pdf/manual/318148.pdf, Mar. 2010.

[32] D. M. Jacobson and J. Wilkes. Disk scheduling algorithmsbased on rotational position. Technical Report HPL-CSP-91-7rev1, HP Laboratories, 1991.

[33] K. Jeffay, D. F. Stanat, and C. U. Martel. On non-preemptivescheduling of periodic and sporadic tasks. In Proc. 12thIEEE Symposium on Real-Time Systems, pages 129–139,San Antonio, TX, 1991.

[34] M. B. Jones and S. Saroiu. Predictability requirements of asoft modem. SIGMETRICS Perform. Eval. Rev., 29(1):37–49, 2001.

[35] T. Kaldewey, T. Wong, R. Golding, A. Povzner, S. Brand,and C. Maltzahn. Virtualizing disk performance. In Real-Time and Embedded Technology and Applications Sympo-sium, 2008. RTAS ’08. IEEE, pages 319–330, St. Louis, MO,USA, Apr. 2008.

[36] S. Karlin and L. Peterson. Maximum packet rates for full-duplex ethernet. Tech Report TR-645-02, Princeton Univer-sity, Feb. 2002.

[37] D. Katcher, H. Arakawa, and J. Strosnider. Engineering andanalysis of fixed priority schedulers. Software Engineering,IEEE Transactions on, 19(9):920–934, Sept. 1993.

[38] S. Kleiman and J. Eykholt. Interrupts as threads. ACMSIGOPS Operating Systems Review, 29(2):21–26, Apr.1995.

23

[39] B. W. Lampson and D. D. Redell. Experience with pro-cesses and monitors in mesa. Commun. ACM, 23(2):105–117, 1980.

[40] M. Lewandowski, M. J. Stanovich, T. P. Baker, K. Gopalan,and A.-I. Wang. Modeling device driver effects in real-timeschedulability analysis: Study of a network driver. In RealTime and Embedded Technology and Applications Sympo-sium, 2007. RTAS ’07. 13th IEEE, pages 57–68, Apr. 2007.

[41] C. L. Liu and J. W. Layland. Scheduling algorithms for mul-tiprogramming in a hard real-time environment. Journal ofthe ACM, 20(1):46–61, Jan. 1973.

[42] J. W. S. Liu. Real-Time Systems. Prentice-Hall, 2000.[43] C. D. Locke. Software architecture for hard real-time appli-

cations: cyclic executives vs. fixed priority executives. Real-Time Syst., 4(1):37–53, 1992.

[44] R. S. Ltd. Hybrid (measurement and static anal-ysis). http://www.rapitasystems.com/WCET-Hybrid-Static-and-Measurement,May 2010.

[45] R. S. Ltd. Rapitime on target timing analysis. http://www.rapitasystems.com/rapitime, May 2010.

[46] C. R. Lumb, J. Schindler, and G. R. Ganger. Freeblockscheduling outside of disk firmware. In Proceedings of theConf. on File and Storage Technologies (FAST), Monterey,CA, Jan. 2002. USENIX.

[47] A. A. M. Aboutabl and J.-D. Decotignie. Temporally deter-minate disk access: An experimental approach. TechnicalReport CS-TR-3752, University of Maryland, 1997.

[48] L. McVoy and C. Staelin. lmbench: Portable tools for per-formance analysis. In In USENIX Annual Technical Confer-ence, pages 279–294, Jan. 1996.

[49] L. McVoy and C. Staelin. Lmbench - tools for performanceanalysis. http://www.bitmover.com/lmbench/,May 2010.

[50] J. Mogul and K. Ramakrishnan. Eliminating receive live-lock in an interrupt-driven kernel. ACM Transactions onComputer Systems, 15(3):217–252, 1997.

[51] I. Molnar. Preemptive kernel patches. http://people.redhat.com/mingo/.

[52] K. Narasimhan and K. D. Nilsen. Portable execution timeanalysis for risc processors. In in Proceedings of the Work-shop on Architectures for Real-Time Applications, 1994.

[53] K. D. Nilsen and B. Rygg. Worst-case execution time anal-ysis on modern processors. In LCTES ’95: Proceedings ofthe ACM SIGPLAN 1995 workshop on Languages, compil-ers, & tools for real-time systems, pages 20–30, New York,NY, USA, 1995. ACM.

[54] J. K. Ousterhout. Why aren’t operating systems gettingfaster as fast as hardware? In Proceedings of the UsenixSummer 1990 Technical Conference, pages 247–256, Ana-heim, CA, USA, June 1990.

[55] D. Parthey. Analyzing real-time behavior of flash memo-ries. Master’s thesis, Chemnitz University of Technology,Chemnitz, Germany, Apr. 2007.

[56] R. Pellizzoni and M. Caccamo. Toward the predictable in-tegration of real-time cots based systems. In Real-TimeSystems Symposium, 2007. RTSS 2007. 28th IEEE Interna-tional, pages 73–82, Dec. 2007.

[57] I. Puaut and D. Hardy. Predictable paging in real-time sys-tems: A compiler approach. In Real-Time Systems, 2007.ECRTS ’07. 19th Euromicro Conference on, pages 169–178,July 2007.

[58] R. Rajkumar, K. Juvva, A. Molano, and S. Oikawa. Re-source kernels: A resource-centric approach to real-timesystems. In Proc. SPIE/ACM Conf. Multimedia Computingand Networking, pages 150–164, Jan. 1998.

[59] A. L. N. Reddy and J. Wyllie. Disk scheduling in a multime-dia I/O system. In MULTIMEDIA ’93: Proceedings of thefirst ACM Int. Conf. on Multimedia, pages 225–233, NewYork, NY, USA, 1993. ACM Press.

[60] J. Regehr. Inferring scheduling behavior with Hourglass.In Proc. of the USENIX Annual Technical Conf. FREENIXTrack, pages 143–156, Monterey, CA, June 2002.

[61] J. Regehr and U. Duongsaa. Preventing interrupt overload.In Proc. 2006 ACM SIGPLAN/SIGBED Conf. on languages,compilers, and tools for embedded systems, pages 50–58,Chicago, Illinois, June 2005.

[62] J. Regehr and J. A. Stankovic. Augmented CPU Reserva-tions: Towards predictable execution on general-purpose op-erating systems. In Proc. of the 7th Real-Time Technologyand Applications Symposium (RTAS 2001), pages 141–148,Taipei, Taiwan, May 2001.

[63] L. Reuther and M. Pohlack. Rotational-position-aware real-time disk scheduling using a dynamic active subset (DAS).In RTSS ’03: Proceedings of the 24th IEEE Int. Real-Time Systems Symposium, page 374, Washington, DC, USA,2003. IEEE Computer Society.

[64] S. Saewong and R. R. Rajkumar. Cooperative schedulingof multiple resources. In RTSS ’99: Proceedings of the20th IEEE Real-Time Systems Symposium, pages 90–101,Phoenix, AZ, USA, Dec. 1999. IEEE Computer Society.

[65] K. Sandstrom, C. Eriksson, and G. Fohler. Handling inter-rupts with static scheduling in an automotive vehicle controlsystem. In Real-Time Computing Systems and Applications,1998. Proceedings. Fifth International Conference on, pages158–165, Oct. 1998.

[66] S. Schonberg. Impact of pci-bus load on applications in a pcarchitecture. In RTSS ’03: Proceedings of the 24th IEEE In-ternational Real-Time Systems Symposium, pages 430–439,Cancun, Mexico, Dec. 2003. IEEE Computer Society.

[67] L. Sha, T. Abdelzaher, K. E. Arzen, A. Cervin, T. P. Baker,A. Burns, G. Buttazzo, M. Caccamo, J. Lehoczky, and A. K.Mok. Real time scheduling theory: A historical perspective.Real-Time Systems, 28(2–3):101–155, Nov. 2004.

[68] L. Sha, J. P. Lehoczky, and R. Rajkumar. Solutions for somepractical problems in prioritized preemptive scheduling. InProc. 7th IEEE Real-Time Sytems Symposium, 1986.

[69] L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority inheritanceprotocols: an approach to real-time synchronisation. IEEETrans. Computers, 39(9):1175–1185, 1990.

[70] B. Sprunt, L. Sha, and L. Lehoczky. Aperiodic task schedul-ing for hard real-time systems. Real-Time Systems, 1(1):27–60, 1989.

[71] M. Spuri and G. Buttazzo. Efficient aperiodic service underthe earliest deadline scheduling. In Proc. IEEE Real-TimeSystems Symposium, Dec. 1994.

24

[72] J. A. Stankovic and K. Ramamritham, editors. Tutorial:hard real-time systems. IEEE Computer Society Press, LosAlamitos, CA, USA, 1989.

[73] M. Stanovich, T. P. Baker, A.-I. A. Wang, and M. G. Har-bour. Defects of the posix sporadic server and how to correctthem. In Real Time and Embedded Technology and Applica-tions Symposium, 2010. RTAS ’10. 16th IEEE, pages 35–45,Stockholm, Sweden, Apr. 2010. IEEE Computer Society.

[74] M. J. Stanovich, T. P. Baker, and A.-I. A. Wang. Throt-tling on-disk schedulers to meet soft-real-time requirements.In Real-Time and Embedded Technology and ApplicationsSymposium, 2008. RTAS ’08. IEEE, pages 331–341, Apr.2008.

[75] D. B. Stewart. Twenty-five-most commons mistakes withreal-time software development. In Embedded Systems Con-ference 1999., Sept. 1999.

[76] D. Stodolsky, J. B. Chen, and B. N. Bershad. Fast inter-rupt priority management in operating system kernels. InUSENIX Microkernels and Other Kernel Architectures Sym-posium, pages 105–110, Berkeley, CA, USA, Sept. 1993.USENIX Association.

[77] J. Strosnider, J. P. Lehoczky, and L. Sha. The deferrableserver algorithm for enhanced aperiodic responsiveness inreal-time environments. IEEE Trans. Computers, 44(1):73–91, Jan. 1995.

[78] T10 Technical Committee on SCSI Storage Interfaces. SCSIarchitecture model - 3 (SAM-3). http://www.t10.org/ftp/t10/drafts/sam3/sam3r14.pdf, 2004.

[79] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti,S. Thesing, D. Whalley, G. Bernat, C. Ferdinand, R. Heck-mann, T. Mitra, F. Mueller, I. Puaut, P. Puschner, J. Staschu-lat, and P. Stenstrom. The worst-case execution-timeproblem—overview of methods and survey of tools. ACMTrans. Embed. Comput. Syst., 7(3):1–53, 2008.

[80] B. L. Worthington, G. R. Ganger, Y. N. Patt, and J. Wilkes.On-line extraction of SCSI disk drive parameters. In SIG-METRICS ’95/PERFORMANCE ’95: Proceedings of the1995 ACM SIGMETRICS joint Int. Conf. on Measurementand modeling of computer systems, pages 146–156, Ottawa,Ontario, Canada, 1995. ACM Press.

[81] J. C. Wu and S. A. Brandt. Storage access support for softreal-time applications. In RTAS ’04: Proceedings of the10th IEEE Real-Time and Embedded Technology and Appli-cations Symposium (RTAS’04), page 164, Washington, DC,USA, 2004. IEEE Computer Society.

[82] J. Zhang, R. Lumia, J. Wood, and G. Starr. Achieving deter-ministic, hard real-time control on an ibm-compatible pc:a general configuration guideline. In Systems, Man andCybernetics, 2005 IEEE International Conference on, vol-ume 1, pages 293–299 Vol. 1, Oct. 2005.

[83] Y. Zhang and R. West. Process-aware interrupt schedulingand accounting. In Proc. 27th Real Time Systems Sympo-sium, Rio de Janeiro, Brazil, Dec. 2006.

25