Focus on ACE

订阅 ace-china
电子邮件:
浏览存于 groups.google.com 上的所有帖子

C++博客 首页 新随笔 联系 聚合 管理
  64 Posts :: 3 Stories :: 22 Comments :: 0 Trackbacks

Priority Inversion 优先级反转是嵌入式实时系统里面的一个经典的问题。简单描述一下这个问题:有三个优先级不同的task,A,B,C; A的优先级最高,B次之,C最低。其中A和C有共享的临界区。如果C已进入临界区,那么A在进入进入临界区之前,就会被阻塞。task B有可能打断C而进入运行状态,这样C什么时候从临界区退出,就是一个未知的时间。A只有C从临界区退出后才能被调度,A被阻塞的时间也是未知的。这样,低优先级的B先于高优先级的A被调度,优先级发生了逆转。
这个问题在一般的操作系统里面不是一个严重的问题,最多A被多阻塞了一段时间。但是,在实时系统里面,如果一个任务在规定的时间里面没有被调度运行,系统就相当于失败了,可能引发系统崩溃。
解决这个问题有两种手段:
1:Priority inheritance(优先级继承),如果一个高优先级的task被阻塞,与它共享临界区的低优先级的task在进入临界区后,优先级就会继承高优先级task的优先级,保证它不会被其他优先级次高的任务打断。从临界区退出后,C的优先级恢复正常。
2:A priority ceiling(最高优先级),给临界区分配最高优先级,如果一个task进入临界区,就把临界区的优先级赋给它,已保证它不会被打断。从临界区退出后,task的优先级恢复正常。

实时操作系统的一个特点就是,一个实时任务,会在规定的时间内得到响应,并且在规定的时间内完成任务。所以,一切不可预知的动作都是有害的。

有兴趣可以看看下面两个链接:
http://en.wikipedia.org/wiki/Priority_inversion

 

Priority inversion

From Wikipedia, the free encyclopedia

Jump to: navigation, search

In scheduling, priority inversion is the scenario where a low priority task holds a shared resource that is required by a high priority task. This causes the execution of the high priority task to be blocked until the low priority task has released the resource, effectively "inverting" the relative priorities of the two tasks. If some other medium priority task, one that does not depend on the shared resource, attempts to run in the interim, it will take precedence over both the low priority task and the high priority task.

In some cases, priority inversion can occur without causing immediate harm—the delayed execution of the high priority task goes unnoticed, and eventually the low priority task releases the shared resource. However, there are also many situations in which priority inversion can cause serious problems. If the high priority task is left starved of the resources, it might lead to a system malfunction or the triggering of pre-defined corrective measures, such as a watch dog timer resetting the entire system. The trouble experienced by the Mars lander "Mars Pathfinder"[1][2] is a classic example of problems caused by priority inversion in realtime systems.

Priority inversion can also reduce the perceived performance of the system. Low priority tasks usually have a low priority because it is not important for them to finish promptly (for example, they might be a batch job or another non-interactive activity). Similarly, a high priority task has a high priority because it is more likely to be subject to strict time constraints—it may be providing data to an interactive user, or acting subject to realtime response guarantees. Because priority inversion results in the execution of the low priority task blocking the high priority task, it can lead to reduced system responsiveness, or even the violation of response time guarantees.

A similar problem called deadline interchange can occur within Earliest Deadline First Scheduling (EDF).

Contents

[hide]

[edit] Solutions

The existence of this problem has been known since the 1970s, but there is no fool-proof method to predict the situation. There are however many existing solutions, of which the most common ones are:

Disabling all interrupts to protect critical sections
When disabled interrupts are used to prevent priority inversion, there are only two priorities: preemptible, and interrupts disabled. With no third priority, inversion is impossible. Since there's only one piece of lock data (the interrupt-enable bit), misordering locking is impossible, and so deadlocks cannot occur. Since the critical regions always run to completion, hangs do not occur. Note that this only works if all interrupts are disabled. If only a particular hardware device's interrupt is disabled, priority inversion is reintroduced by the hardware's prioritization of interrupts. A simple variation, "single shared-flag locking" is used on some systems with multiple CPUs. This scheme provides a single flag in shared memory that is used by all CPUs to lock all inter-processor critical sections with a busy-wait. Interprocessor communications are expensive and slow on most multiple CPU systems. Therefore, most such systems are designed to minimize shared resources. As a result, this scheme actually works well on many practical systems. These methods are widely used in simple embedded systems, where they are prized for their reliability, simplicity and low resource use. These schemes also require clever programming to keep the critical sections very brief, under 100 microseconds in practical systems. Many software engineers consider them impractical in general-purpose computers.
Arguably, these methods are similar to priority ceilings.
A priority ceiling
With priority ceilings, the shared mutex process (that runs the operating system code) has a characteristic (high) priority of its own, which is assigned to the task locking the mutex. This works well, provided the other high priority task(s) that try to access the mutex does not have a priority higher than the ceiling priority.
Priority inheritance
Under the policy of priority inheritance, whenever a high priority task has to wait for some resource shared with an executing low priority task, the low priority task is assigned the priority of the highest waiting priority task for the duration of its own use of the shared resource, thus keeping medium priority tasks from pre-empting the (originally) low priority task, and thereby effectively the waiting high priority task as well.

[edit] See also

[edit] Notes

  1. ^ What Really Happened on Mars by Glenn Reeves of the JPL Pathfinder team
  2. ^ Explanation of priority inversion problem experienced by Mars Pathfinder

[edit] References

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Priority_inversion"

posted on 2009-09-15 17:15 Stone Jiang 阅读(1266) 评论(0)  编辑 收藏 引用

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理