Last Time. u Priority-based scheduling. u Schedulable utilization u Rate monotonic rule: Keep utilization below 69%

Transcription

1 Last Tme u Prorty-based schedulng Ø Statc prortes Ø Dynamc prortes u Schedulable utlzaton u Rate monotonc rule: Keep utlzaton below 69%

2 Today u Response tme analyss u Blockng terms u Prorty nverson Ø And solutons u Release jtter u Other extensons

3 Response Tme vs. RM u Rate monotonc result Ø Tells us that a broad class of embedded systems meet ther tme constrants: Scheduled usng fxed prortes wth RM or DM prorty assgnment Total utlzaton not above 69% Ø However, doesn t gve very good feedback about what s gong on wth a specfc system u Response tme analyss Ø Tells us for each task, what s the longest tme between when t s released and when t fnshes Ø Then these can be compared wth deadlnes Ø Gves nsght nto how close the system s to meetng / not meetng ts deadlne Ø Is more precse (rejects fewer systems)

4 Computng Response Tme u WC response tme of hghest prorty task R 1 Ø R 1 = C 1 Ø Hopefully obvous u WC response tme of second-prorty task R 2 Ø Case 1: R 2 T 1 R 2 = C 2 + C 1 R 1 R 2 T 1 T

5 More Second-Prorty u Case 2: T 1 < R 2 2T 1 Ø R 2 = C 2 + 2C 1 T 1 R 2 R 1 2T 1 T u Case 3: 2T 1 < R 2 3T 1 Ø R 2 = C 2 + 3C 1 u General case of the second-prorty task: Ø R 2 = C 2 + celng ( R 2 / T 1 ) C 1

6 Task Response Tme u General case: R = C + j hp() R Tj C j u hp() s the set of tasks wth prorty hgher than I Ø Only hgher-prorty tasks can delay a task u Problem wth usng ths equaton n practce?

7 Computng Response Tmes u Rewrte as a recurrence relaton and solve by teratng: R u Fnshed when R n+1 = R n Ø Or when R n > D n+ 1 = u Choose R 0 = 0 or R 0 = C Ø There may be many solutons to the recurrence C Ø These startng ponts guarantee convergence to the smallest soluton (unless there s dvergence) u Result s nvald f R > T Ø Why? + j hp( ) R T n j C j

8 Response Tme Example u Task 1: T = 30, D = 30, C = 10 u Task 2: T = 40, D = 40, C = 10 u Task 3: T = 52, D = 52, C = 12 u Utlzaton = 81% Rejected by the rate monotonc test! R n+ 1 = C + j hp( ) R T n j C j u R 1 = 10 u R 2 = 20 u R 3 = 52

9 Sharng Resources u So far tasks are assumed to be ndependent Ø Not allowed to block (e.g. on a network devce) Ø Not allowed to contend for shared resources u Bg problem n practce! u Soluton: Ø Compute worst-case blockng tme for each task Ø Longest tme that task s delayed by a lower-prorty task Ø Why just lower prorty? u Now we can analyze the system agan: R n+ 1 = C + B + j hp( ) R T n j C j

10 Computng Blockng Terms u How do we compute blockng terms? Ø Depends on the synchronzaton protocol u Tasks synchronze by dsablng nterrupts Ø Best answer: Each task gets blockng term wth length of the longest crtcal secton n a lower-prorty task Ø Smpler answer: Each task gets blockng term wth length of the longest crtcal secton n any task Ø Why do these work? u Tasks synchronze usng mutexes Ø Blockng term generally mpossble to bound oops! Ø Standard thread locks are unfrendly to real-tme systems Lock wat queue s FIFO Ø Possble soluton: Prorty queues for mutexes

11 Prorty Inverson u Prorty nverson: Low-prorty task delays a hgh prorty task Ø Mutexes (even wth prorty queung) provde unbounded prorty nverson preempton P(s) blocks T P(s) succeeds

12 Prorty Inverson Case Study u Mars Pathfnder Ø Lands on Mars July Ø Msson s successful u Behnd the scenes Ø Sporadc total system resets on the rover Ø Caused by prorty nverson Ø Debugged on the ground, software patch uploaded to fx thngs u Detals Ø Rover controlled by a sngle RS6000 runnng vxworks Ø Rover devces polled over 1553 bus Ø At 8 Hz bc_sched task sets up bus transactons Ø bc_dst task runs (also at 8 Hz) to read back data

13 More Pathfnder u Symptom: Ø bc_sched sometmes was not fnshed by the tme bc_dst ran Ø Ths trggered a system reset Should never happen snce these tasks are hgh prorty u Problem: bc_sched shared a mutex wth ASI/MET task, whch does meteorologcal scence at low prorty Ø Occasonally the classc prorty nverson happened when there were long-runnng medum prorty tasks u Soluton: Ø vxworks supports prorty nhertance wth a global flag Ø They turned t on

14 Prorty Inverson Solutons 1. Avod blockng dsable nterrupts nstead u u Pros: u Effcent u Smple Con: u Also delays unrelated, hgh prorty tasks 2. Immedate prorty celng protocol before lockng, rase prorty to hghest prorty of any thread that can touch that semaphore u u Pros: u Farly smple u Less blockng of unrelated tasks Cons: u Requres ahead-of-tme system analyss u Stll has some pessmstc blockng

15 Prorty Inverson Solutons 3. Prorty nhertance protocol When a task s blockng other tasks (by holdng a mutex) t executes at the prorty of the hghest-prorty blocked task u u Pros u No pessmstc blockng Cons u Complcated n presence of nested lockng u Not that effcent u Blockng terms larger than IPCP u Other solutons exst, such as lock-free synchronzaton

16 IPCP Bonus u In IPCP, rasng prorty prevents anyone else who mght access a resource from runnng Ø So why take a lock at all? Ø Turns out that lockng s not necessary rasng prorty s enough Ø HOWEVER: Task must not voluntarly block (e.g. on dsk or network) whle n a crtcal secton

17 Overheads u A real RTOS requres tme to: Ø Block a task Ø Make a schedulng decson Ø Dspatch a new task Ø Handle tmer nterrupts u For a well-desgned RTOS these tmes can be bounded Ø Worst-case blockng tme of the RTOS needs to be added to each task s blockng term Ø 2x worst-case context swtch tme needs to be added to each task s WCET We always charge the cost of a context swtch to the hgher-prorty task

18 Release Jtter u Release jtter J Tme between nvocaton of task and tme at whch t can actually run Ø E.g. task becomes conceptually runnable at the start of ts perod But must wat for the next tmer nterrupt before the scheduler sees t and dspatches t Ø Or, task would lke to run but must wat for network data to arrve before t actually runs R = C + B + j hp() R + Tj J C j

19 Other Extensons u Sporadcally perodc tasks Ø Task has an outer perod and smaller nner perod Ø Models bursty processng lke network nterrupts u Sporadc servers Ø Provde rate-lmtng for truly aperodc processng E.g. nterrupts from an untrusted devce u Arbtrary deadlnes Ø When D > T prevous equatons do not apply Ø Can rewrte u Precedence constrants Ø Task A cannot run untl Task B has completed Models scenaro where tasks feed data to each other Ø Makes t harder to schedule a system

20 Summary u Prorty based schedulng Ø It s what RTOSs support Ø A strong body of theory can be used to analyze these systems Ø Theory s practcal: Many real-world factors can be modeled u Response tme analyss supports worst-case response tme for each prorty-based task Ø Blockng terms Ø Release jtter u Prorty nverson can be a major problem Ø Solutons have nterestng tradeoffs