嵌入式实时操作系统中的优先级反转问题

电电侠   科科大大，我最近发现了并行编程世界中一个神奇的现象——优先级反转，我一直以为任务的执行顺序都是固定的。  

是啊。通常情况下，任务的优先级是根据其重要性和紧急性来设定的。但是，在并发系统或多任务环境中，确实存在一种被称为“优先级反转”的现象。

科科君   电电侠  

什么时候会遇到这种现象？

解决资源争用问题时。

科科君

死锁预防是实时系统设计中的一个重要因素。不幸的是,即使使用安全排除技术,这可能也不是困难的终点。在解决资源争用问题时,可能引入新的优先级翻转问题。

电电侠   能详细解释下优先级反转的原理吗？   优先级翻转的基本原理可以通过一个简单的两任务(A 和 B)系统的行为来解释。 科科君

假设任务A 正在使用一个锁定的资源,此时调度程序决定进行任务交换,新任务B希望使用 A 持有的资源。在检查访问机制时,发现资源不可用,因此任务 B 挂起。互斥机制按计划执行。但是如果 B的优先级高于 A 呢? 结果仍然相同,B仍然被阻塞。结果是低优先级的任务 A 阻塞了高优先级的任务B;在 A 释放锁定资源之前,B不能执行。系统的行为表现得好像优先级颠倒了一样,即优先级翻转。然而,这种行为正是使用互斥时所期望的,没什么异常。

电电侠   （若有所思）在双任务系统中,性能下降可能不是一个大问题。   但是看下图的情况。 科科君

这是一个四任务系统,由任务 A、B、C和 D(按照优先级顺序)组成。系统还包括两个共享资源 W 和 X。请注意,为了简化对系统行为的解释,做了以下假设。

(1)上下文切换(重新调度)仅在滴答(tick)时间发生。

(2)任务可以随时挂起。

(3)任务可以随时就绪。

一个运行时场景

上图示例的一个运行时场景,如下图所示。在t0时刻,任务 D正在执行,其他任务处于挂起状态。在下一个滴答中断(t1时刻)发生之前,D锁定资源W。

注意:所有其他任务都已就绪。

在t1时刻,任务A抢占D,任务D重新进入就绪(等待运行)状态。不久之后,A 试图使用资源W 但发现它被锁定,因此任务A 挂起。t2时刻,任务 B被激活,运行至完成,然后挂起。在t3时刻,任务C运行至完成并挂起。然后在t4时刻,D 再次执行。只有当任务 D释放资源锁时,A 才能执行(t5时刻)。

在此设计中,任务A被赋予最高优先级,因为它是一项重要的任务。然而由于互斥机制锁,任务A只能被迫等待所有其他任务完成后才能执行。

电电侠   显然这种表现是不能接受的, 如何才能防止“连锁”优先级翻转情况的发生?   这个问题可以通过两种方式解决,都涉及临时提升任务优先级。

科科君 01

运行任务的优先级可以提高到通过优先继承技术获取的确定值。

为共享资源分配优先级,然后将正在运行的任务的优先级提高到资源优先级值,这种方式称为优先级天花板技术。

审核编辑：黄飞