μC/OS-Il在TMS320VC33上的可靠应用 02 定时器, 优先级, 程序

samwalton

2 OSRdyGrp和OSRdyTbl
    在笔者的应用系统中，除了定时器1中断外，还使用 了外部中断2、DMA中断和串口接收中断，把这些中断全 部打开后，会出现一个非常奇怪的现象。系统刚开始运行 时一切正常，一段时间后，与idle task不在同一个优先级 组的所有任务再也不执行了。但从程序上看，这些任务应 该处于就绪状态，除非就绪任务的优先级与idle task处于 同一个组，否则系统永远都在执行idle task。通过检查 OSRdyTbl发现，这些不被调度的任务的确处于就绪状 态，但在OSRdyGrp中却没有设置相应的标志．如果在 OSRdyTbl表中任务是就绪的，与该任务优先级组相对应 的OSRdyGrp中的标志却是0，那么任务调度时这些就绪 的任务是不会被调度的。在μC／OS-II中，OSRdyGrp与 OSRdyTbl的值都是同时修改的，并且还采用了临界区保 护，为什么还会出现OSRdyGrp与OSRdyTbl状态不一致 的现象呢?通过对汇编代码的仔细分析，发现问题出现在 函数OSTimeTick中，编译器产生了高效但不可靠的代 码。笔者使用的开发平台是Code Composer V4.1，代码 生成工具版本为5.11。此版本的代码生成工具产生的 OSTimeTick函数的汇编代码如下：
   
   
    OSTimeTick函数的while循环结构从第5行开始至第23行结束。修改OSRdyGrp的语句是第8行，可以看出对OSRdyGrp的修改没有保存至相应的内存单元，而是保存在寄存器r0中，对OSRdyTbl的修改却直接保存到了内存单元(第14行)。位于循环体外的第4行语句将OSRdyGrp赋值给10，第24行将r0的内容保存至OSRdyGrp。编译器利用寄存器优化了对OSRdyGrp的访问，循环结构中OSRdyGrp值的每次改变都保存在寄存器中，只是在循环开始和结束时访问了两次内存，编译器这样的处理显然是高效的．如果不优化，语句“OSRdyGrp|=ptcb->OSTCBBitY”必须以读-改-写的方式实现，OSRdyGrp值的每次改变需要访问两次内存，而一般情况下对内存的访问是耗时的．应尽量避免。由上述代码容易看出，这样的优化使得对OSRdyGrp的访问位于临界区以外，因而引入了不安全因素。因为在时钟节拍中断服务程序OSTicklSR中允许嵌套中断，所以第19行以后的语句是可中断的。如果在20~23行之间发生了中断，并且相应的中断服务程序改变了OSRdyGrp，那么第24行的赋值可能使OSRdyrp获得一个错误的结果，造成 OSRdy(jrp与C)SRdyrTbl的不一致。第4行的赋值语句同样是危险的，如果有中断发生，rO中暂存的值不一定是当前正确的OSRdyGrp。奇怪的是，无论采用何种编译优化选项，编译器对OSRdyGrp的处理都是一样的，即使禁止优化也没有用。在函数0S_TaskStat中对于OSStatRdy 的处理，无论采用何种编译优化选项都不会对OSStatRdy 进行寄存器优化。知道原因后，对这一问题的处理是非常简单的，只要在OSRdyGrp声明时加上volatile修饰符(位于文件uCOS_II．H中)就可以禁止编译器对OSRdyGrp 进行寄存器优化。给OSRdyGrp加上volatile修饰符后的编译结果为：
   
   
    与上面的第7、8行对比可以看出，对OSRdyGrp的每次修改都访问了内存单元，并且是在临界区内进行的。