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 Dr. Yann-Hang Lee (480)

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

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

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

Real-time Systems Lab, Computer Science and Engineering, ASU 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

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

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

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

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

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

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

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

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

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

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

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

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

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) = U(7) = U(2) = U(5) = U(8) = U(3) = U(6) = U(9) =

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

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

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

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

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

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: < U(2) =  First two tasks are schedulable by UB test  Utilization of all three tasks: > U(3) =  UB test is inconclusive  Need to apply RT test 23

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

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 =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 High 2 Medium0200 3 Low

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

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

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

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

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

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

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

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 event event event event event total

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 event 1 event 4 event 3 miss deadline 51

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 ) E1a E2a E3a E4a E5a E6a

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

Real-time Systems Lab, Computer Science and Engineering, ASU Analysis After Improvements Is it scheduable? eiei eaea epU event event (1.7) event event (4.5) event (3.9) event total