r i r 2 c 2 2c 1 r c c i i j t j j hp i
play

R i R 2 = C 2 + 2C 1 R = C + C i i j T j j - PDF document

Mar 22, 2024 •231 likes •281 views

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

  1. 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 1 � Tells us that a broad class of embedded systems meet their � R 1 = C 1 time constraints: � Hopefully obvious • Scheduled using fixed priorities with RM or DM priority 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 � T 1 going on with a specific system • R 2 = C 2 + C 1 � Response time analysis R 2 T 1 T 2 � Tells us for each task, what is the longest time between R 1 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 i � R 2 = C 2 + 2C 1 R = C + C � � i i j � � T j ∀ j ∈ hp ( i ) T 1 R 2 2T 1 R 1 T 2 � hp(i) is the set of tasks with priority higher than I 1 1 1 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? � R 2 = C 2 + 3C 1 � General case of the second-priority task: � R 2 = C 2 + ceiling ( R 2 / T 1 ) C 1 1

  2. Computing Response Times Response Time Example � Rewrite as a recurrence relation and solve by � Task 1: T = 30, D = 30, C = 10 iterating: � Task 2: T = 40, D = 40, C = 10 � � n R � n + 1 � i � � Task 3: T = 52, D = 52, C = 12 R = C + C i j i � T � � Utilization = 81% – Rejected by the rate monotonic j ∀ j ∈ hp ( i ) test! � Finished when R in+1 = R in � � n � R � Or when R in > D i n + 1 i � � R = C + C i j � Choose R i0 = 0 or R i0 = C i i T � � j ∀ j ∈ hp ( i ) � There may be many solutions to the recurrence � These starting points guarantee convergence to the � R 1 = 10 smallest solution (unless there is divergence) � R 2 = 20 � Result is invalid if R i > T i � R 3 = 52 � Why? 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 the longest critical section in a lower-priority task � Solution: � 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 � R = C + B + C • Lock wait queue is FIFO i i j i � T � � Possible solution: Priority queues for mutexes j ∀ j ∈ hp ( i ) 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 things 1 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

  3. More Pathfinder Priority Inversion Solutions Avoid blocking – disable interrupts instead 1. � 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 Immediate priority ceiling protocol – before locking, 2. task, which does meteorological science at low raise priority to highest priority of any thread that priority can touch that semaphore � Pros: � Occasionally the classic priority inversion happened when � Fairly simple there were long-running medium priority tasks � Less blocking of unrelated tasks � Solution: � 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 Priority inheritance protocol – When a task is � In IPCP, raising priority prevents anyone else who 3. 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 enough � Pros � No pessimistic blocking � HOWEVER: Task must not voluntarily block (e.g. on disk or network) while in a critical section � Cons � 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 and time at which it can actually run � Block a task � Make a scheduling decision � E.g. task becomes conceptually runnable at the start of its period � Dispatch a new task • But must wait for the next timer interrupt before the � Handle timer interrupts 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 R + J i i each task’s WCET R = C + B + C � � i i i j � � • We always “charge” the cost of a context switch to the T j j hp ( i higher-priority task ∀ ∈ ) 3

  4. 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 systems � Sporadic servers � Theory is practical: Many real-world factors can be modeled � Provide rate-limiting for truly aperiodic processing � Response time analysis – supports worst-case • E.g. interrupts from an untrusted device response time for each priority-based task � Arbitrary deadlines � Blocking terms � When D i > T i previous equations do not apply � Release jitter � Can rewrite � Priority inversion can be a major problem � Precedence constraints � 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

Recommend

More recommend