PRIORITY INHERITANCE PROTOCOLSWill Hedgecock

EECE 354

10/13/2010

Sha, L. et al. “Priority Inheritance Protocols: An Approach to Real-Time Synchronization.” IEEE Transactions on Computers, Vol. 39, No. 9, Sept 1990.

Background• A common scheduling problem in the context of real-time

systems is the effect of blocking caused by the need for synchronization of jobs that share resources

• Most real-time systems operate preemptively• Paper approaches scheduling from this perspective

• Many safety/timing-critical programming languages support preemptive scheduling• Includes Ada – primary language used by the US Dept. of Defense

• Preemption, mixed with blocking due to resource sharing, can cause several problems• Deadlock• Inability to meet critical timing deadlines• Priority Inversion Problem

Priority Inversion Problem• A high priority task can become blocked by a lower priority

task indefinitely• If lower priority task locks access to resources shared by both

tasks

• Since higher priority tasks are usually more important and have stricter deadlines, this can lead to system instability and further scheduling problems

Priority Inversion Definition• High-priority job J should be able to preempt a lower

priority job immediately upon J's initiation• Inversion occurs especially where access to shared resources

must be serialized

• If a low priority job gains access right before J is initiated, J must wait until the low priority job releases the resource before running• Can lead to missed deadlines even at low resource utilization

levels

• The term "schedulability" refers to the level of resource utilization attainable before a deadline is missed

• Less blocking makes a system more schedulable

Definitions and Assumptions• Job: any sequence of instructions which continues until

completion if executing alone on a processor• At the end of such execution, all locks held by the job must have been

released

• Periodic Task: a sequence of the same type of job occurring at regular intervals

• Aperiodic Task: a sequence of the same type of job occurring at irregular intervals

• "Blocked" means a higher priority task must wait for a lower priority task before executing• The reverse is not considered blocking

• Assume critical sections may be properly nested• Assume a semaphore may only be locked once in a single

nested critical section

Basic Priority Inheritance Protocol

Basic Priority Inheritance Protocol• Whenever a low-priority job blocks one or more higher-

priority jobs, it ignores its original priority distinction and executes at the level of the highest priority job it is blocking

PreviousExample:

Example withPriority Inheritance:

Basic Priority Inheritance Protocol

• Priority inheritance is transitive• If J2 blocks J1 and J3 blocks J2, then J3 inherits the priority of J1

• 2 Types of blocking:• Direct: A higher priority job

needs to access a semaphore that is locked

• Push-Through: A lower priority job has inherited the priority of a high-priority job; thus, when a medium priority job is ready to execute, it must wait for the low priority job to finish

Basic Priority Inheritance Properties• A high-priority job can only be blocked if a low-priority job is already in

its critical section when the high-priority job became ready• A high-priority job can only be blocked by one lower-priority task for at

most the duration of one critical section, regardless of the number of shared semaphores between the two jobs• This is only true if deadlock prevention measures are taken

• A high-priority job can be blocked by n lower-priority jobs for at most the duration of EACH of the n jobs' critical sections

• A semaphore S can only cause push-through blocking on a job if there are both lower-priority and equal or higher priority jobs that require access to S

• A job can only be blocked by at most one critical section for each semaphore it requires access to • i.e. if it requires 2 semaphores, it could be blocked by at most 2 critical sections

• The maximum possible amount of time blocked corresponds to the sum of the longest critical sections which are accessed via the shared semaphores

Basic Priority Inheritance Downfalls

• Does not prevent deadlocks• See example

• Blocking chains can be formed, meaning a high-priority job could be blocked for the duration of all the critical sections of lower-priority tasks which are active and rely on the same semaphores

• These two downfalls are addressed in the Priority Ceiling Protocol

Priority Ceiling Protocol

Priority Ceiling Protocol

• Underlying idea: When a job J preempts another job's critical section, it will only enter into its own critical section if the priority at which the job is running is guaranteed to be higher than the highest possible priorities of all preempted jobs/critical sections

• Method: Every semaphore is assigned a priority ceiling equal to the priority of the highest priority task that uses the semaphore

• A job J can only enter a critical section if J's priority is higher than the priority ceilings of all semaphores locked by jobs other than J

Priority Ceiling Protocol

Priority Ceiling Definition• When a job J wants to lock a semaphore and enter its critical section, it

can only do so if its current priority is higher than the priority ceiling of all other locked semaphores

• Job J continues to execute at its assigned priority until it is preempted and ends up blocking higher priority jobs• At this time, it will inherit the priority of the highest-priority job it is blocking

• When job J exits its critical section, it resumes executing at its assigned priority

• The task of inheriting a priority and resuming the original priority are atomic indivisible actions

• Any higher priority job can preempt any lower priority job and execute, as long as it is not attempting to enter a critical section

• This protocol introduces a new type of blocking called "ceiling blocking"• When a higher priority task is blocked because it is not higher than the priority

ceiling of a locked semaphore

Priority Ceiling Example

Priority Ceiling Advantages• In the basic priority inheritance protocol, a job could be blocked

by as many critical sections/semaphores as were present in lower interacting jobs• In this protocol, a job can only be blocked for at most the duration of one

longest possible critical section of a lower priority job• This is true since one semaphore out of a set cannot be locked unless the

job is at a higher priority than anything else preempted

• Suppositions:• If a job J in its critical section is preempted by a job K which enters its

critical section, there is no way job J will ever inherit a priority higher than job K until job K completes

• This protocol prevents transitive blocking• This protocol prevents deadlocks (for the same reason as it

prevents transitive blocking)• Thus, programmers can write arbitrary sequences of properly nested

semaphore accesses without deadlocking

Schedulability Analysis• Makes several assumptions:

• Uses rate-monotonic algorithm• Tasks are all independent• All tasks are periodic• All execution times are known• No jobs rely on external events

• i.e. they all run to completion once started

Schedulability Analysis• Previous theorem guarantees schedulability based on

rate-monotonic preemption-based prioritizing• Does not take into account blocking by lower priority jobs

• Bi is the worst-case blocking time of a given task• Essentially makes C take into account preemption by all higher-

priority tasks, plus worst-case blocking time by a lower-priority task• If we can schedule under these conditions, we can obviously

schedule with no blocking

Schedulability Analysis

• Corollary to Theorem 17:

• Generalized Theorem:

Protocol Implementation Notes• We can replace a traditional "ready queue" with one simple job queue

ordered by priority• The currently running job is at the head of the list• Only single queue needed because under priority ceiling, the job with the highest

(inherited) priority is always eligible to execute

• An additional "semaphore queue" is required which lists currently locked semaphores according to their priority ceilings• LockSem() and ReleaseSem() maintain these two queues

• Possible to further optimize protocol so that unnecessary blocking does not occur• Use of priority floor which further helps identify when a task will not need to be

blocked• Using both floor and ceiling is called "priority limit" protocol and avoids some

unnecessary blocking, but does not increase schedulability

• Another option is the "job conflict protocol" which allows a job J to lock a semaphore if the priority of J is equal to the priority of S, and no preempted lower priority jobs access S

Reference• Sha, L. et al. “Priority Inheritance Protocols: An Approach

to Real-Time Synchronization.” IEEE Transactions on Computers, Vol. 39, No. 9, Sept 1990.