Non-Preemptive Access to Shared Resources in Hierarchical Real-Time Systems

1. Non-Preemptive Access to Shared Resources in HierarchicalReal-Time Systems Marko Bertogna, Fabio Checconi, Dario Faggioli CRTS workshop – Barcelona, November, 30th Scuola Superiore S.Anna, Pisa, Italy

2. Outline • Target architecture • Shared resource protocols • Non-preemptive execution of CS • Schedulability tests • Admission control • Simulations • Conclusions and future extensions Marko Bertogna CRTS Workshop, Barcelona

3. Hierarchical systems Component = Task or Server CPU C1 C2 C3 Q1 , P1 Q2 , P2 Q3 , P3 … … … Marko Bertogna CRTS Workshop, Barcelona

4. Target architecture • General purpose OS supporting hierarchicalexecution on a single processor • Set of independently developed applications with soft real-time requirements • Different applications may access common shared resources (Local vs global) • Few information available on tasks timely parameters • Fast scheduling and resource arbitration protocols Marko Bertogna CRTS Workshop, Barcelona

5. Access to shared resources • Problem with classic protocols (i.e. SRP, PCP) • to work properly (ceiling computation)  need to know a priori which shared resources will be accessed by each task • for schedulability analysis  need to know the length of critical sections (at least reasonable upper bounds) • not suitable for highly dynamic systems and general purpose OS • Classic servers incur the budget exhaustion problem Marko Bertogna CRTS Workshop, Barcelona

6. Budget exhaustion problem Server 1 Q = 10, P = 100 Lock (R1) Unlock (R1) Server 2 Q = 90, P = 100 Lock (R1) BLOCKED Marko Bertogna CRTS Workshop, Barcelona

7. Solution • Perform a “budget check” before each locking operation • BROE server (Fisher, Bertogna, Baruah – RTSS’07) • CBS-like server for hierarchical systems with support for globally shared resources • If CS_length ≤ q  acquire lock • Else  wait until virtual time equals real time q = 10 Lock (R1) Q = 10 P = 100 |CS| = 5 q = 4 WAIT t = 6 Marko Bertogna CRTS Workshop, Barcelona

8. Non-preemptiveaccess to shared resources • Disable preemptions before each locking operations • No need for complex locking protocols • Reduced resource holding times • Very efficient with small CS lengths • Simple algorithms to derive safe non-preemptive chunk lengths [see Baruah, ECRTS’05] • O(n), O(1) • Pseudo-polynomial (tight?) hi = maximum non-preemptive chunk length for component Ci Marko Bertogna CRTS Workshop, Barcelona

9. Component interface hi ≤ Qi hi(child) ≤ hi(parent) CPU C1 C2 C3 Q1, P1, h1 Q2, P2, h2 Q3, P3, h3 … … … Marko Bertogna CRTS Workshop, Barcelona

10. O(n) test • A set of components that is schedulable with preemptive EDF on a (Q,P) server remains schedulable if each component Ck executes non-preemptively for at most time units, with . Marko Bertogna CRTS Workshop, Barcelona

11. O(1) test • A set of components that is schedulable with preemptive EDF on a (P,Q) server remains schedulable if all components execute non-preemptively for at most time units. Marko Bertogna CRTS Workshop, Barcelona

12. Admission control • The system keeps track of the largest critical section Ri locked by each component Ci • Scheduling invariants: • Ri ≤ hi , for all i • Rmax ≤ h • When a new component asks to be admitted at a particular level: • compute new hi’ values (for all components with larger periods at the same level) • if for any admitted component: Ri > hi’ reject the new component • else admit component and update hi values to hi’ Marko Bertogna CRTS Workshop, Barcelona

13. Admission control policies • When a component locks a critical section for longer than hi: • suspend it  budget exhaustion problem (may lead to deadlock conditions in case of nested CS) • abort it  possible system inconsistencies • continue executing it  temporal system overrun • Then, restore system schedulability by removing the component(s) with: • largest utilization • least importance • latest arrival time • longest critical section Marko Bertogna CRTS Workshop, Barcelona

14. Observations • No need to know a priori the critical section lengths  upper bounds extracted and refined at run-time • Components conditionally admitted into the system • System dynamically converges to a stable condition • No way to preventively avoid CS overruns Marko Bertogna CRTS Workshop, Barcelona

15. Simulations • 10 entities • Q = 5 • P = 100 • U: [0.1;0.9] • T: [20P;500P] Marko Bertogna CRTS Workshop, Barcelona

16. Simulations • 10 entities • Q = 50 • P = 100 • U: [0.1;0.9] • T: [5P;50P] Marko Bertogna CRTS Workshop, Barcelona

17. Conclusions • Simple protocol for CS arbitration in hierarchical systems • Particularly suited for general purpose OS’s • Reduced overhead • User doesn’t need to specify any information on CS lengths • System dynamically extracts timely parameters to grant soft real time requirements Marko Bertogna CRTS Workshop, Barcelona

18. Next Step • Pseudo-polynomial algorithms to find tight bounds on the NP chunk lengths • Adapt our protocol to multicore systems • Generalize to multicore hierarchical systems • Implement in Linux (particular attention to overall complexity) • Final results expected by the end of 2009 Marko Bertogna CRTS Workshop, Barcelona