VxWorks互斥量优先级反转三部曲

最近发现VxWorks互斥量优先级反转的设计非常微妙，甚至有时觉得就像大富翁里面“请神容易，送神难”的衰神一样。为了让各位看官不重蹈我之覆辙，特书此文。

首先，让我们回顾一下何谓优先级定义反转。优先级反转的应用场景就是高优先级任务阻塞在被低优先级任务占用的互斥量，而长时间得不到调度的问题。最著名的例子是“火星探路者”。优先级反转让低优先级任务的优先级暂时提升到被阻塞的高优先级任务的水平上，而让低优化级任务尽快执行完成而释放互斥量。

但是，暂时到底有多久？按照相对论，天上一日人间一年。科技总是让人匪夷所思，不是吗？

让我们从前传开始。话说在VxWorks江湖中，有三个任务A、B、C，优先级从高到低依次为A > B > C。

前传：

故事总是从偶然开始。话说一天小弟C在少得可怜的调度机会中机缘巧合获取了互斥量M，然后很自然的被老大A抢走了CPU。A玩得正high的时候，发现前面有一扇门，必须要用互斥量M才能打开。于是A很不情愿的排到了M的等待队列上，当发现只有他一个在队列里，不禁一喜，满以为很快就轮到他了。不过人生不如意十之八九。等到花开花落，雁字回时，还没轮到他。他不耐烦的向调度器吐槽：“你不是完全优先级调度吗？我堂堂高优先级任务却一直没有调度到！”

勤勤恳恳的调度器劝慰道：“稍安勿躁，待我细细查来。”边说边翻阅着厚厚的调度记录，然后说：“我倒是很想调度你来着，只可惜落花有意流水无心。你不是一直在等M吗？你的小弟C占用了M，只怪C的优先级太低，江湖上吃不开。这段时间，山中无老虎，猴子称霸王。B玩疯了。”

“这绝对不行！”A争辩道：“你必须给我解决。”

“我也是按例行事的小卒一枚，容我把情况向上反映。N个工作日后答复你。”调度器也一脸无奈。

䃼丁１：

２N天后，江湖上出现了一则公告。亮闪闪的互斥量优先级继承规则横空出世。A细读后喜上眉梢。原来A阻塞在己被C占用的M后，C瞬间从屌丝升级成高富帅，C的优先级提升为A的优先级，C狐假虎威一番，快速搞定事情后，释放M。然后A就可以占用M而进入他的showtime。而A要做的仅仅是在创建M时配置优先级反转安全。

今生：

没过多久，A发现事有蹊跷。江湖传闻出现了一个跟他相同优先级的隐身侠，常借他之名，行不义之事。原来A只看到了故事的开头，却没猜到结尾。C不仅发现A请求已被他占用的M后，他的优先级自动提升到A的优先级，而且只要此后手握一个不相干的配置优先级反转安全的互斥量N，就算释然M给A，就算没有其他任务请求N，他的优先级仍然保持在A的水平上。直到他释放完占用的所有优先级反转安全的互斥量，他的优先级才会复原。看到VxWorks的世界是真是扁平得紧！

得知真相后，A气不打一处出。这不是修改引入吗？他把调度器数落了一通。调度器依然耐心的听完，然后依然不置可否的抛出N日后再答复。

补丁2：

又过了N+2天，江湖又出了一则公告。这次轮到C傻眼了。原来优先级还原的条件更精确了。只要把优先级提升的互斥量们都释放了，优先级就还原。狐假虎威的好日子到头了。等一等，互斥量们！C似乎看到了一线曙光。经过几次实验，C发现只要他先占用N后，再忽悠B请求N，这时他同时占有A请求的M和B请求的N，而他的优先级提升了更高的A优先级。当他释放M后，由于还手握N，优先级依然保持在A的水平。方法是有了，不过忽悠B也不容易。

来世：

传说在遥远的乌托邦，每当释放导致优先级提升的互斥量时，优先级会根据当前占有的互斥量情况，重新计算。当C释放了A请求的互斥量时，C的优先级不再是A的了。人人各安其位，井然有序。

好了，让我们面对现实吧。现实意味着在各种矛盾中找到微妙而脆弱的平衡。在设计和编码中我们经常陷入两难的境地。所以我理解VxWorks在方案的完备与实现的简单高效之间做出的选择。再说出现三个任务间的纠葛，本来就是一种设计的臭味。在局部细节上解决不了的问题，通常提升到更高的层次就会拨云见日般的发现问题的症结所在，解决之道也呼之欲出。

䃼丁３：

重新审视互斥设计，避免出现同时申请多个互斥量的场景。