1. Real-time Systems Lab, Computer Science and Engineering, ASU Scheduling Algorithm and Analysis (ESP – Fall 2014) Computer Science & Engineering Department Arizona State University Tempe, AZ 85287 Dr. Yann-Hang Lee yhlee@asu.edu (480) 727-7507

2. Real-time Systems Lab, Computer Science and Engineering, ASU Task Scheduling  Schedule: to determine which task is assigned to a processor at any time  order of execution  meet deadlines, fast response time, utilize resource effectively  Need an algorithm to generate a schedule  optimal scheduling algorithm: always find a feasible schedule if and only if a feasible schedule exists  Scheduler or dispatcher: the mechanism to implement a schedule  Misconcept:  RTOS will schedule tasks to meet task deadlines  A good schedule will reduce CPU load 1

3. Real-time Systems Lab, Computer Science and Engineering, ASU Task Functional Parameters  Preemptivity: suspend the executing job and switch to the other one  should a job (or a portion of job) be preemptable  context switch: save the current process status (PC, registers, etc.) and initiate a ready job  transmit a UDP package, write a block of data to disk, a busy waiting loop  Preemptivity of resources: concurrent use of resources or critical section  lock, semaphore, disable interrupts  How can a context switch be triggered?  Assume you want to preempt an  executing job -- why  a higher priority job arrives  run out the time quantum waiting executing ready blocked suspended dispatched wake-up 2

4. Real-time Systems Lab, Computer Science and Engineering, ASU Event- and Time-Triggered Systems  Time-triggered control system  All activities are carried out at certain points in time know a priori at design time (based on a globally synchronized time base)  Transmission of messages  Task execution  Monitoring of external states  All nodes have a common notion of time  Event-triggered control system  All activities are carried out in response to events external to the system  Reception of a message  Termination of a task  External interrup 3

5. Real-time Systems Lab, Computer Science and Engineering, ASU 0102030405060 Major and Minor Cycle Model  Time is divided into equal-sized frame  minor cycle = length of frame  Major cycle = length of schedule = k * minor_cycle  An example: A=(10,4) B=(20,6) C=(30,5)  major cycle=60, minor cycle=10  scheduling string AB_AC_AB_AC_AB_A_  Jobs must be done within a minor cycle  limit timing error to one frame  suspend and resume as background, continue, or abort if overrun 4

6. Real-time Systems Lab, Computer Science and Engineering, ASU An Example  A1 must be done at least every 10ms, and takes 1ms  A2 must be completed with 5ms when E occurs and takes 2 ms  E must be detected by polling and is detectable for at least 0.5 ms  E would not occur twice within 50 ms  polling of E takes 0 overhead 0.5ms 5

7. Real-time Systems Lab, Computer Science and Engineering, ASU Major/Minor Cyclic Scheduling  There should be a periodic polling action for E  Assume a timer of 0.5ms to activate polling operation and no polling overhead  Should be an interval of 2ms to execute A2 for an arbitrary 5ms interval  May detect E in the first frame and execute A2 in the second frame  period=2.5ms  A2 takes 2ms if E, otherwise is 0  WCET=2ms  Should be an interval of 1ms to execute A1 for an arbitrary 10ms interval  Period= 10ms, WCET= 1ms  Since 2ms + 1ms > 2.5ms, we will divide A1 into two parts of 0.5ms A2 A1_1 A2 A1_2 A2 A2 6

8. Real-time Systems Lab, Computer Science and Engineering, ASU Time Triggered Architecture (TTA)  Multiple CPU nodes connected by a TDMA bus.  Bus schedule is divided into fixed-length time slots,  Each CPU node is assigned a time slot to transmit messages.  Messages are delivered to their destination CPU nodes at the end of the time slot, regardless of their exact arrival times. 7

9. Real-time Systems Lab, Computer Science and Engineering, ASU Summary of Cyclic Schedule  Pros  simple, table-driven, easy to validate (knows what is doing at any moment)  fit well for harmonic periods and small system variations  static schedule  deterministic, static resource allocation, no preemption  small jitter, no scheduling anomalies  Cons  difficult to change (need to re-schedule all tasks)  fixed released times for the set of tasks  difficult to deal with dependencies  schedule algorithm may get complex (NP-hard)  doesn’t support aperiodic tasks efficiently  Processes with sizeable computation times. 8

10. Real-time Systems Lab, Computer Science and Engineering, ASU Priority-Driven Scheduling of Periodic Tasks  Why priority-driven scheduling  use priority to represent urgency  easy implementation of scheduler (compare priorities and dispatch tasks)  tasks can be added or removed easily  no direct control of execution instance  How can we analyze the schedulability if we don’t know when a task is to be executed  Let’s begin a deterministic case in one processor  independent periodic tasks  deadline = period  preemptable  no overhead for context switch 9

11. Real-time Systems Lab, Computer Science and Engineering, ASU Priority-Driven Schedules  Assign priority when jobs arrive  static -- all jobs of a task have a fixed priority  dynamic -- different priorities to individual tasks of a task  relative priorities don’t change while jobs are waiting  Static priority schedules  Rate-monotonic -- the smaller a task period, the higher its priority  Deadline-monotonic – if deadline  period, the smaller a task’s deadline (relative), the higher its priority  Dynamic priority schedules  EDF -- earliest deadline (absolute) first  Schedulable utilization:  a scheduling algorithm can feasibly schedule any sets of priority tasks if the total utilization is equal to or less than the schedulable utilization of the algorithm 10

12. Real-time Systems Lab, Computer Science and Engineering, ASU Earliest-deadline First (EDF) Schedule  Priority preemptive scheduling  a job with earliest (absolute) deadline has the highest priority  does not require the knowledge of execution time  Optimal if single processor, no resource contention, preemption  Scheduling anomaly if non-preemptive --- the schedule fails after we reduce job execution times T1T2T3T1T2T3 D1D1 D2D2 D3D3 Missed deadline ( all jobs meet their deadline under EDF after increasing e 1 ) 11

13. Real-time Systems Lab, Computer Science and Engineering, ASU dkdk didi JkJk JiJi rkrk ( r k ) dkdk didi JkJk JkJk JiJi (non-EDF) (EDF) Earliest-deadline First (EDF) Schedule  Priority preemptive scheduling  a job with earliest (absolute) deadline has the highest priority  does not require the knowledge of execution time  Optimal if  single processor, no resource contention, preemption  why it is optimal: assume a feasible schedule 12

14. Real-time Systems Lab, Computer Science and Engineering, ASU EDF Schedule  A optimal algorithm under single processor and preemptable tasks  How do we know a set of periodic tasks are schedulable under EDF ?  If we know the schedulable utilization SU of EDF, then any sets of tasks are schedulable when U  SU  Theorem: A set of n periodic tasks can be scheduled by EDF iff  This schedulability utilization is no long true if deadline < period. 13

15. Real-time Systems Lab, Computer Science and Engineering, ASU Example of EDF Schedule  A digital robot with EDF schedule  control loop: e c  8ms at 100Hz  BIST: e b  50ms  given  BIST can be done every 250ms  Add a telemetry task to send and receive messages with e t  15ms  if BIST is done every 1000ms  given  the telemetry task can have a relative deadline of 100ms  sending or receiving must be separated at least 100ms 14

16. Real-time Systems Lab, Computer Science and Engineering, ASU Rate-Monotonic Scheduling Algorithm  A base case: no additional overhead, simple periodic tasks with p i =D i  Assign priorities according their periods  T i has a higher priority that T k if i < k ( p i < p k )  Is RM optimal?  if there is a feasible fixed-priority schedule, then RM is feasible  How do we know RM is feasible  schedulability test  Results:  RM is optimal if p i  D i  sufficient condition  utilization test  a complete test  what is the worst response time given all possible arrivals and preemptions 15

17. Real-time Systems Lab, Computer Science and Engineering, ASU Critical Instant  Critical instant of T i : a job of T i arriving at the instant has a maximum response time  If we can find the critical instant of T i, then  check whether all jobs of T i meet their deadlines  let’s increase ei until the maximum response time = D i   schedulable utilization  In-phase instant is critical: all higher priority tasks are released at the same instant (assume all jobs are completed before the next job in the tasme task is released.)  which T 2 has the maximum response time T 1 T 2 T 1, T 2 T 2 T 1 16

18. Real-time Systems Lab, Computer Science and Engineering, ASU Schedulability: UB Test  Utilization bound (UB) test: a set of n independent periodic tasks scheduled by the rate monotonic algorithm will always meet its deadlines, for all task phasings, if  For harmonic task sets, the utilization bound is U(n)=1.00 for all n. U(1) = 1.0 U(4) = 0.756 U(7) = 0.728 U(2) = 0.828 U(5) = 0.743 U(8) = 0.724 U(3) = 0.779 U(6) = 0.734 U(9) = 0.720 17

19. Real-time Systems Lab, Computer Science and Engineering, ASU Schedulability Test: Time-Demand Analysis  Consider in-phase instant only  If J i is done at t, then the total work must be done in [0,t] is (from J i and all higher priority tasks)  Can we find a t  D i such that w i (t)  t  cannot check all t  [0, D i ]  check all arrival instants and D i  The completion time of J i satisfies t w(t) timeDiDi 18

20. Real-time Systems Lab, Computer Science and Engineering, ASU Schedulability: RT Test  Theorem: for a set of independent, periodic tasks, if each task meets its first deadline, with worst-case task phasing, the deadline will always be met.  Response Time (RT) test:  let a n = response time of task i. a n may be computed by the following iterative formula:  Test terminates when a n+1 = a n  Task i is schedulable if its response time is before its deadline: a n ≤ T i 19

21. Real-time Systems Lab, Computer Science and Engineering, ASU RMA for Periodic Tasks  A Sample Problem - Periodics 100 msec 40 msec 20 msec Periodics Servers Aperiodics 20 msec 2 msec 10 msec 50 msec 5 msec Data Server Comm Server Emergency 100 msec 150 msec 350 msec Deadline 6 msec after arrival 11 22 33 20

22. Real-time Systems Lab, Computer Science and Engineering, ASU Sample Problem: UB Test  Total utilization is.200 +.267 +.286 =.753 < U(3) =.779  The periodic tasks in the sample problem are schedulable according to the UB test. epU Task  1 201000.200 Task  2 401500.267 Task  3 1003500.286 21

23. Real-time Systems Lab, Computer Science and Engineering, ASU scheduling points Timeline for The Sample Problem 0100200 300400 33 22 11 22

24. Real-time Systems Lab, Computer Science and Engineering, ASU Example: Applying RT Test (1)  Taking the sample problem, we increase the compute time of ז1 from 20 to 40; is the task set still schedulable?  Utilization for the first task : 40/100=0.4 < U(1)  Utilization of first two tasks: 0.667 < U(2) = 0.828  First two tasks are schedulable by UB test  Utilization of all three tasks: 0.953 > U(3) = 0.779  UB test is inconclusive  Need to apply RT test 23

25. Real-time Systems Lab, Computer Science and Engineering, ASU Example: Applying RT Test (2)  Use RT test to determine if ז 3 meets its first deadline: i = 3 24

26. Real-time Systems Lab, Computer Science and Engineering, ASU Example: Applying RT Test (3) a 3 = a 2 = 300 Done!  Task is schedulable using RT test.  a 3 = 300 < p 3 = 350 25

27. Real-time Systems Lab, Computer Science and Engineering, ASU Timeline for The Example 0100200300 11 33 22  3 completes its work at t=300 26

28. Real-time Systems Lab, Computer Science and Engineering, ASU Summary  UB test is simple but conservative  RT test is more exact but also more complicated  To this point, UB and RT tests share the same limitations:  All tasks run on a single processor  All tasks are periodic and noninteracting  Deadlines are always at the end of the period  There are no interrupts  Rate monotonic priorities are assigned  There is zero context switch overhead  Tasks do not suspend themselves 27

29. Real-time Systems Lab, Computer Science and Engineering, ASU Modeling Task Switching 28

30. Real-time Systems Lab, Computer Science and Engineering, ASU Schedulability with Interrupts  Interrupt processing can be inconsistent with rate monotonic priority assignment.  interrupt handler executes with high priority despite its period  interrupt processing may delay execution of tasks with shorter periods  Effects of interrupt processing must be taken into account in schedulability model.  Question is: how to do that? 29

31. Real-time Systems Lab, Computer Science and Engineering, ASU Determining Schedulability with Interrupts Task(i)Period(p)Execution Time(e) PriorityDeadline (D) 33 20060HW200 11 10020High100 22 15040Medium150 44 35040Low350  3 is an interrupt handler 30

32. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Interrupt Priority  Test is applied to each task.  Determine effective utilization (f i ) of each task i using q Compare effective utilization against bound, U(n). n = num(H n ) + 1 num(H n ) = the number of tasks in the set H n Preemption form the tasks that can hit more than once (with period less that D i ) Execution of a task under test Preemption from tasks That can hit only once (with period greater than D i ) 31

33. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Interrupt Priority:  3  For  3, no tasks have a higher priority: H = H n =H 1 = { }.  Note that utilization bound is U(1): num(H n ) = 0. Plugging in numbers: 32

34. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Interrupt Priority:  1  For  1,  3 has a higher priority: H = {  3 }; H n = {}; H 1 = {  3 }.  Note that utilization bound is U(1): num(Hn) = 0. Plugging in the numbers: 33

35. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Interrupt Priority:  2  For  2 : H={  1,  3 }; H n ={  1 }; H 1 ={  3 };  Note that utilization bound is U(2): num(H n ) = 1. Plugging in the numbers: 34

36. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Interrupt Priority:  For  4 : H={  1,  2,  3 }; H n ={  1,  2,  3 }; H 1 ={};  Note that utilization bound is U(4): num(H n ) = 3. Plugging in the numbers: 35

37. Real-time Systems Lab, Computer Science and Engineering, ASU Priority Inversion in Synchronization  1(H) B  2(M)  3(L) Time  1 :{…P(S1)…V(S1)…}  3 :{…P(S1)…V(S1)…} S1 unlocked Attempt to lock S1 (blocked) S1 locked S1 unlocked S1 locked 36

38. Real-time Systems Lab, Computer Science and Engineering, ASU Priority Inversion  Delay to a task’s execution caused by interference from lower priority tasks is known as priority inversion  Preemption is normal, but priority inversion should be avoided  Priority inversion is modeled by blocking time  Identifying and evaluating the effect of sources of priority inversion is important in schedulability analysis  Sources of priority Inversion  Synchronization and mutual exclusion  Non-preemtable regions of code  FIFO (first-in-first-out) queues 37

39. Real-time Systems Lab, Computer Science and Engineering, ASU Accounting for Priority Inversion  Recall that task schedulability is affected by  preemption: two types of preemption  can occur several times per period  can occur once per period  execution: once per period  blocking: at most once per period for each source  The schedulability formulas are modified to add a “blocking” or “priority inversion” term to account for inversion effects 38

40. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test with Blocking  Include blocking while calculating effective utilization for each tasks: H n Preemption(can hit n times) Execution Blocking H 1 Preemption(can hit once) 39

41. Real-time Systems Lab, Computer Science and Engineering, ASU RT Test with Blocking  Blocking is also included in the RT test  Perform test as before, including blocking effect 40

42. Real-time Systems Lab, Computer Science and Engineering, ASU  Consider the following example Periodic tasks What is the worst case blocking effect (priority inversion) experienced by each task ? Example: Considering Blocking 25 msec 100 msec 50 msec 200 msec 100 msec 300 msec 10 msec 30 msec Data Structure 11 22 33 41

43. Real-time Systems Lab, Computer Science and Engineering, ASU Example: Adding Blocking  Task  2 does not use the data structure. Task  2 does experiences no priority inversion  Task  1 shares the data structure with  3. Task  1 could have to wait for  3 to complete its critical section. But worse, if  2 preempts while  1 is waiting for the data structure,  1 could have to wait for  2 ’s entire computation.  This is the resulting table taskPeriodExecution Time PriorityBlocking delay Deadline 11 10025High30+50100 22 20050Medium0200 33 300100Low0300 42

44. Real-time Systems Lab, Computer Science and Engineering, ASU UB Test for Example  Recall UB test with blocking: Not schedulable with additional RT test,  3 is shown to be schedulable 43

45. Real-time Systems Lab, Computer Science and Engineering, ASU Nonpreemption Protocol  2 :{…P(S1)…V(S1)…}  4 :{…P(S1)…V(S1)…} ready blocked ready S1 locked S1 unlocked Time  1 (H)  4 (L) 22 33 44

46. Real-time Systems Lab, Computer Science and Engineering, ASU Basic Inheritance Protocol (BIP)  2 :{…P(S1)…V(S1)…}  4 :{…P(S1)…V(S1)…} ready S1 lockedS1 unlocked  1 (H)  4 (L) 22 33 blocked attempts to lock S1 S1 unlocked S1 locked ready inherits the priority of  2 after  2 is blocked 45

47. Real-time Systems Lab, Computer Science and Engineering, ASU Highest Locker’s Priority Protocol  2 :{…P(S1)…V(S1)…}  4 :{…P(S1)…V(S1)…} ready S1 lockedS1 unlocked  1 (H)  4 (L) 22 33 B B run with the priority of  2 46

48. Real-time Systems Lab, Computer Science and Engineering, ASU Summary of Synchronization Protocols 1 Only if tasks do not suspend within critical sections 2 PCP is not affected if tasks suspend within critical sections. 47

49. Real-time Systems Lab, Computer Science and Engineering, ASU Case Study  The target system responds to 6 events  each event is processed by an ISR and an application routine  ISRs are nonpreemption and set up event ready flags  Main program checks ready flags in round-robin manner  if flag is set, calls the application routing Main program E1 E6E5E4E3E2 RTOS and ISRs 48

50. Real-time Systems Lab, Computer Science and Engineering, ASU Scheduling Discipline wait for signals 49

51. Real-time Systems Lab, Computer Science and Engineering, ASU Task Data  The total utilization is only 55% in the worst-case eiei eaea epU event 12.00.52.5400.063 event 27.58.516750.213 event 36.00.66.61250.053 event 421.027.048.02500.192 event 55.024.029.010500.028 event 63.01.04.040000.001 total0.550 50

52. Real-time Systems Lab, Computer Science and Engineering, ASU A Possible Scenario  Examine a possible scenario of event 1, 3 and 4  The main program just checked the flag for event 3 and then three interrupts arrives 040 80 120 160 200 240 0125 250 0 250 event 1 event 4 event 3 miss deadline 51

53. Real-time Systems Lab, Computer Science and Engineering, ASU Applying RMA in the Case Study  Event 4 application is schedulable (f 4 <69%) EventPeriod Preempt {Hn} Execute Preempt {H1} total (f i ) E1a400.013 E2a750.113 E3a1250.005 E4a2500.1980.1080.2540.56 E5a10500.023 E6a40000.0003 52

54. Real-time Systems Lab, Computer Science and Engineering, ASU Improving Response Times  Process events in RM order  go back to the main loop after completing an application routine  Streamlined ISR  move the work done in ISR to application routines  Preemptable services Main program E1 E6E3 RTOS and ISRs E2 E5 E4 53

55. Real-time Systems Lab, Computer Science and Engineering, ASU Analysis After Improvements Is it scheduable? eiei eaea epU event 12.00.52.5400.063 event 21.514.5(1.7)16750.213 event 36.00.66.61250.053 event 46.541.5(4.5)482500.192 event 55.024(3.9)2910500.028 event 63.01.04.040000.001 total0.550 54