Priority Ceiling Protocol

In Chapter 4, I mentioned that tasks have a static priority defined at compile time that cannot be changed. One exception to this rule is the priority ceiling protocol. When a task locks a resource, it assumes the priority of the resource while that resource is locked. The functioning of the priority ceiling protocol is as follows.

1. A resource is defined in the OIL configuration file. This resource is then defined for a set of tasks in the application.

2. When the system is generated using this configuration file, the ceiling priority for the resource is set.

(a) The ceiling priority will be greater than or equal to the highest priority of all the tasks that access this resource.

(b) The ceiling priority will be less than the lowest priority of all tasks that do not access the resource and have a priority greater than the highest priority found in item (a) above.

3. When the task locks a resource, its priority is temporarily set to the ceiling priority of the resource.

4. When the task releases the resource, its priority is returned to the statically defined prior-ity for the task.

With a priority ceiling protocol, priority inversion is eliminated because only one task is capable of locking a resource. In OSEK/VDX, it is not possible for a task to enter a WAITING state because of a resource locked by another task when it requests that resource. In the pre-vious example, the priority of task A is set to the ceiling priority of the resource when it locks the resource. The ceiling priority will be at least 3 — the priority of task C. Consequently, tasks B or C will never preempt task A, and priority inversion cannot occur. The revised sequence of events is shown in Figure 7.3.

The sequence of events in this figure is as follows.

1. Task A locks resource R and has its priority raised to the ceiling priority of the resource.

2. Task C is activated. Because of the priority ceiling protocol, this task remains in the READY state.

3. Task B is activated. Again, because of the priority ceiling protocol, this task remains in the READY state.

4. Task A releases resource R and has its priority reverted to the static priority. Task C enters theRUNNING state.

5. Task C terminates and task B enters the RUNNING state.

6. Task B terminates and task A resumes running.

7. Task A terminates.

Priority Ceiling Protocol

85 Figure 7.3 Priority ceiling and priority inversion.

As illustrated in Figure 7.3, the priority ceiling protocol allows tasks to be scheduled as expected. Because task C is activated before task B, it is proper for task B to remain in the READY state and not preempt task A. However, if task B is activated before task C but after task A locks the resource, it would be expected that task B preempts task A. With the priority ceiling protocol active, this preemption would not occur. This is one drawback of the priority ceiling protocol, where a lower priority task can inhibit a higher priority task that is lower than the ceiling priority. However, the time that a resource is locked should be minimized by good application design. When a task releases a resource, the scheduler runs immediately and the preemption will occur at that point. Because the time that a resource is locked can be cal-culated for all tasks, the maximum latency until preemption occurs can be addressed. This drawback of the priority ceiling protocol is less severe than the effect of priority inversion or deadlock and can be addressed in the application design.

Deadlock is eliminated in much the same way. Task A is set to the ceiling priority of resource R1 when it locks this resource. Again, the ceiling priority will be at least 3, the prior-ity of task C. Task C will never preempt task A and will not lock resource R2. Task A can lock resource R2 successfully because task C is not allowed to preempt task A. The priority of Task A may be raised if the ceiling priority of R2 is greater than R1. The revised sequence of events from the previous example of deadlock is shown in Figure 7.4.

The sequence of events in Figure 7.4 is as follows.

1. Task A locks resource R1 and has its priority raised to the ceiling priority of the resource.

2. Task C is activated. Because of the priority ceiling protocol, this task remains in the READY state.

3. Task A locks resource R2 and has its priority set to the maximum ceiling priority of R1 and R2.

86

Figure 7.4 Priority ceiling and deadlock.

4. Task A releases resource R2 and has its priority set to the ceiling priority of R1.

5. Task A releases resource R1 and has its priority reset to the statically defined priority of the task. At this point, scheduling occurs and task C preempts and begins running.

6. Task C terminates and task A resumes running.

7. Task A terminates.

Notice in steps 4 and 5 above that the resources were released in a last in, first out (LIFO) order. This is a requirement of the OSEK/VDX standard that must be followed by the appli-cation. In the extended status mode, a violation of the release order is identified by the OS.

The previous examples have focused on the required priority ceiling protocol for all tasks.

The OSEK/VDX standard allows the optional extension of the priority ceiling protocol to interrupt levels. Because interrupt handling is processor dependent, the standard leaves a description of how software priorities and hardware interrupt levels are handled to the imple-mentation. For example, one processor might be able to mask an interrupt in hardware, and another processor might be required to handle the interrupts in software. When a task is raised to an interrupt level priority, the implementation must mask all interrupts of lower pri-ority.

The extension of the priority ceiling protocol for interrupts is handled as follows.

1. The set of all possible priorities is divided into two sections: the lower section is reserved for tasks and the upper section is reserved for Interrupt Service Routines (ISR). The upper section of priorities is referred to as virtual priorities because they function differently from the normal task priorities.

2. Each ISR is assigned a virtual priority in the configuration file.

C

Managing Resources

87

3. The priority ceiling protocol, as seen from the application, appears to function exactly the same. However, because the ceiling priority for a resource could be a virtual priority, the effect to the implementation could be extensive. Interrupt masking is hidden from the application, but it will affect the time to lock resources and activate tasks.

As can be seen in these revised examples, the priority ceiling protocol effectively eliminates the problems of priority inversion and deadlock.