Suspension-based locks provide a programming interface similar to the one offered by spin locks: the operations acquire(`q) and release(`q) (also named lock(`q)/unlock(`q) or P(`q)/V(`q)) are called before and after a critical section, respectively, and the implementation ensures that, for any resource `q, at any time, the lock on `q can be held by at most one job. The crucial difference to spin locks is that the operation acquire(`q) does not spin until the lock is successfully acquired, but rather suspends the calling job, and hence allows another pending job on the same processor core to be scheduled.
Suspension-based locks can conceptually also be used for global resources.
However, throughout this work, we assume that suspension-based locks are only used for local resources, and spin locks are used for global resources, as mandated by the AUTOSAR specification.
Suspension-based locks are used as part of two classic locking protocols for uniprocessor systems, the Priority Ceiling Protocol and the Stack Resource Protocol, which we describe next.
The Priority Ceiling Protocol
The Priority Ceiling Protocol (PCP) [121] is a classic real-time locking protocol designed for uniprocessor systems under fixed-priority schedul-ing, but it can also be used for local resources in a partitioned multi-core system. For each local resource `q the PCP defines the priority ceil-ing Π(`q) to be the highest scheduling priority of any task accessing `q: Π(`q) = minTi{πi|Ni,q > 0}. Further, the PCP defines the system ceiling Π(t) at time t to be the maximum priority ceiling of any resource heldˆ at time t: ˆΠ(t) = min`q{Π(`q)| `q is locked at time t} ∪ {n + 1} , where Π(t) = n + 1 indicates that no resource is locked at time t.ˆ
The PCP (simplified without support for nested requests) defines the following locking rules:
• If a job Ji requests the resource `q and Ji’s priority i is higher than the system ceiling at time t, i.e., i < ˆΠ(t), then Ji’s request is served and Ji can enter its critical section. If Ji’s priority is at most the system ceiling at time t, i.e., i ≥ ˆΠ(t), then Ji’s request is blocked.
• If a job Ji holds a resource `q and a higher-priority job Jh (with h < i) requests resource `q, then Ji inherits Jh’s higher priority until Ji releases `q.
Jobs are scheduled according to a fixed-priority scheduler, taking into account that jobs may temporarily inherit higher scheduling priorities according the locking rules stated above. Notably, in contrast to critical sections protected by spin locks, the PCP allows preemptions during the execution of critical sections.
The schedule in Figure 2.4 illustrates the behavior of the PCP. At time t = 1 the job J3, acquires the lock on resource `1 and starts executing its critical section. The job J is released at time t = 2 and preempts J since J has a
5
0 10
J
1J
2P
1J
3`1 job executing
job executing critical section job holding resource`1 `1
job release
`1
job suspended while waiting for resource
Figure 2.4: Example schedule for the PCP.
higher priority. At time t = 4 the job J1 is released, preempts J2 and issues a request for `1 at time t = 5. Since `1 is still held by J3, job J1 is blocked and J3 inherits J1’s priority. Job J3 continues the execution of its critical section during the interval [5, 6) and then releases the lock on `1, allowing J1 to acquire the lock and execute its critical section.
AUTOSAR-compliant systems use a variant of the PCP as described above, the Immediate Priority Ceiling Protocol or OSEK PCP. The only difference under the immediate PCP is that a job’s priority is immediately increased to the resource ceiling once the lock on a resource is acquired (effectively replacing the second rule stated above). Notably, the immediate PCP exhibits the same worst-case behavior as the PCP with regard to the delay that jobs may incur, but allows for an easier implementation.
Next, we summarize the Stack Resource Protocol, which is related to the PCP and forms the basis of a locking protocol supporting multicore systems.
The Stack Resource Protocol
The Stack Resource Protocol (SRP) [23] is another classic real-time locking protocol for uniprocessor systems, that can, similar to the PCP, also be used for local resources in a multicore system under partitioned fixed-priority
scheduling. For the sake of simplicity, we describe a simplified variant of the SRP that omits the concept of preemption levels as used in [23], which is required for the analysis of the SRP under EDF scheduling. The SRP is based on notion of resource ceilings, similar to the PCP. The SRP, however, aims to reduce the number of context switches between jobs with the following locking rule:
• A newly released job Ji may only start executing at time t if i < ˆΠ(t).
This rule ensures that, at the time Ji starts executing, all (local) resources that Ji might access are available. Compared with the PCP, this rule of the SRP causes a job to incur delay before starting to execute, while under the PCP the delay is incurred when Ji issues a request for a resource that is already held. The total worst-case delay that a job can incur under the SRP, however, is the same as under the PCP (and hence also the same as under the immediate PCP used in AUTOSAR-compliant systems5).
As an example, consider the jobs and their arrival times in Figure 2.5. At time t = 2, when J2 is released, the system ceiling ˆΠ(2) is ˆΠ(2) = 1, since J3 holds resource `1, which is also accessed by J1. Hence, since 2 6< ˆΠ(2) holds, J2 does not start executing until time t = 3, when J3 releases its lock on `1 and the system ceiling is lowered to ˆΠ(3) = n + 1 = 4. At time t = 4, job J1
is released and starts executing immediately (preempting J2) since ˆΠ(4) = 4 and hence 1 < ˆΠ(4).
The SRP is used as part of the Multiprocessor Stack Resource Protocol, a locking protocol suitable for both local and global resources under partitioned fixed-priority.
5In fact, the immediate PCP can be considered to be an implementation of the SRP since the immediate priority increase effectively ensures the locking rule we stated for the SRP.
5
0 10
J
1J
2P 1 J
3`1
`1
Figure 2.5: Example schedule for the SRP.