嵌入式操作系统(二)

icewood

文章篇幅太长，这是原文的第二部分，译文将在第三部分贴出：
Priority inversion is the term for the scenario where a higher priority task fails to run when it should, but a lower priority task can run instead.

Figure 6 illustrates the priority inversion problem: Priority inversion can happen when a higher priority task (Task 3) has to wait on a resource which is occupied by a preempted low priority task (Task 1). A task with a priority between Task 1 and Task 3 (like Task 2) now has the chance to run in the meantime. By running this task, Task1 is prevented from releasing the resource which Task 3 is waiting on. The situation can only be resolved by a termination of Task2, but this means Task 2 runs before the higher priority task (priority inversion).
Figure 1-6: Occurrence of priority inversion

Semaphores can also result in deadlocks. Assume two tasks share two resources and lock them in different orders. One task (Task A) locks the first resource using semaphore S1. Then, in the ordinary course of events a second task (Task runs and locks the second resource with semaphore S2. It needs to use the first resource (S1), but cannot because it is locked by the first task (Task A). All it can do is pass control back to the first task (Task A), which then attempts to use the second resource (S2). It cannot use it because the second task (Task has locked it, so it passes control back to the second resource. But the second resource cannot run, so it passes control back to the first task, endlessly. The two tasks are deadlocked because each is waiting on a semaphore locked by the other task. Figure 7 illustrates this situation.
Figure 1-7: Two tasks reaching deadlock
Priority Ceiling Protocol
With the priority ceiling protocol, each resource gets its own ceiling priority. The ceiling priority of the resource is equivalent to the priority of the highest priority task that may use this resource. A task will get the resource’s ceiling priority during the access of that resource and get its old priority back after the access. All tasks below the ceiling priority cannot preempt other tasks, therefore all other tasks using the same resource cannot preempt. Preemption can only take place after the resource access is completed and the original task's priority is restored.

This method prevents preemption, which is the primary cause of possible resource conflicts. Therefore problems like priority inversion and deadlocks cannot happen. The main disadvantage however, is that all lower priority tasks get locked out, even when they are not using the resource.

OSEK/VDX OS uses this approach for resource management.
Highest Locker's Priority Protocol
This protocol is similar to the priority ceiling protocol except with the possibility that a task, not using the resource and with a lower priority than the priority of a particular resource, can preempt the tasks with original lower priority using that resource. To achieve this, the scheduler needs to consider two task priorities, the original priority and the resource priority of a task.
Summary
This section introduced you to some of the concepts involved with synchronizing access to shared resources. Some of these protocols are intricate with subtle side effects. The principal point to take away from this section is that an RTOS must control simultaneous access to shared resources, and that the mechanism used can have significant consequences with regard to how tasks are scheduled.



















本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4274/showart_30108.html