2.4 Real-Time Locking Protocols
2.4.3 Uniprocessor Real-Time Locking Protocols
In contrast to the multiprocessor case reviewed below (Section 2.4.4), uniprocessor locking is well- studied and understood. In particular, protocols that support nested resource requests exist and have been adopted in several commercial RTOSs and, to some degree, even in the POSIX standard. Additionally, bothFPresponse time analysis (Theorem 2.2) and theEDFdensity test (Theorem 2.4) have been extended to account for priority inversions. In the presence of bounded pi-blocking, HRT schedulability can be established with the following two theorems.
Theorem 2.12(Audsleyet al., 1993). Letτ ={T1, . . . , Tn}denote a set of constrained-deadline
sporadic tasks indexed in order of decreasing priority. On a uniprocessor, underFPscheduling, the response timeriof taskTi∈τ is bounded by the smallestRithat satisfies the following equation:
Ri =ei+bi+ i−1 X h=1 Ri ph ·eh.
Theorem 2.13 (Baker, 1990, 1991). An arbitrary-deadline sporadic task setτ ={T1, . . . , Tn}is HRT schedulable underEDFon a uniprocessor if, for eachTi ∈τ,
bi min(di, pi)
+ X
Tk∈τ
δk≤1.
Both HRT schedulability tests are sustainable with respect to execution requirements and periods (Baruah and Burns, 2006; Burns and Baruah, 2008).
In the discussion of the following four locking protocols, we first assumeFPscheduling and that all resources are subject to mutex constraints, which is the model most commonly assumed in prior work. EDFscheduling and RW andk-exclusion constraints are considered thereafter.
Non-preemptive sections. The example shown in Figure 2.25 illustrates that ill-timed preemptions of resource-holding jobs can cause unbounded priority inversions. The simplest approach to avoiding unbounded priority inversions is to disallow preemptions during critical sections completely. That is,
20 15 10 5 0 time T1 T2 T3 job release job completion job deadline job scheduled critical section locked unlocked
Figure 2.28: NCPschedule of the scenario shown in Figure 2.25. SinceJ3,1 is non-preemptable
at time 5,J1,1is not transitively delayed byJ2,1. J1,1suffers pi-blocking during[3,6);J2,1 suffers pi-blocking during[5,6). Maximum pi-blocking is limited tob1 = 4,b2= 4, andb3= 0.
critical section. This prevents later-arriving, higher-priority jobs from preempting a resource-holding job, thereby ensuring that each request will be completed as soon as possible (once it has been satisfied). We refer to this locking protocol as thenon-preemptive critical section protocol(NCP).
Example 2.12. An example schedule is shown in Figure 2.28, which depicts the same jobs that were shown in Figure 2.25. SinceJ3,1 executes its critical section non-preemptively during[2,6), it is not preempted whenJ1,1andJ2,1arrive at times 3 and 5, respectively. As a result,J2,1 does not
transitively delayJ1,1. J1,1still suffers pi-blocking during[3,6), but in contrast to Figure 2.25, it
is limited to the length ofJ3,1’s critical section. Note that there are no suspensions and no failed
lock attempts (i.e., unsatisfied requests)—under theNCP, once a job starts executing, all its resource requests are satisfied immediately (assuming resource-holding jobs do not suspend for locking-
unrelated reasons). ♦
In general, theNCPensures that any job incurs pi-blocking at most once, and only immediately when it is released. Further, theNCPlimits the maximum duration of priority inversion to the length of one outermost request of any lower-priority job. Thus, underFP scheduling, a bound on the maximum duration of priority inversion incurred by anyJiis given bybi = max{Lk,q|k > i∧1≤
q≤nr}. TheNCPis in widespread use in practice, and particularly so in deeply embedded systems that execute all tasks in kernel mode, because non-preemptivity can be very efficiently realized by disabling interrupt delivery, which can be achieved with a single instruction on many platforms (recall Section 2.1.3).
The biggest disadvantage of theNCPis that jobs that do not access any shared resources may still suffer a priority inversion on release,i.e., eachbireflects the resource usage of other tasks and
20 15 10 5 0 time T1 T2 T3 job release job completion job deadline job scheduled critical section locked unlocked
Figure 2.29: NCPschedule that demonstrates that the highest-priority task is subject to pi-blocking even if it is independent.T2 andT3 share one resource`q, butN1,1 = 0. The first job ofT1, released at time 1, is “lucky” and can preemptJ3,1. However, the second jobJ1,2 is released whileJ3,1
executes a long critical section. As a result,J1,2is not scheduled until after its deadline.
(i.e.,N1,1= 0), but tasksT2andT3do. Further,T1has a very tight deadline. BecauseJ3,1executes its request non-preemptively,J1,2cannot preemptJ3,1and consequently misses its deadline. This
shows that it can be problematic if locking protocols penalize independent tasks.
Priority inheritance. Shaet al. (1990) designed an elegant mechanism that avoids delaying higher- priority jobs if they do not request resources. Theirpriority inheritance protocol(PIP) only intervenes when preempting a lower-priority job would delay a higher-priority job (Shaet al., 1990; Rajkumar, 1991). Priority inheritance prevents such preemptions by raising the effective priority of resource- holding jobs to that of the highest-priority waiting job. LetW(Ji, t)denote the set of jobs that are
waiting forJiat timet,i.e., that have issued a request for a resource that is currently being held by Ji. Under thePIP,Ji’s effective priority is defined as
y(Ji, t),min{Y(Ji, t)}[{y(Jk, t)|Jk∈W(Ji, t)}.
Note that priority inheritance is transitive sincey(Ji, t)is defined in terms of eachy(Jk, t). That
is, ifJkis waiting for a resource that a jobJj holds, andJjis waiting for a resource thatJiholds,
theny(Ji, t)≤y(Jj, t)≤y(Jk, t)≤Y(Jk, t). This yields a powerful progress property: whenever a waiting jobJksuffers a priority inversion (i.e., ifJkhas the highest base priority), then the job at the end of the “wait-for” dependency chain is guaranteed to be scheduled. This limits the duration of each priority inversion to the length of one outermost critical section. Further, since jobs are preemptable at all times, the highest-priority job is only delayed if it issues requests itself. If there are
20 15 10 5 0 time T1 T2 T3 job release job completion job deadline job scheduled lock attempt critical section
job suspended
locked unlocked
Figure 2.30: PIPschedule of the scenario that results in a deadline miss under theNCP(Figure 2.29). Under thePIP, jobs are always preemptable. Hence,J1,2 can preemptJ3,1in the middle of a critical section and thus completes on time. Note thatJ2,1 does not incur pi-blocking immediately upon
release (sinceJ3,1is preemptable), but is nonetheless delayed when it requires the resource still held
byJ3,1.
multiple jobs waiting for a resource, then their requests are satisfied in order of decreasing effective priority.
Example 2.13. Figure 2.30 shows the example scenario from Figure 2.29 scheduled using thePIP instead of theNCP. Here,J1,2, can preemptJ3,1during its critical section and thus meet its deadline. A second example shown in Figure 2.31 further demonstrates that thePIPis effective at preventing unbounded priority inversions. Unlike the case in Figure 2.25,J2,1cannot preemptJ3,1at time 5 becauseW(J3,1,5) ={J1,1}, and thusy(J3,1,5) = min{3,1}= 1<y(J2,1,5). ♦
In contrast to theNCP, a job may incur a priority inversioneach timethat it requests a resource (that is has not previously acquired). Further, jobs that do not request any shared resources may still be subject to priority inversion if they are not the highest-priority job. For example, if a low-priority jobJ3holds a resource that a high-priority jobJ1requires, then a middle-priority jobJ2 will not be scheduled whileJ3 inheritsJ1’s priority—bothJ1andJ2are subject to priority inversion whileJ3
completes its critical section. In Figure 2.31, this happens during the interval[5,7).
ThePIPyields the following bound on the maximum cumulative priority inversion duration results (assumingFPscheduling). LetAidenote the set of resources that are shared by both tasks of
equal-or-higher and lower priority thanTi,i.e.,
Ai ,{`q| ∃h, ls.t.1≤h≤i∧i < l≤n∧Nh,q>1∧Nl,q >1}. (2.6)
In the worst case, each resource inAiis held by a lower-priority job whenJi commences execution and requested by a higher-priority job (orJiitself) whileJiis pending; the maximum duration of
20 15 10 5 0 time T1 T2 T3 job release job completion job deadline job scheduled lock attempt critical section
job suspended
locked unlocked
Figure 2.31: PIPschedule of the scenario shown in Figure 2.25. SinceJ3,1inheritsJ1,1’s priority
during[4,7),J1,1 is not transitively delayed byJ2,1.J1,1incurs pi-blocking during[4,7). SinceJ3,1
has a lower base priority thanJ2,1,J2,1suffers a priority inversion during[5,7).
priority inversion is thusbi =P`q∈Aimax{Ll,q|l > i}. The bound stated here has been somewhat simplified; see (Shaet al., 1990) for a bound that is less pessimistic if|Ai|>(n−i). However, even then it shows that tasks can have a greater risk of priority inversion under thePIPthan under the NCP. Nonetheless, thePIPis mandated by the POSIX real-time standard and thus widely used in practice.
Another limitation of thePIPis that it is susceptible todeadlock,i.e., to jobs waiting indefinitely for each other to release a resource. Deadlock is only an issue when requests may be nested, that is, when jobs may acquire more than one resource at a time.
Example 2.14. A typical deadlock scenario involving two resources`2and`3is shown in Figure 2.32. JobJ3,1 acquires`3at time 1 and is then preempted by the simultaneous arrivals ofJ2,1andJ1,1.
J1,1requires neither`2nor`3and completes without incurring any pi-blocking.J2,1, however, first locks`2and then requests`3, which is still being held byJ3,1. Consequently,J2,1 suspends andJ3,1
continues to execute its critical section until it, too, requests`2.J3,1 andJ2,1are now deadlocked. ♦
Priority ceiling. Shaet al. (1990) solved both the deadlock problem and the potential for excessive pi-blocking under thePIPwith thepriority-ceiling protocol(PCP) (Shaet al., 1990; Rajkumar, 1991). The intuition underlying thePCPis to delay potentially problematic resource requests until deadlock is impossible. Whether a given request is “potentially problematic” is determined based on the priorities of the tasks sharing a resource according to the following three definitions.
Thepriority ceilingof a resource`q, denotedΠ(`q), is the base priority of the highest-base- priority task that accesses`q; formally,Π(`q),min{i|Ni,q>0}underFPscheduling. Based on
20 15 10 5 0 time T1 T2 T3 3 1 3 2 2 job release job completion job deadline job scheduled lock attempt critical section
job suspended
locked unlocked
Figure 2.32: Example schedule of three tasks showing that jobs can deadlock under the PIP. There are three resources`1, `2, `3. The numbers within each critical section and next to failed lock attempts indicate the index of the requested resource.J3,1andJ2,1issue nested requests for`2and `3, respectively. Deadlock results since neither job can release the resource it holds without first
acquiring the other.
the priority ceiling, thesystem ceilingat timet, denotedΠ(t)ˆ , is the highest priority ceiling of any resource in use at timet, orn+ 1if no resource is in use;i.e.,
ˆ
Π(t),min{n+ 1} [{Π(`q)|`qis in use at timet}.
Finally, letL(t)denote the job that raisedΠ(t)ˆ to its current value. In other words, ifΠ(t)ˆ < n+ 1, thenL(t)holds a resource`qat timetsuch thatΠ(`q) = ˆΠ(t).
Based on the two ceilings, the PCP extends thePIPby enforcing an additional constraint prior to satisfying requests: a requestRi,q,v issued by jobJi is only satisfied at timetif either (i)Y(Ji, t) >Π(t)ˆ or(ii)L(t) = Ji. Condition (i) implies that deadlock is impossible because it prevents a later-arriving, higher-priority jobJifrom acquiringanyresources while a lower-priority job holds at least one resource thatJimightrequest. As a necessary precondition forJito deadlock, there must exist a resource`q, whereNi,q >1, that is already being held by a lower-priority job whenJi locks a second resource`xat timet. (In Figure 2.32, this is the case forJ2,1at timet= 6
withq= 3andx= 2.) SinceNi,q>1, it follows thatΠ(`q)≤iand thusΠ(t)ˆ ≤i, which implies
that condition (i) is false at timet. Therefore,Ji cannot acquire any resources until all resources
that it might request have become available, which precludes deadlock. Condition (ii) is required to prevent jobs from deadlocking with themselves when they issue nested requests. As under thePIP, conflicting requests are satisfied in order of decreasing effective priority, and jobs inherit the priority of blocked higher-priority jobs.
20 15 10 5 0 time 1 2 3 4 ˆ (t) T1 T2 T3 3 1 2 3 2 3 2 job release job completion job deadline job scheduled lock attempt critical section
job suspended
locked unlocked
Figure 2.33: PCPschedule of the scenario that results in deadlock under thePIP(Figure 2.32). The step function above the schedule shows the corresponding system ceilingΠ(t)ˆ as a function of time. Deadlock is avoided becauseJ2,1’s request for`2at time 6 remains unsatisfied until time 10, when the system ceiling is momentarily lowered ton+ 1 = 4. SinceJ2,1immediately acquires`2, the system ceiling is instantaneously restored to`2’s priority ceilingΠ(`2) = 2.
Example 2.15. Figure 2.33 demonstrates how condition (i) prevents deadlock. As in Figure 2.32,
J3,1andJ2,1acquire both`2and`3in a nested fashion. However, under thePCP,J2,1 is prevented from acquiring`2at time 6 becauseJ3,1raised the system ceiling to`3’s priority ceilingΠ(`3) = min{3,2} = 2at time 1. J2,1’s request thus fulfills neither condition (i) nor (ii) until time 10,
when the system ceiling is (briefly) lowered ton+ 1 = 4when J2,1 releases`3. J3,1’s request
for`2 at time 7 is satisfied immediately even thoughJ3,1’s effective priority does not exceed the system ceiling because it is the last job to have raised the system ceiling,i.e.,J3,1’s request satisfies condition (ii) but not condition (i). Note thatJ1,1’s request for`1at time 3 is not delayed by thePCP
sincey(J1,1,3) = 1<Π(3) = 2ˆ . ♦
In general, thePCPavoids deadlock and limits the maximum duration of priority inversion to one (outermost) critical section of any lower-priority job. DefineAias for thePIPin Equation (2.6). AssumingFPscheduling, the maximum (cumulative) duration of priority inversion experienced by anyJiunder thePCPis limited tobi = max{Ll,q|`q ∈Ai∧l > i}. Note that, like theNCP and unlike thePIP, the pi-blocking bound is anO(1)term,i.e., it does not depend on the number of tasksnor the number of shared resourcess. Further, unlike theNCP, the highest-priority job is not subject to priority inversion if it does not access any shared resources. ThePCPis thus an asymptotically optimal uniprocessor real-time locking protocol.
Release blocking. Baker (1990, 1991) proposed a second priority-ceiling-based protocol, namely thestack resource policy(SRP). The bound on maximum pi-blocking under theSRPis identical to the bound ensured by thePCP, but the time at which the priority inversion (if any) is incurred differs. Recall that thePCPworks by delaying “potentially problematic requests.” The key insight underlying theSRPis that the resource-sharing problem can be considerably simplified by delaying the time of “problematic preemptions” instead. We shall use a similar approach in Chapter 6.
Under thePCP, a job may execute immediately after its release, but may become blocked once it issues a resource request. In contrast, under theSRP, a job suffers a priority inversion either immediately upon release or not at all. Define each resource ceilingΠ(`q)and the system ceiling
ˆ
Π(t)as before in the definition of thePCP. TheSRPconsists of a single scheduling rule:a newly- released jobJi,j is not eligible to execute until timet, wheret≥ai,j, such thatY(Ji,j, t)<Π(t).ˆ In other words, each job is initially suspended and only resumed once its priority exceeds the system ceiling. Note that theSRPdoes not require priority inheritance. WhenJi later issues a request during its execution, theSRPscheduling rule implies thatJi’s request will be satisfied immediately: all resources thatJimightrequest are available after its initial wait. This implies that deadlock is impossible.
Example 2.16. An exampleSRP schedule is shown in Figure 2.34. As before in Figures 2.32 and 2.33,J2,1is released at time 2. However, under theSRP, it may not commence execution until time 9 becauseΠ(t)ˆ ≤2for eacht∈[1,9). As under thePCP, the highest-priority jobJ1,1is not
affected by the resource-sharing of lower-priority jobs. ♦
Locking underEDF. We have assumedFPscheduling in the discussion so far. However, with only small changes, theNCP,PIP, andSRP, andPCPcan be applied toEDFas well. A key property of EDFis that lower-priority jobs released prior to jobJi’s arrival stem from tasks with strictly longer
relative deadlines.
Lemma 2.4. UnderEDF(either uniprocessor, global, clustered, or partitioned), if a lower-priority jobJl,karrived prior toJi,j,i.e., ifal,k < ai,jandY(Ji,j, t)<Y(Jl,k, t), thendi < dl.
Proof. This follows from the definition ofEDFpriorities:
20 15 10 5 0 time 1 2 3 4 ˆ (t) T1 T2 T3 3 1 2 3 2 3 2 job release job completion job deadline job scheduled lock attempt critical section
job suspended
locked unlocked
Figure 2.34: SRPschedule of the scenario that results in deadlock under thePIP(Figure 2.32). Similarly to thePCP(Figure 2.33), theSRPavoids deadlock by means of the system ceiling.J2,1
is suspended immediately upon release because its priority does not exceed the system ceiling. At time 9, whenJ3,1 releases`3, the priority ceiling is lowered to four andJ2,1 becomes eligible to execute.
{definition ofEDFbase priorities} ⇔ di,j < dl,k∨(di,j =dl,k∧i < l)
{definition of absolute deadline}
⇔ ai,j+di< al,k+dl∨(ai,j+di=al,k+dl∧i < l)
{sinceai,j > al,k }
⇒ di < dl∨(di< dl∧i < l)
⇔ di < dl.
Since this relies only on the definition of theEDFprioritization function, the lemma applies equally toEDF,P-EDF,C-EDF, andG-EDF.
Common to theNCP,PIP,PCP, andSRPis that only earlier-arrived, lower-priority jobs can causeJito incur a priority inversion (since lower-priority jobs cannot issue outermost requests while
Jiis pending). This, together with Lemma 2.4, implies that only critical sections of tasks with strictly
larger relative deadlines pi-block Ji underEDF. In contrast, underFP, only critical sections of