PRIORITY INHERITANCE
PROTOCOLS
Will 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
Previous
Example:
Example with
Priority
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 higherpriority 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.