Small RTOS51中的一個(gè)典型問(wèn)題及其解決方法

　　1 問(wèn)題描述

　　在將Smau RTOS51應(yīng)用于實(shí)驗(yàn)室某項(xiàng)目時(shí)，發(fā)現(xiàn)了一個(gè)奇怪的問(wèn)題。簡(jiǎn)單說(shuō)來(lái)，就是一個(gè)以無(wú)條件方式申請(qǐng)消息的任務(wù)竟然在沒(méi)有取到消息的情況下，以指示“等待超時(shí)”的代碼返回了。

　　在這里，首先解釋一下任務(wù)申請(qǐng)消息的兩種方式：無(wú)條件方式和超時(shí)方式。所謂五條件方式是指任務(wù)申請(qǐng)消息時(shí)，如果暫時(shí)沒(méi)有消息可取，則任務(wù)將一直等待消息，直至取到為止；而超時(shí)方式是指任務(wù)等待消息是有時(shí)間限制的，超過(guò)所設(shè)定的最大時(shí)間，即便沒(méi)有取到消息，函數(shù)也可以正常返回，只是返回值不是消息，而是“超時(shí)代碼”(此方式可以防止任務(wù)因取不到消息而被永久性?huà)炱??？梢?jiàn)，如果任務(wù)以無(wú)條件方式申請(qǐng)消息，那么函數(shù)若能夠返回，則說(shuō)明任務(wù)一定是取到消息了，而返回值又怎么可能是“等待超 時(shí)”呢?經(jīng)過(guò)仔細(xì)分析SmallRTS5l的源代碼，找到了問(wèn)題產(chǎn)生的根源。

　　假定有任務(wù)IDX以超時(shí)方式調(diào)用OSQPend()函數(shù)申請(qǐng)消息。OSQPend()函數(shù)首先會(huì)把IDX放到此消息隊(duì)列的等待任務(wù)表中，然后再去判斷隊(duì)列中是否有消息。最佳情況是隊(duì)列中確實(shí)有消息，則OSQPend()再把IDX從此消息隊(duì)列的等待任務(wù)表中刪除，接著OSQPend()返回，任務(wù)取到消息。

　　此刻，假定消息隊(duì)列中設(shè)有消息。那么，OSQPend()就會(huì)調(diào)用OSClearSigna1(OSRunningTaskID())和OS-Sched()這兩個(gè)系統(tǒng)函數(shù)，迫使IDX進(jìn)入休眠態(tài)，同時(shí)調(diào)度器調(diào)度下一個(gè)最高優(yōu)先級(jí)的就緒任務(wù)來(lái)運(yùn)行。假定任務(wù)IDY被選中，且IDY在運(yùn)行中通過(guò)調(diào)用OSQIntPost()函數(shù)向此消息隊(duì)列發(fā)送了一則消息。則OSIntPost（）將把所有等待這個(gè)消息隊(duì)列的任務(wù)中優(yōu)先級(jí)最高的那個(gè)任務(wù)喚醒，并且把它從該消息隊(duì)列的等待任務(wù)表中刪除，假定它就是IDX。

　　當(dāng)任務(wù)IDY進(jìn)入休眠態(tài)后，操作系統(tǒng)才會(huì)調(diào)度IDX來(lái)運(yùn)行。于是IDX從上次被強(qiáng)迫休眠的地方開(kāi)始運(yùn)行，即從OSQPend（）函數(shù)中緊接著OSSched（）的那條指令開(kāi)始執(zhí)行。具體來(lái)說(shuō)，OSQPend（）將首先查看IDX是否滿(mǎn)足超時(shí)條件（用來(lái)判斷任務(wù)是因?yàn)榈却瑫r(shí)被喚醒的還是因?yàn)榇_實(shí)取到消息而被喚醒的），若超時(shí)時(shí)限尚未到達(dá)，OSQPend（）再接著檢查消息隊(duì)列中是否已經(jīng)有了消息。根據(jù)上面的假定，可以知道任務(wù)IDX確實(shí)是因?yàn)槿〉较⒍粏拘训?。于是，OSQpend（）把IDX從此消息隊(duì)列的等待任務(wù)表中刪除，OSQPend（）正常返回。這樣，任務(wù)IDX取到消息，接著運(yùn)行。

　　以上都沒(méi)有什么問(wèn)題，但是，有一種情況被忽略了，而正是這種情況的出現(xiàn)導(dǎo)致了任務(wù)IDX被長(zhǎng)時(shí)間掛起，就算隊(duì)列中有消息存在，IDX也無(wú)法被喚醒，只能等到其超時(shí)為止。

　　為討論方便，不妨仍按上述假定情況來(lái)分析。當(dāng)任務(wù)IDX被喚醒且IDY進(jìn)入休眠狀態(tài)后，系統(tǒng)必將調(diào)度下一個(gè)優(yōu)先級(jí)最高的就緒任務(wù)來(lái)運(yùn)行。在前面，認(rèn)為這個(gè)任務(wù)就是IDX，然而此時(shí)，假定它是另一個(gè)比IDX優(yōu)先級(jí)更高的任務(wù)IDZ(因?yàn)橛锌赡苁侵袛喟袸DZ喚醒的，所以中斷退出時(shí)，操作系統(tǒng)強(qiáng)制IDY進(jìn)入休眠態(tài)，轉(zhuǎn)而調(diào)度IDZ運(yùn)行）。非常巧合的是，IDZ在運(yùn)行的過(guò)程中向同一個(gè)消息隊(duì)列也申請(qǐng)了消息。由于之前IDY已經(jīng)向消息隊(duì)列發(fā)送過(guò)一條消息，則IDZ將正常取到此條消息。于是，消息隊(duì)列中的消息數(shù)減為O（Buf[0]==0）。在任務(wù)IDZ進(jìn)入休 眠后，任務(wù)IDX被操作系統(tǒng)調(diào)入CPU運(yùn)行。同樣，函數(shù)OSQPend（）首先查看IDX是否等待超時(shí)。如果沒(méi)有超時(shí)再檢查消息隊(duì)列中是否存在消息。注意到先前已經(jīng)假定消息被任務(wù)IDZ給取走了，所以檢查的結(jié)果當(dāng)然是隊(duì)列中不存在消息。IDX就只好再次進(jìn)入休眠，函數(shù)OSSched（）調(diào)度別的任務(wù)運(yùn)行。

　　于是問(wèn)題出現(xiàn)了。IDX是因?yàn)闀簳r(shí)取不到消息而被掛起的，但此時(shí)這個(gè)消息隊(duì)列的等待任務(wù)表中已經(jīng)投有IDX的蹤影了，它之前就已被那個(gè)發(fā)送消息的IDY在OSQIntPost()函數(shù)中給刪除了。

　　結(jié)果，即使后面有任務(wù)再次向隊(duì)列中發(fā)送消息，IDX也取不到了，因?yàn)橄l(fā)送函數(shù)OSQIntPost()已經(jīng)無(wú)法從消息隊(duì)列的等待任務(wù)表中找到IDX了，它將被長(zhǎng)時(shí)間掛起，直至超時(shí)。也就是說(shuō)，任務(wù)IDX明明可以取到消息的，卻取不到，最后只能以指示其等待超時(shí)的代碼返回。

　　這還是一種相對(duì)來(lái)說(shuō)不太嚴(yán)重的錯(cuò)誤，無(wú)非就是任務(wù)沒(méi)取到消息，以超時(shí)返回而已．如果任務(wù)IDX以無(wú)條件方式申請(qǐng)消息，而又恰恰發(fā)生了上面的情況，會(huì)有什么樣的后果呢?由于OSQPend()函數(shù)自身的特性，所謂五條件等待就是把超時(shí)時(shí)間設(shè)為0。結(jié)果任務(wù)IDX被喚醒后，OSQPend()必然會(huì)檢測(cè)到其已超時(shí)，然后又會(huì)檢測(cè)到隊(duì)列中沒(méi)有消息，所以就必然以“超時(shí)代碼”返回。結(jié)果就發(fā)生了文章開(kāi)頭所說(shuō)的一幕；一個(gè)必須在取到消息后才能返回的任務(wù)，居然在沒(méi)有取到消息的情況下以指示其等待超時(shí)的代碼返回了。

2 解決方法

　　問(wèn)題已經(jīng)找到，就有解決的辦法．以《嵌入式實(shí)時(shí)操作系統(tǒng)SmallRT0s5l原理與應(yīng)用》(陳明計(jì)，北京航空航天大學(xué)出版社，2004)中程序清單7.5為例。書(shū)中的代碼如下：

　　#if OS_MAX_TASKS<9              ／／把當(dāng)前任務(wù)加入到此消息隊(duì) 
                                                       ／／列的等待任務(wù)表中
    Buf[3]=OSMapTbl[OSRunnmgTasklD()]； (5)
#else
    if(OSRunningTasklD()<8){ (6)
    Buf[3]=OSMap Tbl[OSRunningTasklD()]； (7)
    else{
    Buf[4] |= OSMapTbl[OSRunningTasklD( ) &()x07]； (8)
    }
#endif
    while(Buf[O]==0) ／／消息隊(duì)列中暫時(shí)投有消息 (9)
    {
#ifdef_C51_
    SP="SP"+sizeof(Buf)。 (10)
    *((uint8 0S_Q_MEM_SEL * data*)(SP+l-slzeof(Buf))=Buf; (11)
#endif{
    OSClearSignal(OSRunningTask())； ／／當(dāng)前任務(wù)進(jìn)入休眠
                                     ／／狀態(tài) (12)
    OSSched()； ／／調(diào)度下一個(gè)最高優(yōu)先級(jí)的就緒任務(wù)運(yùn)行(13)
#ifdef_C51_
    Buf= *((uint8 OS_Q_MEM SEL*dota*)(SP+1-sizeof(Buf))； (14)
    SP="SP-sizeof"(Buf); (15)
#endif
    if(OSWaitTick[OSRunningTasklD()]==O)(16)
    {
    break； ／／任務(wù)再次運(yùn)行，如果超時(shí)到,退出循環(huán)
    }
    } ／／while(Buf[0]==O)

　　修改的方法是把(5)~(8)放在(9)后面作為while()循環(huán)的第一步，其他不變。即只有在OSQPend()函數(shù)檢測(cè)到?jīng)]有消息可取的情況下，才把任務(wù)添加到對(duì)應(yīng)于此消息隊(duì)列的等待任務(wù)表中。一來(lái)，若隊(duì)列中已經(jīng)存在消息，這可以加快。SQPend()的執(zhí)行速度；二來(lái)，對(duì)于以超時(shí)方式申請(qǐng)消息的任務(wù)，不會(huì)發(fā)生如前所述的隊(duì)列申明明有消息，任務(wù)卻取不到，只能等待至超時(shí)為止的情況。即使IDZ搶先一步取走消息，只要尚未超時(shí)，IDX會(huì)再一次被OSQPend()添加到消息隊(duì)列的等待任務(wù)表中。這樣，以后運(yùn)行的OSQIntPost()函數(shù)就能夠知道IDX仍然在等待消息，從而使lDX有機(jī)會(huì)獲得消息。

　　此法簡(jiǎn)單易行，但對(duì)于以無(wú)條件方式申請(qǐng)消息的任務(wù)并不湊效。因?yàn)闊o(wú)條件等待時(shí)，任務(wù)被喚醒，其必然滿(mǎn)足超時(shí)條件。所以無(wú)論其能否取到消息，指令都會(huì)跳出while(Buf[0]==0)循環(huán)，結(jié)果就有可能返回讓人難以理解的超時(shí)代碼。這時(shí)，需應(yīng)用程序通過(guò)額外檢測(cè)OSQPend()的返回代碼類(lèi)型來(lái)判斷任務(wù)是否真正取到消息。

　　另一種方法是仿照uC／OS—II的思路(較復(fù)雜，不推薦)。在發(fā)送消息的OSQInatPost()函數(shù)中，如果檢測(cè)到有任務(wù)正 在等待此消息，則并不把消息數(shù)(Buf[0])加l，其他部分不變。這樣，即使IDZ搶在IDX再次運(yùn)行前申請(qǐng)消息，也會(huì)因?yàn)榘l(fā)現(xiàn)隊(duì)列中沒(méi)有消息而被迫進(jìn)入休眠．但對(duì)于正在函數(shù)OSQPCnd()中等待消息的任務(wù)IDX來(lái)說(shuō)，當(dāng)它再次運(yùn)行時(shí)也會(huì)發(fā)現(xiàn)消息隊(duì)列中的消息數(shù)為O。這時(shí)，OSQPend()就需要另外檢測(cè)IDX是否仍然在等待任務(wù)表中來(lái)判斷任務(wù)到底能否取到消息。若任務(wù)還處在消息隊(duì)列的等待任務(wù)表中，則任務(wù)必定是由“超時(shí)”喚醒的，可直接返回超時(shí)代碼；否則，說(shuō)明是有別的任務(wù)通過(guò)發(fā)送消息將其喚醒的，則可以取到消息。這樣，以無(wú)條件方式等待消息的任務(wù)也就不會(huì)返回指示其等待超時(shí)的代碼了。只是此方法也有一個(gè)BUG，那就是如果有任務(wù)搶在IDX取走此消息之前向隊(duì)列中又發(fā)送了另一個(gè)消息，則新入隊(duì)列的消息存放位置將會(huì)重疊前一條消息(uC／OS—II中不存在此問(wèn)題)。也就是說(shuō)，首先進(jìn)入隊(duì)列的那條消息被覆蓋掉了，而誰(shuí)也不知道它曾經(jīng)存在過(guò)。

　　同樣的問(wèn)題也會(huì)發(fā)生在互斥型信號(hào)量的操作中，感興趣的讀者可以參看相關(guān)代碼分析。

　　結(jié) 語(yǔ)

　　需說(shuō)明一點(diǎn)，以上分析僅僅針對(duì)Small RTOS51(V1.12.1)。在本文發(fā)表前，本人曾與《嵌入式實(shí)時(shí)操作系統(tǒng)Smell RTOS61原理與應(yīng)用》一書(shū)的作者陳明計(jì)先生就此問(wèn)題通過(guò)E_mail進(jìn)行過(guò)討論。他指出：“V1.12.1的版本確實(shí)有此問(wèn)題，但在V1.20的版本中不會(huì)（盡管代碼相似）”。只是筆者在看過(guò)V1.20版本后覺(jué)得，只有當(dāng)任務(wù)IDX優(yōu)先級(jí)較高時(shí)，才有可能不發(fā)生此類(lèi)錯(cuò)誤，否則就很難保證了。