关于uC／OS-Ⅱ中优先级翻转问题

关于uC／OS-Ⅱ中优先级翻转问题 关于uC,OS-?中优先级翻转问题 经验交流 关于uC/OS—II中优先级翻转问置 ?山东大学秦绍华陈涤 1uC/OS-ll的运行机制 在嵌入式系统的应用中,实时性是一个重要的指 标,而优先级翻转是影响系统实时性的重要问题.本文 着重分析优先级翻转问题的产生和影响,以及在uC/OS— II中的解决. uC/OS—II采用基于固定优先级的占先式调度方式, 是一个实时,多任务的操作系统.系统中的每个任务具 有一个任务控制快0S—TCB,任务控制块任务执行 的环境,包括任务的优先级,任务的堆栈指针,任务的 相关事件控制块指针等.内核将系统中处于就绪态的任 务在就绪(readylist)进行标注,通过就绪表中的两个变 量OSRdyGrp和OSRdyTbl[】可快速查找系统中就绪的任 务.在uC/OS.II中每个任务有唯一的优先级,因此任务 的优先级也是任务的唯一编号(ID),可以作为任务的唯 一 标识.内核可用控制块优先级表OSTCBPrioTbl【】由任 务的优先级查到任务控制块的地址.uC/OS-II主要就是 利用任务控制快OS—TCB,就绪表(readylist)和控制块优 先级表OSTCBPrioTbl【】来进行任务调度的.任务调度程 序OSSched()首先由就绪表(readylist)中找到当前系统中 处于就绪态的优先级最高的任务,然后根据其优先级由 控制块优先级表OSTCBPrioTbl【】取得相应任务控制块的 地址,由OS—TASK—sw0程序进行运行环境的切换.将 当前运行环境切换成该任务的运行环境,则该任务由就 绪态转为运行态.当这个任务运行完毕或因其它原因挂 起时,任务调度程序OSSehedO再次到就绪表(readylist) 中寻找当前系统中处于就绪态中优先级最高的任务,转 而执行该任务,如此完成任务调度.若在任务运行时发 生中断,则转向执行中断程序,执行完毕后不是简单的 返回中断调用处,而是由OSIntExitO程序进行任务调度, 执行当前系统中优先级最高的就绪态任务.当系统中所 有任务都执行完毕时,任务调度程序OsSched()就不断 执行优先级最低的空闲任务oSTaskldle(),等待用户程 序的运行.. 2uC/OS-II中的优先级翻转问题 在uC/OS—II中,多个任务按照优先级高低由内核调 度执行,而且任务调度所花的时间是常数,与应用程序 中建立的任务数无关.对于占先式内核,任务的响应时 间是确定的,而且是最优化的,占先式内核保证最高优 先级的任务最先执行. 任务的响应时间=寻找最高优先级任务的时间+任 务切换时间 在uC/OS—II中寻找进入就绪态的最高优先级任务是 通过查就绪表实现的,这减少了所需时间. y=OSUnMapTbl[OSRdyGrp]; X-----OSUnMapTbl[oSRdyTbl[y]]; prio=(y<<3)+x; 任务切换是通过调用汇编函数OS— TASK— sw0来实 现的,主要完成两个任务运行环境的保存和恢复.因此 用户可以通过安排任务的优先级,保证系统的实时性. 当涉及到共享资源的互斥访问时,多任务实时操作系 统常常会出现优先级翻转问题(priorityinversion),不能 保证高优先级任务的响应时间,影响系统的实时性, UC/OS—II中也存在同样问题.所谓优先级翻转问题 (priorityinversion)即当一个高优先级任务通过信号量机 制访问共享资源时,该信号量已被一低优先级任务占 有,而这个低优先级任务在访问共享资源时可能又被 其它一些中等优先级的任务抢先,因此造成高优先级 任务被许多具有较低优先级的任务阻塞,实时性难以 得到保证.例如:有优先级为A,B和c的三个任务, 优先级A>B>C,任务A,B处于挂起状态,等待某一事 件的发生,任务c正在运行,此时任务c开始使用某一 共享资源S.在使用中,任务A等待的事件到来,任务 A转为就绪态,因为它比任务C优先级高,所以立即执 行.当任务A要使用共享资源S时,由于其正在被任务 C使用,因此任务A被挂起,任务C开始运行.如果此 时任务B等待的事件到来,则任务B转为就绪态.由于 任务B的优先级比任务C高,因此任务B开始运行,直 到其运行完毕,任务c才开始运行.直到任务C释放共 享资源S后,任务A才得以执行.在这种情况下,优 先级发生了翻转,任务B先于任务A运行.这样便不 能保证高优先级任务的响应时间,解决优先级翻转问 题有优先级天花板(priorityceiling)和优先级继承(priority inheritance)两种办法. 优先级天花板是当任务申请某资源时,把该任务的 优先级提升到可访问这个资源的所有任务中的最高优先 级,这个优先级称为该资源的优先级天花板.这种方法 简单易行,不必进行复杂的判断,不管任务是否阻塞了 高优先级任务的运行,只要任务访问共享资源都会提升 任务的优先级.在uC/OS—II中,可以通过 OSTaskChangePrio()改变任务的优先级,但是改变任务的 优先级是很花时间的.如果不发生优先级翻转而提升了 任务的优先级,释放资源后又改回原优先级,则无形中 浪费了许多CPU时间,也影响了系统的实时性. 优先级继承是当任务A申请共享资源S时,如果S 正在被任务C使用,通过比较任务C与自身的优先级, 如发现任务C的优先级小于自身的优先级,则将任务C 的优先级提升到自身的优先级,任务C释放资源S后, 再恢复任务c的原优先级.这种方法只在占有资源的低 优先级任务阻塞了高优先级任务时才动态的改变任务的 优先级,如果过程较复杂,则需要进行判断.uC/OS-II 不支持优先级继承,而且其以任务的优先级作为任务标 识,每个优先级只能有一个任务,因此,不适宜在应用 程序中使用优先级继承. 3uC/OS-II中优先级翻转问题的解决 在uC/OS-II中,为解决优先级翻转影响任务实时性 的问题,可以借鉴优先级继承的方法对优先级天花板方 法进行改进.对uC/OS-II的使用,共享资源任务的优先 级不是全部提升,而是先判断再决定是否提升.即当有 任务A申请共享资源S时,首先判断是否有别的的任务 正在占用资源S,若无,则任务A继续执行,若有,假 设为任务B正在使用该资源,则判断任务B的优先级是 否低于任务A,若高于任务A,则任务A挂起,等待任 务B释放该资源,如果任务B的优先级低于任务A,则 提升任务B的优先级到该资源的优先级天花板,当任务 B释放资源后,再恢复到原优先级.在uC/OS-II中,每 个共享资源都可看作一个事件,每个事件都有相应的事 件控制块ECB.在ECB中包含一个等待本事件的等待任 务列表,该列表包括OSEventTbl[]和OSEventGrp两个域, 通过对等待任务列表的判断可以很容易的确定是否有多 个任务在等待该资源,同时也可判断任务的优先级与当 前任务优先级的高低,从而决定是否需要用 OSTaskChangePio()来改变任务的优先级.这样,仅在优 先级有可能发生翻转的情况下才改变任务的优先级,而 且利用事件的等待任务列表进行判断,比用 OSTaskChangePio()来改变任务的优先级速度快,并占用 较少的CPU时间,有利于系统实时性的提高. 总之,优先级翻转问题是多任务实时操作系统普遍 存在的问题,这个问题也存在于uC/OS-II中.通过在应 用程序中进行简单的判断,在可能出现优先级翻转的情 况下动态的改变任务的优先级,可以有效地避免任务的 优先级翻转,保证高优先级任务的执行,提高了系统的 实时性._l 参考文献 1LabrosseJeanJ.uC/OS—II一源码公开的实时嵌入式操作系 统.邵贝贝译.北京:中国电力出版社,2001 2魏忠,蔡勇,雷红卫编着.嵌入式开发详解.北京:电子工 业出版社,2003 3徐甲同,等编着.计算机操作系统教程.西安:西安电子科 技大学出版社,2001 (收稿日期:2004—10—12) Microchip发布2871脚LCD单片机及可驱动192段LCD的8o弓}脚单鼍瓤 .j警ll_lIl譬0. :i?霉.. Mieroehip(美国微芯科技公司)近日发布8款内置液晶显示(LCD)模块的8位PIC 单片机.新款LCDPIC单片机系列包 括28引脚LCD单片机,适用于需要嵌入式控制的简单,成本效益高的显示应用,以及可驱动I92段LCD的8O引脚可编程单片 机,适用于触摸屏和分段式LCD显示屏应用.这批MieroehipLCDPIC系列单片机的新成员,在该系列原有引脚数目和性能水 平选择广泛的基础上,增强了产品功能,能满足多种LCD段显示屏的不同需求. MieroehipLCDPIC系列单片机配备程序闪存,功耗低,并具有LCD控制功能.与市场上同类LCD单片机相比,其程序闪 存大大提升了代码开发和现蔺再编程的灵活性.该系列单片机还配备了纳瓦技术,符合业界对低功耗的要求?包括在体眠 状态下驱动LCD显示等.新器件内置的LcD模块能通过软件进行配置,可有效减少系统元器件数目和电路板尺寸,降低系统 成本. 72丰尊-_.-入菇???一I_圈_