On the Scheduling of Mixed-Criticality Real-Time Task Sets

Transcription

1 On the Schedulng of Mxed-Crtcalty Real-Tme Task Sets Donso de Nz, Karthk Lakshmanan, and Ragunathan (Raj) Rajkumar Carnege Mellon Unversty, Pttsburgh, PA Abstract The functonal consoldaton nduced by the costreducton trends n embedded systems can force tasks of dfferent crtcalty (e.g. ABS Brakes wth DVD) to share a processor and nterfere wth each other. These systems are known as mxedcrtcalty systems. Whle tradtonal temporal solaton technques prevent all nter-task nterference, they waste utlzaton because they need to reserve for the absolute worst-case executon tme (WCET) for all tasks. In many mxed-crtcalty systems the WCET s not only rare, but at tmes dffcult to calculate, such as the tme to localze all possble objects n an obstacle avodance algorthm. In ths stuaton t s more approprate to allow the executon tme to grow by stealng cycles from lower-crtcalty tasks. Even more crucal s the fact that temporal solaton technques can stop a hgh-crtcalty task (that was overrunnng ts nommal WCET) to allow a low-crtcalty task to run, makng the former mss ts deadlne. We dentfy ths as the crtcalty nverson problem. In ths paper, we characterze the crtcalty nverson problem and present a new schedulng scheme called zero-slack schedulng that mplements an alternatve protecton scheme we refer to as asymmetrc protecton. Ths protecton only prevents nterference from lower-crtcalty to hgher-crtcalty tasks and mproves the schedulable utlzaton. We use an offlne algorthm wth two parts: a zero-slack calculaton algorthm, and a slack analyss algorthm. The zero-slack calculaton algorthm mnmzes the utlzaton needed by a task set by reducng the tme low-crtcalty tasks are preempted by hgh-crtcalty ones. Ths algorthm can be used wth prorty-based preemptve schedulers (e.g. RMS, EDF). The slack analyss algorthm s specfc for each prorty-based preemptve scheduler and we develop and evaluated the one for RMS. We prove that ths algorthm provdes the same level of protecton aganst crtcalty nverson as the best known prorty assgnment for ths purpose, crtcalty as prorty asgnment (CAPA). We also prove that zero-slack RM provdes the same level of schedulable utlzaton as RMS when all tasks have equal crtcalty levels. Fnally, we present our mplementaton of the runtme enforcement mechansms n Lnux/RK to demonstrate ts practcalty. I. INTRODUCTION In modern real-tme embedded systems, such as avoncs and automotve systems, there s ncreasng pressure to reduce cost and physcal resources such as power and heat. Ths has resulted n the consoldaton of functonalty of dfferent crtcalty nto shared hardware resources (e.g. processor and memory). Unfortunately, such sharng can lead to nterference across tasks (e.g. one task usng the processor longer than expected) of dfferent crtcalty potentally causng crtcal falures. For nstance, f we deploy an ABS brakng system task on the same processor as a navgaton system task of the car, f the latter does not release the processor on tme t could make the former mss ts deadlne. Ths problem s a concern of growng nterest. In partcular, the US Ar Force Research Laboratory has been leadng the Mxed-Crtcalty Archtecture Requrements (MCAR) [1] ntatve to nvestgate buldng blocks to safely construct these mxed-crtcalty systems. Resource parttonng s the key mechansm used to prevent nterferences due to shared resources. Ths parttonng ncurs ts own costs. In partcular, we need to provson for the worst-case resource demand (e.g. worst-case executon tme WCET) even though such a demand s only exercsed n rare occasons. Obtanng ths WCET s a challengng task due to hardware unpredctablty (e.g. caches, ppelnes, speculatve executon) and the dependency of the executon tme of some algorthms on the envronment (e.g. number of obstacles to avod). As a result, WCET numbers are often obtaned through measurements and supplemented by an added cushon factor as an educated and typcally conservatve estmate. Ths leads to a twofold problem: poor average utlzaton of the processor and occasonal enforcement (temporary stoppng) of tasks that need to run longer than ther WCET. Such enforcement prevents low-crtcalty tasks from nterferng wth hghercrtcalty ones and can make the low-crtcalty task mss ts deadlne whle preventng the mssng of the deadlne of the hgher-crtcalty task. Unfortunately, such enforcement can also be suffered by the hgher-crtcalty task to prevent ts nterference on a low-crtcalty task. As a result, the enforcement can make the hgher-crtcalty task mss ts deadlne to allow the low-crtcalty one to meet ts own. We call ths type of enforcement symmetrc enforcement because t acts the same way n both drectons: low-to-hgh and hgh-to-low crtcaltes. Ths enforcement can have the opposte effect to our orgnal ntent: a lower-crtcalty task s favored over a hgher-crtcalty tasks and crtcalty nverson s sad to occur. One way to elmnate the crtcalty nverson problem s to smply assgn the prortes of the tasks n the order of ther crtcalty levels. We call ths scheme Crtcalty As Prorty Assgnment (CAPA). However, ths scheme can lead to very poor utlzaton f the resultng order turns out to be contrary to the best prorty assgnment to maxmze utlzaton (e.g. rate-monotonc prorty, proven to be optmal for fxed-prorty schedulng). Such an approach can lead to very low levels of schedulable utlzaton due to forced prorty nverson. In ths paper, we descrbe a schedulng polcy called zeroslack schedulng to provde a new form of protecton we call asymmetrc protecton. Ths new form of protecton elmnates the mpact on deadlne due to the crtcalty nverson whle mnmzng the penalty on schedulable utlzaton. We also

2 develop new metrcs to evaluate crtcalty nverson. The rest of ths paper s organzed as follows. Secton II summarzes the related work n ths area. Secton III ntroduces the crtcalty nverson problem, and develops the blockng terms requred to characterze t. Secton IV develops the zeroslack schedulng scheme to deal wth crtcalty nverson and presents performance metrcs for mxed-crtcalty schedulng. Secton V apples the zero-slack scheme to rate-monotonc (RM) schedulng, and proves useful propertes about the ntegrated zero-slack RM scheduler. Secton VI detals our mplementaton of zero-slack RM schedulng on Lnux/RK. Fnally, we provde our concludng remarks n secton VII. II. RELATED WORK Multple papers have been publshed related to overload schedulng. [2] and [3] use a form of crtcalty together wth a value assgned to task completons. Ther approach s then to maxmze the accrued value. In our case, we do not requre a value for task completon (whch can be dffcult to obtan) but use an absolute rankng that matches the common semantcs of mxed-crtcalty task sets. Addtonal studes have also been done on onlne schedulng of overloads [4 6]. These schemes do not nclude an explct noton of crtcalty and hence cannot take advantage of ths noton. Ch-Sheng et al. present n [7] an approach to map the semantc mportance of tasks n a task set nto QoS servce classes to mprove the resource utlzaton. Ther objectve s to ensure that the allocated resources are never less for a hghcrtcalty task than for a lower-crtcalty one. In our case, we focus on deadlnes, and guarantee that whenever an overload reduces the resources avalable we ensure that a hgh-crtcalty task wll not mss ts deadlne due to the allocaton of more resources to a lower-crtcalty task. Varous operatng systems lke Lnux/RK [8], QLnux [9], Wndows Vsta [10], and Ralto [11], provde extensve mechansms for resource solaton through advance reservatons. Although such exstng technques are fundamental to provdng hard tmng guarantees, they are stll agnostc to crtcalty and enforce solaton symmetrcally. In contrast, our scheme uses tasks crtcaltes and overload budgets to create an asymmetrc enforcement wthout ncurrng crtcalty nverson. In the specfc context of overload schedulng, schedulng algorthms based on the elastc task model have been proposed [12]. Tasks wth hgher elastcty are allowed to run at hgher rates when requred, whereas tasks wth lesser elastcty are restrcted to a more steady rate. Ths elastcty does not explctly capture the crtcalty of a task, and t requres all remanng tasks to be compressed under an overload scenaro. Our soluton explctly supports overload scenaros and crtcalty levels through a crtcal mode (C) of operaton n addton to the normal mode (N) of operaton. Durng ths crtcal mode, we block the lower-crtcalty tasks, thereby transferrng utlzaton only from the lower-crtcalty tasks under overloaded condtons to beneft hgher-crtcalty tasks. Closely related to our proposal for dual-executon modes vz. normal mode (N) and crtcal mode (C) s the work on dual-prorty schedulng [13]. Dual-prorty schedulng s an effectve technque for responsvely schedulng soft tasks wthout compromsng the deadlnes of crucal hard real-tme tasks. Whle ther noton of crucal tasks s somewhat smlar to crtcalty there are two stark dfferences. Frst, non-crucal tasks are not gven any schedulng guarantees n ther work, whereas, n our scheme all crtcalty levels have a guarantee on ther executon tmes. Secondly, ther lmtaton to two levels smplfes the analyss but also lmts the utlty. In contrast, we allow an unlmted number of crtcalty levels wth an mplct graceful degradaton on overload that follows the crtcalty order. Another related work to dual-prorty schedulng s the earlest deadlne zero laxty (EDZL) algorthm [14, 15]. In EDZL, tasks are scheduled based on earlest deadlne frst (EDF) untl some task reaches zero laxty (or zero slack), n whch case ts prorty s elevated to the hghest level. Whle the noton of zero slack s used n our soluton, the exstng EDZL results do not consder the noton of task crtcaltes and are not drectly applcable to the mxed-crtcalty schedulng problem. Perod transformaton has been an mportant soluton studed n the context of mxed-crtcalty systems [16, 17]. Ths technque has been subsequently extended and generalzed n [18]. For any gven task set, we can transform the tasks by scalng both ther computaton tme and perod equally. In the context of mxed crtcalty, we can perform perod transformaton to ensure that the task prortes match the requred crtcalty. The problem n usng ths soluton for dealng wth overload scenaros s that the perod transformaton needs to be performed assumng the task wll overrun ts absolute WCET,.e., wth an overloaded computaton-tme. Performng such a perod transform usng the overloaded computaton tme results n early and pessmstc preemptons by the perod-transformed hgher-crtcalty tasks over the lowercrtcalty tasks. The proposed zero-slack schedulng algorthm swtches tasks to ther crtcal mode only when there would be zero slack remanng to meet ther correspondng overloaded computaton tme requrements. Therefore, the zeroslack schedulng algorthm does not mpose more nterference than necessary to provde schedulng guarantees n mxedcrtcalty systems. III. THE CRITICALITY INVERSION PROBLEM Prorty-based preemptve schedulng polces assgn prortes to tasks, and at run-tme, attempt to schedule the hghest-prorty ready task. The prorty assgnment can be fxed across task nstances (fxed-prorty schedulers) or t can change across task nstances (dynamc prorty schedulers). In tradtonal real-tme schedulng, prortes are assgned wth the purpose of maxmzng schedulable utlzaton whle respectng the deadlnes of all the tasks n the set. The utlzaton maxmzaton approach of tradtonal realtme schedulers makes two mportant assumptons: (1) all tasks are equally mportant, and (2) the utlzaton never goes beyond the allowable threshold(s). These two assumptons seldom hold n mxed-crtcalty systems. In partcular, tasks

3 can have dfferent crtcalty levels. Hence, f there s ever a stuaton where we can only satsfy the deadlne of one task, then we should choose to meet the one wth hgher crtcalty. The second assumpton does not hold for a more subtle reason. Specfcally, the fact that enforcement s even consdered as a protecton mechansm mples that there s a possblty that some tasks can go beyond ther specfed worstcase executon tme. Whle ths s, n general, consdered a fault, an explct protecton aganst t s needed because t can create (temporal) overload stuatons. These overload stuatons are precsely when crtcalty nverson can occur. Snce the tradtonal prorty assgnment made by the scheduler was talored to ncrease schedulable utlzaton, t s agnostc to crtcalty. In partcular, under prorty-based preemptve schedulng, a low crtcalty task can have a hgher schedulng prorty than a hgher-crtcalty task. Such prorty assgnment would schedule the low crtcalty task earler than the hghercrtcalty task, potentally makng the latter mss ts deadlne. On the other hand, f we assgn prortes based on crtcalty (as ntroduced n Secton I), then we elmnate crtcalty nverson. However, ths assgnment can potentally create sgnfcant prorty nverson [19] from the perspectve of prorty-based preemptve schedulers. To consder both schedulng prortes and task crtcaltes, and explctly capture the overload executon requrements, let us defne a task τ as: where: τ = (C, C o, T, D, ζ ) C s ts worst-case executon tme under non-overloaded condtons, C o s the overload executon budget, T s the perod of the task, D s the deadlne of the task (wth D T ), ζ s the crtcalty of the task. We follow the same conventon as wth prortes: lower ts value, hgher the crtcalty. It s worth notng that the overload budget C o s used to create a precse defnton our guarantee,.e., how much overload s guaranteed. As we wll show later, t s possble to reserve a conservatve (large) C o snce t does not add up across crtcalty levels. The prorty blockng densty P B for task τ s then defned as: where: P B = τ j ζ j<ζ pb j D (1) pb j s the maxmum tme that a hgher-crtcalty task τ j can block the executon of an nstance of τ durng whch the schedulng prorty of τ s hgher than that of τ j. Smlarly, the crtcalty blockng densty CB for task τ s calculated as: CB = τ j ζ <ζ j cb j D (2) where: cb j s the maxmum tme that a lower-crtcalty task τ j can block the executon of an nstance of τ durng whch the schedulng prorty of τ j s hgher than that of τ. P B and CB become blockng utlzaton when D = T quantfyng the exact schedulable utlzaton loss. However, we present our general dscusson on utlzaton loss usng the blockng densty fgures to allow the more general case where D T. Notwthstandng we wll use the blockng utlzaton to evaluate our Zero-Slack Rate-Monotonc algorthm n Secton V-E snce D = T n ths case. Both pb j and cb j vary dependng on how and when the scheduler assgns prortes and the strateges used to tradeoff prorty and crtcalty blockng. In the next secton we dscuss the strateges taken n our new schedulng scheme. IV. ZERO-SLACK SCHEDULING Our schedulng polcy works on top of tradtonal prortybased preemptve real-tme schedulers. It s based on the observaton that crtcalty nverson only matters under overload condtons. We use ths observaton to create two executon zones for each task τ. In the frst zone, every task s ncluded whle n the second zone, every task τ j ζ j > ζ s suspended. Ths suspenson effectvely blocks the nterference of lowercrtcalty tasks n the case of an overload condton, up to the completon of the task actvaton. It must be noted that τ tself can also be suspended by a task τ c ζ c < ζ n τ c s second zone. The executon zones partton the executon of each task nto two modes: the normal mode (N mode) and the crtcal mode (C mode). Our schedulng algorthm then calculates the executon tme for each mode. We now defne our schedulng guarantee. A. Schedulng Guarantee Our scheduler performs admsson control, and f admtted 1, a task τ s guaranteed to run up to C o f no hgher crtcalty tasks exceeds ts C. Ths guarantee follows the separaton of the overloaded from the non-overloaded stuaton. Ths separaton allows us to make two strategc decsons. Frst, when no overload condton s present, we should schedule the task wth the objectve of maxmzng utlzaton. And secondly, we also avod ntroducng any nterference preventon untl the last nstant necessary to satsfy our guarantee. The last nstant to block nterference for a task τ s the latest tme at whch the nterference preventon mechansm can free enough cycles for τ to complete ts C o before ts deadlne. Ths nstant s dentfed as zero-slack nstant because t leaves no slack n C mode after the completon of C o. Ths s the nstant at whch the executon mode of the task swtches from N mode nto C mode. Avodng nterference preventon tll ths last nstant enables us to maxmze the total schedulable utlzaton, whle stll meetng our schedulng guarantee. 1 In the rest of ths paper, when we use the term schedulable, we refer to the property of satsfyng ths schedulng guarantee.

4 Our scheme s dvded nto two parts. The frst part s an admsson test that determnes the zero-slack nstant for each of the tasks n a task set. The second s a runtme enforcement mechansm that prevents nterference based on the crtcalty and the zero-slack nstant of each task. B. Admsson Control Our admsson control scheme takes the form of a slackdscovery algorthm. We start wth the worst-case assumpton that there s no slack n the N mode of the tasks and they always need to run n C mode. Ths s equvalent to CAPA. Then, we start movng computaton tme from the C mode (n C c) to the N mode (n Cn ) of the tasks as we dscover slack n the N mode. Ths scheme s presented n Algorthm 1. The algorthm converges when t cannot move the zeroslack nstant of any task towards ther deadlne. Ths s codfed wth two varables per task Z 0 (zero-slack before cycle) and Z 1 (zero-slack after cycle). Insde the cycle, the algorthm calculates the slack vector n for task τ n N mode (wth a set of all the orgnal tasks - Γ n ) and C mode (wth a set of hgher-crtcalty tasks - Γ c ). The slack vector contans a sequence of slack regons ordered by tme, where each slack regon contans a startng nstant and duraton. Wth these slack vectors, we obtan a new zero-slack nstant (Z 1) wth the functon GetSlackZeroInstant that takes Co and accommodates the most computaton avalable n the N mode slack vector, wth the rest n the C mode slack vector. After the convergence of ths algorthm a taskset Γ s schedulable f τ Γ T otalslack(v c) Co. Algorthm 1 Compute Fnal Zero-Slack Instants (t = D ) 1: Z 1 0 2: repeat 3: Z 0 Z1 4: for all n taskset do 5: V n GetSlackV ector(, Γ n ) 6: V c GetSlackV ector(, Γ c ) 7: Z 1 GetSlackZeroInstant(, V c, V n, t) 8: end for 9: untl Z 0 = Z1 10: return Z 1 The functon GetSlackVector used n Algorthm 1 s specfc to each prorty-based preemptve schedulng algorthm and we wll dscuss t later n the context of rate-monotonc schedulng. However, the functon GetSlackZeroInstant s generc. Ths functon s presented n Algorthm 2. At the begnnng of ths algorthm, we ntalze the C c and C n of the task to C o and 0 respectvely. The cycle n ths algorthm frst fnds the last tme nstant at whch C c unts of slack are avalable n the slack vector V c before t = D (at lne 3). Then, we calculate how much slack s avalable from zero to ths nstant n the vector V n (at lne 5). Ths avalable slack s then transferred from C c to C n (lnes 7 and 8). The next teraton of the cycle then fnds the next nstant for a smaller TABLE I SAMPLE CRITICAL TASK SET Task C C o T D Crtcalty Prorty τ τ C c (due to the transfer n lnes 7 and 8), movng ths nstant closer to t = D. The loop ends when we are not able to transfer any more computaton from C c to Cn. The functon StartOfTralngSlack returns the nstant at whch the requested slack (C o) for task τ starts such that t s avalable before deadlne t = D. The functon SlackUpToInstant, on the other hand, returns the amount of slack avalable up to the specfed nstant. It s to be noted here that for smplcty of presentaton, we assume that the orgn of tme concdes wth the release of task τ. Algorthm 2 GetSlackZeroInstant(,V c, V n, t): Calculate Instant of Slack = 0 before tme t 1: C c Co ; C n 0 2: repeat 3: t 1 StartOfT ralngslack(, C c, V c ) 4: f t 1 0 and t 1 t then 5: k u SlackUpT oinstant(v n, t 1 ) C n 6: k u = max(mn(k u, C c ), 0) 7: C c Cc k u 8: C n C n + k u 9: else 10: k u 0 11: end f 12: untl k u = 0 13: return t 1 C. A Two-Task Example We now llustrate the admsson control algorthm usng a two-task example and deadlne-monotonc schedulng. Consder the task set n Table I. In ths table, we present the parameters of two tasks, wth an addtonal column for ther deadlne-monotonc prorty. Note that the prorty and the crtcalty of the tasks n ths table are the nverse of each other. Wth these parameters we proceed to calculate the C c and C n for each task τ n the set. For our task set n Table I, C2 n and C2 c are obtaned by frst calculatng the slack for τ 2 n both the N mode and the C mode. In N mode, the slack up to the end of ts deadlne (8) s 4 whch s not enough to schedule ts C2 o = 5 (ths s, n fact, the problem when usng pure deadlne-monotonc schedulng). Ths means that we need to swtch ths task to C mode at some pont to compensate. To do ths, we start by executng ts C2 c = 5 tme n C mode. Then, we evaluate the last nstant Z 2 that C2 c tme unts are avalable n C mode. Snce τ 2 has the hghest crtcalty, t s the only task runnng n ts C mode, and hence ths last nstant s ts deadlne (8) C2(5) c = Z 2 = 3. Then, we check how much tme s avalable n N mode up to

5 Fg. 1. τ τ Swtch to C mode Two-Task Example of the Zero-Slack Schedule tme 3, whch n ths case s 1 (.e., 3 C1 o = 1). We then make ths the ntal tme for C2 n and subtract t from C2. c Next, we repeat the operaton to fnd the last nstant to schedule C2 c = 4 unts of tme n C mode (Z 2 = 4). Ths, n turn, ncrements the avalable slack n N mode (up to nstant 4) to 2, movng another unt to C2 n (.e., C2 n = 2 and C2 c = 3). The last ncrement then leads us to the last nstant when C2 c = 3 s avalable n C mode (Z 2 = 5). Ths new nstant does not ncrement the avalable slack n N mode but defnes the fnal zero-slack nstant Z 2 for task τ 2 to swtch to C mode. The fnal schedule can be seen n Fgure 1. In ths fgure, we can see τ 1 runnng frst for ts whole executon tme C1 o = 2. Then, τ 2 runs for 2 unts and then gets preempted by the second arrval of τ 1 at tme 4. Then, τ 1 runs for one more unt. At ths pont we reach the zero-slack nstant Z 2 of τ 2 and suspend τ 1. When there s no overload n the system, τ 2 wll run only for 0.5 unts more and resume τ 1. However, n an overload stuaton, τ 2 wll have enough cycles to complete ts C2 o = 5 before the end of ts deadlne (at 8). It s worth notng that our computaton of the zero-slack nstant n ths example starts by assumng that there s no slack n the N mode and, as t dscovers more slack, keeps movng computaton to N mode. The key property of ths technque s that the computaton executed n C mode decreases monotoncally. A second mportant observaton s that the ntal executon dstrbuton (between C n and C c) may not be schedulable. In ths example, the ntal startng pont s, n fact, not schedulable,.e., f τ 2 runs always n C mode and only uses up to C 2 (2.5) unts of tme startng at zero, τ 1 msses ts deadlne because only 1.5 unts are left before ts deadlne (4) and our guarantee s not honored (ths s how CAPA would schedule the task set). However, wth the fnal schedulng parameters the task set honors our guarantee. That s, f τ 2 only uses C 2, then t means that at ts zero-slack nstant (5), t wll only run for 1 2 a tme unt more leavng tme unts for τ 1 (that only needs 1 more) to complete ts C2. o D. Proof of Convergence of the Zero-Slack Computaton Because our scheme reles on the convergence of the zeroslack computaton algorthm, we state the assumptons of the algorthm and prove ts convergence. The zero-slack computaton algorthm assumes the use of a non-anomalous 2 fxed-prorty schedulng algorthm. These algorthms ensure that reducng any C j of τ j Γ never 2 Some multprocessor schedulng schemes are known to be anomalous, where ths property does not hold. ncreases the response tme W τ Γ. Unprocessor schedulng algorthms lke RMS and CAPA are known to be nonanomalous wth respect to computaton tme [20]. Assumng the use of ths algorthm, we can prove convergence. Lemma 1: When non-anomalous schedulng algorthms are used to calculate the slack vectors, the Compute Fnal Zero- Slack Instants algorthm (Algorthm 1) converges. Proof: The proof follows from the followng three loop nvarants for Algorthm 1: 1) Z 1 0 τ Γ 2) Z 1 Z0 τ Γ 3) Z 1 D τ Γ Gven these three loop nvarants, we can observe that Z 1 starts at 0, never decreases snce Z 1 Z 0, and s bounded to be less than or equal to D. Therefore, Algorthm 1 converges. We now prove that these three loop nvarants hold true for Algorthm 1. Z 1 Z0 τ Γ: At the begnnng of the teraton, task τ s splt nto C c unts of executon n the crtcal mode (C), and C o Cc unts of executon n the normal mode (N). Durng the teraton, the executon tme n the crtcal mode C c never ncreases. For any non-anomalous schedulng algorthm, the slack avalable n the crtcal mode (C) can never decrease snce C c never ncreases. Therefore, the zero slack nstant Z1 calculated usng the slack avalable n the crtcal mode (C) s never pushed earler than Z 0.e. decreased n value. Z 1 0 τ Γ: ths follows from the ntalzaton condton Z 1 = 0 and the prevously establshed nvarant that Z 1 Z0 τ Γ. Z 1 D τ Γ: Consder a task τ wth a zero-slack schedulng nstant of D. The amount of tme spent n the crtcal mode (C) s 0. Therefore, there s no addtonal slack avalable n the crtcal mode (C). Ths mples that the zeroslack schedulng nstant can be moved no further than D. E. Runtme Behavor of The Zero-Slack Schedulng The central pece of the runtme mechansm of our scheme s the dual-mode executon mplementaton. It s mportant to keep the overhead of such a mechansm as lean as possble. We can acheve ths by usng the zero-slack nstants calculated offlne as tmers to swtch to C mode. These tmers then mark the tme when the lower-crtcalty tasks are suspended. For ths reason, we need to keep track of the crtcalty level of the tasks to be able to dstngush whch tasks need to be suspended. At the same tme, we need to keep track of whch tasks are n C mode n order to know whch tasks to resume when a task fnshes ts C mode. In a resource reservaton framework, the admsson test can be performed at the tme of the resource reservaton and the correspondng zero-slack nstants can be computed. F. Effectveness of Scheme To evaluate the effectveness of our schedulng algorthm, we defned a metrc to measure a reducton of the blockng densty factors (P B and CB ) defned n Secton III. For

6 CB, we know that a task τ j ζ < ζ j mposes a blockng term cb j = Co j n the worst case. For P B, a task τ j ζ j < ζ mposes a blockng term pb j = C j n the worst case. Because the blockng factors at each task level may nvolve parts of the blockng factors of other tasks, the fnal tasksetwse blockng, s calculated by takng the maxmum blockng among all the tasks: T B Γ = max τ Γ (CB + P B ) Ths total blockng s the maxmum blockng present n the task set Γ whose crtcalty-awareness s mproved by zero-slack schedulng. We call ths combned blockng mxedcrtcalty blockng (MC blockng). It s worth notng that ths value depends on the level of nverson between prortes and crtcaltes, as well as ther budgets and perods. For nstance, for the task set n Table I, the blockng factors are defned as: P B 1 = C2 D 1 = = P B 2 = 0 (because t s the lowest prorty) CB 1 = 0 (because t s the lowest crtcalty) CB 2 = Co 1 D 1 = 2 4 = 0.5 Hence, the MC blockng of the task set s the maxmum of the sum of the factors that s equal to ) Resdual MC blockng: The effectveness of an algorthm n reducng MC blockng s calculated by the amount of resdual MC blockng that the algorthm s not able to remove. For nstance, n the task set of Table I, when crtcalty s used as the schedulng prorty (CAPA), both CB 1 and CB 2 are zero. However, P B 1 = C2 D 1 = = (and P B 2 = 0). Takng the maxmum of the factors the resdual MC blockng left by the algorthm s On the other hand, when RMS s used, then P B 1 = P B 2 = 0. But CB 2 = Co 1 D 1 = 2 4 = 0.5 (and CB 1 = 0), s the resdual MC blockng left by the algorthm. Fnally, n the case of the zero-slack scheduler, the factors are reduced to P B 1 = Cc 2 D 1 = = 0.125, P B 2 = 0, CB 1 = 0, and CB 2 = C1 D 2 = C1 D D 2 = = ( 1 D 2 s the fracton of C 1 that executes n the second arrval of τ 1 before the zero-slack nstant). Hence, the resdual MC blockng s It s worth notng that the zero-slack scheduler reduces both P B and CB. P B s reduced because only a fracton of the C2 o (0.5) s run wth a prorty greater than the schedulng prorty (deadlne-monotonc prorty). CB s reduced because the swtchng to crtcal mode at the zeroslack nstant of τ 2 reduces ths blockng from 2 4 to 3 8 (2 n the frst perod of τ 1 and 1 n ts second perod). The reducton n crtcalty blockng s just enough to enable the completon of C2. o Furthermore, the fact that P B 1 was reduced from to 0.125, when compared to CAPA, ndcates that the zero-slack algorthm has further capacty to tolerate a larger prorty blockng wthout breakng the schedulng guarantee. We capture ths tolerance wth a metrc we call laxty densty. 2) Laxty Densty: The laxty densty of a task τ measures the avalable densty for τ after we dscount the preemptons of hgher-prorty tasks and the blockng factors left by the schedulng algorthm of nterest for ths task. The laxty densty for a task τ s then defned as: LaxU = A() Co (P B + CB ) C j (3) D D j where: τ j H hc A() s the avalable densty for task τ for a specfc prorty-based preemptve scheduler. For nstance, for rate-monotonc schedulng wth n mplct-deadlne tasks, ths s n(2 1 n 1) (see [21]) Co D s the overload densty of τ P B + CB s the blockng factor for the schedulng algorthm of nterest C j τ j H hc D j s the densty consumed by the hgherprorty and hgher-crtcalty tasks (H hc ) The laxty densty allows us to see how an algorthm spreads the laxty of the system across the dfferent tasks. Hence a successful algorthm wll keep the mnmum laxty across the tasks of the task set always greater than or equal to zero. Ths means that, an algorthm X s better than an algorthm Y, f there exst task sets where the mnmum laxty under Y goes below zero whle under X s greater than or equal to zero, but f there exsts a task set wth a mnmum laxty under X below zero, ts mnmum laxty under Y s also below zero. We wll use ths metrc to evaluate the performance of our zero-slack RM once we dscuss ts detals n the next secton. V. THE ZERO-SLACK RATE-MONOTONIC SCHEDULING (ZERO-SLACK-RM) The zero-slack schedulng polcy works on top of a prortybased preemptve scheduler and reles on the calculaton of slack vectors provded by such scheduler. In ths secton, we present the slack vector calculaton for the rate-monotonc scheduler. We chose the RM scheduler to smplfy the explanaton of the zero-slack scheme. Hence, n ths secton we wll assume mplct deadlnes (D = T ). A. Worst-Case Phasng of Dual-Mode Tasks Key to the calculaton of the slack vectors n the ratemonotonc schedulng s the phasng of the tasks. For a snglemode executon, Lu and Layland [21] proved that the phasng that creates the maxmum preempton for a task τ happens when every task τ j prorty(τ j ) < prorty(τ ) arrves at the same tme as τ. However, n a dual-mode task, ths worstcase phasng does not hold. Ths s because, when tasks reach ther zero-slack nstants, they wll suspend lower-crtcalty tasks. On the one hand, ths suspenson acts, as ntended, to avod preemptons suffered by task τ from lower-crtcalty tasks. However, t also acts as a preempton when hghercrtcalty tasks suspend τ. Hence, to calculate the worst-case delay mposed by ths type of preempton, we need to algn all the suspensons n the same way as the perod arrvals. Unfortunately, f we algn the zero-slack nstants of the hghercrtcalty tasks, we may msalgn the arrval of hgher-prorty tasks. In other words, t s not always possble to algn both

7 TABLE II ZERO-SLACK-RM SCHEDULED TASK SET Task C C o T D Crtcalty Prorty ZS Instant τ τ τ τ 0 τ 1 τ the worst-case arrval of the tasks and the zero-slack nstants. The mplcaton of ths msalgnment s that we cannot create a sngle ntegrated crtcal zone based on the algnment of both types of preemptons. As a result, we take a pessmstc approach by assumng that the effects of both algnments always happen. Although the worst-case phasng may not exst, t provdes an upper bound on the total nterference mposed on task τ. Ths can be shown as follows. Before the zero-slack nstant, the maxmum nterference from hgher-prorty tasks happens when they are released smultaneously wth τ (from [21]). After the zero-slack nstant, τ effectvely blocks all the lower - crtcalty tasks. Therefore, the nterference can only arse from hgher-crtcalty tasks. By swtchng all the hgher-crtcalty tasks to ther crtcal mode (C) along wth τ, the nterference suffered by τ n the crtcal mode (C) s also maxmzed. B. A Zero-Slack-RM Schedulng Example Let us use an example to llustrate the characterstcs of the zero-slack-rm scheduler. Table II presents a task set wth the prortes assgned by the rate-monotonc scheduler and the zero-slack nstants calculated by our algorthm. Due to space lmtatons, we wll focus our dscussons on τ 1. Fgure 2 presents the crtcal zone of ths task. In ths fgure, we can see the preempton from τ 0 n the N mode of τ 1 for 50 unts of tme. After ths, τ 1 runs for 10 unts and then reaches ts zero-slack nstant at tme 60, swtchng to C mode. In C mode, t suspends the lowercrtcalty task τ 0, but at the same tme t s suspended by the hgher-crtcalty task τ 2. Ths suspenson s the pessmstc approach we use due to the absence of an exact worst-case phasng (as dscussed n Subsecton V-A). τ 2 then runs for C 2 (40) unts and resumes the lower-crtcalty tasks. However, n order to mantan the crtcalty order, ths resumpton s mplemented as a stack, meanng that t only returns to the prevous crtcalty level (leavng τ 0 suspended). Then, τ 1 can contnue executng completng ts C1 o (100) at tme 190. Each task n the task set has ts own (pessmstc) crtcal zone smlar to the one presented n Fgure 2, but they are unfortunately not necessarly algned wth each other. C. Calculatng The Slack Vectors n Zero-Slack-RM In order to calculate the slack vectors n zero-slack-rm, we frst defne an nterferng taskset for each task τ under zero-slack-rm. For each of the two executon modes (C and N=RM), there could be dfferent tasksets that could nterfere wth (.e. preempt) τ. We use Cj E to represent the effectve executon tme that wll be consdered for each nterferng task Zero-slack nstant Fg. 2. Crtcal Zone of Task 1 τ j. In partcular, n the RM mode, the task set that would nterfere wth task τ s defned as: Γ n = Γ rm = H lc H hc L hc S where, * H lc s the set of tasks wth hgher rate-monotonc prortes but lower crtcalty. These tasks attempt to run for C o unts. That s, τ j H lc, CE j Cj o. * H hc s the set of tasks wth hgher rate-monotonc prortes and hgher crtcalty. These tasks run for ther respectve non-overloaded computaton tme. If a hgher-crtcalty task executes beyond ts non-overloaded computaton tme, then the schedulng guarantee of lower-crtcalty task τ need not be honored. Hence, τ j H hc, Cj E C j. * L hc s the set of tasks wth lower rate-monotonc prortes and hgher crtcalty. These tasks are consdered to be runnng n ther C mode. In fact, we only need to consder the part of computaton that runs n ts C mode. That s, assumng that a rm, j contans the slack avalable to task τ j τ j L hc n RM mode, whle honorng the guarantee of task τ, then Cj E (C j a rm, j ). Intally, we assume that there s no slack avalable n RM mode (a rm, j = 0), but as we move the zero-slack nstants of the tasks towards the end of ther perod we wll dscover addtonal slack n RM mode reducng Cj E further, n turn the avalable slack n RM mode ncreases. * S s the set of tasks wth the same level of crtcalty but hgher prorty. These tasks are runnng at ther C o,.e., τ j S, Cj E Cj o. The nterferng task set for C mode of task τ s defned as: Γ c = H hc L hc S wth the same set of defntons as before. Note that the low crtcalty tasks are excluded snce the lower-crtcalty tasks are blocked durng τ C mode of executon. Wth these task sets, we create a slack vector for each executon zone usng Algorthm 3. Ths algorthm receves as parameters the ndex of the task we are evaluatng and the nterferng task set, ordered by ncreasng order of prorty. Algorthm 3 calculates the slack vector gven a task τ and ts nterferng task set Γ, for the executon mode under consderaton. The algorthm uses a parameter C v to accumulate the total slack avalable to τ over the entre perod of duraton t. The outer loop of Algorthm 3, adds new entres to the slack

8 vector. The nner loop computes the tme nstant R current by whch C v unts of slack are avalable, and the tme nstant b at whch the next nterferng task I m arrves. Dfference between b and R current s the next avalable slack regon for τ. Algorthm 3 GetSlackVector(, Γ, t = T ): Slack Vector Calculaton 1: ndex 0 ; C v 0 2: repeat 3: R current C v l b 0 4: repeat 5: R prevous R current 6: R current C v + j Γ Rprevous 7: b t ; I m 8: for (j Γ) do 9: A Rprevous T j T j 10: f (A < b) then 11: b A ; I m j 12: end f 13: end for 14: f (R prevous = R current ) then T j C e j 15: R current R current + CI e m 16: end f 17: untl (R prevous = R current or R current t) 18: V [ndex].slack mn(b, t) R current 19: V [ndex].tme R current 20: C v Cv + (mn(b, t) R current) 21: ndex : untl (R current t) 23: return V D. Propertes of The Zero-Slack-RM Scheduler We now present the propertes of our zero-slack RM scheduler. 1) Subsumes CAPA: Any task set schedulable under Crtcalty-As-Prorty Assgnment(CAPA) s also schedulable under the zero-slack schedulng scheme. Proof: Algorthm 1 starts wth assgnng Z 0 = Z 1 = 0 for all tasks τ. Under ths assgnment of zero-slack nstants, the zero-slack scheduler behaves essentally lke a CAPA scheme, snce whenever τ s released all the lower crtcalty tasks are mmedately blocked due to τ swtchng to ts crtcal mode (Z 1 = 0). Therefore, f the task set s schedulable under CAPA, t should be schedulable at the frst teraton of Algorthm 1. In ths scenaro, we now nductvely prove that each task τ remans schedulable over subsequent teratons. Durng subsequent teratons of the Compute Fnal zeroslack Instant algorthm, the Algorthm 2 s used to transfer addtonal computaton of up to k u from the crtcal mode (C) to the normal mode (N). Ths transfer s performed only to use up the slack of k u avalable n the normal mode (N) as calculated usng SlackUpToInstant tll the zero-slack nstant t 1. Consderng any task τ, ths transfer of computaton does not ncrease the blockng terms suffered by τ from hgher crtcalty tasks executng n ther C mode. The normal mode N of τ remans unaffected, snce the addtonal computaton s transferred to only fll up the avalable slack. Therefore, the response tme of task τ only reduces wth subsequent teratons. Hence, f task τ was schedulable n the prevous teraton, t contnues to reman schedulable. Ths completes the proof by nducton. 2) Corollary: Graceful Degradaton: When a task τ j executes for a C such that C j < C Cj o, then only tasks τ wth ζ > ζ j can mss ther deadlne. Ths follows from the schedulng guarantee provded by zero-slack schedulng, whch was descrbed n subsecton IV-A, and the property that rate-monotonc schedulng s non-anomalous. 3) Subsumes RM Scheduler: Any task set schedulable under rate-monotonc schedulng s also schedulable under the zero-slack schedulng scheme. Proof: For any task set Γ consstng of tasks τ = (C, T ) schedulable under the RM schedulng scheme, consder an equvalent Γ z wth tasks τ z = (C, C o, T, ζ ) wth C = C o = C and ζ = π, where π s the prorty assgned to task τ under RM schedulng. Schedulng the task set Γ z usng CAPA produces the same schedule as the RM scheduler, snce the prortes are completely algned wth the crtcalty under the chosen ζ values. Hence, Γ z s also schedulable under CAPA, snce t s schedulable under RM schedulng. Usng the property that zero-slack schedulng subsumes CAPA, t follows that Γ z s also schedulable under zero-slack schedulng. τ z 4) Utlzaton Propertes: A task set Γ z wth wth tasks = (C, C o, T, ζ ) s schedulable under zero-slack-rm f: U rm U z = Co k C j + + T k T j ζ k =ζ andt k <T ζ j<ζ andt j<t C o + ζ p<ζ andt p T C p T (4) From the perspectve of τ, under overloaded condtons, the utlzaton s Co T. The worst-case nterferng utlzaton arsng from the equal-crtcalty hgher-prorty tasks τ k s gven by Co k T k, snce they could potentally msbehave. The worst-case nterferng utlzaton arsng from hgher-crtcalty hgher-prorty tasks τ s gven by Cj T j, and the blockng utlzaton from hgher-crtcalty lower-prorty tasks s gven by Cp T. We do not have to consder the lower-crtcalty tasks snce they cannot affect the schedulablty of task τ. If the lower-crtcalty tasks could mpose any nterference on τ that causes t to potentally become unschedulable, then the zeroslack nstant would have been moved earler to ensure the schedulablty of τ. It s mportant to note here that Equaton (4) s only used to present a property of the Zero-Slack RM Scheduler. For the purposes the admsson control, we use the response-tme test based slack dscovery algorthm descrbed n Algorthm 3. E. Laxty Utlzaton Comparson The propertes of the zero-slack-rm algorthm can be depcted graphcally n a comparson of ts laxty utlzaton

9 Laxty Utlzaton (0,1,2) (0,2,1) (1,0,2) (1,2,0) (2,0,1) (2,1,0) Fg. 3. Crtcalty Vector Laxty Utlzaton vs Crtcalty-to-Prorty Inverson RMSMn CAPAMn ZSMn RMSTotal CAPATotal ZSTotal aganst that of both RMS and CAPA. Fgure 3 depcts ths comparson. We decded not to nclude perod transformaton n the comparson gven that n the end t wll behave as RMS wth overloaded computaton tme, as descrbed n secton II. For the comparson, we use the task set presented n Table II. We then vary the crtcalty of the task set (as a crtcalty vector [ζ 0, ζ 1, ζ 2 ]) to explore all the dfferent degrees of prorty-to-crtcalty nverson. Because ths task set s harmonc, we use 1 as the avalable utlzaton A() for each task τ, the maxmum for a harmonc task set under ratemonotonc schedulng. The assgned crtcalty vector s shown n the X-axs, and the mnmum and total laxty utlzaton values are plotted. It s to be noted here that the total laxty utlzaton can be greater than 1 because the laxty avalable to a task could also be avalable to other tasks n the system. Fgure 3 shows that there are crtcalty assgnments for whch ether RMS or CAPA or both algorthms are unable to acheve a mnmum laxty greater than or equal to 0 (to make t schedulable), whereas zero-slack schedulng ensures a mnmum laxty greater than or equal to zero n all cases. In partcular, ths fgure shows that, for a crtcalty assgnment [1, 0, 2], both RMS and zero-slack schedulng algorthms are feasble, whereas, CAPA renders the task set unschedulable. However, for the crtcalty assgnment [1, 2, 0], RMS s unschedulable, whereas, CAPA and zero-slack schedulng contnue to reman feasble. Ths llustrates that zero-slack schedulng subsumes both RMS and CAPA. We observe that the total laxty avalable under zero-slack schedulng s bounded by the maxmum total laxty avalable under RMS and CAPA. Specfcally, Fgure 3 shows that zeroslack schedulng always has a total laxty that s ether upper bounded by the laxty of RMS or by the laxty of CAPA. However, there are crtcalty assgnments lke [2, 1, 0], where both RMS and CAPA have negatve mnmum laxty but zeroslack schedulng remans feasble. The reason for ths behavor s that the key factor determnng feasblty s the dstrbuton of avalable laxty, as opposed to the total avalable laxty tself. For the crtcalty assgnment [2, 1, 0], whle CAPA has more laxty than zero-slack schedulng, the latter dstrbutes the laxty more evenly among the tasks by controllng the swtchng between dfferent executon modes. F. Relaxng Constrants For smplcty of presentaton, the dscusson so far has assumed mplct-deadlne constrants and accommodated ratemonotonc schedulng. It s mportant to note here that our slack vector calculaton n Algorthm 3 uses generc statcprorty preemptve schedulng results [22], therefore enablng t to be readly extended to other prorty assgnments. For nstance, t can be extended to deadlne-monotonc schedulng, whch s an optmal schedulng algorthm for systems wth constraned deadlnes (D T ). In the context of deadlnemonotonc schedulng, t s straght forward to use t = D nstead of T n Algorthm 3, after assgnng deadlne-monotonc prortes to tasks. Due to space constrants, we do not dscuss the densty-based propertes of such a Zero-Slack Deadlne- Monotonc (ZSDM) scheduler. Subsequent support for release jtter also follows from exstng results for fxed-prorty schedulng based on those presented n [22]. Ths s due to the fact that we employ ther basc analyss n step 6 of Algorthm 3. Replacng ths response-tme computaton wth the results n [22] wll enable such extensons. In order to smplfy the presentaton of our results, we avod a detaled dscusson of such extensons. VI. IMPLEMENTATION The zero-slack-rm scheduler and ts runtme enforcement mechansm have been mplemented n Lnux/RK [8]. Lnux/RK s a resource kernel that creates tme (or space) parttons of resources, e.g. CPU, provdng temporal solaton between these parttons. These parttons are called resource reserves. Tasks are then assocated wth these reserves. Tme reserves are specfed as a consumpton tme (C) of the resource over a perod of tme (T ). Wth ths specfcaton, Lnux/RK ensures that the tasks do not consume more tme than the allocated one over the specfed perod. These reserves are mplemented as perodc servers [23] where ther budget s replenshed perodcally and f ths budget s exhausted before the end of the perod, the assocated tasks are stopped. These tasks are resumed once the reserve s replenshed. Our runtme enforcement s mplemented as a new type of reserve n Lnux/RK wth two executon modes. Ths reserved type s called a crtcalty reserve. A crtcalty reserve adds two addtonal parameters to the regular CPU reserve: the crtcalty (ζ) and the zero-slack nstant (ZS), and uses C o as the C consumpton tme. A. Zero-Slack Enforcement The dual executon mode s mplemented as a zero-slack enforcement. Specfcally, a tmer s setup at the start of the perod of every task τ to expre accordng at the zero-slack nstant. If, when the tmer expres, τ has not fnshed ts actvaton, t suspends all the tasks wth a crtcalty lower that ts own, thereby enterng ts C mode. It also sets a global

10 crtcalty-level varable to equal ts own crtcalty ndcatng that no task wth lower crtcalty should be runnng (storng the prevous value as set by any prevous task n C mode n a stack). In addton, t puts the suspended tasks n a lst that s ordered by crtcalty. Once τ fnshes ts executon, then t resumes the tasks n C mode for the next crtcalty level, or all the tasks f no other task s n C mode. Fnally, when a reserve s replenshed, the crtcalty level of the assocated task s compared aganst the current crtcalty level and t s added to the suspended lst f t s lower. VII. CONCLUSIONS In ths paper, we studed the problems ntroduced by mxedcrtcalty task sets. We also dentfed the shortcomngs of tradtonal temporal solaton schemes to prevent nter-task nterference n mxed-crtcalty systems. In partcular, we characterzed and quantfed the crtcalty nverson problem that arses when a hgher-crtcalty tasks msses ts deadlne because t s forced to wat for a lower-crtcalty task. We then presented a new schedulng scheme wth a new protecton polcy, whch we call as asymmetrc protecton that only prevents nterference to hgher-crtcalty tasks from lowercrtcalty tasks. Our scheme has a generc offlne zero-slack computaton algorthm and runtme enforcement mechansm that can be used wth any prorty-based preemptve scheduler that has non-anomalous schedulng behavor. The other part of our scheme s a slack analyss algorthm that s specfc to each prorty-based preemptve scheduler. We developed the slack analyss algorthm for RMS and proved multple propertes of the ntegrated algorthm (zero-slack RM). Ths algorthm provdes the same level of protecton aganst crtcalty nverson as the best known prorty assgnment for ths purpose, crtcalty as prorty (CAPA). Zero-slack RM provdes the same level of schedulable utlzaton as RMS f crtcalty levels are equal to prortes, and better f they are dfferent and we use our schedulng guaranteed. We also developed two metrcs to evaluate such algorthms. Frst, a mxedcrtcalty blockng (MC blockng) metrc measures how much blockng reducton s possble n a specfc task set. Secondly, laxty utlzaton measures how well a schedulng algorthm reduces the MC blockng of the task set to make the task set schedulable. These metrcs are then used to show that zeroslack RM always outperforms or equals CAPA and RMS to spread the MC blockng reducton of a task set to the tasks that need t the most. Fnally, we demonstrate the practcalty of our runtme enforcement wth an mplementaton n Lnux/RK. REFERENCES [1] D. Homan, Desgnng future systems for arworthness certfcaton, cdgll/cpsweek09 MCAR/MCAR%20overvew%20BoF%20CPS%20PA% 20approved.pdf, [2] P. Meja-Alvarez, R. Melhem, and D. Mosse, An ncremental approach to schedulng durng overloads n real-tme systems, n In Proceedngs of the 21st, IEEE RTSS, [3] G. Buttazzo, M. Spur, and F. Sensn, Value vs deadlne schedulng n overload condtons, n In Proceedngs of the 16st, IEEE Real-Tme Systems Symposum, [4] G. Koren and D. Shasha, Dover; an optmal on-lne schedulng algorthm for overloaded real-tme systems, n In Proceedngs of the IEEE Real-Tme Systems Symposum, [5] S. Baruah and J. Hartsa, Schedulng for overload n real-tme systems, IEEE Transactons on Computers, vol. 46, no. 9, pp , [6] M. Gardner and L. J.W.S., Performance algorthms for schedulng real-tme systems wth overrun and overload, n In Proceedngs of the 11th Euromcro Conference on Real-Tme Systems, [7] C.-S. Shh, P. Gant, and L. Sha, Schedulablty and farness for computaton tasks n survellance radar systems, n In Proceedngs of the 10th RealTme and Embedded Computng Systems and Applcatons Conference, [8] S. Okawa and R. Rajkumar, Lnux/rk: A portable resource kernel n lnux, In Proceedngs of the 19th, IEEE Real-Tme Systems Symposum, [9] A. Sundaram, P. Chandra, P. Goyal, Shenoy, J. Sahn, and H. Vn, Applcaton performance n the qlnux multmeda operatng system, In Proceedngs of the Eghth ACM Conference on Multmeda, November [10] X. Feng, Towards real-tme enabled mcrosoft wndows, Proceedngs of the 5th Internatonal Conference On Embedded Software, pp , [11] M. J. Paul, M. B. Jones, P. J. Leach, R. P. Draves, and J. S. Barrera, Modular real-tme resource management n the ralto operatng system, Mcrosoft Research, Advanced Technology Dvson, pp , [12] G. Buttazzo, G. Lpar, and L. Aben, Elastc task model for adaptve rate control, IEEE Real-Tme Systems Symposum, pp , [13] R. Davs and A. Wellngs, Dual prorty schedulng, In Proceedngs of the 16th IEEE RTSS, pp , Dec [14] S. Cho, S.-K. Lee, A. Han, and K.-J. Ln, Effcent realtme schedulng algorthms for multprocessor systems, IEICE Trans. Communcatons, E85-B(12), pp , Dec [15] M. Crne and T. Baker, Edzl schedulng analyss, In Proceedngs of ECRTS, pp. 9 18, July [16] S. Vestal, Preemptve schedulng of mult-crtcalty systems wth varyng degrees of executon tme assurance, In Proceedngs of the Real-Tme Systems Symposum (Tucson, AZ, December 2007), pp , [17] L. Sha, J. P. Lehoczky, and R. Rajkumar, Task schedulng n dstrbuted real-tme systems, n Proceedngs of the IEEE Industral Electroncs Conference. IEEE, [18] S. Baruah and S. Vestal, Schedulablty analyss of sporadc tasks wth multple crtcalty specfcatons, Euromcro Conference on Real-Tme Systems, pp , July [19] L. Sha, R. Rajkumar, and J. Lehoczky, Prorty nhertance protocols: an approach to real-tme synchronzaton, Computers, IEEE Transactons on, vol. 39, no. 9, pp , Sep [20] S. Baruah and A. Burns, Sustanable schedulng analyss, n RTSS 06: Proceedngs of the 27th IEEE Internatonal Real- Tme Systems Symposum, 2006, pp [21] C. L. Lu and J. W. Layland, Schedulng algorthms for multprogrammng n a hard-real-tme envronment, J. ACM, vol. 20, no. 1, pp , [22] K. Tndell, A. Burns, and A. Wellngs, An extendble approach for analysng fxed prorty hard real-tme tasks, The Journal of Real-Tme Systems, 6(2), pp , March [23] T. M. Ghazale and T. P. Baker, Aperodc servers n a deadlne schedulng envronment, Real-Tme Syst., vol. 9, no. 1, pp , 1995.