Last Time Today Response Time Vs. RM Computing Response Time More Second-Priority Task I Response Time

Last Time Today Priority-based scheduling Response time analysis Static priorities Blocking terms Dynamic priorities Priority inversion Schedulable utilization And solutions Rate monotonic rule: Keep utilization below 69% Release jitter Other extensions Response Time vs. RM Computing Response Time Rate monotonic result WC response time of highest priority task R Tells us that a broad class of embedded systems meet their 1 time constraints: R1 = C 1 • Scheduled using fixed priorities with RM or DM priority Hopefully obvious assignment • Total utilization not above 69% WC response time of second-priority task R 2 However, doesn’t give very good feedback about what is Case 1: R 2 ≤ T1 going on with a specific system • R2 = C 2 + C 1 Response time analysis R T T Tells us for each task, what is the longest time between R1 2 1 2 when it is released and when it finishes Then these can be compared with deadlines 1 1 Gives insight into how close the system is to meeting / not 2 meeting its deadline Is more precise (rejects fewer systems) More Second-Priority Task i Response Time Case 2: T 1 < R 2 ≤ 2T 1 General case: R = C + 2C Ri 2 2 1 Ri = Ci + ∑ Cj j ∀j∈hp (i) T R1 T1 R2 2T 1 T2 1 1 1 hp(i) is the set of tasks with priority higher than I 2 2 Only higher-priority tasks can delay a task Case 3: 2T 1 < R 2 ≤ 3T 1 Problem with using this equation in practice? R2 = C 2 + 3C 1 General case of the second-priority task: R2 = C 2 + ceiling ( R 2 / T 1 ) C 1 1 Computing Response Times Response Time Example Rewrite as a recurrence relation and solve by Task 1: T = 30, D = 30, C = 10 iterating: n Task 2: T = 40, D = 40, C = 10 + R n 1 = + i Task 3: T = 52, D = 52, C = 12 Ri Ci ∑ Cj j ∀j∈hp (i) T Utilization = 81% – Rejected by the rate monotonic test! n+1 n Finished when R i = R i n n n+1 R Or when R i > D i = + i Ri Ci ∑ Cj Choose R 0 = 0 or R 0 = C j i i i ∀j∈hp (i) T There may be many solutions to the recurrence These starting points guarantee convergence to the smallest solution (unless there is divergence) R1 = 10 R = 20 Result is invalid if R i > T i 2 Why? R3 = 52 Sharing Resources Computing Blocking Terms So far tasks are assumed to be independent How do we compute blocking terms? Not allowed to block (e.g. on a network device) Depends on the synchronization protocol Not allowed to contend for shared resources Tasks synchronize by disabling interrupts Big problem in practice! Best answer: Each task gets blocking term with length of Solution: the longest critical section in a lower-priority task Simpler answer: Each task gets blocking term with length of Compute worst-case blocking time for each task the longest critical section in any task Longest time that task is delayed by a lower-priority task Why do these work? Why just lower priority? Tasks synchronize using mutexes Now we can analyze the system again: Blocking term generally impossible to bound – oops! n Standard thread locks are unfriendly to real-time systems + R n 1 = + + i • Lock wait queue is FIFO Ri Ci Bi ∑ Cj j Possible solution: Priority queues for mutexes ∀j∈hp (i) T Priority Inversion Priority Inversion Case Study Priority inversion: Low-priority task delays a high Mars Pathfinder priority task Lands on Mars July 4 1997 Mutexes (even with priority queuing) provide unbounded Mission is successful priority inversion Behind the scenes… Sporadic total system resets on the rover preemption P(s) – blocks T1 Caused by priority inversion Debugged on the ground, software patch uploaded to fix 1 things 2 Details 3 Rover controlled by a single RS6000 running vxWorks Rover devices polled over 1553 bus P(s) – succeeds At 8 Hz bc_sched task sets up bus transactions bc_dist task runs (also at 8 Hz) to read back data 2 More Pathfinder Priority Inversion Solutions 1. Avoid blocking – disable interrupts instead Symptom: Pros: bc_sched sometimes was not finished by the time bc_dist Efficient ran Simple This triggered a system reset Con: • Should never happen since these tasks are high priority Also delays unrelated, high priority tasks Problem: bc_sched shared a mutex with ASI/MET 2. Immediate priority ceiling protocol – before locking, task, which does meteorological science at low raise priority to highest priority of any thread that priority can touch that semaphore Occasionally the classic priority inversion happened when Pros: there were long-running medium priority tasks Fairly simple Solution: Less blocking of unrelated tasks Cons: vxWorks supports “priority inheritance” with a global flag Requires ahead-of-time system analysis They turned it on Still has some pessimistic blocking Priority Inversion Solutions IPCP Bonus 3. Priority inheritance protocol – When a task is In IPCP, raising priority prevents anyone else who blocking other tasks (by holding a mutex) it might access a resource from running executes at the priority of the highest-priority So why take a lock at all? blocked task Turns out that locking is not necessary – raising priority is Pros enough No pessimistic blocking HOWEVER: Task must not voluntarily block (e.g. on disk or Cons network) while in a critical section Complicated in presence of nested locking Not that efficient Blocking terms larger than IPCP Other solutions exist, such as lock-free synchronization Overheads Release Jitter A real RTOS requires time to: Release jitter J i – Time between invocation of task i Block a task and time at which it can actually run Make a scheduling decision E.g. task becomes conceptually runnable at the start of its Dispatch a new task period Handle timer interrupts • But must wait for the next timer interrupt before the scheduler sees it and dispatches it For a well-designed RTOS these times can be Or, task would like to run but must wait for network data to bounded arrive before it actually runs Worst-case blocking time of the RTOS needs to be added to each task’s blocking term 2x worst-case context switch time needs to be added to each task’s WCET Ri + Ji i = i + i + j • R C B ∑ C We always “charge” the cost of a context switch to the j higher-priority task ∀j∈hp (i) T 3 Other Extensions Summary Sporadically periodic tasks Priority based scheduling Task has an “outer period” and smaller “inner period” It’s what RTOSs support Models bursty processing like network interrupts A strong body of theory can be used to analyze these Sporadic servers systems Theory is practical: Many real-world factors can be modeled Provide rate-limiting for truly aperiodic processing • E.g. interrupts from an untrusted device Response time analysis – supports worst-case Arbitrary deadlines response time for each priority-based task Blocking terms When D i > T i previous equations do not apply Release jitter Can rewrite Precedence constraints Priority inversion can be a major problem Solutions have interesting tradeoffs Task A cannot run until Task B has completed • Models scenario where tasks feed data to each other Makes it harder to schedule a system 4.

Load more