火星探路者号频繁重启：优先级反转的经典一课

很多人对 1997 年登陆火星的 NASA“火星探路者号”（Mars Pathfinder）及其“旅居者号”（Sojourner）巡视器并不陌生。最初一切正常，但几天之后，着陆器开始出现一连串整机复位：看门狗定时器检测到异常，不断强制系统重启。Vivek Bhageria 在最近的一篇文章中回顾了这次故障的来龙去脉，以及最终的处理办法。

根因：优先级反转

问题的本质是优先级反转：当低优先级任务占有着高优先级任务所需的资源时，高优先级任务就只能被挡住、无法执行。此次运行的是 VxWorks，但这类问题并不专属于某个操作系统——任何采用优先级调度的系统都可能遇到。

简化后的场景是这样的：有两个任务共用同一把互斥锁，以避免彼此踩踏。

• 优先级最高的任务负责数据分发；
• 优先级最低的任务负责气象数据处理；
• 此外还有一个中等优先级的任务，负责总线维护。

故障发生在这样的时序里：低优先级任务拿到了互斥锁，还没来得及释放就用完了自己的时间片；高优先级任务随即发现拿不到锁。按理说，此时低优先级任务应该继续运行并尽快释放锁，但它又被等待执行的中优先级任务抢占了。

结果就是：高优先级任务在等一个资源，而这个资源要等最低优先级的任务重新获得 CPU 才可能被释放。这就是优先级反转。

测试时曾经出现过

令人遗憾的是，工程师在测试阶段其实偶尔见过这一现象，但和人们常做的那样，把它当成了偶发的“小毛病”忽略过去。文中的那句老话很值得记住：

如果你不知道它为什么会发生，那你就不能确定它不会再发生。

VxWorks 本身预料到了这种局面，而且航天器的资源也允许针对那把出问题的互斥锁打开优先级继承：当有更高优先级的任务在等待时，持有锁的低优先级任务会临时获得优先级提升，从而尽快执行完并释放资源。于是，工程师在数亿公里之外修改了这一设置，重启循环随之停止。

这类故障后来成了实时系统教学中的经典案例：一个看似只是“调度细节”的机制，足以让整台航天器陷入反复重启。原文还给出了更多细节，Hackaday 也在十年前做过自己的分析。