Small RTOS51中的一个典型问题及其解决方法

1、small rtos51中的一个典型问题及其解决方法small rtos5l是一款特地为80c51系列设计的实时操作系统(事实上应当称其为实时内核)，大部分代码用编写，易于移植，非常适合于资源紧急的8位机。同时，它也是学习操作系统原理极好的入门材料。本人就是在学习完smallrtos5l的基础上进一步学习了闻名的uc/0s-ii，受益颇多。1 问题描述在将smau rtos51应用于试验室某项目时，发觉了一个惊奇的问题。容易说来，就是一个以无条件方式申请消息的任务居然在没有取到消息的状况下，以指示“等待超时”的代码返回了。在这里，首先说明一下任务申请消息的两种方式：无条件方式和超时方式。所谓五

2、条件方式是指任务申请消息时，假如临时没有消息可取，则任务将向来等待消息，直至取到为止；而超时方式是指任务等待消息是有时光限制的，超过所设定的最大时光，即便没有取到消息，函数也可以正常返回，只是返回值不是消息，而是“超时代码”(此方式可以防止任务因取不到消息而被永远性挂起)。可见，假如任务以无条件方式申请消息，那么函数若能够返回，则解释任务一定是取到消息了，而返回值又怎么可能是“等待超时”呢?经过认真分析smallrts5l的源代码，找到了问题产生的根源。假定有任务idx以超时方式调用osqpend()函数申请消息。osqpend()函数首先会把idx放到此消息队列的等待任务表中，然后再去推断队

3、列中是否有消息。最佳状况是队列中的确有消息，则osqpend()再把idx从今消息队列的等待任务表中删除，接着osqpend()返回，任务取到消息。此刻，假定消息队列中设有消息。那么，osqpend()就会调用osclearsigna1(osrunningtaskid()和os-sched()这两个系统函数，迫使idx进入休眠态，同时调度器调度下一个最高优先级的就绪任务来运行。假定任务idy被选中，且idy在运行中通过调用osqintpost()函数向此消息队列发送了一则消息。则osintpost（）将把全部等待这个消息队列的任务中优先级最高的那个任务唤醒，并且把它从该消息队列的等待任务表中删

4、除，假定它就是idx。当任务idy进入休眠态后，操作系统才会调度idx来运行。于是idx从上次被强迫休眠的地方开头运行，即从osqpend（）函数中紧接着ossched（）的那条命令开头执行。详细来说，osqpend（）将首先查看idx是否满足超时条件（用来推断任务是由于等待超时被唤醒的还是由于的确取到消息而被唤醒的），若超时时限尚未到达，osqpend（）再接着检查消息队列中是否已经有了消息。按照上面的假定，可以知道任务idx的确是由于取到消息而被唤醒的。于是，osqpend（）把idx从今消息队列的等待任务表中删除，osqpend（）正常返回。这样，任务idx取到消息，接着运行。以上都没有

5、什么问题，但是，有一种状况被忽视了，而正是这种状况的浮现导致了任务idx被长时光挂起，就算队列中有消息存在，idx也无法被唤醒，只能等到其超时为止。为研究便利，不妨仍按上述假定状况来分析。当任务idx被唤醒且idy进入休眠状态后，系统必将调度下一个优先级最高的就绪任务来运行。在前面，认为这个任务就是idx，然而此时，假定它是另一个比idx优先级更高的任务idz(由于有可能是中断把idz唤醒的，所以中断退出时，操作系统强制idy进入休眠态，转而调度idz运行）。十分巧合的是，idz在运行的过程中向同一个消息队列也申请了消息。因为之前idy已经向消息队列发送过一条消息，则idz将正常取到此条消息。

6、于是，消息队列中的消息数减为o（buf0=0）。在任务idz进入休 眠后，任务idx被操作系统调入cpu运行。同样，函数osqpend（）首先查看idx是否等待超时。假如没有超时再检查消息队列中是否存在消息。注重到从前已经假定消息被任务idz给取走了，所以检查的结果固然是队列中不存在消息。idx就只好再次进入休眠，函数ossched（）调度别的任务运行。于是问题浮现了。idx是由于临时取不到消息而被挂起的，但此时这个消息队列的等待任务表中已经投有idx的踪影了，它之前就已被那个发送消息的idy在osqintpost()函数中给删除了。结果，即使后面有任务再次向队列中发送消息，idx也取不到了，

7、由于消息发送函数osqintpost()已经无法从消息队列的等待任务表中找到idx了，它将被长时光挂起，直至超时。也就是说，任务idx明明可以取到消息的，却取不到，最后只能以指示其等待超时的代码返回。这还是一种相对来说不太严峻的错误，无非就是任务没取到消息，以超时返回而已假如任务idx以无条件方式申请消息，而又恰恰发生了上面的状况，会有什么样的后果呢?因为osqpend()函数自身的特性，所谓五条件等待就是把超时时光设为0。结果任务idx被唤醒后，osqpend()必定会检测到其已超时，然后又会检测到队列中没有消息，所以就必定以“超时代码”返回。结果就发生了文章开始所说的一幕；一个必需在取到消

8、息后才干返回的任务，竟然在没有取到消息的状况下以指示其等待超时的代码返回了。2 解决办法问题已经找到，就有解决的方法以嵌入式实时操作系统smallrt0s5l原理与应用(陈明计，北京航空航天高校出版社，2004)中程序清单7.5为例。书中的代码如下：if os_max_tasks9 把当前任务加入到此消息队列的等待任务表中buf=osmaptblosrunnmgtaskld()； (5)elseif(osrunningtaskld()8) (6)buf=osmap tblosrunningtaskld()； (7)elsebuf |= osmaptblosrunningtaskld( ) &(

9、)x07； (8)endifwhile(bufo=0) 消息队列中临时投有消息 (9)ifdef_c51_sp=sp+sizeof(buf)。 (10)*(uint8 0s_q_mem_sel * data*)(sp+l-slzeof(buf)=buf; (11)endifosclearsignal(osrunningtask()； 当前任务进入休眠状态 (12)ossched()； 调度下一个最高优先级的就绪任务运行(13)ifdef_c51_buf= *(uint8 os_q_mem sel*dota*)(sp+1-sizeof(buf)； (14)sp=sp-sizeof(buf); (

10、15)endifif(oswaittickosrunningtaskld()=o)(16)break； 任务再次运行，假如超时到,退出循环 while(buf0=o)修改的办法是把(5)(8)放在(9)后面作为while()循环的第一步，其他不变。即惟独在osqpend()函数检测到没有消息可取的状况下，才把任务添加到对应于此消息队列的等待任务表中。一来，若队列中已经存在消息，这可以加快。sqpend()的执行速度；二来，对于以超时方式申请消息的任务，不会发生如前所述的队列申明明有消息，任务却取不到，只能等待至超时为止的状况。即使idz抢先一步取走消息，只要尚未超时，idx会再一次被osqpe

11、nd()添加到消息队列的等待任务表中。这样，以后运行的osqintpost()函数就能够知道idx仍然在等待消息，从而使ldx有机会获得消息。此法容易易行，但对于以无条件方式申请消息的任务并不凑效。由于无条件等待时，任务被唤醒，其必定满足超时条件。所以无论其能否取到消息，命令都会跳出while(buf0=0)循环，结果就有可能返回让人难以理解的超时代码。这时，需应用程序通过额外检测osqpend()的返回代码类型来推断任务是否真正取到消息。另一种办法是模仿ucosii的思路(较复杂，不推举)。在发送消息的osqinatpost()函数中，假如检测到有任务正在等待此消息，则并不把消息数(buf0

12、)加l，其他部分不变。这样，即使idz抢在idx再次运行前申请消息，也会由于发觉队列中没有消息而被迫进入休眠但对于正在函数osqpcnd()中等待消息的任务idx来说，当它再次运行时也会发觉消息队列中的消息数为o。这时，osqpend()就需要另外检测idx是否仍然在等待任务表中来推断任务到底能否取到消息。若任务还处在消息队列的等待任务表中，则任务必然是由“超时”唤醒的，可挺直返回超时代码；否则，解释是有别的任务通过发送消息将其唤醒的，则可以取到消息。这样，以无条件方式等待消息的任务也就不会返回指示其等待超时的代码了。只是此办法也有一个bug，那就是假如有任务抢在idx取走此消息之前向队列中又发送了另一个消息，则新入队列的消息存放