1. 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.

2. 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

3. 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

4. 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

5. 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

6. Basic Priority Inheritance Protocol

7. 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:

8. 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

9. 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

10. 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

11. Priority Ceiling Protocol

12. 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

13. Priority Ceiling Protocol

14. 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

15. Priority Ceiling Example

16. 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

17. 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

18. 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

19. Schedulability Analysis
Corollary to Theorem 17:
Generalized Theorem:

20. 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

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