火星探路者太空船上的软件到底怎么了？

Send_linux

　　
火星拓荒者（Mars Pathfinder）是一艘在1997年携带探测车登陆火星并建立基地的美国太空船。它包括命名为卡尔萨冈纪念站的登陆者，和一辆重量很轻 (10.6公斤/23磅)，命名为旅居者号的轮型机器人火星车。这艘太空船于火星全球探勘者号发射一个月之后的1996年12月4日由德爾它 II发射，并于1997年7月4日于火星上称为欧克西亚沼区的克里斯平原阿瑞斯谷着陆。

图1：旅居者号火星车
火星拓荒者号着陆后﹐开始把数据传送回地球。几天后，信息和图像传送就被一系列的总系统复位所中断。对于软件工程师来说，这个问题是被如何诊断和解决的，仍然是一个引人入胜的故事。【1】

诊断问题
拓荒者号的应用程序是由 VxWorks 实时操作系统（RTOS）来调度。由于VxWorks提供优先级抢占的线程调度，依据相对紧迫性，具有优先级线程的任务会被执行。
气象数据采集任务作为一个普通的、低优先级线程运行，并且使用互斥锁定（mutexes）来同步的信息总线。其它高优先级的线程在必要时会获得优先权，其中包括一个非常高优先级的总线管理任务，它也以互斥锁定来访问总线。不幸的是，在这种情形下，一个长期运行的、具有比气象任务更高、但是比总线管理任务更低优先级的通信任务，阻止了总线管理任务的运行。
不久，一个看门狗定时器注意到总线管理任务已经很长时间没有被执行了，一定是出了什么问题，所以强制总系统复位。（后来工程师们承认在飞行前测试时已经发现系统复位。他们把这些复位归类于硬件故障，而去专注于关键任务――登陆软件。）

寻求解决方案
工程师们疯狂的工作在实验室复制品上去诊断和解决这个问题，最终发现了优先级反转。当一个高优先级任务间接地被一个“反转”了相对优先级的中等优先级任务优先抢占时，则优先级反转发生（见图2）。这个显然违反了优先级模型――高优先级任务只能被更高优先级的任务阻止运行，或者被能迅速完成共享资源使用的低优先级任务短暂地阻止运行。

图2：优先级反转
为了解决这个问题，他们开启了一个布尔参数，来指示是否应该进行互斥锁定的优先级继承。 上述的互斥锁定已经把该参数关闭；如果打开它，优先级反转就能被阻止。
根据优先级继承，当高优先级任务请求信号（semaphore）时，持有信号的任务优先级继承高优先级任务的优先级。在图2中，当任务“high”请求信号时，任务“low”将继承任务“high”的优先级。这使得“low”能优先抢占“medium”。
造成问题（对其它两个也可能造成同样的问题）的互斥锁定的初始化参数存储在一个全局变量中，其地址放在发射软件的符号表里。因为VxWorks包含一个C语言解释器，允许开发人员输入和执行C表达式和函数来进行系统调试。它可以给太空船上传一个简短的C程序。在解释C程序时，可以改变这些变量的值从假（FALSE）到真（TRUE）。这就杜绝了系统复位问题。

工程师们学到了什么？

   
• 只有对实际系统行为的详细追踪，才能捕获和识别错误执行序列。而对一个不能追踪的黑盒子来说，是无法诊断的；
• 系统中具备调试工具是非常重要的。如果不能修改系统，则问题无法修正；
• 花费额外的时间确保在测试阶段的优先级继承正确性，甚至牺牲一些本来非常宝贵的额外性能开销。
  

解决方案来源
当主讲人提到一份论文――它第一个识别优先级反转问题，并且提出了解决方案。特别的事发生了――令人惊讶的是，作者们都在房间里，收到了热情的接待。论文原文是：
L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An Approach to Real-Time Synchronization. In IEEE Transactions on Computers, vol. 39, pp. 1175-1185, Sep. 1990.
【1】本摘要根据麦克琼斯（Mike Jones）于1997年12月所记录的风河系统（Wind River Systems）公司首席技术官大卫维尔纳（David Wilner）在IEEE实时操作系统研讨会上的专题演讲

链接： rapita systems

译文链接： http://blog.jobbole.com/42802/

本文来自ChinaUnix新闻频道，如果查看原文请点：http://news.chinaunix.net/opensource/2013/0711/2844542.shtml