Lecture #5: the Rate-Monotonic Theory for Real-Time Scheduling

EEM202A/CSM213A - Fall 2011

Lecture #5: The Rate-Monotonic Theory for Real-time Scheduling

Mani Srivastava [email protected] Networked & Embedded Systems Lab UCLA

• MANDATORY READING ‣ L. Sha, R. Rajkumar, S.S. Sathaye. Generalized rate-monotonic scheduling theory: a framework for developing real-time systems. Proceedings of the IEEE, vol.82, (no.1), p.68-82, Jan. 1994. - http://ieeexplore.ieee.org/iel1/5/6554/00259427.pdf?arnumber=259427 ‣ L. Sha, R. Rajkumar, and J.P. Lehoczky. Priority inheritance protocols: an approach to real-time synchronization. IEEE Transactions on Computers, vol.39, (no.9), Sept. 1990. p.1175-85. - http://beru.univ-brest.fr/~singhoff/cheddar/publications/sha90.pdf

• RECOMMENDED READING ‣ C.L. Liu, and J.W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the Association for Computing Machinery, vol.20, (no.1), Jan. 1973. p. 46-61. - http://citeseer.ist.psu.edu/liu73scheduling.html ‣ J. Lehoczky, L. Sha, and Y. Ding. The rate monotonic scheduling algorithm: exact characterization and average case behavior. Proceedings of Real Time Systems Symposium, p. 166-171, Dec. 1989. ‣ Enrico Bini, Giorgio Buttazzo and Giuseppe Buttazzo, "Rate Monotonic Analysis: The Hyperbolic Bound", IEEE Transactions on Computers, Vol. 52, No. 7, pp. 933-942, July 2003. - http://feanor.sssup.it/~giorgio/paps/2003/ieeetc-hb.pdf

2 Scheduling Tasks with Timing Constraints

• Allocate processor time to tasks so that critical timing constraints are met ‣ Tasks have an associated terminating function that needs to be executed

• Variants of the scheduling problem ‣ Statically known vs. dynamic task set ‣ Single vs. multiple processor ‣ One shot vs. repetitive - In repetitive, multiple instances (or requests) of a task arrive ‣ Sporadic vs. periodic ‣ Singe rate vs. multi-rate periodic tasks ‣ Stateless vs. stateful tasks ‣ Dependent vs. independents tasks ‣ Known vs. unknown arrival times

• This lecture: static priority based preemptive scheduling ‣ Single processor ‣ Known # of independent but stateful tasks with inﬁnitely many instances ‣ Arrival times of task instances are unknown but periodic with different rates

3 Computation & Timing Model of the System

• Requests for tasks for which hard deadlines exist are periodic, with constant inter-request intervals but otherwise unknown request arrival times • Run-time for each task is constant for that task, and does not vary with time ‣ can be interpreted as the maximum running time • Deadlines consist of runnability constraints only ‣ each task must ﬁnish before the next request for it ‣ eliminates need for buffering to queue tasks • Tasks are independent ‣ requests for a certain task does not depend on the initiation or completion of requests for other tasks ‣ however, their periods may be related • Other implicit assumptions ‣ No task can implicitly suspend itself, e.g. for I/O ‣ All tasks are fully preemptible ‣ All kernel overheads are zero

4 Formally Characterizing the Task Set

• Set Γ of n independent tasks τ1, τ2, … τn

• Request periods are T1, T2, ... Tn ‣ Request rate of τi is 1/Ti ‣ τi,j indicates j-th instance of i-th task (∀ j = 1, 2, …)

• Request phases R1, R2, ... Rn are unknown ‣ Ri represents the arrival time of τi,1 ‣ Task set is called concrete if all Ri are known, non-concrete otherwise ‣ Here we restrict to non-concrete task sets

• Run-times are C1, C2, ... Cn ‣ These are worst case execution time

• Relative deadlines are D1, D2, ... Dn ‣ Special case: Di == Ti

5 Scheduling Algorithm

• Set of rules to determine the task to be executed at a particular moment

• One possibility: Preemptive & priority driven ‣ Tasks are assigned priorities - Static or ﬁxed approach - priorities are assigned to tasks once for all - Dynamic approach - priorities of tasks may change from request to request - Mixed approach - some tasks have ﬁxed priorities, others don’t ‣ At any instant, the highest priority task is run - Whenever there is a request for a task that is of higher priority than the one currently being executed, the running task is interrupted, and the newly requested task is started

• Therefore, scheduling algorithm == method to assign priorities

6 Importance of Scheduling Algorithm

• Consider ‣ Task 1 with period T1 = 50 ms, and a worst-case execution time of C1 = 25 ms ‣ Task 2 with T2 = 100 ms and C2 = 40 ms. ‣ Each task instance should ﬁnish before the next instance of that task arrives

• CPU utilization, Ui, of task i is Ci/Ti, so that U1 = 50% and U2 = 40% ‣ This means total requested utilization U = U1 + U2 = 90%

• Is there enough CPU time?

7 http://www.netrino.com/Embedded-Systems/How-To/RMA-Rate-Monotonic-Algorithm Importance of Scheduling Algorithm

• CPU utilization, Ui, of task i is Ci/Ti, so that U1 = 50% and U2 = 40% ‣ This means total requested utilization U = U1 + U2 = 90%

• Is there enough CPU time?

7 http://www.netrino.com/Embedded-Systems/How-To/RMA-Rate-Monotonic-Algorithm Deriving Optimum Fixed Priority Assignment Rule

8 Critical Instant of a Task

• Deﬁnitions ‣ Response time of a request of a certain task is the time span between the request and the end of response to that task ‣ Critical instant for a task = time instant at which a request for that task will have the maximum response time ‣ Critical time zone of a task = time interval between a critical instant & the deadline of the corresponding request of the task

• Can use Critical Instant to determine whether a given priority assignment will yield a feasible scheduling algorithm ‣ If requests for all tasks at their critical instants are fulﬁlled before their respective deadlines, then the scheduling algorithm is feasible

• Theorem 1: A critical instant for any task occurs whenever the task is requested simultaneously with requests of all higher priority tasks

9 Example

• Consider τ1 & τ2 with T1=2, T2=5, & C1=1, C2=1 • Case 1: τ1 has higher priority than τ2 ‣ Priority assignment is feasible ‣ Can increase C2 to 2 and still avoid overﬂow

T1 T1 t t 1 2 3 4 5 1 2 3 4 5 T T2 t 2 t 1 2 3 4 5 1 2 3 4 5

CRITICAL TIME ZONE CRITICAL TIME ZONE

C2=1 C2=2 10 Example (contd.)

• Case 2: τ2 has higher priority than τ1 ‣ Priority assignment is still feasible ‣ But, can’t increase beyond C1=1, C2=1

T2 t 1 2 3 4 5

T1 t 1 2 3 4 5

CRITICAL TIME ZONE Case 1 seems to be the better priority assignment for schedulability… how do we formalize this?

11 Observation

• Consider τ1 & τ2 with T1 < T2 • Let, τ1 be the higher priority task. From Theorem 1, the following must hold: ⎣T2/ T1⎦C1 + C2 ≤ T2 (necessary condition, but not sufﬁcient) • Let, τ2 be the higher priority task. The following must hold: C1 + C2 ≤ T1 • Note: C1 + C2 ≤ T1 ⇒ ⎣T2/ T1⎦C1 + ⎣T2/ T1⎦C2 ≤ ⎣T2/ T1⎦ T1

⇒ ⎣T2/ T1⎦C1 + ⎣T2/ T1⎦C2 ≤ T2

⇒ ⎣T2/ T1⎦C1 + C2 ≤ T2 since ⎣T2/ T1⎦ ≥ 1

• Therefore, whenever T1 < T2 and C1, C2 are such that the task schedule is feasible with τ2 at higher priority than τ1, then it is also feasible with τ1 at higher priority than τ2 ‣ but opposite is not true

12 A Possible Rule for Priority Assignment

• Assign priorities according to request rates, independent of run times ‣ Higher priorities for tasks with higher request rates ‣ For tasks τi and τj, if Ti < Tj, Priority(τi) > Priority(τj)

• Called Rate-Monotonic (RM) Priority Assignment ‣ It is optimum among static priority based schemes

• Theorem 2: No other ﬁxed priority assignment can schedule a task set if RM priority assignment can’t schedule it, i.e., if a feasible priority assignment exists, then RM priority assignment is feasible

13 Intuitive Proof for RM Optimality

• Consider n tasks {τ1, τ2, … τn} s.t. T1 < T2 < …. < Tn • Let they be schedulable with non-RM priorities {Pr(1), …, Pr(n)} ‣ ∴ ∃ at least one pair of adjacent tasks, τp and τp+1, such that Pr(p) < Pr(p+1) [higher value is higher priority] • Swap the priorities of tasks τp and τp+1 ‣ New priority of τp is Pr(p+1), new priority of τp+1 is Pr(p) ‣ Note that Pr(p+1) > Pr(p) (by assumption 1) • Tasks {τ1, …, τp-1} should not get affected ‣ We are only affecting lower priority tasks • Tasks {τp+2, …, τn} should also not get affected ‣ Both τp and τp+1 need to be executed (irrespective of the order) before any task in {τp+2, …, τn} gets executed • Task τp should not get affected ‣ Since we are only increasing its priority

14 Proof (contd.)

• Consider τp+1: ‣ Since original schedule is feasible, in the time interval [0, Tp], exactly one instance of τp and τp+1 complete execution along with (possibly multiple) instances of tasks in {τ1, …, τp-1} - Note that τp+1 executes before τp. ‣ New schedule is identical, except that τp executes before τp+1 (start/ end times of higher priority tasks is same) - Still, exactly one instance of τp and τp+1 complete in [0, Tp]. Since Tp < Tp+1, task τp+1 is schedulable

Old schedule t {τ1, …, τp-1} Tp Tp+1 τp

New schedule t τp+1 Tp Tp+1 We have proven that swapping the priority of two adjacent tasks to make their priorities in accordance

with RM does not affect the schedulability (i.e., all tasks {τ1, τ2, … τn} are still schedulable) 15 Proof (contd.)

• If τp and τp+1 are the only such non RM tasks in original schedule, we are done since the new schedule will be RM • If not, starting from the original schedule, using a sequence of such re- orderings of adjacent task pairs, we can ultimately arrive at an RM schedule (Exactly the same as bubble sort) • E.g., Four tasks with initial priorities {3, 1, 4, 2} for {τ1, τ2, … τ4} {3 1 4 2} is schedulable

{3 4 1 2} is schedulable

RM priority {4 3 1 2} is schedulable assignment

{4 3 2 1} is schedulable

Hence, Theorem 2 is proved. 16 Processor Utilization Factor

• Processor Utilization Factor: fraction of processor time spent in executing the task set ‣ i.e. 1 - fraction of time processor is idle ‣ Provides a measure of computational load on CPU due to a periodic task set ‣ A task set is deﬁnitely not schedulable if its processor utilization factor is > 1

• For n tasks, τ1, τ2, … τn the utilization factor U = C1/T1 + C2/T2 + … + Cn/Tn

• U for a task set Γ can be improved by increasing Ci’s (slower processor) or decreasing Ti’s as long as tasks continue to meet deadlines at critical instants

• U=1 means that the processor is fully utilized ‣ processor is just fast enough, so that one is not overpaying in cost or energy

17 Limitations of Fixed-priority Scheduling

• It is not always possible to fully utilize the CPU

• Even though RMA is the optimal ﬁxed-priority scheme, it has a worst-case schedulable processor utilization bound that is < 1 ‣ The worst-case schedulable bound for one task is 100% ‣ But, as the number of tasks increases, the schedulable bound decreases, eventually approaching ln 2 (~ 69%)

• It is possible for a set of tasks to require just 70% CPU utilization and still not meet all their deadlines

T1=50, C1=25, T2=75, C2=30, U = 90% 18 How Large can U be for Fixed Priority Scheduling?

• For a given priority assignment, a set of tasks fully utilizes a processor if: ‣ the priority assignment is feasible for the set ‣ and, if an increase in the run time of any task in the set will make the priority assignment infeasible

• The U at which this happens is called the upper bound Uub(Γ,A) for a task set Γ under algorithm A

• The least upper bound of U is the minimum of the U’s over all task sets that fully utilize the processor ‣ for all task sets whose U is below this bound, ∃ a feasible ﬁxed priority assignment ‣ U above this bound can be achieved only if the task periods Ti’s are suitably related ‣ Ulub(Γ,A) = minΓ Uub(Γ,A)

• Ulub(Γ,A) is an important characteristic of a scheduling algorithm A as it allows easy veriﬁcation of schedulability of a task set ‣ Below this bound, a task set is deﬁnitely schedulable ‣ Above this bound it may be schedulable

19 Least Upper Bound of Processor Utilization

YES ? NO

Γ1 U Uub1

Γ2 U Uub2

Γ3

Uub3 U

Γ4

Uub4 U

Γm

Uubm U

U 1 lub 20 Utilization Factor for RM Priority Assignment

• RM priority assignment is optimal ‣ If a task set cannot be scheduled using the RMA algorithm, it cannot be scheduled using any static-priority algorithm

• ∴ for a given task set, the U achieved by RM priority assignment is ≥ the U for any other priority assignment

• ∴ the least upper bound of U = the inﬁmum of U’s for RM priority assignment over all possible T’s and all C’s for the tasks

21 Ulub for RM

• Theorem 3: For a set of two tasks with ﬁxed priority assignment, the least upper bound to processor utilization factor is U=2(21/2-1)

• Proof Sketch: ‣ Task set: τ1 = (T1, C1), τ2 = (T2, C2) where T2 > T1 - According to RM, τ1 has higher priority than τ2 ‣ In a critical time zone of τ2 - there are ⎡T2/T1⎤ requests for τ1

- there are F=⎣T2/T1⎦ periods of τ1 entirely contained in T2

‣ Adjust C2 to fully utilize the available processor time within the critical time zone

22 Two Tasks Case Proof (contd.)

• Case 1: C1 is short enough so that all • Case 2: The execution of the th requests for τ1 within the critical time ⎡T2/T1⎤ request for τ1 overlaps the zone of τ2 are completed before the next request for τ2, next request of τ2, i.e.,C1 ≥ T2-T1⎣T2/T1⎦ i.e., C1 ≤ T2-T1⎣T2 /T1⎦ ‣ Then, largest possible ‣ Then, largest possible C2 = (T1-C1) ⎣T2/T1⎦ C2 = T2 - C1⎡T2/T1⎤ ‣ So that, ‣ So that, U = (T1/T2) ⎣T2/T1⎦+ C1((1/T1)-(1/ U = 1 - C1((1/T2)⎡T2/T1⎤ - 1/T1 ) T2) ⎣T2/T1⎦) ‣ U monotonically decreases with C1 ‣ U monotonically increases with C1

23 Two Tasks Case Proof (contd.)

• The minimum U occurs at the boundary of cases 1 & 2, i.e. for C1 =T2-T1⎣T2/T1⎦

‣ U = 1-(T1/T2)(⎡T2/T1⎤-(T2/T1))((T2/T1)-⎣T2/T1⎦) = 1 - f(1-f)/(I+f) where I =⎣T2 /T1⎦

f = (T2/T1)-⎣T2 /T1⎦= fractional part of T2/T1 • U is monotonically increasing with I ‣ min U occurs at min value of I, i.e. I=1 • Minimizing U over f, one gets f = 21/2-1 • So, min U = 2(21/2-1) ≈ 0.83

• Note: U=1 when f=1, i.e. when period of lower priority task is a multiple of the period of the higher priority task

24 General Case

• Theorem: For a set of n tasks with ﬁxed priority assignment, the least upper bound to processor utilization factor is U=n(21/n-1) ‣ Or, equivalently, a set of n periodic tasks scheduled by RM algorithm will always meet their deadlines for all task start times if 1/n C1/T1 + C2/T2 + … + Cn/Tn ≤ n(2 -1)

• As n→∞, the U rapidly converges to ln 2 = 0.69 ‣ This is a rather tight bound ‣ But, note that this is just the least upper bound - task set with larger U may still be schedulable - e.g., note that if {Tn/Ti} = 0 for i=1,2,…,n-1, then U=1

• How to check if a speciﬁc task set with n tasks is schedulable? ‣ If U ≤ n(21/n-1) then it is schedulable ‣ otherwise, use Theorem 1!

25 Theorem 1 Recalled

• Theorem 1: A critical instant for any task occurs whenever the task is requested simultaneously with requests of all higher priority tasks

• Can use this to determine whether a given priority assignment will yield a feasible scheduling algorithm ‣ if requests for all tasks at their critical instants are fulﬁlled before their respective deadlines, then the scheduling algorithm is feasible

• Applicable to any static priority scheme… not just RM

26 Example #1

• Task τ1 : C1 =20; T1 =100; D1 =100 Task τ2 : C2 =30; T2 =145; D2 =145

Is this task set schedulable?

U = 20/100 + 30/145 = 0.41 ≤ 2(21/2-1) = 0.828

Yes!

27 Example #2

• Task τ1 : C1 =20; T1 =100; D1 =100 Task τ2 : C2 =30; T2 =145; D2 =145 Task τ3 : C3 =68; T3 =150; D3 =150

Is this task set schedulable?

U = 20/100 + 30/145 + 68/150 = 0.86 > 3(21/3-1) = 0.779

Can’t say! Need to apply Theorem 1.

• Consider the critical instant of τ3, the lowest priority task ‣ τ1 and τ2 must execute at least once before τ3 can begin executing ‣ therefore, completion time of τ3 is ≥ C1 +C2 +C3 = 20+68+30 = 118 ‣ however, τ1 is initiated one additional time in (0,118) ‣ taking this into consideration, completion time of τ3 = 2 C1 +C2 +C3 = 2*20+68+30 = 138 • Since 138 < D3 = 150, the task set is schedulable

28 Hyperbolic Bound for RM

• Feasibility analysis of RM can also be performed using a different approach, called Hyperbolic Bound ‣ Enrico Bini, Giorgio Buttazzo and Giuseppe Buttazzo, "Rate Monotonic Analysis: The Hyperbolic Bound", IEEE Transactions on Computers, Vol. 52, No. 7, pp. 933-942, July 2003. - http://feanor.sssup.it/~giorgio/paps/2003/ieeetc-hb.pdf

• Theorem: a set Γ of n periodic tasks with processor utilization Ui for the i-th task is schedulable with RM priority assignment if n ∏(Ui +1) ≤ 2 i=1 • Same complexity as Liu and Layland test but less pessimistic ‣ Shows than the bound is tight: best possible bound using individual task utilization factors ‣ Gain in terms of schedulability over the classical test is sqrt(2) for n tending to inﬁnity 29 Exact Response Time Analysis for RM: Necessary and Sufﬁcient Condition Test

• For the highest priority task, worst case response time R is its own computation time C ‣ R = C

• Other lower priority tasks suffer interferences from higher priority processes ‣ Ri = Ci + Ii ‣ Ii is the interference in the interval [t, t+Ri]

30 Response Time Analysis (contd.)

• Consider task i, and a higher priority task j • Interference from task j during Ri: ‣ # of releases of task k = ⎡Ri/Tj⎤

‣ each will consume Cj units of processor ‣ total interference from task j = ⎡Ri/Tj⎤ * Cj • Let hp(i) be the set of tasks with priorities higher than that of task i • Total interference to task i from all tasks during Ri:

31 Response Time Analysis (contd.)

• This leads to:

• Smallest Ri will be the worst case response time • Fixed point equation: can be solved iteratively

32 Algorithm

33 Digression: What is wrong with this test?

• What is wrong with the following test?

Ci + Ii ≤ Ti i−1 I = Ti C i ∑ T j j j =1 ⎡ ⎤

• It is sufﬁcient, but is it necessary?

34 RM Schedulability

• Consider tasks τ1, τ2, … τn in decreasing order of priority • For task τi to be schedulable, a necessary and sufﬁcient condition is that we can ﬁnd some t ∈ [0,Ti] satisfying the condition

t ≥ ⎡t/T1⎤C1 + ⎡t/T2⎤C2 + … ⎡t/Ti-1⎤Ci-1 + Ci

• But do we need to check at exhaustively for all values of t in [0,Ti]?

35 RM Schedulability (contd.)

• Observation: RHS of the equation jumps only at multiples of T1, T2, … Ti-1

• It is therefore sufﬁcient to check if the inequality is satisﬁed for some t ∈ [0,Ti] that is a multiple of one or more of T1, T2, … Ti-1

t ≥ ⎡t/T1⎤C1 + ⎡t/T2⎤C2 + … ⎡t/Ti-1⎤Ci-1 + Ci

36 RM Schedulability (contd.)

• Notation Wi(t) = Σj=1..iCj⎡t/Tj⎤

Li(t) = Wi(t)/t Li = min0 ≤ t ≤ Ti Li(t) L = max{Li} • General sufﬁcient & necessary condition: ‣ Task τi can be scheduled iff Li ≤1 • Practically, we only need to compute Wi(t) at all times αi = {kTj | j=1,…,i; k=1,…,⎣Ti/Tj⎦} ‣ these are the times at which tasks are released ‣ Wi(t) is constant at other times • Practical RM schedulability conditions: ‣ if mint∈αi Wi(t)/t ≤ 1, task τi is schedulable ‣ if maxi∈{1,…,n}{mint∈αi Wi(t)/t} ≤ 1, then the entire set is schedulable

37 Example

• Task set: ‣ τ1: T1=100, C1=20 ‣ τ2: T2=150, C2=30 ‣ τ3: T3=210, C3=80 ‣ τ4: T4=400, C4=100

• Then: ‣ α1 = {100} ‣ α2 = {100,150} ‣ α3 = {100,150,200,210} ‣ α4 = {100,150,200,210,300,400}

• Plots of Wi(t): task τi is RM-schedulable iff any part of the plot of Wi(t) falls on or below the Wi(t)=t line.

38 Example (contd.)

• W1(t): computed for t ∈ α1 = {100} • W4(t): computed for t ∈ α4 = {100, 150, ‣ W1(100) = 20 200, 210, 300, 400} ‣ W4(100) = 20+30+80+100 = 230 • W2(t): computed for t ∈ α2 = {100, 150} ‣ W4(150) = 20+30+80+100+20 = 250 ‣ W2(100) = 20+30 = 50 ‣ W4(200) = 20+30+80+100+20+30 = ‣ W2(150) = 20+30+20 = 70 280 ‣ W4(210) = 20+30+80+100+20+30+20 • W3(t): computed for t ∈ α3 = {100, 150, = 300 200, 210} ‣ W4(300) = ‣ W3(100) = 20+30+80=130 20+30+80+100+20+30+20+80 = 380 ‣ W3(150) = 20+30+80+20=150 ‣ W4(400) = ‣ W3(200) = 20+30+80+20+30=180 20+30+80+100+20+30+20+80+20 ‣ W3(210) = 20+30+80+20+30+20=200 +30 = 430

39 Example (contd.)

20 30 80 100 1/4 U = 100 + 150 + 210 + 400 = 1.03 > 4(2 −1) = 0.757 4 U = (1+ 20 )(1+ 30 )(1+ 80 )(1+ 100 ) = 2.49 ∏ i=1 i 100 150 210 400 39 Comments on On-line RM Schedulability

• Sufﬁcient schedulability tests based on processor utilization ‣ Polynomial time: can be efﬁciently calculated at run-time upon task arrival ‣ But, lead to poor processor utilization

• Exact tests: based on critical instant analysis ‣ Provide necessary and sufﬁcient schedulability condition ‣ But are too complex to be executed on line for large task sets - pseudopolynomial: polynomial in numeric values of the input

• Other schedulability tests have sought to balance complexity versus acceptance ratio ‣ e.g. Enrico Bini and Giorgio C. Buttazzo, “Schedulability Analysis of Periodic Fixed Priority Systems,” IEEE Transactions on Computers, 3:11, November 2004.

40 Deadline Monotonic Priority Assignment (DMP)

• Relax the Di=Ti constrain ‣ Consider Ci ≤ Di ≤ Ti • Fixed priority of a process is inversely proportional to its relative deadline ‣ Di < Dj ⇒ Pi > Pj • Optimal: can schedule any task set that any other static priority assignment can • Example: RM fails but DMP succeeds for the following

41 Schedulability Analysis of DMP

• One approach is to reduce task periods to relative deadlines 1/n - C1/D1 + C2/D2 + … + Cn/Dn ≤ n(2 -1) • But this is very pessimistic • Better approach is to do critical instant analysis

42 Transient Overload

Task Peak Ci Ave Ci Ti Criticality 1 20 10 100 Critical 2 30 25 150 Critical 3 80 40 210 Non critical 4 100 20 400 Critical

• Not RM schedulable if all tasks take their worst case execution times, but is schedulable in the average case • Can we arrange so that the three critical tasks always meet their deadlines, while the non-critical task meets many of its deadlines?

43 Dealing with Transient Overload

• Transient system overload may cause some deadlines to be missed • Lower priority tasks are likely to miss their deadlines ﬁrst in an overload situation • But, the more important task may have been assigned a lower priority: priority != importance • One could assign priorities according to importance ‣ e.g. by artiﬁcially reducing smaller deadline ‣ but… reduces schedulablity

44 Example

• Consider two tasks: Task τ1: C1 =3.5; T1 =10; D1 =10; less important Task τ2: C2 =7; T2 =14; D2 =13; critical task

• τ2 will have lower priority - completion time test shows that τ2 is not schedulable - but is important and must be guaranteed!

• Making priority τ2 of τ1 will make unschedulable

45 A Better Approach: Period Transformation

• One could transform period of τ2 to 7, yielding a modiﬁed task set Task τ1: C1 =3.5; T1 =10; D1 =10 Task τ2a: C2a=3.5; T2a=7; D2a=6

• Note: in period transformation, the real deadline is at the last transformed period - deadline at the second transformed period of τ2a is at most 6 (7+6=13)

• Now, τ2a has higher priority, and the task set is schedulable!

46 Using Period Transformation to Improve Schedulability

• Consider two tasks: Task τ1: C1=5; T1=10 Task τ2: C2=5; T2=15

• These two tasks are just schedulable with utilization 83.3%

• If we transform, Task τ1a: C1a=2.5; T1a=5 Task τ2: C2=5; T2=15 the utilization bound becomes 100%

47 Sporadic Tasks

• Tasks that are released irregularly, often in response to some event in the environment ‣ no periods associated ‣ but must have some maximum release rate (minimum inter-arrival time) - Otherwise no limit on workload!

• How to deal with them? ‣ consider them as periodic with a period equal to the minimum inter-arrival time ‣ other approaches…

48 Handling Sporadic Tasks: Approach 1

• Deﬁne ﬁctitious periodic task of highest priority and of some chosen execution period

• During the time this task is scheduled to run, the processor can run any sporadic task that is awaiting service ‣ if no sporadic task awaiting service, processor is idle

• Outside this time the processor attends to periodic tasks

• Problem: wasteful!

49 Handling Sporadic Tasks: Approach 2 (Deferred Server)

• Whenever the processor is scheduled to run sporadic tasks, and ﬁnds no such tasks awaiting service, it starts executing other (periodic) tasks in order of priority

• However, if a sporadic task arrives, it preempts the periodic task and can occupy a total time up to the time allotted for sporadic task

• Less wasteful… • Schedulability?

50 Task Synchronization

• So far, we considered independent tasks

• However, tasks do interact: semaphores, locks, monitors, rendezvous etc. ‣ shared data, use of non-preemptable resources

• This jeopardizes systems ability to meet timing constraints ‣ e.g. may lead to an indeﬁnite period of priority inversion where a high priority task is prevented from executing by a low priority task

51 Priority Inversion Example

• Let τ1 & τ3 share a resource & let τ1 have a higher priority. Let τ2 be an intermediate priority task that does not share any resource with either. Consider: ‣ τ3 obtains a lock on the semaphore S and enters its critical section to use a shared resource ‣ τ1 becomes ready to run and preempts . Next τ1 tries to enter its critical section by trying to lock S. But S is locked and therefore τ1 is blocked. ‣ τ2 becomes ready to run. Since only τ2 and τ3 are ready to run, τ2 preempts τ3 while τ3 is in critical section.

52 Priority Inversion Example (contd.)

• What would we prefer? ‣ τ1, being the highest priority task, should be blocked no longer than the time τ3 takes to complete its critical section

• But, in reality, duration of blocking is unpredictable ‣ τ3 can be preempted until τ2 and any other pending intermediate priority tasks are completed

• Duration of priority inversion is a function of the task execution times,and is not bounded by the duration of critical sections

53 Just another theoretical problem?

• Recall Mars Pathﬁnder from 1997? ‣ unconventional "landing" -- bouncing onto the Martian surface surrounded by airbags ‣ deploying the Sojourner rover ‣ gathering and transmitting voluminous data back to Earth ‣ panoramic pictures that were such a hit on the Web

• But… ‣ a few days into the mission, not long after Pathﬁnder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data. ‣ reported in the press as "software glitches" and "the computer was trying to do too many things at once”

54 What really happened on Mars?

• The failure was a priority inversion failure! • A higher priority task bc_dist was blocked by a much lower priority task ASI/MET which had grabbed a shared resource and was then preempted by medium priority task ‣ a mutual exclusion semaphore used within the select() mechanism to control access to the list of file descriptors that the select() mechanism was to wait on ‣ bc_dist sent data to ASI/MET via pipe • The higher priority bc_dist task didn’t finish in time • An even higher priority scheduling task bc_sched periodically creates a transactions for next bus cycle • bc_sched checks that bc_dist is finished (hard deadline), and if not, it resets the system

55 Software Timeline

56 What saved the day?

• How did they find the problem? ‣ Trace/log facility + a replica on earth • How did they fix it? ‣ changed the creation flags for the semaphore so as to enable “priority inheritance” ‣ vxWorks supplies global configuration variables for parameters such as the "options" parameter for the semMCreate used by the select service - Turns out that the Pathfinder code was such that this global change worked with minimal performance impact ‣ Spacecraft code was patched: sent “diff” - custom software on the spacecraft (with a whole bunch of validation) modified the onboard copy

57 Why was it not caught before launch?

• The problem only manifested itself when ASI/MET data was being collected and intermediate tasks were heavily loaded • Before launch testing was limited to the "best case" high data rates and science activities. ‣ data rates on Mars were higher than anticipated and the amount of science activities proportionally greater served to aggravate the problem. ‣ did not expect nor test the "better than we could have ever imagined" case • Did see the problem before landing but could not get it to repeat when they tried to track it down ‣ neither reproducible or explainable ‣ attributed to “hardware glitches” ‣ lower priority - focus was on the entry and landing software

58 Diagnosing the Problem

• Diagnosing this problem as a black box would have been impossible • Only detailed traces of actual system behavior enabled the faulty execution sequence to be captured and identiﬁed • Engineer's initial analysis that "the data bus task executes very frequently and is time-critical -- we shouldn't spend the extra time in it to perform priority inheritance" was exactly wrong

59 Process Interactions & Blocking

• Priority inversions • Blocking • Priority inheritance

60 Example: Priority Inversion

61 Example: Priority Inheritance

62 Response Time Calculations & Blocking

• R = C + B + I ‣ solve by forming recurrence relation

• With priority inheritance:

63 Response Time Calculations & Blocking (contd.)

• Where usage is a 0/1 function:

usage(k, i) = 1 if resource k is used by at least one process with a priority < i, and at least one process with a priority greater or equal to i. Otherwise it gives the result 0.

• CS(k) is the computational cost of executing the k-th critical section.

64 Priority Ceiling Protocols

• Basic idea: ‣ priority ceiling of a binary semaphore S is the highest priority of all tasks that may lock S ‣ When a task τ attempts to execute one of its critical sections, it will be suspended unless its priority is > than the priority of all semaphores currently locked by tasks other than τ ‣ If task τ is unable to enter its critical section for this reason, the task that holds the lock on its semaphore with the highest priority ceiling is - said to be blocking τ - hence, inherits the priority of τ

65 Priority Ceiling Protocols (contd.)

• Two forms ‣ Original ceiling priority protocol (OCPP) ‣ Immediate ceiling priority protocol (ICPP) • On a single processor system ‣ A high priority process can be blocked at most once during its execution by lower priority processes ‣ Deadlocks are prevented ‣ Transitive blocking is prevented ‣ Mutual exclusive access to resources is ensured (by the protocol itself)

66 Example of Priority Ceiling Protocol in Operation

• Two tasks τ1 and τ2 with two shared data structures protected by binary semaphores S1 and S2. - τ1: {… Lock(S1)… Lock(S2) … Unlock (S2) … Unlock (S1) … } - τ2: {… Lock(S2)… Lock(S1) … Unlock (S1) … Unlock (S2) … }

• Assume τ1 has higher priority than τ2

• Note: priority ceilings of both S1 & S2 = priority of τ1

67 Example of Priority Ceiling Protocol in Operation (contd.)

Attempts to lock S1 (blocked)

S2 unlocked S1 locked S2 locked S1 unlocked

Otherwise τ1 and τ2 τ1 will be deadlocked

S1 unlocked S locked 1 S2 unlocked S2 locked

τ2

Inherits priority of τ1

t t0 1 t2 t3 68 OCPP

• Each process has a static default priority assigned (perhaps by the deadline monotonic scheme) • Each resource has a static ceiling value deﬁned, this is the maximum priority of the processes that use it • A process has a dynamic priority that is the maximum of its own static priority and any it inherits due to it blocking higher priority processes • A process can only lock a resource if its dynamic priority is higher than the ceiling of any currently locked resource (excluding any that it has already locked itself).

69 Example of OCPP

70 ICPP

71 Example of ICPP

72 OCPP vs. ICPP

• Worst case behavior identical from a scheduling point of view • ICCP is easier to implement than the original (OCPP) as blocking relationships need not be monitored • ICPP leads to less context switches as blocking is prior to ﬁrst execution • ICPP requires more priority movements as this happens with all resource usages; OCPP only changes priority if an actual block has occurred.

73 Release Jitter

• A key issue in distributed systems • Sporadic task will be released at time 0, 5, 25, 45, and so on … ‣ i.e. at times 0, T-J, 2T-J, 3T-J, and so on…

74 Release Jitter (contd.)

• Examination of the derivation of the schedulability equation implies that process i will suffer one interference from S if Ri is between 0 and T-J, that is Ri ∈ [0, T–J), two if Ri ∈ [T–J, 2T-J), three if Ri ∈ [2T–J, 3T-J), and so on…

75 Release Jitter (contd.)

• In general, periodic tasks do not suffer jitter • But, an implementation may restrict granularity of system timer which releases periodic tasks ‣ a periodic task may therefore suffer from jitter • If response time is to be measured relative to the real release time then the jitter value must be added to that previously calculated:

periodic Ri = Ri + Ji

76 Arbitrary Deadlines

• Case when deadline Di < Ti is easy… • Case when deadline Di > Ti is much harder ‣ multiple iterations of the same task may be alive simultaneously ‣ may have to check multiple task initiations to obtain the worst case response time • Example: consider two tasks ‣ Task 1: C1 = 28, T1 = 80 ‣ Task 2: C2 = 71, T2 = 110 ‣ Assume all deadlines to be ∞

77 Arbitrary Deadlines (contd.)

• Response time for task 2:

initiation completion time response time 0 127 127 110 226 116 220 353 133 330 452 122 440 551 111 550 678 128 660 777 117 770 876 106

• Response time is worst not for the first initiation ‣ Not sufficient to consider just the first iteration

78 Schedulability Condition for Arbitrary Deadlines

• Analysis for situations where Di (and hence potentially Ri ) can be greater than Ti

• The number of releases that need to be considered is bounded by the lowest value of q = 0,1,2,… for which the following relation is true:

79 Arbitrary Deadlines (contd.)

• The worst-case response time is then the maximum value found for each q:

• Note: for D ≤ T, the relation is true for q=0 if the task can be scheduled, in which case the analysis simpliﬁes to original ‣ if any R>D, the task is not schedulable

80 Arbitrary Deadlines with Release Jitter

81 Accounting for Context Switching Overhead

• Let context switching overhead be: ‣ Cost of swapping out: TCS_out ‣ Cost of swapping in: TCS_in • For simplicity, assume swap in or swap out are non-preemptible • Then, each higher priority task that arrives during the lifetime of a lower priority task adds an overhead of 2*(TCS_out + TCS_in) or (TCS_out + TCS_in) to the response time ‣ Only (TCS_out + TCS_in) when a mid priority task arrives after the higher priority task came but before the latter ﬁnished • When is the critical instant for task i? ‣ Task i arrives just as a lower priority task in lp(i) started to be swapped in, and a higher priority task in hp(i) arrives while the task i was swapped in

82 Accounting for Context Switching Overhead: Di ≤ Ti case

⎡ Ri ⎤ Ri = Ci + 2TCS _ in + TCS _ out + ∑ ⎢ ⎥( C j + 2TCS _ out + 2TCS _ in ) j∈hp(i) ⎢ Tj ⎥ NOTE: This is a conservative analysis

Task ∈ lp(i) arrives Higher priority task arrives

Task “i” arrives, just after swap in of lower priority task begins Higher priority task executes Task “i” executes

Swap out Swap in

83 Accounting for Processor Shutdown Also

• To save power, we shut down the processor when idle • Shutting down costs TSD while waking up costs TWU ‣ TSD = cost of saving state ‣ TWU = cost of restoring state + cost of PLL to stabilize ‣ TSD ≅ TWU is a reasonable approximation • For simplicity, assume shutdown and wake-up are non-preemptible • Critical instant for Task i is the worse of the following: ‣ Task i arrives just as a lower priority task in lp(i) started to be swapped in, and a higher priority task in hp(i) arrives while the task i was swapped in ‣ Task i arrives just as the processor started to shutdown, and a higher priority task in hp(i) arrives while the task i was swapped in after wake up.

84 Accounting for Processor Shutdown: Di ≤ Ti case

⎡ Ri ⎤ Ri = Ci + max(2TCS _ in + TCS _ out ,TSD + TWU + TCS _ in ) + ∑ ⎢ ⎥( C j + 2TCS _ out + 2TCS _ in ) j∈hp(i) ⎢ Tj ⎥

NOTE: This is a conservative analysis

Processor becomes idle and starts Higher priority task arrives shutdown

Task “i” arrives, while shutdown is going on Higher priority task executes Task “i” executes

Wake up Swap out Swap in Shut down 85