NonPreemptive Access to Shared Resources in Hierarchical RealTime 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

3
Hierarchical systems
Component Task or Server
CPU
C1
C2
C3
Q3 , P3
Q1 , P1
Q2 , P2



4
Target architecture

• General purpose OS supporting hierarchical
  execution 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

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

6
Budget exhaustion problem
Server 1 Q 10, P 100
Lock (R1)
Unlock (R1)
Server 2 Q 90, P 100
Lock (R1)
BLOCKED
7
Solution

• Perform a budget check before each locking
  operation
• BROE server (Fisher, Bertogna, Baruah RTSS07)
• 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
8
Non-preemptive access 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, ECRTS05
• O(n), O(1)
• Pseudo-polynomial (tight?)

hi maximum non-preemptive chunk length for
component Ci
9
Component interface
hi Qi hi(child) hi(parent)
CPU
C1
C2
C3
Q3, P3, h3
Q1, P1, h1
Q2, P2, h2



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 .
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.
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 gt hi ? reject
  the new component
• else admit component and update hi values to hi

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

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

15
Simulations

• 10 entities
• Q 5
• P 100
• U 0.10.9
• T 20P500P

16
Simulations

• 10 entities
• Q 50
• P 100
• U 0.10.9
• T 5P50P

17
Conclusions

• Simple protocol for CS arbitration in
  hierarchical systems
• Particularly suited for general purpose OSs
• Reduced overhead
• User doesnt need to specify any information on
  CS lengths
• System dynamically extracts timely parameters to
  grant soft real time requirements

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