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