“火星探路者”与VxWorks优先级反转问题

“火星探路者(Mars Pathfinder, MPF)”于1997年07月04日在火星表面着陆。在开始的几天内工作稳定,并传回大量数据,但是几天后,“探路者”开始出现系统复位、数据丢失的现象。

经过研发人员的分析,最后得出结论,就是因为系统里发生了优先级反转的问题。

其中有如下两个任务需要互斥访问共享资源“信息总线”:

T1:总线管理任务,高优先级(这里用T1表示),负责在总线上放入或者取出各种数据,频繁进行总线数据I/O,它被设计为最重要的任务,并且要保证能够每隔一定的时间就可以操作总线。对总线的异步访问是通过互斥信号量来保证的。

T6:数据收集任务,优先级低(这里用T6表示),它运行频度不高,只向总线写数据,并通过互斥信号量将数据发布到“信息总线”。

如果“数据收集任务 T6”持有信号量期间,“总线管理任务 T1"就绪,并且也申请获取信号量,则总线管理任务阻塞,直到数据收集任务释放信号量。

这样看起来会工作很好,当数据收集任务很快完成后,高优先级的总线管理任务会很快得到运行。

但是,另有一个需要较长时间运行的通信任务(这里用T3表示),其优先级比T6高,比T1低,在很少情况下,如果通信任务被中断程序激活,并且刚好在总线管理任务(T1)等待数据收集任务(T6)完成期间就绪,这样T3将被系统调度,从而比它低优先级的数据收集任务T6得不到运行,因而使最高优先级的总线管理任务(T1)也无法运行,一直被阻塞在那里。在经历一定的时间后,看门狗观测到“总线”没有活动,将其解释为严重错误,并使系统复位。

这个就是优先级反转。

解决的办法:
VxWorks中采用了优先级继承协议,当高优先级任务需要低优先级任务占用资源时,将低优先级任务的优先级提高到和高优先级相同的级别,也就是低优先级继承了高优先级任务的优先级级别。

在上面的例子中,T6会继承T1的优先级别,从而能保证T1一定比T3优先调度。在VxWorks中,默认情况下该功能被关闭,所以就有可能发生优先级反转,也就导致了“火星探路者”中问题的发生。

另外还有一个防止优先级反转的是优先级天花板,不论是否阻塞了高优先级任务,持有该协议的任务在执行期间,都被赋予优先级天花板看作的优先级,以使任务尽快完成操作。

你可能感兴趣的:(“火星探路者”与VxWorks优先级反转问题)