PriorityInversion - IEEF TRANSACTIONS ON COMPUTERS, VOL....

Info iconThis preview shows pages 1–11. Sign up to view the full content.

View Full Document Right Arrow Icon
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 2
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 4
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 6
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 8
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 10
Background image of page 11
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: IEEF TRANSACTIONS ON COMPUTERS, VOL. 39, NO. 9. SEPTEMBER I990 1175 Priority Inheritance Protocols: An Approach to Real—Time Synchronization LUI SHA, MEMBER, IEEE, RAGUNATHAN RAJKUMAR, MEMBER. IEEE, AND JOHN P. LEHOCZKY. MEMBER. IEEE Abstract—A direct application of commonly used synchro- nization primitives such as semaphores, monitors. or the Ada rendezvous can lead to uncontrolled priority inversion, a situa- tion in which a higher priority job is blocked by lower priority jobs for an indefinite period of time. In this paper, we investi- gate tuo protocols belonging to the class ofpriority inheritance protocols. called the basic priority inheritance protocol and the priority ceiling protocol. We Show that both protocols solve this uncontrolled priority inversion problem. In particular, the pri- ority ceiling protocol reduces the worst case task blocking time to at most the duration of execution of a single critical section of a lower priority task. In addition. this protocol prevents the formation of deadlocks. We also derive a set of sufficient con- ditions under which a set of periodic tasks using this protocol is scltedulablc. Index Terms—Priority inheritance. priority inversion, real- time Mstems, scheduling, synchronization. I. INTRODUCTION HE SCHEDULING of jobs with hard deadlines has been an important area of research in real-time computer sys- ems. Both nonpreemptive and preemptive scheduling algo- rithms have been studied in the literature [3]. [4]. [6]»[8], [I0]. [I l]. An important problem that arises in the context of such real—time systems is the effect of blocking caused by the need for the synchronization ofjobs that share logical or phys- ical resources. Mok [9] showed that the problem of deciding whether it is possible to schedule a set of periodic processes is NP-hard when periodic processes use semaphores to en- force mutual exclusion, One approach to the scheduling of real-time jobs when synchronization primitives are used is to try to dynamically construct a feasible schedule at run-time. Mok [9] developed a procedure to generate feasible sched- ules with a kernelizcd monitor, which does not permit the preemption of jobs in critical sections. It is an efiective tech- nique for the case where the critical sections are short. Zhao, Ramamritham. and Stankovic [I4], [15] investigated the use Manuscript received December 1. 1987; revised May I, 1988. This work was supported in pan by the Office of Naval Research under Contract N000I4- SLR-0734. in pan by Naval Ocean Systems Center under Contract N6600l-‘ 87-00155. and in part by the Federal Systems Division of IBM Corporation under University Agreement YA~278067. L. Sha is with the Software Engineering Institute and the Department of Computer Science. Carnegie Mellon University. Pittsburgh. PA 152l3. R. Rajkumar is with IBM Thomas J. Watson Research Center. Yorktown Heights. NY 10598. 7 I.-P. Lehoczky is with the Department of Statistics. Carnegie Mellon Uni- vcrstty. Pittsburgh. PA l52l3. IEEE Log Number 0037197 of heuristic algorithms to generate feasible schedules. Their heuristic has a high probability of success in the generation of feasible schedules. In this paper, we investigate the synchronization problem in the context of priority—driven preemptive scheduling. an ap- proach used in many real-time systems. The importance of this approach is underscored by the fact that Ada. the lan- guage mandated by the US. Department of Defense for all its real-time systems, supports such a scheduling discipline. Unfortunately. a direct application of synchronization mecha- nisms like the Ada rendezvous. semaphores. or monitors can lead to uncontrolled priority inversion: a high priority job be- ing blocked by a lower priority job for an indefinite period of time Such priority inversion poses a serious problem in real-time systems by adversely affecting both the schedulabil- ity and predictability of real-time systems. In this paper. we formally investigate the priority inheritance protocol as a pri— ority management scheme for synchronization primitives that remedies the uncontrolled priority inversion problem. We for- mally define the protocols in a uniprocessor environment and in terms of binary semaphores. In Section II, we review the problems of existing synchronization primitives, and define the basic concepts and notation. In Section III, we define the basic priority inheritance protocol and analyze its properties. In Section IV, we define an enhanced version of the basic priority inheritance protocol referred to as the priority ceiling protocol and investigate its properties. Section V analyzes the impact of this protocol on sebcdulability analysis when the rate-monotonic scheduling algorithm is used and Section VI examines the implication considerations as well as some pos- sible enhancements to the priority ceiling protocol. Finally, Section VII presents the concluding remarks. II. THE PRIORITY INVERSION-PROBLEM Ideally, a high—priority job J should be able to preempt lower priority jobs immediately upon J’s initiation. Priority inversion is the phenomenon where a higher priority job is blocked by lower priority jobs. A common situation arises when two jobs attempt to access shared data. To maintain con- sistency, the access must be serialized. If the higher priority job gains access first then the proper priority order is main- tained; however, if the lower priority job gains access first and then the higher priority job requests access to the shared data. this higher priority job is blocked until the lower priority job completes its access to the shared data. Thus, blocking is a form of priority inversion where a higher priority job must wait for the processing of a lower priority job. Prolonged du- 00l8—9340/90/0900-lUS$01.00 © I990 IEEE ll76 rations of blocking may lead to the missing of deadlines even at a low level of resource utilization. The level of resource utilization attainable before a deadline is missed is referred to as the schedu/ability of the system. To maintain a high de- gree of schedulability, we will develop protocols that would minimize the amount of blocking. It is also important to be able to analyze the performance of any proposed protocol in order to determine the schedulability of real-time tasks that use this protocol. Common synchronization primitives include semaphores, locks. monitors, and Ada rendezvous. Although the use of ese or equivalent methods is necessary to protect the con— sistency of shared data or to guarantee the proper use of non- preemptable resources. their use may jeopardize the ability of the system to meet its timing requirements. In fact, a direct application of these synchronization mechanisms can lead to an indefinite period of priority inversion and a low level of schedulability. Example 1: Suppose that J1, J3, and J; are three jobs arranged in descending order of priority with J, having the highest priority. We assume that jobs J1 and J; share a data structure guarded by a binary semaphore 5. Suppose that at time t1. job J3 locks the semaphore S and executes its criti- cal scction. During the execution ofjob J3‘s critical section, the high priority job J, is initiated. precmpts J3. and later at— tempts to use the shared data. However. Job J1 will be blocked on the semaphore S. We would expect that J1. being the high- est priority job, will be blocked no longer than the time for job J; to Complete its critical section. However. the duration of blocking is. in fact, unpredictable. This is because job J3 can be preempted by the intermediate priority job J3. The blocking of J3, and hence that ole, will continue until J3 and any other pending intermediate jobs are completed. The blocking period in Example I can be arbitrarily long. This situation can be partially remedied if a job in its critical section is not allowed to be preempted; however, this solution is only appropriate for very short critical sections, because it creates unnecessary blocking. For instance, once a low prior- ity job enters a long critical section, a high priority job which does not access the shared data structure may be needlessly blocked. An identical problem exists in the use of monitors. The priority inversion problem was first discussed by Lamp- son and Redell [2] in the context of monitors. They suggest that the monitor be executed at a priority level higher than all tasks that would ever call the monitor. In the case of the Ada rendezvous, when a high priority job (task) is waiting in the entry queue of a server job, the server itself can be preempted . by an independent job J, if job J’s priority is higher than both the priority of the server and the job which is currently in rendezvous with the server. Raising the server priority to be higher than all its callers would avoid this particular problem but would create a new problem: a low priority job may un- necessarily block the execution of independent higher priority jobs via the use of the server. The use of priority inheritance protocols is one approach I? rectify the priority inversion problem in existing synchro- nization primitives. Before we investigate these protocols. we first define the basic concepts and state our assumptions. A IEEE TRANSACTIONS ON COMPUTERS. VOL. 39. NO. 9. SEPTEMBER 1090 job is a sequence of instructions that will continuously use the processor until its completion if it is executing alone on the processor. That is, we assume that jobs do not suspend them- selves, say for I/O operations; however. such a situation can be accommodated by defining two or more jobs. In addition, we assume that the critical sections of a job are properly nested and a job will release all of its locks, if it holds any, before or at the end of its execution. In all our discussions below, we assume that jobs J], J2,---,J,, are listed in de- scending order of priority with J1 having the highest priority. A periodic task is a sequence of the same type ofjob occur- ring at regular intervals, and an aperiodic task IS a sequence of the same type of job occurring at irregular intervals. Each task is assigned a fixed priority, and every job of the same task is initially assigned that task’s priority. If several jobs are eligible to run, the highest priority job will be run. Jobs With the same priority are executed in a FCFS discipline. When a job J is forced to wait for the execution of lower priority jobs, job J is said to be “blocked. ” When a job waits for the execution of high priority jobs or equal priority jobs that have arrived earlier. it is not considered as “blocked.” We now state our notation. Notation: - J, denotes ajob, i.e.. an instance ofa task 7,. P, and T,- dcnote the priority and period of task 7,-, respectively. a A binary semaphore guarding shared data and/or re- source is denoted by S,-. P(S,) and V(S,) denote the indivisiblc operations lock (wait) and unlock (signal), respectively, on the binary semaphore Si. o The jth critical section in job J, is denoted by :i'j and corresponds to the code segment of job J,- between the jth P operation and its corresponding V operation. The semaphore that is locked and released by critical section Zi,j is denoted by SM. 0 We write 2,3,- C 2“. if the critical section z,-.J- is entirely contained in zi,k. o The duration of execution of the critical section 2,-_J-, de- noted dj‘j, is the time to execute 2,” when .1,- executes on the processor alone. We assume that critical sections are properly nested. That is, given any pair of critical sections z,;,- and z,-_k, then either 21,} C Zi_k. Zi_k C z,-_J-, or Zr"; 02,31, = 6.111 addition, we assume that a semaphore may be locked at most once in a single nested critical section. Definition: A job J is said to be blocked by the critical section Z”- of job J; if J,- has a lower priority than J but J has to wait for J ,~ to exit z,; J- in order to continue execution. Definition: A job J is said to be blocked by job J ,- through semaphore S, if the critical section z,-_j blocks J and SM = . In the next two sections. we will introduce the concept of priority inheritance and a priority inheritance protocol called the priority ceiling protocol. An important feature of this pro- tocol is that one can develop a schedulability analysis for it in the sense that a schedulability bound can be determined. If the utilization of the task set stays below this bound. then the deadlines of all the tasks can be guaranteed. In order to create such a bound. it is necessary to determine the worst case du- sax er al. PRIORITY INHERITANCE PROTOCOLS ration of priority inversion that any task can encounter. This worst case blocking duration-will depend upon the particular protocol in use. Notation: Big] denotes the set of all critical sections of the lower priority job Jj which can block Jg. That is, 3,“. ={:, klj > i and :j‘k can block J,-}.l Since we consider only properly nested critical sections, the set of blocking critical sections is partially ordered by set inclusion. Using this partial ordering, we can reduce our attention to the set of maximal elements of i3“. Bin. Specif- ically. we have 6.7.] ={Zj'kl(zj"k E B“) /\( ~ 32],," 6 6,3,- such that :j‘t- C :J.,,,)} The set 3,11 contains the longest critical sections of JJ- which can block J,- and eliminates redundant inner critical sections. For purposes of schedulability analysis, we will restrict atten- tion to 13' : U]. 46;]. the set of all longest critical sections that can block J,. III Till: BASIC I’RioRi'H' lNIII-‘RI'I‘ANCIE PROTOCOL The basic idea of priority inheritance protocols is that when a job J blocks one or more higher priority jobs. it ignores its original priority assignment and executes its critical section at the highest priority Icch of all the jobs it blocks. After exiting its critical section. job J returns to its original priority level. To illustrate this idea. we apply this protocol to Example I. Suppose that job J, is blocked by job J3. The priority inheritance protocol requires that job J; execute its critical section at job Jr’s priority. As a result Job J: will be unable to preempt job J; and will itsell'be blocked. That is. the higher priority job J; must wait for the critical section of the lower priority job J; to be executed. because job J; “inherits” the priority ofjob J.. Otherwise. Jl will be indirectly preempted by J3. When J3 exits its critical section. it regains its assigned lowest priority and awakens J, which was blocked by J3. Job J.. having the highest priority. immediately preempts J3 and runs to completion. This enables J2 and J3 to resume in succession and run to completion. .4. The Definition of the Basic Protocol We now define the basic priority inheritance protocol. I) Job J. which has the highest priority among the jobs ready to run. is assigned the processor. Before job J enters a critical section, it must first obtain the lock on the semaphore S guarding the critical section. Job J will be blocked, and the lock on S will be denied. if semaphore S has been already locked. In this case. job J is said to be blocked by the job which holds the lock on S. Otherwise. job J will obtain the lock on semaphore S and enter its critical section. When job J exits its critical section. the binary semaphore associated with the critical section will be unlocked, and the highest priority job. if any. blocked by job J will be awakened. 3) A job J uses its assigned priority. unless it is in its crit- ical section and blocks higher priority jobs. lf job J blocks higher priority jobs. J inherits (uses) PH. the highest prior- ’ Note that the second sutlix of d“ and the tits! sullix of :14 correspond ll‘ jfll" J}. 1177 ity of the jobs blocked by J. When J exits a critical section. it resumes the priority it had at the point of entry into the critical section.2 3) Priority inheritance is transitive. For instance, suppose J1, J2, and J3 are three jobs in descending order of priority. Then. ifjob J3 blocks job 12, and J3 blocksjob J1. J3 would inherit the priority of J, via J3. Finally. the operations of priority inheritance and of the resumption of original priority must be indivisible.3 4) A job J can preempt another job JL if jOl) J is not blocked and its priority is higher than the priority. inherited or assigned. at which job JL is executing. It is helpful to summarize that under the baSic priority inher- itance protocol. a high priority job can be blocked by a low- priority job in one of two situations. First. there is the direct blocking. a situation in which a higher priority job attempts to lock a locked semaphore. Direct blocking is necessary to ensure the consistency of shared data. Second. a medium pri- ority job J] can be blocked by a low priority job J3. which inherits the priority of a high priority job J0. We refer to this form of blocking as push-through blocking. which is neces- sary to avotd having a high-priority job Jo being indirectly preempted by the execution of a medium priority job J.. B. The Properties of the Basic Protoeol We now proceed to analyze the properties of the basic pri» ority inheritance protocol defined above. In this section. we assume that deadlock is prevented by some external means. e.g.. semaphores are accessed in an order that is consistent with a predefined acyclical order. Throughout this section. 6; refers to the sets of the longest critical sections that can block J, when the basic priority inheritance protocol is used. Lemma 1.‘ A job J” can be blocked by a lower prior- ity job JL. only if JL is executing within a critical section zluj E 6;,‘L. when J” is initiated. Proof: By the definitions of the basic priority inheritance protocol and the blocking set BILL. task JL can block JH only if it directly blocks J H or has its priority raised above JH through priority inheritance. In either case. the critical section zLJ- currently being executed by JL is in BQ‘L. If JL is not within a critical section which cannot directly block JH and cannot lead to the inheritance of a priority higher than J H. then J L can be preempted by J H and can never block JH. Lemma 2: Under the basic priority inheritance protocol, a high priority job J H can be blocked by a lower priority job J L for at most the duration of one critical section of EAL regardless of the number of semaphores J and J L share. Proof: By Lemma 1. for JL to block J”. JL must be currently executing a critical section :LJ- 6 69’ L. Once J L exits zLJ, it can be preempted by JH and J” cannot be blocked by JL again. 2 For example. when J executes l'(53) in {PtSIL- .P(S:l.~ '. l’tS;). - . l"(S|)}. it reverts to the priority it had before it executed Pisa). This may be lower than its current priority and cause J to be preempted by a higher priority task. J would. of course. still hold the lock on St. ‘The operations must be indivisible in order to maintain internal consis- tency of data structures being manipulated in the run<timc system 1178 Theorem 3: Under the basic priority inheritance proto- col. given a job J0 for which there are n lower priority jobs {J1,- ~ - ,J,, job Jo can be blocked for at most the duration of one critical section in each of Bah l 51 g n. Proof: By Lemma 2, each of the n lower priority jobs can block job .10 for at most the duration of a single critical section in each of the blocking sets 65d. We now determine the bound on the blockings as a function of the semaphores shared by jobs. Lemma 4: A semaphore S can cause push—through block- ing to job J. only if S is accessed both by a Job which has priority lower than that of J and by a job which has or can inherit priority equal to or higher than that of J. Proof: Suppose that JL accesses semaphore S and has priority lower than that of J. According to the priority inher— itance protocol, if S is not accessed by ajob which has or can inherit priority equal to or higher than that of J. then job JL's critical section guarded by S cannot inherit a priority equal to or higher than that of J. In this case. job J1, will be preempted by job .I and the lemma follows. ’ We next define 5‘7,” to be the set of all longest critical sections ofgiob J, guarded by semaphore Si. and which can block job J, either directly or via push-through blocking. That is. in!» : {:/,,.|:j_,, G 3;] and SJ”, : Si. Let 3"," A. = U15, Lil". represent the set of all longest crit- ical sections corresponding to semaphore Si. which can block J,. Lemma 5: Under the basic priority inheritance protocol, a job J, can encounter blocking by at most one critical section in 5"“ A. for each semaphore Si. 1 3 k g m. where m is the number of distinct semaphores. Proof: By Lemma 1. Job J1, can block a higher prior- ity job J” if J,, is currently executing a critical section in 5;,_L. Any such critical section corresponds to the locking and unlocking of a semaphore Sk. Since we deal only with binary semaphores, only one of the lower priority jobs can be within a blocking critical section corresponding to a particular semaphore Si. Once this critical section is exited, the lower priority job JL can no longer block JH. Consequently, only one critical section in 6; corresponding to semaphore Sk can block JH. The lemma follows. Theorem 6: Under the basic priority inheritance protocol, if there are m semaphores which can block job J, then J can be blocked by at most in times. Proof: It follows from Lemma 5 that job J can be blocked at most once by each of the m semaphores. Theorems 3 and 6 place an upper bound on the total block- ing delay that a job can encounter. Given these results, it is possible to determine at compile-time the worst case blocking duration of a job. For instance. if there are four semaphores which can potentially block job J and there are three other lower priority tasks, J may be blocked for a maximum dura- tion of three longest subcritical sections. Moreover, one can find the worst case blocking durations for a job by studying the durations of the critical sections in Bifj and 3'34. ’ Still. the basic priority inheritance protocol has the follow- ing two problems. First. this basic protocol. by itself. does not prevent deadlocks. For example. suppose that at time It . job v. lEEE TRANSACTlONS ON COMPUTERS. VOL 39. NO. 9, SEPTEMBER I990 J2 locks semaphore $2 and enters its critical section. At time t;,~job J2 attempts to make a nested access to lock semaphore 5.. However, job J], a higher priority job, is ready at this time. Job J, preempts job J3 and locks semaphore 5.. Next. ifjob J] tries to lock semaphore $3, a deadlock is formed. The deadlock problem can be solved, say, by imposing a total ordering on the semaphore accesses. Still, a second prob- lem exists. The blocking duration for a job, though bounded, can still be substantial, because a chain of blocking can be formed. For instance. suppose that J. needs to sequentially access S. and 8:. Also suppose that J: preempts J3 within the critical section 1:3,; and enters the critical section £13 Job Jl is initiated at this instant and finds that the semaphores S] and S: have been respectively locked by the lower priority jobs J3 and J3. As a result, J1 would be blocked for the du- ration of two critical sections, once to wait for J; to release Si and again to wait for J2 to release 32. Thus. a blocking chain is formed. We present in the next section the priority ceiling protocol that addresses effectively both these problems posed by the basic priority inheritance protocol. lV. Tin-L PRIORITY Cl;ll.ll\‘(i Pniiriicot. A. Overview The goal of this protocol is to prevent the formation of deadlocks and of chained blocking. The underlying idea of this protocol is to ensure that when a job J preempts the critical section of another job and executes its own critical section z. the priority at which this new critical section : Will execute is guaranteed to be higher than the inherited priorities of all the preempted critical sections. If this condition cannot be satisfied. job J is denied entry into the critical section Z and suspended. and the job that blocks J inherits J‘s priority. This idea is realized by first assigning a priority ceiling to each semaphore, which is equal to the highest priority task that may use this semaphore. We then allow ajob J to start a new critical section only if J's priority is higher than all priority ceilings of all the semaphores locked by jobs other than J. Example 2 illustrates this idea and the deadlock avoidance property while Example 3 illustrates the avoidance of chained / blocking. Example 2: Suppose that we have three jobs J 0, J l . and J 3 in the system. In addition, there are two shared data structures protected by the binary semaphores S I and $3, respectively. We define the priority ceiling of a semaphore as the priority of the highest priority job that may lock this semaphore. Suppose the sequence of processing steps for each job is as follows. Jo= {---,P(50).~-.V($o),---} J1={"'1P(Sl),"'sp(52)’"'vV(SZ)y"')V(Sl)i”'} ‘12={'“iP(SZ)”"1P(Sl)v"'iV(Sl)s iV(SZ)v ‘}- Recall that the priority of job J i is assumed to be higher than that of job J 2. Thus, the priority ceilings of both semaphores S, and S; are equal to the priority of job J1. The sequence of events described below is depicted in Fig. l. A line at a low level indicates that the corresponding job 5H1. C! c.’.. PRlORlTY INHERITANCE PROTOCOLS Critical sccu'on guarded by so O'iticn] section guarded by Sl Sllocked (aucmpl to lock 8}) 5] locked 1179 M11“ Critiad soctionguardodby 52 S locked 2 S2 “"‘w‘w Slmlocked Sl unlocked vi llll llllllllE-Jlllllllllllll Fig. l. is blocked or has been preempted by a higher priority Job. A has raised to a higher level indicates that the _|ob is executing. The absence oi" a line indicates that the job has not yet been initiated or has completed. Shaded portions indicate execution ot' critical sections. Suppose that 0 At time I”. J; is initiated attd it begins execution and then locks semaphore $3. . At time 1.. Job J; is initiated and preempts job .13. . M titnc 13. job J, tries to enter its critical section by making an indtvisihle s} stem call to execute I’tSl). How— ever. the run-time system will iind that JUh .11 ‘s priority is not higher than the priority ceiling of locked semaphore 5;. Hence. the run-time system suspends job J, without locking S, Job .13 now inherits the priority of job J] and resumes execution. Note that J, is blocked outside its critical section. As J, is not given the lock on 51 but suspended instead. the potential deadloek involving J, and J; is prevented. a At time (3. J: is still in its critical section and the highest priority job J0 is initiated and preempts J2. Later. Jo attempts to lock semaphore 30. Since the priority of Jo is higher than the priority ceiling of locked semaphore 33. job J0 will be granted the lock on the semaphore So. Job Jo will therefore continue and execute its critical section. thereby effectively precmpting J 1 in its critical section and not encountering any blocking. . At time (4. J 0 has exited its critical section and completes execution. Job J; resumes. since J1 is blocked by J: and cannot execute J 2 continues execution and locks S I. . At time 15, J3 releases 5. 0 At time (b. J: releases S; and resumes its assigned pri- ority. Now. Jr is signaled and having a higher priority. it preempts J 3. resumes execution, and locks 32. Then. J l locks 51. executes the nested critical section. and un~ locks S, Later it unlocks S; and executes its noneritical section Code. . At (1. J1 completes execution and J3 resumes. Sequence of events described in Example 2 0 Al I“. J: completes. Note that in the above example. J“ is never blocked because its priority is higher than the priority ceilings of semaphores S. and 5;. J1 was blocked by the lower priority job J3 dur- ing the intervals [[3, (3] and I14, (“1. However. these intervals correspond to part of the duration that J; needs to lock S; Thus. J1 is blocked for no more titan the duration of one crit- ical section of a lower priority job J3 even though the actual blocking occurs over disjoint time intervals. [I is. indeed. a property of this protocol that any _]0h can be blocked for at most the duration of a single critical section of a lower pri- ority job. This property is further illustrated by the following example. Example 3: Consider the example from the previous sec- tion where a chain of blockings can be formed. We assumed that Job J1 needs to access SI and S; sequentially while J3 accesses S: and J3 accesses 5.. Hence. the priority ceilings of semaphores S. and 33 are equal to P1. As before. let job J3 lock 51 at time to. At time n. job J; is initiated and preempts J3. However. at time 13, when J3 attempts to lock 32, the run-time system finds that the priority of J; is not higher than the priority ceiling P1 of the locked semaphore 5]. Hence, J; is denied the lock on S; and blocked. Job J3 resumes execution at Jg's priority. At time 13, when J; is still in its critical section. J l is initiated and finds that only one semaphore S] is locked. At time [4. J. is blocked by J3 which holds the lock on 3.. Hence, J3 inherits the priority of J}. At time {5. job J3 exits its critical section 23". resumes its original priority. and awakens J). .lob J3. having the highest priority. preempts J3 and runs to completion. Next. J: which is no longer blocked completes its execution and is followed by J3. . Again. note that J; is blocked by J; in the interval [14, [5] which corresponds to the single critical section :3 l- Also. job J; is blocked by J; in the disjoint intervals [(3. ti] and [14, I5] which also correspond to the same critical section :1. llbO Critical section guarded by 30 Critical section guarded by S1 blocked by )2 (attempt to lock 50) blocked by J2 (aucmpt to lock 52) SI unlocked Fig 8 Definition Having illustrated the basic idea of the priority ceiling pro- tocol and its properties, we now present its dchnition. ll Job .I. which has the highest priority among the jobs ready to run. is assigned tltc processor. and let S‘ be the semaphore with the highest priority ceiling of all semaphores currently locked by ~|obs other than job J Before job J en— tcrs its critical section. it must tirst obtain the lock on the semaphore S guarding the shared data structure. Job J will be blocked and the lock on S will be denied. ii' tltc priority ot'ioh J is not higher than the priority ceiling of semaphore .8" 4 In this case. job .I is said to be blocked on semaphore S' and to be blocked by the job which holds the lock on 3'. Otherwise job J will obtain the lock on semaphore S and en- ter its critical section. When a job J exits its critical section, the binary semaphore associated with the critical section will be unlocked and the highest priority job. if any. blocked by job J will be awakened. 2) AJOb J uses its assigned priority. unless it is in its critical section and blocks higher priority jobs. lfjob J blocks higher priority jobs. J inherits P”. the highest priority of the jobs blocked by J. When J exits a critical section. it resumes the priority it had at the point of entry into the critical section.5 Priority inheritance is transitive. Finally, the operations of priority inheritance and of the resumption of previous priority must be indivisible. 3) A job J. when it does not attempt to enter a critical section, can preempt another job JL if its priority is higher than the priority. inherited or assigned. at which job J L is executing. We shall illustrate the priority ceiling protocol using an example. " Note that ifS has been already locked. the priority ceiling ofS will be at least equal to the priority of J. Because job J‘s priority is not higher than the priority ceiling of the semaphore S locked by another job. J will be blocked. Hence. this rule implies that it' a liob J attempts to lock it semaphore that has ht?“ already locked. J will be denied the lock and blocked instead That is. alien J exits the part ot'a critical section. it resumes its previous priority Solncked 74$ llZiEE TRANSACTIONS ON COMPUTERS. VOL. 39. NO. 9. SEPTEMBER I990 MM Critical section guarded by S 2 SI locked S2 unlitchd S l ked 2unoc Sequence ltl' events described in li\am[tlc 4 Eanp/c 4: We assume that the priority ot'job .l, is higher than that ofjob J, t I, The processing steps in each job are as follows: Job J” accesses :0.” and :(H by executing the steps {' ' '. ]’(S(1)u '.V(So). ' ' ' ,I’(St).' ' ' . "'(St). }. job J1 accesses only If": by executing { J’tszl,~ .Viszl.‘ }. and job J; accesses 3;: and makes a nested semaphore access to S. by executing {- ,P($2).o~.I'<Sn. -.V(S.>.~-,V(S:i,---}. Note that the priority ceilings of semaphores St, and S, are equal to P0. and the priority ceiling of semaphore S: is PI Fig. 2 depicts the sequence of events described below. Suppose that I At time to, job J3 begins execution and later locks Sg. . At time I]. job Jr is initiated. preempts J3. and begins execution. . At time (2, while attempting to access 83 already locked by .12. job J1 becomes blocked. Job J2 now resumes the execution of its critical section 2;: at its inherited priority ofJ., namely P1. . At time 13, job J 3 successfully enters its nested critical section 23,, by locking Si. Job J; is allowed to lock 8.. because there is no semaphore S‘ which is locked by other jobs. 0 At time {4. job J3 is still executing :3. I but the highest priority job Jo is initiated. Job J0 preempts J3 within 13,. and executes its own noncritical section code. This is possible because Po. the priority of Jo. is higher than P. . the inherited priority level at which Job Jg‘s :;_1 was being executed. a At timc15 JUb J“ attempts to enter its critical section :(l_tt SHA c.‘ al.‘ PRIORITY lNHERlTANCE PROTOCOLS by locking St), which is not locked by any job. However. since the priority ofjob Jo is not higher than the priority ceiling P0 of the locked semaphore S] . job J0 is blocked by job J3 which holds the lock on S]. This is a new form of blocking introduced by the priority ceiling protocol in addition to the direct and push—through blocking encoun- tered in the basic protocol. At this point. job J3 resumes its execution of :11 at the newly inherited priority level (ll. Po. . At time I“. job J3 exits its critical section :3‘1 Semaphore S, is now unlocked. job J; returns to the pre- viously inherited priority of Pt . and Job Jr. is awakened. At this point. J“ precmpts job J3. because its priority Pi, is higher than the priority ceiling P. of 33. Job Jr, will be granted the lock on St. and will execute its criti— cal section Cut). Later. it unlocks St, and then locks and unlocks S]. . At time (7. job Jr. completes its execution. and job J3 resumes its execution of :1: at its inherited priority P, a At time Ix. Job J; exits :373. semaphore S: is unlocked. job J_s returns to its own priority Pg. and job J. is awak- ened At this point. job J, preenipts job J3 and J, is granted the lock on S: c‘tites its noncritical section code. . At time In. job J] completes its execution and finally .job .I; resumes its execution. until it also completes at time lio Later. J] unlocks S; arid exc- ‘l‘hc priority ceiling protocol introduces a third type of blocking in addition to direct blocking and push-through blocking caused by the basic priority inheritance protocol. An instance of this new type of blocking occurs at time 15 in the above example. We shall refer to this form of block- ing as ceiling blocking. Ceiling blocking is needed for the avoidance of deadlock and of chained blocking. This avoid- ance approach belongs to the class of pessimistic protocols which sometimes create unnecessary blocking. Although the priority ceiling protocol introduces a new form of blocking. the worst case blocking is dramatically improved. Under the basic priority inheritance protocol. a job J can be blocked for at most the duration of min(n, m) critical sections. where n is the number of lower priority jobs that could block J and m is the number of semaphores that can be used to block J. On the contrary. under the priority ceiling protocol a job J can be blocked for at most the duration of one longest subcritical section. C. The Properties of the Priority Ceiling Protocol Before we prove the properties of this protocol, it is impor- tant to recall the two basic assumptions about jobs. First. a job is assumed to be a sequence of instructions that will con- tinuously execute until its completion. when it executes alone on a processor. Second. ajob will release all of its locks, if it ever holds any. before or at the end of its execution. The re- laxation of our first assumption is addressed at the end of this section. Throughout this section. the sets BL,» ,f,. and B,’ refer to the blocking sets associated with the priority ceiling protocol. Li’mma 7: A job J can be blocked by a lower priority job 1181 JL. only if the priority OfJOb J is no higher than the highest priority ceiling of all the semaphores that are locked by all lower priority jobs when J is initiated. Proof: Suppose that when J is initiated. the priority of job J is higher than the highest priority ceiling of all the semaphores that are currently locked by all lower priorityjobs. By the definition of the priority ceiling protocol, job J can always preempt the execution ofjob JL. and no higher priority job will ever attempt to lock those locked semaphores. Lemma 8: Suppose that the critical section :1.” ofgiob Jj is preempted by job J,- which enters its critical section :,.,,,_ Under the priority ceiling protocol. job Jj cannot inherit a priority level which is higher than or equal to that ofjob J, until job J, completes. Proof: Suppose that job Jj inherits a priority that is higher than or equal to that ofjob J, before J,- completes. Hencc. there must exist a job J which is blocked by Jj. In addition. J's priority tnust be higher than or equal to that ofjob .1, We now show the contradiction that J cannot be blocked by J_,. Since job J, precmpts the critical section :7“, ofjob .l_, and enters its own critical section :,.,,,. job ./,'s priority must be higher than the priority ceilings ol~ all the semaphores currently locked by all lower priority Jobs. Since J‘s priority is assumed to be higher than or equal to that of.l,. it follows that job J‘s priority is also higher than the priority ceilings of all the semaphores cttrrently locked by all lower priority jobs. By Lemma 7. J cannot be blocked by J_,. Hence. the contradiction and the lemma follows. Definition: Transitive blocking is said to occur if a job J is blocked by J, which. in tttrn. is blocked by another job Jj. Lemma 9: The priority ceiling protocol prevents transitive blocking. Proof: Suppose that transitive blocking is possible. Let J3 block job J3 and let job J3 block job J,. By the transitivity of the protocol. job J3 will inherit the priority ole which is assumed to be higher than that of job J3. This contradicts Lemma 8, which shows that J3 cannot inherit a priority that is higher than or equal to that of job J2. The lemma follows. Theorem 10: The priority ceiling protocol prevents dead- locks. Proof: First. by assumption. a job cannot deadlock with itself. Thus. a deadlock can only be formed by a cycle of jobs waiting for each other. Let the n jobs involved in the blocking cycle be {Jl,--~,J,,}. Note that each of these 72 jobs must be in one of its critical sections. since a job that does not hold a lock on any semaphore cannot contribute to the deadlock. By Lemma 9, the number of jobs in the blocking cycle can only be two, i.e.. n = 2. Suppose that job Jg‘s critical section was preempted by job J.. which then enters its own critical section. By Lemma 8. job J 3 can never inherit a priority which is higher than or equal to that ofjob J. before job J 1 completes. However. if a blocking cycle (deadlock) is formed. then by the transitivity of priority inheritance. job J: will inherit the priority of job Jr. This contradicts Lemma 8 and hence the theorem follows. Remark: Lemma 1 is true under the priority ceiling pro- tocol. Remark: Suppose that the run-time system supports the llSZ priority ceiling protocol. Theorem 10 leads to the useful re- sult that programmers can write arbitrary sequences of prop- erly nested semaphore accesses. As long as each job does not deadlock with itself, there will be no deadlock in the system. Lemma 1]: Let JL be ajob with a lower priority than that of job J, Job J, can be blocked by job J1, for at most the duration of one critical section in 6:1; Proof: First, job J, will preempt JL if J1, is not in a critical section 21”," 6 (3,1,, Suppose that job J; is blocked by :L.,.,. By Theorem 10, there is no deadlock and hence job JL will exit 1L," at some instant I] Once Job J]. leaves this critical section at time I..job J,_ can no longer block job J,- This is because job J, has been initiated and J,_ is not within a critical section in BM. It follows from Lemma 1 that job J,_ can no longer block job J,. Theorem I2: A Job J can be blocked for at most the du— ration of at most one element of 8,-‘. Proof: Suppose that job J can be blocked by n > I ele- ments of B,- By Lemma ll. the only possibility is that job J is blocked by n dillercnt lower priority jobs. Suppose that the first two lower priority jobs that block job J are .11 and J; By Lemma l. in order for both these jobs to block job J. both of them must be in a longest blocking critical section when job J is initiated. Let the lowest priority job J: enter its blocking critical section first. and let the highest priority ceiling of all the semaphores locked by J: be p]. Under the priority ceiling protocol. in order for job J1 to enter its critical section when J: is already inside one. the priority ofjob J; must be higher than priority ceiling pg. Since we assume that job J can be blocked by job J3. by Lemma 7 the priority ofjob J cannot be higher than priority ceiling p3. Since the priority ofjob J] is higher than {)3 and the priority ofjob J is no higher than p:. job J.‘s priority must be higher than the priority of job J. This contradicts the assumption that the priority of job J is higher than that of both J. and J3. Thus. it is impossible for job J to have priority higher than both jobs J1 and J; and to be blocked by both of them under the priority ceiling protocol. The theorem follows immediately. Remark: We may want to generalize the definition of a job by allowing it to suspend during its execution, for instance, to wait for I/O services to complete. The following corollary presents the upper bound on the blocking duration of a gen- eralized job that might suspend and later resume during its execution. Corollary 13: If a generalized job J suspends itself n times during its execution. it can be blocked by at mom I! + 1 not necessarily distinct elements of B}. V. SCHEDULABILITY ANALYSIS Having proved the properties of the priority ceiling proto- col. we now proceed to investigate the effect of blocking on the sehedulability of a task set. In this section, we develop a set of sufficient conditions under which a set of periodic tasks using the priority ceiling protocol can be scheduled by the rate—monotonic algorithm, which assigns higher priorities to tasks with shorter periods and is an optimal static priority algorithm when tasks are independent [8]. To this end. we will use a simplified scheduling model. First. we assume that lElZF. TRANSACTlONS ON COMPUTERS. VOL. 3‘). NO. 9. SEPTEMBER 1990 all the tasks are periodic. Second. we assume that each job in a periodic task has deterministic execution times for both its critical and noncritical sections and that it does not syn- chronize with external events, i.e.. a job will execute to its completion when it is the only job in the system. Finally, we assume that these periodic tasks are assigned priorities accord— ing to the rate~monotonic algorithm. Readers who are inter- ested in more general scheduling issues. such as the reduction of aperiodic response times and the effect of task stochastic execution times. are referred to [41 and ill]. We quote the following theorem also due to Liu and Lay— land which was proved under the assumption of independent tasks. i.e., when there is no blocking due to data sharing and synchronization. Theorem 14: A set of n periodic tasks scheduled by the rate-monotonic algorithm can always meet their deadlines if 9 + + 9 _ Tl Tn _ where C,- and T; are the execution time and period of task 1,, respectively. V Theorem 14 ofl'ers a sullieicnt (worst case) condition that characterizes the rate-monotonic schedulability ofa given peri- odic task set. The following exact characterization was proved by Lchoczky. Sha. and Ding [5]. An example of the use of this theorem will be given later in this section. Theorem 15: A set of n periodic tasks scheduled by the rate-monotonic algorithm will meet all their deadlines for all task phasings if and only if W. l 3i 5n, (LIch I lek T] I T [Ti = U-—’ — I Mix/jigs J/TL iTji T where C]. Ty. and U, are the execution time. period. and utilization of task TJ‘, respectively, and R,- ={(k, I)|l g k g i, I: [Ti/TU}. When tasks are independent of one another. Theorems l4 and 15 provide us with the conditions under which a set of n periodic tasks can be scheduled by the rate-monotonic algorithm.6 Although these two theorems have taken into ac- count the etfect of a task being preempted by higher prior- ity tasks, they have not considered the efiect of a job. being blocked by lower priority jobs. We now consider the effect of blocking. Each element in 3; is a critical section accessed by a lower priority job and guarded by a semaphore whose priority ceiling is higher than or equal to the priority of job J {. Hence, 6;” can be derived from 6;. By Lemma 7 and Theorem 12, job J ,- of a task 1- can be blocked for at most the duration of a single element in 8;. Hence, the worst case blocking time for J is at most the duration of the longest element of B“. We denote this worst case blocking time of a job in task 1.» by 8,. Note that given a set of n periodic tasks. 8,, = 0. since there is no lower priority task to block 1,,. "That is, the conditions under which all the Jobs of all the n tasks will meet their deadlines. SH-\ ('1 ul. PRIORITY INHERITANCE PROTOCOLS Theorems 14 and 15 can be generalized in a straightforward fashion. In order tO test the schedulability of -r,-, we need to consider both the preemptions caused by higher priority tasks and blocking from lower priority tasks along with its own utilization. The blocking of any job of 7,- can be in the form of direct blocking, push-through blocking, or ceiling blocking but does not exceed 8,. Thus, Theorem 14 becomes Theorem 16: A set of n periodic tasks using the prior- ity ceiling protocol can be scheduled by the rate-monotonic algorithm if the following conditions are satisfied: C, C: C,- B, . 1,,- __v, __< 2r_1, Tl Tg—r TT,’ T,‘_l( ) Proof: Suppose that for each task 1, the equation is sat- isfied. It follows that the equation of Theorem 14 will also be satisfied with n = i and C, replaced by C,’ : (C, + 8,). That is. in the absence of blocking. any job of task T,‘ will still meet its deadline even if it executes for (C,- + 13,-) units of time. It follows that task 7,. if it executes for only C, units of time. can be delayed by 8, units of time and still meet its deadline. Hence. the theorem follows, Remark: The first itcrms in the above inequality constitute the effect of preemptions from all higher priority tasks and r,‘s own execution time, while [3, of the last term represents the worst case blocking time due to all lower priority tasks for any job of task 7,. To illustrate the efTect of blocking in Theorem 16. suppose that we have three harmonic tasks: T]:(C1=1,Tlr‘f T3 =(C: = LT: =-’ 4), 73 =(C3 7: 2. T3 :- 8). In addition, 8, = B; = 1. Since these tasks are harmonic, the utilization bound becomes 100%. Thus, we have “C,/T, + Bl/T. = l” for task 7, Next, we have “CI/T. +C: /T3 + Bg/Tg = l" for task T2. Finally. we have “Cl/Tl +Cg/T3 + C3/T; = l“ for task 73. Since all three equations hold. these three tasks can meet all their deadlines. Corollary 17: A set of n periodic tasks using the prior- ity ceiling protocol can be scheduled by the rate-monotonic algorithm if the following condition is satisfied: Cl +--~+Ci +max -- B'T') gn(2‘/" —-1). T—l Tn Tl,- 'Tn—l Proof: Since n(2‘/" — 1) g [(2'” —— l) and max(B,/T,, v - »,B,,_,/T,,_,) 2 B,/T,-, if this equation holds then all the equations in Theorem 16 also hold. Similar to the sufficient condition in Theorem 16. the con— ditions in Theorem 15 can be easily generalized. Specifically, Theorem 18: A set of n periodic tasks using the prior- ity ceiling protocol can be scheduled by the rate-monotonic algorithm for all task phasings if Ti, 1 <i<n, 1‘- I (kn/)ERI T- 1T, C,- B,- Ti J — — —— < [Tk +17, + m. - 1 j—l where C,. T,, and U,- are defined in Theorem 15. and B,- is the worst case blocking time for 7,. PFOOf.‘ The proof is identical to that of Theorem 16. 1183 Remark: The blocking duration B,- represents the worst case conditions and hence the necessary and sufficient condi- tions of Theorem 15 become sufficient conditions in Theorem 18. The following example helps clarify the use of Theorem 18. Consider the case of three periodic tasks. I Task 71’ C] =40;Tl = 3] =20; U] . Task 1'3th :40; T2 = 150; B; = 30; U2 2 0.267 . Task 73. C3 = 100; T3 =2 350; 83 2 0, U3 : 0.286. Task 7, can be blocked by task 73 for at most 20 units, while 73 can be blocked by task 73 for at most 30 time units. The lowest priority task. 1'3, cannot be blocked by any lower priority tasks. The total utilization of the task set ignoring blocking is 0.952. far too large tO apply the conditions of Theorem 16. Theorem 18 is checked as follows: 1) Task 7,: Check C1 +8; 3 100. Since 40 +20 5100. task 71 is sehedulable. 2) Task 73: Check whether either C,+C2+833100 80+30>100 or 2C1+C2+825150 120+303150. Task 72 is sehedulable and in the worst case phasing will meet its deadline exactly at time 150. 3) Task 13: Check whether either C1+C2+C33l00 40+40+l00>100 or ZC,+C2+C35150 80+40+100>150 or2Ci+2C2+C3£2OO 80+80+100>200 or3C|+2C2+C333OO l20+80+100=300 or 4cl +302 +C3 g 350 160 + 120+ 100 > 350. Task 73 is also sehedulable and in the worst case phasing will meet its deadline exactly at time 300. VI. APPLICATIONS OF THE PROTOCOL AND FUTURE WORK In this section, we briefly discuss the implementation as- pects of the protocol as well as the possible extensions of this work. A. Implementation Considerations The implementation of the basic priority inheritance pro- tocol is rather straightforward. It requires a priority queue- ing of jobs blocked on a semaphore and indivisible system calls Lock_Semaphore and Release_Semaphore. These sys— tem calls perform the priority inheritance Operation, in addi— tion to the traditional Operations of locking, unlocking, and semaphore queue maintenance. The implementation of the priority ceiling protocol entails further changes. The most notable change is that we no longer 1184 maintain semaphore queues. The traditional ready queue is replaced by a single job queue J0b_Q. The job queue is a priority-ordered list of jobs ready to run or blocked by the ceiling protocol. The job at the head of the queue is assumed to be currently running. We need only a single prioritized Job queue because under the priority ceiling protocol. the job with the highest (inherited) priority is always eligible to ex- ecute. Finally, the run-time system also maintains S_List. a list of currently locked semaphores ordered according to their priority ceilings. Each semaphore S stores the information of the job. if any. that holds the lock on S and the ceiling of S. Indivisible system calls Lock-Scnmp/iore and Release: Semaphore maintain J0b_Q and S_List. An example of the implementation can be seen in [13]. The function Lock_Semup/zore could also easily detect a self-deadlock where a job blocks on itself. Since the run-time system associates with each semaphore the Job. if any. that holds the lock on it. a direct comparison of a job requesting a lock and the job that holds the lock determines whether a self- dcadlock has occurred. 11' such a self-deadlock does occur. typically dtie to programmer error. the job could be aborlctl and an error message delivered. Suppose monitors are used for achieving mutual exclusion. We again assume that a job does not suspend tiiilil its comple- tion when it executes alone on the processor. We also assume that the job does not deadlock with itself by making nested monitor calls. A job inside a monitor inherits the priority of any higher priority job waiting on the monitor. To apply the priority ceiling protocol. each monitor is assigned a priority ceiling. and a job J can enter a monitor only if its priority is higher than the highest priority ceiling of all monitors that have been entered by other jobs. Since the priority ceiling protocol prevents deadlocks. nested monitor calls will not be deadlocked, The implications of priority ceiling protocol to Ada tasking are more complicated and are beyond the scope of this paper. Readers who are interested in this subject are referred to [I]. B. Future Work The priority ceiling protocol is an effective real-time syn- chronization protocol for it prevents deadlock, reduces the blocking to at most one critical section. and is simple to im- plement. Nonetheless. it is still a suboptimal protocol in that it can cause blocking to a job that can be avoided by en- hancements to the protocol. Although a formal treatment of possible enhancements is beyond the scope of this paper. we would like to present the ideas of some possible enhancements to stimulate more research on this subject. For example. we can define the priority floor of a semaphore. analogous to its priority ceiling. as the priority of the lowest priority job that may access it. Then. a job J can lock 3 semaphore S if its priority is higher than the pri— ority ceiling of S or if the following conditions are true. The lock on S can also be granted if the priority of J is equal to the priority ceiling of S and the priority floor of S is greater than the highest priority preempted job. This latter condition. called the priorityfloor condition. ensures that neither a pre- cml‘md job nor a higher priority job accesses S. This guaran— lEEF. TRANSACTIONS ON COMPUTERS. VOL. 39. NO 9. SEPTEMBER 1990 tees that deadlocks and chaining will be avoided. This protocol is called the priority limit protocol. The priority limit proto— col eliminates the ceiling blocking that J() encounters at time 15 in Example 4. Moreover. this protocol requires identical information as does the priority ceiling protocol and can be implemented with equal case. However. the priority limit pro- tocol does not improve the worst case behavior and hence the schedulability. It is also possible to enhance the priority limit protocol by replacing the priority floor condition by the following condi- tion. A job J can also be allowed to lock a semaphore S if the priority of J is equal to the priority of S and no preempted lower priority job accesses the semaphore S. This condition also guarantees avoidance of deadlock and chaining. This pro— tocol is called the job conflict protocol and is better than the priority ceiling and priority limit protocols.7 The job conflict protocol is. however. still a suboptimal protocol. It will be an interesting exercise to develop an optimal priority inheritance protocol. and then compare it to the priority ceiling protocol for both perl'oriiiance and implementation complexity. Vll. CoNt‘i.tisioN The scheduling ol'jobs with hard deadlines is an important area of research in real-tune computer systems. In this pa- per. we have investigated the synchronization problem in the context of priority—driven preemptive scheduling. We showed that a direct application of commonly used synchronization primitives may lead to uncontrolled priority inversion. a situ- ation in which a high priority job is indirectly preempted by lower priority jobs for an indefinite period of time. To reni- cdy this problem. we investigated two protocols belonging to the class of priority inheritance protocols. called the basic priority inheritance protocol and the priority ceiling pro— tocol in the context of a uniprocessor. We showed that both protocols solve the uncontrolled priority inversion problem. In particular. the priority ceiling protocol prevents deadlocks and reduces the blocking to at most one critical section. We also derived a set of sufficient conditions under which a set of periodic tasks using this protocol is schedulable by the rate-monotonic algorithm. Finally, we outlined implementa- tion considerations for and possible extensions to this proto- col. ACKNOWLEDGMENT The authors wish to thank D. Cornhill for his contributions on the priority inversion problems in Ada, J. Goodenough for his many insightful and detailed comments on this paper that helped us to clarify some of the key issues, and K. Ramam- ritham for his suggestions on the possible enhancements of this protocol. We would also like to thank H. Tokuda. T. Ess, J. Liu. and A. Stoyenko for their helpful comments. Finally. we want to thank the referees for their many fine suggestions. REFERENCES [l] J. B. Goodcnough and L. Sha. "The priority ceiling protocol: A method for minimizing the blocking of high priority Ada tasks." in Proc. 2nd ACM Int. Workshop Real-Time Ada Issues. 1°88. [2] B. W. Lampson and D. D. Redell. "Experiences with processes and monitors in Mesa." C‘omnmn. ACM. vol 23. no. 2. pp. 105-117. Feb. 1°80. 7 This enhancement was suggested by Kritlii Raiiiaiiirithani. 7.1. SHA er al.. PRIORITY INHERITANCE PROTOCOLS [H H1 11 J. P. Lehoczky and L. Sha. “Performance of real—time bus scheduling algorithms." ACM Perform. Eval. Rev.. Special Issue. vol. 14. no. 1. May 1986. J. P Lehoczky. L. Sha. and J. Strosnider. “Enhancing aperiodic re- sponsiveness in a hard real-time environment." in Proc. IEEE Real- Time Sysr. S_wnp.. 1987 J P. Lchoczky. L. Sha. and Y Ding, “The rate monotonic schedul- ing algorithm—Exact characterization and average case behavior." in Proc IEEE Real-Time Syst. Syrup. 1989. D. W. Lcinbaugh, "Guaranteed response time in a hard real-time en- vironment." IEEE Trans. Software Eng.. Jan. 1980. J. Y Leung and M. 1,. Merrill. "A note on preemptive scheduling of periodic. real time tasks." Inform. Processing Lark, vol. 11. no. 3. pp. 115-118. Nov. 1980. C. L. Liu and J. W Layland. “Scheduling algorithms for multipro- gramming in a hard real time envtronment.” J. ACM. vol, 31). no. 1. pp 46-61. 1973. A K. Mok. "Fundamental design problems ofdistrihuted systems for the hard real ttmc envrronment." PhD. dissertation, M.1.T.. 1983 K. Ramamritliam and J. A Stankovic. “Dynamic task scheduling in hard real-time distributed systems," IEEE Software. July 191-14. L. Sha. J. 1’. Lelioc/.ky. and R. Rajkumar. “Solutions for sortie prac- tical problems tn prioritized preemptive scheduling." in Prof. IEEE RmLT/me Sl’fi'l. Strut/1.. 1986 l. Slta. R. Riljhtllllilr. and'J. 1’ [choc/Ry, "Task scheduling itt distributed real—time systems." in I’rot'. IIL'ISIL' IIH/ll.\'lfl(l/ Matron (turf. l9ll7. —. ‘l’riority inheritance protocols: An approach to real time syn- chronization." Tech. Rep. Dcp, ('otttput 5L1, ('MU, 19117 W /.lt:to. K. Rtttliamrtthattt. and J. A. Sttttikovic. "Scheduling tasks with resource requirements “1 hard real-time systems." Ilflfiz' 72mm: Software fine, Apr was. —, "Preemptive scheduling under time and resource constraints." [El-IE Tram. (buyout, Aug. 19157. 1,113 Shit [5‘76- M‘l'l-il received the “5.15.5. (Hons) degree front Mcthl University. Montreal. 1’.Q.. Canada in 1978 and the M.S.l"..li and l‘h.1). degrees front Carnegie-Mellon University (CMU). Pittsburgh. PA. in 1979 and 19XS. He was an engineer in the (‘M U Department of Computer Science from 1979 to 198-1 and was a member of the Research Faculty in CMU CS depart- ment from 1985 to 191117. Stnce 1988 he has been a membcr of the Technical Stalls in the CMU‘s Soft- ware Engineering lnstitutc. a member of Research Faculty in the CMU CS department. and a senior member of the Advanced Real-Time Technology (ART) project at CMU CS dcpanmcnt. He is inter- 1185 ested in developing analytical solutions for the problems in the construction of distributed rea1~time systems. Dr. Sha is a member of the IEEE Competer Society. Ragunalhan Rajkumar (M‘90) received the 13.12. (Hons ) degree from the P.S.G. College of Tech- nology. Coimbatore, 1ndia. and the MS. and PhD. degrees from Carnegie Mellon University in 1986 and 1989. respectively. He has been a Research Staff Member at the IBM Thomas J. Watson Research Center. Yorktown Heights. NY. since 1989. His interests lie in the area of real-time systems. Dr. Rajkumar is a member ofthe IEEE Computer Society and the Association for Computing Machin- ery. John 1'. Lehoczky (M'XX) received the BA. de- gree in mathematics front Oberlin College. Oberlin. ()11. in 1965, and the M.S. and PhD. degrees in statistics from Stanford University. Stanford. CA. in 1967 and 1969. respectively. He was an Assistant Professor of Statistics at Carnegie Mellon University. Pittsburgh. PA. from 1969 to 1973. Associate Professor from 1973 to 1981. and Professor from 1981 to the present. He has served as Head of the Department of Statistics since 19114. His research interests involve applied probability theory with emphasis on models in the area of computer and com- munication systems. In addition. he is a senior member ofthc Advanced Real- Time Technology (ART) Project in the Carnegie Mellon University Computer Science Department and is doing research in distributed real-time systems. Dr. Lchoezky is a member of Phi Beta Kappa. a fellow of the Institute of Mathematical Statistics. and the American Statistical Association. He is a member of the Operations Research Society of America and the Institute of Management Science. He served as area editor of Management Science from 1981 to 1986. ...
View Full Document

Page1 / 11

PriorityInversion - IEEF TRANSACTIONS ON COMPUTERS, VOL....

This preview shows document pages 1 - 11. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online