论文部分内容阅读
摘要：实时性是嵌入式应用中一个重要的指标，而优先级翻转是影响系统实时性的一个重要因素。可剥夺型内核中，任务以独占方式使用共享资源时，将出现低优先级任务先于高优先级任务运行的现象，即优先级翻转。本文以实时操作系统uC/OS-II为例，分析了产生优先级翻转的原因，阐述了利用互斥信号量解决该问题的原理并通过具体的应用程序对这一方法的可行性进行了验证。
关键词：uC/OS-II；优先级翻转；mutex ；IAR EW
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)03-10779-02
1 引言
使用实时内核的过程中，难免会遇到优先级翻转问题。相应的解决办法有优先级继承和优先级顶置两种。优先级继承的核心是：内核在低优先级任务阻塞高优先级任务时提高低优先级任务的优先级使其与高优先级任务的优先级等同；遗憾的是uC/OS-II却不支持这种方法。对于优先级顶置，当某个任务申请共享资源时，内核会将该任务的优先级提升到可访问这个资源的所有任务中的最高优先级，任务间可共享资源且不需信号量；这种办法看似简单，但在实际未发生优先级翻转的情况下同样影响了系统的实时性。利用互斥信号量（mutex）的方法则是在借鉴优先级继承的基础上改进了优先级顶置。
2 uC/OS-II中的优先級翻转
uC/OS-II中，多个任务按照优先级高低由内核调度执行。同时，任务调度所花的时间是常数并且与应用程序中建立的任务数无关。对于占先式内核，它能保证最高优先级的任务最先执行并且任务的响应时间是确定的也是最优化的。下面解释出现优先级翻转的原因。
如图1所示，任务1的优先级高于任务2，任务2的优先级高于任务3。任务1和任务3使用同一共享资源，而用于保护该资源的信号量同一时间内只允许某个任务以独占式对其进行访问；但不使用信号量的任务2可以剥夺最低优先级任务1的使用权。通过分析不难得出以下结论：优先级较低的任务2先于优先级最高的任务1运行了，即产生了优先级翻转现象。
任务以独占方式使用共享资源是产生上述现象的根本所在。当前某个任务能否顺利运行，同时由其自身的优先级和是否占有信号量两个因素决定而后者的约束力更强。类似上述情况，如果具有中间优先级的任务较多，则高优先级任务的运行环境会更加恶化。
3 mutex原理简介
uC/OS-II中通过对信号量赋予不同的初值让它执行相应的功能。如果信号量用于对共享资源的访问，那么其初值赋为1，此时当作二值信号量来使用即mutex。Mutex也称作互斥型信号量(mutual exclusion semaphores)，实际的应用程序中我们可以用它实现对共享资源的独占式处理，从而缓解优先级翻转问题。
利用mutex解决上述问题的关键在于：使用共享资源期间，将获得信号量任务的优先级暂时提升到高于所有任务的优先级别之上以使其不被任何较高优先级任务打断；待该任务释放信号量之后，再恢复其原有优先级。
uC/OS-II的mutex包括以下三个元素：1个标志，标明mutex是否可用；1个优先级别，用于赋给占有mutex的任务（具有最高级别）；1个等待该mutex的任务列表。
4 可行性验证
4.1 IAR EW简介
IAR Embedded Workbench(简称IAR EW)是由瑞典IAR System推出的一种非常有效的嵌入式系统开发工具，其中完全集成了开发嵌入式系统所需要的文件编辑、项目管理、编译、链接和调试工具，具有统一界面。该系列适用于开发基于8位、16位以及32位微处理器的嵌入式系统，用户可针对多种不同的目标处理器，在相同的集成环境中进行基于不同的嵌入式系统应用程序开发，从而提高了工作效率。下面通过编写两个应用程序并对比其运行结果来进一步验证mutex有效缓解uC/OS-II中优先级翻转问题的可行性。程序的编写、调试均在IAR EW中完成，最后的运行结果则在Terminal I/O终端窗口中观察。
4.2 一般情况
如图2所示，应用程序中分别建立三个任务：task1、task2 和task3；优先级：task1最高、task2次之、task3最低。信号量semaphore1同一时刻只能由一个任务占有，而semaphore2允许两个任务同时访问该资源。其中，task1的运行只需拥有semaphore1；task2的运行则要求占有semaphore1和semaphore2；而task3得到semaphore2即可运行。程序运行后的结果如下：
图2 任务与信号量关系图
正如图3中的结果显示，task1优先级最高，先获得cpu使用权及对semaphore1的访问权然后开始运行，运行完后释放semaphore1；task3只需申请到共享资源semaphore2后就可以运行；task2则要等待task1释放semaphore1后才能运行。糟糕的情况却出现了：task2运行之后并没有立即释放semaphore1，此时具有最高优先级的task1因为得不到该资源而被挂起。下面是未设置断点且task2运行后释放了semaphore1的情况，同样出现了优先级翻转的现象。
4.3引入mutex的情况
程序中同样定义了三个任务Taskprio10、Taskprio15和Taskprio20，其优先级分别为10、15和20；cnt1、cnt2和cnt3是信号量计数器，其值分别对应Taskprio10 count、Taskprio15 count和Taskprio20 count。程序运行期间，若有任务申请信号量，首先对cnt的初值进行判断：如果cnt>0，则执行cnt-1，任务继续运行；如果cnt<0，系统会将相应的任务列入任务等待表使其处于等待状态。
图5中所显示的结果表明：使用mutex之后，任务能够按照其优先级的高低先后运行，优先级翻转现象不再出现。
图4 全速运行后的结果图5 mutex应用实例运行结果
5 总结
优先级翻转是任何一个多任务实时操作操作系统都无法避免的问题，本文分析了该现象产生的原因，主要讨论了uC/OS-II中运用mutex解决该问题的方法并对其可行性进行了验证。相对优先级继承和优先级顶置策略，在可能出现优先级翻转的情况下动态的改变任务优先级能够保证高优先级任务的执行，有效地提高了系统的实时性。知识领域的探索是永无止境的，如何更大程度得改进嵌入式系统的实时性是人们今后应不断努力的方向。
参考文献：
[1]Jean J.Labrosse.嵌入式实时操作系统uC/OS-II(第2版)[M].北京航空航天大学出版社,2003.
[2]任哲.嵌入式实时操作系统uC/OS-II原理及应用[M].北京航空航天大学出版社,2005.
[3]徐爱钧.IAR EWARM嵌入式系统编程与实践[M]. 北京航空航天大学出版社,2006.
[4]ChengZhang and David Cordes.Resource Access Control For Dynamic Priority Distributed Real-time Systems[M].Springer Netherlands,2006.101-127.
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。
关键词：uC/OS-II；优先级翻转；mutex ；IAR EW
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)03-10779-02
1 引言
使用实时内核的过程中，难免会遇到优先级翻转问题。相应的解决办法有优先级继承和优先级顶置两种。优先级继承的核心是：内核在低优先级任务阻塞高优先级任务时提高低优先级任务的优先级使其与高优先级任务的优先级等同；遗憾的是uC/OS-II却不支持这种方法。对于优先级顶置，当某个任务申请共享资源时，内核会将该任务的优先级提升到可访问这个资源的所有任务中的最高优先级，任务间可共享资源且不需信号量；这种办法看似简单，但在实际未发生优先级翻转的情况下同样影响了系统的实时性。利用互斥信号量（mutex）的方法则是在借鉴优先级继承的基础上改进了优先级顶置。
2 uC/OS-II中的优先級翻转
uC/OS-II中，多个任务按照优先级高低由内核调度执行。同时，任务调度所花的时间是常数并且与应用程序中建立的任务数无关。对于占先式内核，它能保证最高优先级的任务最先执行并且任务的响应时间是确定的也是最优化的。下面解释出现优先级翻转的原因。
如图1所示，任务1的优先级高于任务2，任务2的优先级高于任务3。任务1和任务3使用同一共享资源，而用于保护该资源的信号量同一时间内只允许某个任务以独占式对其进行访问；但不使用信号量的任务2可以剥夺最低优先级任务1的使用权。通过分析不难得出以下结论：优先级较低的任务2先于优先级最高的任务1运行了，即产生了优先级翻转现象。
任务以独占方式使用共享资源是产生上述现象的根本所在。当前某个任务能否顺利运行，同时由其自身的优先级和是否占有信号量两个因素决定而后者的约束力更强。类似上述情况，如果具有中间优先级的任务较多，则高优先级任务的运行环境会更加恶化。
3 mutex原理简介
uC/OS-II中通过对信号量赋予不同的初值让它执行相应的功能。如果信号量用于对共享资源的访问，那么其初值赋为1，此时当作二值信号量来使用即mutex。Mutex也称作互斥型信号量(mutual exclusion semaphores)，实际的应用程序中我们可以用它实现对共享资源的独占式处理，从而缓解优先级翻转问题。
利用mutex解决上述问题的关键在于：使用共享资源期间，将获得信号量任务的优先级暂时提升到高于所有任务的优先级别之上以使其不被任何较高优先级任务打断；待该任务释放信号量之后，再恢复其原有优先级。
uC/OS-II的mutex包括以下三个元素：1个标志，标明mutex是否可用；1个优先级别，用于赋给占有mutex的任务（具有最高级别）；1个等待该mutex的任务列表。
4 可行性验证
4.1 IAR EW简介
IAR Embedded Workbench(简称IAR EW)是由瑞典IAR System推出的一种非常有效的嵌入式系统开发工具，其中完全集成了开发嵌入式系统所需要的文件编辑、项目管理、编译、链接和调试工具，具有统一界面。该系列适用于开发基于8位、16位以及32位微处理器的嵌入式系统，用户可针对多种不同的目标处理器，在相同的集成环境中进行基于不同的嵌入式系统应用程序开发，从而提高了工作效率。下面通过编写两个应用程序并对比其运行结果来进一步验证mutex有效缓解uC/OS-II中优先级翻转问题的可行性。程序的编写、调试均在IAR EW中完成，最后的运行结果则在Terminal I/O终端窗口中观察。
4.2 一般情况
如图2所示，应用程序中分别建立三个任务：task1、task2 和task3；优先级：task1最高、task2次之、task3最低。信号量semaphore1同一时刻只能由一个任务占有，而semaphore2允许两个任务同时访问该资源。其中，task1的运行只需拥有semaphore1；task2的运行则要求占有semaphore1和semaphore2；而task3得到semaphore2即可运行。程序运行后的结果如下：
图2 任务与信号量关系图
正如图3中的结果显示，task1优先级最高，先获得cpu使用权及对semaphore1的访问权然后开始运行，运行完后释放semaphore1；task3只需申请到共享资源semaphore2后就可以运行；task2则要等待task1释放semaphore1后才能运行。糟糕的情况却出现了：task2运行之后并没有立即释放semaphore1，此时具有最高优先级的task1因为得不到该资源而被挂起。下面是未设置断点且task2运行后释放了semaphore1的情况，同样出现了优先级翻转的现象。
4.3引入mutex的情况
程序中同样定义了三个任务Taskprio10、Taskprio15和Taskprio20，其优先级分别为10、15和20；cnt1、cnt2和cnt3是信号量计数器，其值分别对应Taskprio10 count、Taskprio15 count和Taskprio20 count。程序运行期间，若有任务申请信号量，首先对cnt的初值进行判断：如果cnt>0，则执行cnt-1，任务继续运行；如果cnt<0，系统会将相应的任务列入任务等待表使其处于等待状态。
图5中所显示的结果表明：使用mutex之后，任务能够按照其优先级的高低先后运行，优先级翻转现象不再出现。
图4 全速运行后的结果图5 mutex应用实例运行结果
5 总结
优先级翻转是任何一个多任务实时操作操作系统都无法避免的问题，本文分析了该现象产生的原因，主要讨论了uC/OS-II中运用mutex解决该问题的方法并对其可行性进行了验证。相对优先级继承和优先级顶置策略，在可能出现优先级翻转的情况下动态的改变任务优先级能够保证高优先级任务的执行，有效地提高了系统的实时性。知识领域的探索是永无止境的，如何更大程度得改进嵌入式系统的实时性是人们今后应不断努力的方向。
参考文献：
[1]Jean J.Labrosse.嵌入式实时操作系统uC/OS-II(第2版)[M].北京航空航天大学出版社,2003.
[2]任哲.嵌入式实时操作系统uC/OS-II原理及应用[M].北京航空航天大学出版社,2005.
[3]徐爱钧.IAR EWARM嵌入式系统编程与实践[M]. 北京航空航天大学出版社,2006.
[4]ChengZhang and David Cordes.Resource Access Control For Dynamic Priority Distributed Real-time Systems[M].Springer Netherlands,2006.101-127.
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。