Lecture #15 Interrupt & Cyclic Task Response Timing Embedded System Engineering Philip Koopman Monday, 14-March-2016

Transcription

1 Lecture #5 Interrupt & Cyclc Task esponse Tng Ebedded Syste Engneerng Phlp Koopan Monday, 4-March-26 Electrcal& Coputer ENGINEEING Copyrght 26-26, Phlp Koopan, All ghts eserved 777 Flght Control Frst Boeng fly by wre arcraft Only coputer networks between plot stcks and control surfaces [Yeh98] 2

2 777 Trplex edundancy 3 PFCs; 3 Networks Note feel unts to sulate feedback fro echancal flght surfaces [Yeh98] 3 Where Are We Now? Where we ve been: Interrupts Where we re gong today: Lookng at the tng of nterrupts (and non-preeptve tasks) Where we re gong next: More Interrupts, Concurrency, Schedulng Analog and other I/O Test #2 4

3 Prevew How do we organze ultple actvtes n an applcaton? Especally f soe of the are te senstve? Cyclc executve Put everythng n one bg an loop ISs only Use a bunch of ISs to do all the work Math to copute response te can get a bt hary Hybrd Man Loop + ISs Many real systes are bult ths way Overall pay attenton to the ath More portantly, the nsght behnd the ath! There s an equaton we expect you to really understand 5 Defnton of Concurrency A ajor feature of coputaton s provdng the lluson of ultple sultaneously actve coputatons Accoplshed by swtchng aong ultple coputatons quckly and frequently Concurrency s when ore than one coputaton s actve at the sae te Only one actually runs at a te, but any can be partally executed = actve IS actve when an progra executng Multple threads actve Multple tasks actve n ths course we re only worred about sngle-cpu systes Gves rse to nherent probles ace condtons f ultple coputatons access shared resources Tng probles f one coputaton affects tng of another Meory probles f coputatons copete for eory space Atteptng to fx the above probles leads to other probles, such as: Deadlocks Starvaton 6

4 How Do You Acheve Concurrency? Many technques possble In bg systes usually pre-eptve ulttaskng But n ebedded systes any other technques are used Why not just use a ulttaskng real te operatng syste? Soetes ths s the rght choce, but t can be: Too bg (eory footprnt ght not ft on sall CPU) Too slow (overhead for task schedulng) Too expensve (runte lcense fee of $ not reasonable on a $.5 CPU) Too coplex (especally to guarantee deternstc tng) Too hard to certfy as safe (what f the TOS has bugs?) Only recently have soe eal Te OS pleentatons been certfed safe So, let s see technques for concurrency and understandng task tng Today concentrate on understandng tng of cyclc execs and ISs 7 Splest Approach Cyclc Executve Create a an loop that executes each task n turn un the loop so fast that all tasks appear to be actve Assue one task s catchng bytes fro the UAT/SCI wthout beng over-run by data rate Other tasks just do varous coputatons really just subroutnes n ths verson No nterrupts only polled operaton! // an progra loop for(;;) { poll_uart(); do_task(); do_task2(); } Executve The an loop s the executve drectng task executon a very prtve scheduler 8

5 Cyclc Exec Tradeoffs If you run an loop fast enough, pleents concurrency Assue all regsters saved/restored wthn each task Ensure loop executes fast enough for poll_uart() to not ss any bytes Sple tng analyss Hard to get wrong as long as t sple and fast enough Frequently used n safety crtcal applcatons Tng s pretty uch the sae every te through loop» (assung tasks are well behaved) Obvous ltatons All tasks have to ft wthn one saple of I/O All code executed each te through loop, even f not really necessary Have to ake code sple so tng s easy to understand Can do ad hoc condtonal executon, but resst the teptaton It turns nto a ess!!! Insst on a clean approach; ore deas follow 9

6 Sple Mult-ate Cyclc Executve What f a sngle an loop s too slow? In prevous exaple, all code runs copletely each te through loop Possble the UAT wll get over-run before task and task2 coplete Soluton break tasks down nto self-contaned parts Ebellshent: Mult-rate soe functons called ore often than others Notes on exaple: Each task part has to fnsh fast enough to eet nu UAT pollng te Each task has to save all ts state soewhere (can t carry lve varables across task parts) Can also have lsts of ponters to tasks, etc. Actual pleentaton vares but dea s the sae Q: Where should you kck the watchdog? Q: Why s the watforter portant? // an progra loop for(;;) { poll_uart(); do_task_part(); poll_uart(); do_task_part2(); poll_uart(); do_task_part3(); } poll_uart(); do_task2_part(); poll_uart(); do_task2_part2(); poll_uart(); do_task2_part3(); watforter(); General Mult-ate Cyclc Exec Tradeoffs More flexble than sple cyclc executve Execute dfferent tasks at dfferent frequences as needed But, each task executes an nteger nuber of tes per an loop Tng stll restrctve Each task or part of task has to be short enough to fnsh before fastest task needs to execute agan Breakng up a long task nto short peces can be very panful If te for fastest task changes, ght have to rewrte code n other tasks Hand-schedule to cover worst case delay between executons of fastest task But, stll sple to analyze Each loop through tasks can be the sae as every other loop Worst case s each lne n an loop executes exactly once poll_uart() 6 tes per loop; everythng else once Agan resst urge to do ad hoc adaptve schedulng always creates a ess! By ths, we ean don t use an f to decde whether a task should run 2

7 Concept Latency and esponse Te Latency s, genercally, the watng te for soethng to happen For real te coputng, t s all about latency! Non-nterrupts te between executons of a task (worst case wat) Interrupts te between nterrupt request asserted and IS executng (worst case wat) Low latency = Short wat ( good ); Hgh latency = Long wat ( bad ) esponse te s ore precse ax te untl coputaton starts runnng For sple cyclc executon: esponse te for any task s one te through an loop For ult-rate cyclc exec: esponse te s te between repeated executons of a partcular task In ths exaple, sx tes faster for UAT pollng than for other tasks In general, depends on how tasks are lsted n the an loop What f low latency really only atters for one task, and t s short? Then use an IS 3 Cyclc Exec Plus Interrupts Process non-te-crtcal routnes n foreground epeated perodcally Process one (or a few) te crtcal functons n background UAT servced on nterrupt nstead of polled UAT can run at speed ndependent of other tasks! Other tasks don t have to be broken down nto peces as long as each task can wat for ts turn n loop // an progra loop for(;;) { do_task(); do_task2(); } vod nterrupt 2 handle_uart(vod) //-(2*2)-2 = $FFD6 for EI { <servce UAT/SCI> } But, t s not a free lunch! What s the latency for task? Te to execute whole loop plus soe nuber of executons of ISs 4

8 Latency Wth Interrupts Sple Verson For prevous exaple, latency of handle_uart() s: Can run back-to-back as any tes as needed So, very low latency What s guaranteed worst case latency of do_task()? Potentally nfnte f handle_uart() runs back-to-back forever What s expected latency of tasks n an loop? How any tes can UAT receve a byte n an loop? call t N Worst case executon te of an loop (sple verson) s: executon te of do_task() + executon te of do_task2() + N * executon te of handle_uart() Fortunately, bounded by speed of seral port But, an loop slows down as baud rate goes up, gvng te for ore nterrupts (ths s an essental property of nterrupt schedulng; ore detal n a few sldes) 5 Latency Wth Multple Interrupts Man Loop There s never just one nterrupt n the worst case What f ultple nterrupts can occur? Latency s nuber of tes each nterrupt can occur (sple verson) Assue M of N of IS2 P of IS3 (n practce could be + dfferent nterrupts; but 3 works for an exaple) Worst case executon te of an loop (sple ncorrect verson) s: executon te of do_task() + executon te of do_task2() + M * executon te of () + N * executon te of IS2() + P * executon te of IS3() So worst case for an loop gets worse as nterrupts are added What dd we ean by sple verson? we ean that t s actually ncorrect the correct verson s ore coplex 6

9 Cyclc+IS Man Latency The Correct Verson As ISs execute, te for an loop s extended As te s extended, there s te for ore ISs to take place As ore ISs take place, te s further extended Fnal te s recursve nfnte suaton Consder ths exaple: task takes sec task2 takes 5 sec takes sec; repeats at ost every sec IS2 takes 2 sec; repeats at ost every 2 sec IS3 takes 3 sec; repeats at ost every 3 sec How long s worst case an loop executon te (.e., task and task2 latency?) an loop wth no ISs s 25 sec In 25 sec, could have ; IS2; IS3 = sec = 329 In 329 sec, could have ; IS3 = 25+ sec = 35 In 35 sec, could have ; IS2; IS3 = 25+8 sec = 358 In 358 sec, could have ; IS2; IS3 = 25+8 sec = 358 sec» (process converges when you get sae answer twce n a row) 7 Cyclc + IS Man Latency The Math Gven: Man loop wth no ISs executes n ManLoopOnly IS takes ISte to execute and runs at ost every ISperod ManTe ManTe ManLoopOnly ManTe ISs ManTe ISperod j ISte Note that ths uses a FLOO FUNCTION not square brackets [ ] Ths s really just the calculaton we worked out on the prevous slde j j Worst case an loop executon te s Take floor of nuber of tes each IS can execute+ tes executon te Ths extends an loop latency. eanng each IS ght be able to execute ore tes Contnue evaluaton untl latency converges to a fxed value Ths s why we kept sayng easer to evaluate for non-is schedules! 8

10 What About Latency For Interrupts Theselves? Interrupts are usually the hgh prorty, fast-reacton-te routnes Wth only one IS, latency s just watng for nterrupt ask to turn off Sae IS ght already be runnng wat for TI I flag ght be set (SEI) wat for next CLI But wth ultple ISs n syste, t gets ore coplex Wat for nterrupt ask to be turned off Wat for other ISs to execute Let s take the case of prortzed nterrupts When ultple nterrupts are pendng, one of the gets prorty over others 9 Lower Hgher Prorty

11 Latency For Prortzed Interrupts Have to wat for other nterrupts to execute One ght already be executng wth lower prorty (have to wat) Or, nterrupts ght be asked for soe other reason ( blockng ) All nterrupts at hgher prorty ght execute one or ore tes Worst case have to assue that every possble hgher prorty nterrupt s queued AND longest possble blockng te (lower prorty nterrupt) Exaple, (sae as prevous stuaton): takes sec; repeats at ost every sec IS2 takes 2 sec; repeats at ost every 2 sec IS3 takes 3 sec; repeats at ost every 3 sec For IS2, latency s: IS3 ght just have started 3 sec ght be queued already sec IS2 wll run after 3 + = 4 sec» Ths s less than sec total (perod of ), so doesn t run a second te 2 Exaple IS Worst Case Latency Assue followng task set ( hghest prorty): takes 5 sec and occurs at ost once every 5 sec takes 6 sec and occurs at ost once every 2 sec IS2 takes 7 sec and occurs at ost once every sec IS3 takes 9 sec and occurs at ost once every 25 sec IS4 takes 3 sec and occurs at ost once every 6 sec IS3 IS2 IS3 9 sec:,, IS TIME (sec) 22

12 Wll IS2 Execute Wthn 5 sec? Worst Case s IS3 runs just before IS2 can start Why ths one? has longest executon te of everythng lower than IS2 Then & go because they are hgher prorty But wat, they retrgger by 2 sec so they are pendng agan IS3 IS2 IS3 2 sec:,, IS TIME (sec) 23 & etrgger, then IS2 goes IS3 IS2 IS3 3 sec:, IS TIME (sec) IS3 IS2 IS3 IS2 43 sec: TIME (sec) 24

13 IS Latency The Math In general, hgher prorty nterrupts ght run ultple tes! Assue N dfferent nterrupts sorted by prorty ( s hghest; N- s lowest) Want latency of nterrupt latency latency ax j latency ISte j ISte j ISs ISperod Very slar to equaton for an loop What t s sayng s true for anythng wth preepton plus ntal blockng te:. You have to wat for one worst-case task at sae or lower prorty to coplete 2. You always have to wat for all tasks wth hgher prorty, soetes repeated j j 25 Another Approach Everythng n Interrupts What f everythng n our syste s te senstve? Another way to organze thngs s put everythng n nterrupts You don t really want to do ths!!! (we ll see why soon) BUT, t gves nsght nto the schedulng ath and varous optons set up nterrupts here // an progra loop for(;;) { // could just do nothng! } // nterrupt prorty s n devce order (#2 s IS ) vod nterrupt 2 handle_devce(vod) { } vod nterrupt 2 handle_devce(vod) { } vod nterrupt 22 handle_devce2(vod) { } vod nterrupt 23 handle_devce3(vod) { } 26

14 27 General Latency For Prortzed Tasks Ths s for the non-preeptve case (tasks can t be pre-epted) True of nterrupts that don t clear the I bt True of an loop as well t s effectvely the lowest prorty task (task N) Notaton: Each task s nubered ; = s hghest prorty; =N- s lowest You know how long each task takes to execute (at least n worst case) C You know perod of nterrupt arrval (worst case) P Interrupts are never dsabled by an progra Interrupts are non-preeptve (once an IS starts, t runs to copleton) s response te te untl starts executon, sae as prevous latency equaton; just cleaner notaton ; ; ax,,,, C P N C k k j N j 28 Exaple esponse Te Calculaton What s the esponse Te for task 2? Note: N=4 (tasks..3) Have to wat for task 3 to fnsh (longest executon te) Have to wat for two executon of task Have to wat for one executon of task ax 2,, 2, 2,2, 2, 2, 3 2, 4 2 C P C P C C j j Task# Perod (P ) Executon Te (C )

15 Math Dfferences For Cobned Syste cobned (nforal ter) = nterrupts + an loop Back to the cyclc executve plus ISs Man loop can be pre-epted (nterrupted) by ISs consder ths task N ISs don t have to wat for an loop copleton but an loop does have to wat for ISs! Math for esponse te IS ath alost unchanged but now have to worry about blockng te B Man loop has to fnsh current nstructon (what f t s a ultply nstructon?) Man loop ght have nterrupts dsabled; B = axu te for ths to happen,, k ax ax C j N, j, B P, k C ; N ; 29 Back To Man Loop esponse Te esponse te for an loop s te to coplete a cycle If data changes just after do_task() starts executng, have to assue wat untl next start of do_task() to do the new coputaton In general, f we assue an loop s task N, response te s one an loop N, N, k C N N, N N P, k C Ths s sae equaton as earler, but wth cleaned up notaton 3

16 Back To The Bg Pcture We ve been buldng up a fraework for non-preeptve schedulng Tasks run to copleton; also called cooperatve task schedulng When one task copletes, task at next hgher prorty executes Any te you have ISs, probably ths s the type of schedulng you need to know! Schedulng suary for response te You always have to wat for one ntal blockng perod Often s the longest executon lower-prorty task Could be soethng else that sets nterrupt ask flag You have to wat for all hgher prorty tasks And, even worse, soe ght execute ultple tes! Assuptons! Syste doesn t get overloaded task copletes before next te task executes Tasks are perodc and you know the worst-case perod P You know the worst-case copute te for each task C You re wllng to schedule for the worst case, perhaps leavng CPU dle n other cases 3 Why Do We Need More Than Ths? Cyclc Exec can be enough Mostly used when CPU s so fast, everythng can be run faster than external world changes Background task plus ISs coonly used Works as long as each IS can be kept short Works as long as everythng that needs to be fast can be put n IS But, here s the rub Low Prorty ISs and Blockng Te esponse te donated by longest IS, even f low prorty esponse te donated by I ask beng set n an progra ( blockng ) So ths only really works f nterrupts are short and an progra can be slow Proble f you need a coplex IS! Proble f you need to dsable nterrupts! But for now, let s look at how people usually ake ths work 32

17 eal Te Syste Pattern Man Plus IS IS does nu possble work to servce nterrupt Man progra loop processes data later, when there s te // an progra loop for(;;) { <detaled servce for devce > <detaled servce for devce > <detaled servce for devce N-> <other background tasks> } // nterrupt prorty s n devce order (#2 s IS ) vod nterrupt 2 handle_devce(vod) { } vod nterrupt 2 handle_devce(vod) { } vod nterrupt 23 handle_devce<n->(vod) { } 33 Exaple Keepng Te Of Day Syste ght need te of day n hours, nutes, seconds Naïve approach do the coputaton n the IS equres dvson and odular arthetc The proble s that ths slows IS, ncreasng ax response te Here s the bg-is approach (we re gong to gnore setup for TOI you ve seen ths before) // current te volatle unt64 ter_val; // assue ntalzed to current te volatle unt8 seconds, nutes, hours; volatle unt6 days; vod nterrupt 6 ter_handler(vod) // TOI { TFLG2 = x8; ter_val += xc6; // 6 bts fracton; 48 bts ntgr seconds = (ter_val>>6)%6; nutes = ((ter_val>>6)/6)%6; hours = ((ter_val>>6)/(6*6))%24; days = (ter_val>>6)/(6*6*24); } 34

18 Keepng The Te Of Day IS Sknny volatle unt64 ter_val; // assue ntalzed to current te volatle unt8 seconds, nutes, hours; volatle unt6 days; vod an(vod) { ntalzaton for(;;) { update_tod(); do_task(); do_task2(); } } vod update_tod() { DsableInterrupts(); // avod concurrency bug ter_tep = ter_val>>6; EnableInterrupts(); seconds = (ter_tep)%6; nutes = ((ter_tep)/6)%6; hours = ((ter_tep)/(6*6))%24; days = (ter_tep)/(6*6*24); } Want ths here nstead of at end of subroutne to nze Blockng Te B vod nterrupt 6 ter_handler(vod) // TOI { TFLG2 = x8; ter_val += xc6; // 6 bts fracton; 48 bts ntgr } // blockng te of IS no longer ncludes dvson operatons! 35 Sknny ISs General dea Move everythng you can to a perodcally run an routne Keep only the bare nu n the IS Usually aounts to storng nfo soewhere for an loop to process later Advantages: educes blockng te of that IS, provng response te Dsadavantages; ssues: It only takes ONE long IS to gve bad blockng te for whole syste! So all the ISs have to be sknny! It feels lke ore work than wrtng long ISs (f you thnk that s work, try debuggng a syste wth rando tng falures!) 36

19 Deprecated Alternatve ISs wth CLI If you have a long IS, why not just re-enable nterrupts? vod nterrupt 6 ter_handler(vod) // TOI { TFLG2 = x8; ter_val += xc6; // 6 bts fracton; 48 bts ntgr #as CLI ; re-enable nterrupts ** BAD IDEA! ** #endas seconds = (ter_val>>6)%6; nutes = ((ter_val>>6)/6)%6; hours = ((ter_val>>6)/(6*6))%24; days = (ter_val>>6)/(6*6*24); } What does ths do? CLI enables nterrupts (sae as EnableInterrupt() call) In GCC use keyword volatle tells copler don t ove ths nstructon around!!! 37 Why Is CLI A eally Bad Idea? What t does f you are careful: e-enables nterrupts whle IS s stll executng TI re-re-enables nterrupts (so ths stll works OK) Blockng te s now fro start of IS untl CLI executes not whole IS So, t s as f you had a shorter IS Makes sure that TOD s updated edately, even n ddle of an loop So why s t a proble? Soe current systes use just ths approach, but t s a bad dea Proble : what f nterrupt re-trggers before end of IS? Need to ake IS re-entrant (ore on ths later) notorously easy to get wrong If IS can occur n bursts, overflowng stack Proble 2: what f IS s changng eory locatons used by another IS? Very trcky to debug f ultple ISs fght over resources and can be nterrupted and desgners ss ths knd of thng because ISs aren t n an flow of code Proble 3: causes prorty nverson f lower prorty nterrupt hts Lower prorty IS copletes before hgher prorty IS! Botto lne ths approach has btten desgners too often; avod t 38

20 evew Cyclc executve Put everythng n one bg an loop OK f loop s fast and external world s slow Scatter hgh-frequency tasks repeatedly throughout anloop esponse te for cyclc exec wat for loop to go all the way around ISs only Prortzed IS response te ncludes: execute worst case blockng task, plus possbly ultple nstances of hgher prorty ISs Hybrd Man Loop + ISs Pretty uch the sae ath, wth an loop as task N Avod CLI n an IS f possble t s the Dark Sde Of The Force Overall yes, we expect you to know these equatons on your own! If you know the prncples, the equatons follow, but eorze f you have to These equatons are a really Good Thng to put on your test notes sheet 39 These equatons are portant:,, k ax ax C j N, j, B P, k C ; N ; N, N, k C N N, N N P, k C

21 Worst Case Interrupt esponse Te Draft, Fall 27 Phlp Koopan Carnege Mellon Unversty Copyrght 27, Phlp Koopan eproducton and dssenaton beyond students of CMU ECE s prohbted.. Overvew: Interrupt Servce outnes (ISs) are coonly used to provde fast response tes to external events or ted events. Because the pont of provdng fast response s to eet deadlnes, t s portant to know the worst case executon te of ultple concurrent nterrupts copetng for processor resources. The usual schedulng theory ath doesn t work that well for ths case because ost schedulng theory assues preeptve task swtchng, whle ISs are usually wrtten to be non-preeptve (.e., nterrupts rean asked whle the IS s runnng). Ths s an nstance of the ore general proble of deternng the axu response te for a prortzed, non-preeptve taskng envronent. 2. Iportance: If only a sngle nterrupt s used n a syste, deternng nterrupt servce latency s relatvely easy. However, f ultple prortzed nterrupts can occur, then soe wll be servced quckly, and others wll be servced ore slowly. There wll be soe worst-case stuaton n whch lower prorty nterrupts wll have to wat for one (or ore) executons of all hgher prorty nterrupts. Ensurng that the worst case latency of lower prorty nterrupts s fast enough to eet real te requreents s an portant analyss ssue. Unfortunately, t s often dffcult or possble to create worst-case stuatons n a testng stuaton, so analytc approaches ust be used to ake sure that testng doesn t ss a partcularly bad tng proble. The IS response scenaro s an nstance of the ore general stuaton of a prortzed cooperatve schedulng taskng syste. In such a syste each task has a prorty, but tasks run to copleton (.e., tasks are non-preeptve). 3. Graphcal Approach For ths dscusson, we assue that there s a collecton of prortzed tasks that needs to be executed perodcally. Those tasks could be ISs, threads, processes, or any xture of the above so long as there s a statc total orderng of prorty across all tasks (.e., fxed task prorty). Ths would be the case, for exaple, for prortzed ISs whch keep nterrupts asked whle executng, deferrng any hgher prorty nterrupt servcng untl the currently executng IS has 27, Phlp Koopan Interrupt esponse Te

22 copleted. Ths s usually how prortzed nterrupts are executed. (The excepton s when a software developer explctly re-enables nterrupts durng an IS, but that s usually bad practce.) Frst, let s work out an exaple graphcally to understand what s nvolved. Consder the below exaple task set ncludng prortzed nterrupts, executon tes, and perods: takes 5 sec to execute and occurs at ost once every 5 sec takes 6 sec and occurs at ost once every 2 sec IS2 takes 7 sec and occurs at ost once every sec IS3 takes 9 sec and occurs at ost once every 25 sec IS4 takes 3 sec and occurs at ost once every 6 sec where s the hghest prorty and IS4 s the lowest prorty. No IS can preept any other IS. When an IS copletes executon, the hghest prorty IS that s ready to execute wll execute next. We assue that any underlyng tasks don t dsable nterrupts. There are a nuber of other assuptons we are akng to splfy ths analyss, but those wll be dscussed later n the analytc approach secton. The frst queston we want to ask s, what s the worst case latency for IS2? For exaple f IS2 ust coplete wthn 5 sec of the te the nterrupt s frst requested, s there a case where that won t happen? The proble s that IS2 s not the only task runnng other ISs are copetng for processor resources. A bad case s when another lower prorty task than IS2 has just started to run when IS2 s trggered for executon. In partcular, the worst case s when the task wth the longest runnng te havng lower prorty than IS2 has just started to run. For ths task set that s IS3 (IS3 and IS4 are both lower prorty than IS2, but IS3 has a uch longer run te of 9 sec copared to the 3 sec run te of IS4). Why dd we pck a lower prorty nstead of a hgher prorty nterrupt to start wth? The reason s that n the worst case, the CPU wll be unavalable for a whle when an nterrupt arrves, causng other nterrupts to ple up before the one we are nterested even has a chance to copete for CPU te. Because no nterrupt wth lower prorty wll execute after IS2 becoes ready to run, selectng one wth a lower prorty adds ore work to the tasks that ust be copleted before IS2 can be started. We ll take all the hgher prorty nterrupts nto account shortly. But once IS2 s ready to run, no lower prorty nterrupt can run, so only one such low prorty nterrupt need be consdered, and the longest executon te one s the worst case. IS3 IS2 IS3 9 sec:,, IS TIME (sec) Fgure. IS3 Executes before,, and IS2 are trggered. 27, Phlp Koopan 2 Interrupt esponse Te

23 Now we have a stuaton where IS3 ght get to run before IS2 by just beatng t to the CPU. Beyond that, t s possble that every hgher prorty nterrupt than IS2 starts just after IS3 starts, but before IS3 ends, so they could also get to run before IS2 as well. Fgure shows ths stuaton, wth IS3 startng to run, followed quckly by,, and IS2 beng trggered. The tes at whch and can be retrggered are also shown n Fgure, snce as we wll fnd out they ght have to be servced one or ore tes before IS2 fnally gets a chance to run. When IS3 fnshes executng at 9 sec, all three of,, and IS2 are pendng. Snce s the hghest prorty task, t goes frst, followed by. Whle s executng, s trggered a second te at 5 sec, and s trggered agan at te 2 sec. Nether of these events dsturbs the executon of snce t s non-preeptable (nterrupts are asked whle executng ISs). Ths leads to a stuaton at te 2 where all three of,, and IS2 are stll pendng (Fgure 2). IS3 IS2 IS3 2 sec:,, IS TIME (sec) Fgure 2. By the te and run once, they have been retrggered. At 2 sec, s the hghest pendng task, so t executes agan, and s agan followed by, at 25 sec. then retrggers at 3 sec, but has not yet trggered agan. So at 3 sec when ends, only and IS2 are pendng (Fgure 3). IS3 IS2 IS3 3 sec:, IS TIME (sec) Fgure 3. At 3 sec, has retrggered and IS2 s stll pendng, but t s not te for yet. At 3 sec s stll the hghest prorty nterrupt pendng, so t runs untl 36 sec (Fgure 4). 27, Phlp Koopan 3 Interrupt esponse Te

24 IS3 IS2 IS3 36 sec: IS TIME (sec) Fgure 4. At 3 sec, and IS2 are pendng, so runs agan. At 36 sec, has copleted executon and s no longer pendng (t won t be trggered agan untl 45 sec). Moreover, s not due to run untl 4 sec. Ths leaves IS2 as the only task pendng, so t starts executon and runs untl 43 sec. By 43 sec has retrggered, so t starts runnng (Fgure 5), but does not nterfere wth the copleton of IS2 because nterrupts are non-preeptable once started. Thus, n the worst case, IS2 copletes at 43 sec after t s trggered. IS3 IS2 IS3 IS2 43 sec: TIME (sec) Fgure 5. At 36 sec, IS2 s the only task stll pendng, so t fnally gets to execute. 4. Analytc Approach Now that we have seen the types of coplcatons that can arse when ultple tasks copete for CPU te, we can take a ore rgorous, atheatcal, approach to the analyss. In ths secton we ll create a set of equatons that coputes the worst case latency for any task n a set of tasks. These equatons can be used to deterne f each task n the set wll eet ts own partcular deadlne. The followng notaton s used n the equatons below: T : Task : esponse te of Task, whch s the worst-case te between when T s ready to start executng and the te t actually starts executon. W : Copleton te of Task C : Coputaton te for one executon of T (worst case largest possble C ) 27, Phlp Koopan 4 Interrupt esponse Te

25 P : Perod for executon T (worst case fastest possble P ). If the task s aperodc, then assue a P correspondng to shortest possble te between any two executons of T (.e., recprocal of worst case shortest nter-arrval te of task executons). D : Deadlne for T B : Blockng te caused by background tasks that ask nterrupts, or other dependences. x : floor functon; rounds x down to next lowest nteger The followng assuptons are used n the equatons below as a startng pont: There are prortzed N tasks, nubered through N-, wth Task called T. In the prevous exaple, each IS handler was a task. Any other tasks runnng on the coputer are referred to as background tasks. Background tasks nterfere wth Tasks through N- only va dsablng nterrupts or task swtchng for soe axu blockng te B. (Blockng te was not shown n the precedng graphcal exaple.) Tasks are statcally prortzed, wth Task beng the hghest prorty and Task N- beng the lowest Each task T executes only when no other task wth hgher prorty s ready to execute, then runs to copleton wthout stoppng (.e., tasks are non-preeptable). If no task T s ready to execute, then background tasks are run untl soe task T s trggered to run. Any task T can and wll preept any background tasks, possbly wth a delay caused by blockng te. (For exaple, ISs preept any non-is code.) Each task s trggered for executon no faster than once per stated perod. Moreover, the perod represents the worst-case nu nter-arrval te between trggers for that task to execute. The perod of each task ay be dfferent. The worst-case longest copute te for each task s known and used n the calculatons. The deadlne for each task s known, and s less than or equal to that task s perod. The cost of changng tasks (e.g., processng an nterrupt and correspondng TI nstructon) s accounted for n the worst-case copute te. The values we are nterested n fndng are the copleton tes of all tasks. For a syste to perfor properly, all tasks ust coplete ther work W at or before the applcable deadlne D. So, the ultate goal s to ensure that: () ( W D ) Whch states: for all values of, the copleton te of Task s less than or equal to the deadlne of Task (.e., all tasks coplete before ther deadlne). The copleton te of a task has two coponents: the te spent watng to start executon (the response te ) and the te spent actually dong the work of the task (the coputaton te C ). (2) W = + C In the systes we re lookng at, tasks are non-preeptable, so once the coputaton of a task starts, that task runs to copleton. Thus, C s a known constant value. But, s trcker, because t ust take nto account the fact that Task has to wat for all hgher prorty tasks to execute and also wat for any blockng te. For exaple, f Task 4 s an IS, that IS can t execute untl any nterrupt askng n the an progra s copleted (.e., blockng te B) and all hgher prorty nterrupts,, 2, and 3 execute at least one te (because n the worst case all four of those 27, Phlp Koopan 5 Interrupt esponse Te

26 nterrupts were trggered just after the begnnng of the blockng te such a sall delay that we wll just be conservatve and consder t to be zero elapsed te n our equatons). Accountng for blockng te starts the buld-up of equatons to obtan : (3) B By ths we ean that s at least as long as the blockng te, but possbly longer. Now let us consder Task. Is B the only factor that could delay the start of executon? Even though ths s the hghest prorty task n the syste, there s soethng else that can delay t. The other factor s soe other task wth a lower prorty that has already begun executon, because tasks are non-preeptable (once started, they run to copleton). The worst case s that the task wth the longest possble coputaton te has just started executon, and ust coplete before Task can run. In other words, a lower prorty task can delay executon of a hgher prorty task because t s allowed to run to copleton. Ths, n effect, s a dfferent for of blockng. In general, for Task, t s possble for soe task wth a hgher task nuber (.e., lower prorty) to be executng, delayng the start of Task. Thus, (4) ax < j< N N ( C ) j Ths eans that the response te for Task ust be at least as bad as the worst case wat caused by the longest coputaton te of any Task j wth a lower prorty than Task. Task tself s not consdered, because we assue that the deadlne for each task s longer than ts perod, so Task ust have copleted executon before t attepts to execute agan. For task N-, whch s the lowest prorty task that sn t a background task, ths delay s zero, snce there s no lower prorty task to get n the way (but, even ths task s subject to blockng te fro the background tasks). Next, we cobne the two startng factors of B and axu C j to get an ntal lower bound on response te. But rather than addng the, we can sply take the axu of the two, because both stuatons can t happen at the sae te. Consder the two possble stuatons. Stuaton (): If a task has to wat for blockng te B, then that eans a task T sn t already runnng (because blockng can only occur due to a task other than Tasks..N- executng). If that s the case, as soon as blockng has fnshed, the hghest prorty task wll begn executng as soon as blockng s over. Ths akes t possble for a task wth lower prorty than Task to delay the start of task after blockng. If Task sn t ready to execute when blockng s copleted, then the blockng te hasn t delayed ts response te, snce t wasn t ready to run. Stuaton (2): If Task j, wth lower prorty than Task, s already executng, then blockng can t occur, because when Task j copletes, Task (or soe task wth hgher prorty) wll edately start executng rather than the background tasks. The background tasks that can cause blockng won t resue executon untl all prortzed tasks, ncludng Task, coplete executon. So, let s defne the effectve blockng te B as: ( ) (5) B' = ax ax C j, B ; < N < j< N B' = B ; otherwse 27, Phlp Koopan 6 Interrupt esponse Te

27 Ths eans that the response te for Task s bounded by an effectve blockng te B, whch s the longest lower prorty task that ght execute, or the blockng te B. Because there s no lower prorty task than Task N-, then blockng te B s the only ssue for that partcular task. For Task, our response te calculaton s done. Because there are no hgher prorty tasks, Task wll run to copleton once the effectve blockng effect has passed (ether watng for background task blockng B or the longest lower prorty task to coplete). (6) = B' The next factor n response te calculatons s that hgher prorty tasks can execute before lower prorty tasks. In the worst case, Task wll have to wat for every possble Task wth hgher prorty to execute at least once. Fro ths pont on, the response te wll have to be coputed teratvely to account for the fact that enough te ay pass for hgh prorty tasks to re-trgger. We ll use the notaton,k to represent the kth teraton of the coputaton for, wth the coputaton terated by ncreasng k untl the answer converges to a fnal value. To keep thngs sple, and confor to the graphc approached used prevously, we start the teraton wth the effectve blockng value B : (7), = B' Next, we have to account for the executon te of all tasks wth hgher prorty than Task, because t s possble all of the trggered just as Task was trggerng. The nuber of tes a partcular Task executes n te T s one ore than the rounded-down (nteger floor functon) nuber of tes the response te,k can be dvded by the perod of Task : (8) executons T = + P For exaple, wth a perod of 7 and an elapsed te of 22, a task could have been trggered not 22/7 = 3.4 tes, but rather that nuber rounded down, whch s 3, plus to account for the fact the task ust assued to have been trggered at te zero, whch gves a total of 4 tes (.e., at tes, 7, 4, and 2 sec). (Note that a celng functon ght see attractve nstead of the floor functon. But, the celng functon doesn t qute work f a response te s an exact ultple of a perod.) Once the nuber of executons s known, the aount of delay that hgher prorty Task causes to the watng Task by the te Task s ready to run s the nuber of executons of Task that have taken place by tes the coputaton te of Task : (9) delay executons C = = + P C 27, Phlp Koopan 7 Interrupt esponse Te

28 The aount of te that s taken by each executon s the task s coputaton te C. Therefore, the total aount of watng te for Task caused by watng for hgher prorty tasks s the su across all those tasks: () = = P + C ; > We stll need to account for the ntal effectve blockng te before any of those hgh prorty tasks can execute, so the coplete equaton s: () = ' + = B = P + C ; > But, here s the trcky part. The aount of te durng whch other tasks can execute depends on the te spent watng t s a recursve equaton wth appearng on both sdes. In ths case, we can break the recurson by sply usng an teratve evaluaton, where we keep re-evaluatng for longer and longer tes untl the result converges to a fnal value. (If the result doesn t converge, that eans Task wll never execute n the worst case.) (2),, = ' + = k + ; k B C > + = P The response te s the result of teratng the above untl t converges, whch s obtaned by takng the lt of,k as k approaches nfnty. As a practcal atter the process only needs to be repeated untl the sae answer s obtaned on two successve teratons. (3) ( ) = l, k k The worst case copleton te W s then the worst case response te plus the executon te of Task : (4) k (, k ) C W = + C = l + As a render, we are assue the tasks are non-preeptable, so t s not possble for another task to nterrupt the executon of Task once t has started. 27, Phlp Koopan 8 Interrupt esponse Te

29 Ths copletes all the peces we need. To recap, below s the fnal set of workng equatons: B' D, =, k + = B' + = W k ( C ), = ax ax j B < j< N = B' ; > = l P, k (, k ) + C ; < N + C ; > Wth the followng equatons applyng nstead of the above for soe specal cases: B' N = B = B' Fgure 6. Suary of equatons. 5. Exaples After all ths, we can get the answer to whether tasks wll eet ther deadlnes by coputng W for all tasks. Let s do ths usng the exaple fro the prevous graphcal analyss and see how the equatons work. Let us revst the prevous exaple and see f the analytc approach yelds the sae result as the graphcal approach. The exaple we used was: N=5 B= takes 5 sec and occurs at ost once every 5 sec; C = 5 ; P = 5 takes 6 sec and occurs at ost once every 2 sec; C = 6 ; P = 2 IS2 takes 7 sec and occurs at ost once every sec; C 2 = 7 ; P 2 = IS3 takes 9 sec and occurs at ost once every 25 sec; C 3 = 9 ; P 3 = 25 IS4 takes 3 sec and occurs at ost once every 6 sec; C 4 = 3 ; P 4 = B= exaple For B=, let s fnd the worst case copleton te of IS2, whch s W 2. B' 2 = ax ax ( C ), ax ax ( 3, 4 ), j B = C C B = ax[ 9,3,] = 9 2< j < 5 2, = B' 2 = 9 Gven ths startng pont (whch corresponds to Fgure ), we us 2, =9 to terate,k : 27, Phlp Koopan 9 Interrupt esponse Te

30 2,, 2, 2, = ' 2 + = k B + C = B' C + + C = = P P P = = = 2 Note that P 2, s 2 sec, whch s the sae result as Fgure 2. Fro ths, t becoes evdent that the teratve equaton s dong the sae thng atheatcally that we dd graphcally n the prevous approach. 2, 2, 2 2 2,2 = B' C + + C = = = P P Ths teraton brngs us to 3 sec, correspondng to the stuaton shown n Fgure 3. 2, 2, 3 3 2,2 = B' C + + C = = = P P Ths teraton brngs us to 36 sec, correspondng to the stuaton shown n Fgure 4 n whch all ISs wth hgher prorty than IS2 have just fnshed executon. 2,2 2, ,3 = B' C + + C = = = P P Because teraton 2,3 hasn t changed copared to 2,2, we can ternate the coputaton and know that addtonal teratons won t change the answer fro 36. Ths gves us a te to copleton of: whch s 43 sec, the sae answer shown n Fgure 5 and s the worst case copleton te. If the deadlne were 5 sec, ths task would always be able to eet ts deadlne under the gven assuptons B=3 Exaple As an exaple of what happens when the effectve blockng te s donated by background task blockng te rather than lower prorty tasks, consder what happens when B=3 sec nstead of sec: B' 2 = ax ax ( C ), ax ax ( 3, 4 ), j B = C C B = ax[ 9,3,3] = 3 2< j < 5 = B' = 3 2, ( ) + C = W2 = l 2, k 2 = k 2 27, Phlp Koopan Interrupt esponse Te

31 IS3 IS2 Blockng te B 3 sec: ; ; IS TIME (sec) Fgure 7. B=3 at te 3 sec. 2,, 2, 2, = ' 2 + = k B + C = B' C + + C = = P P P = = 24 IS3 IS2 Blockng te B 24 sec: ; ; IS TIME (sec) Fgure 8. B=3 at te 24 sec. 2, 2, ,2 = B' C + + C = = = P P IS3 IS2 Blockng te B 35 sec: ; IS TIME (sec) Fgure 9. B=3 at te 35 sec. 27, Phlp Koopan Interrupt esponse Te

32 2,2 2, ,3 = B' C + + C = = = P P IS3 IS2 Blockng te B 4 sec: ; IS TIME (sec) Fgure. B=3 at te 4 sec. 2,3 2, ,4 = B' C + + C = = = P P IS3 IS2 Blockng te B 46 sec: ; IS TIME (sec) Fgure. B=3 at te 46 sec. 2,4 2, ,5 = B' C + + C = = P P IS3 IS2 2 = 5 Blockng te B 5 sec: IS TIME (sec) Fgure 2. B=3 at te 5 sec. 27, Phlp Koopan 2 Interrupt esponse Te

33 2,5 2, ,5 = B' C + + C = = = P P At ths pont the coputaton has converged, so we know that IS2 wll start executon at te 5 sec. IS3 IS2 Blockng te B IS TIME (sec) Fgure 3. IS2 executes startng at 5 sec and endng at 58 sec for B=3. ( ) + C = W2 = l 2, k 2 = k Thus the graphcal and analytc technques both arrve at the sae answer n the sae way, and IS2 has a worst-case executon te of 58 sec for ths partcular case Other Exaples As further exercses, the reader should confr the followng results both graphcally and analytcally for ths exaple task set wth varous values of B: B= B=2 B=4 B=2 B=3 W = 4 W = 4 W = 4 W = 7 W = 8 W = 2 W = 2 W = 2 W = 28 W = 29 W 2 = 43 W 2 = 43 W 2 = 43 W 2 = 46 W 2 = 58 W 3 = 46 W 3 = 46 W 3 = 47 W 3 = 66 W 3 = 67 W 4 = 57 W 4 = 59 W 4 = 6 W 4 = 9 W 4 = 92 As an addtonal exaple, the graphcal results showng the tng for the B=2 case are below: 27, Phlp Koopan 3 Interrupt esponse Te

34 IS3 IS4 IS2 IS TIME (sec) Fgure 3. worst case latency for B=2. IS3 causes the longest effectve blockng te. IS3 IS4 IS2 IS TIME (sec) Fgure 4. worst case latency for B=2. IS3 causes the longest effectve blockng te. IS3 IS4 IS2 IS3 IS TIME (sec) Fgure 5. IS2 worst case latency for B=2. IS3 causes the longest effectve blockng te. 27, Phlp Koopan 4 Interrupt esponse Te

35 IS4 IS2 IS3 IS4 IS2 IS TIME (sec) Fgure 6. IS3 worst case latency for B=2. IS4 causes the longest effectve blockng te. Background Tasks Only IS2 IS3 IS4 B IS2 IS3 IS TIME (sec) Fgure 7. IS4 worst case latency for B=2. B s the longest effectve blockng te because there are no lower prorty nterrupts to process. 6. More Inforaton The ore generalzed proble ncludes coputng executon tes for both preeptve tasks runnng under an operatng syste and non-preeptve ISs. A descrpton of the ath for that ore general case can be found n: Y. Wang, M. Saksena, Schedulng fxed-prorty tasks wth preepton threshhold, IEEE Internatonal Conference on eal-te Coputng Systes and Applcatons, Deceber 999. Thanks to Jen Morrs Black for her research work n ths area. 27, Phlp Koopan 5 Interrupt esponse Te

36

37

38 8-348 Sprng 26 Md-Seester Inforal Course Feedback The offcal feedback systes don t gve us nforaton n te to ake d-course correctons. So we ve developed ths sple feedback for to ake sure you get a chance to nfluence how the reander of the course s run. You can put your nae on the sheet f you want a personal reply, but we ll read all the feedback carefully even f t s anonyous.. What s the one ost portant thng you d lke to see changed about ths course between now and the end of the seester? (Soe thngs we can change and soe we can t, but ost years soeone has an dea we can pleent rght away. So we wll serously consder what you say, and change thngs that we can do wthout breakng other aspects of the course.) 2. What s the thng you lke ost about ths course? Do you want to see us do ore of t, or s the extent about rght already? 3. Any other coents on the course?