Small RTOS51中消息隊列的一處隱患

[b]引 言 [/b] Small RTOS5l是一款專門為80C5l系列單片機設(shè)計的實時操作系統(tǒng)(實際上應(yīng)該稱其為實時內(nèi)核)，大部分代碼用C語言編寫，易于移植，十分適合于資源緊張的8位機。同時，它也是學(xué)習(xí)嵌入式操作系統(tǒng)原理極好的入門材料。本人就是在學(xué)習(xí)完SmallRTOS5l的基礎(chǔ)上進一步學(xué)習(xí)了著名的uC/0S-II，受益頗多。 1 問題描述 在將Smau RTOS51應(yīng)用于實驗室某項目時，發(fā)現(xiàn)了一個奇怪的問題。簡單說來，就是一個以無條件方式申請消息的任務(wù)竟然在沒有取到消息的情況下，以指示“等待超時”的代碼返回了。 在這里，首先解釋一下任務(wù)申請消息的兩種方式：無條件方式和超時方式。所謂五條件方式是指任務(wù)申請消息時，如果暫時沒有消息可取，則任務(wù)將一直等待消息，直至取到為止;而超時方式是指任務(wù)等待消息是有時間限制的，超過所設(shè)定的最大時間，即便沒有取到消息，函數(shù)也可以正常返回，只是返回值不是消息，而是“超時代碼”(此方式可以防止任務(wù)因取不到消息而被永久性掛起)?？梢?，如果任務(wù)以無條件方式申請消息，那么函數(shù)若能夠返回，則說明任務(wù)一定是取到消息了，而返回值又怎么可能是“等待超時”呢?經(jīng)過仔細分析SmallRTS5l的源代碼，找到了問題產(chǎn)生的根源。 假定有任務(wù)IDX以超時方式調(diào)用OSQPend()函數(shù)申請消息。OSQPend()函數(shù)首先會把IDX放到此消息隊列的等待任務(wù)表中，然后再去判斷隊列中是否有消息。最佳情況是隊列中確實有消息，則OSQPend()再把IDX從此消息隊列的等待任務(wù)表中刪除，接著OSQPend()返回，任務(wù)取到消息。 此刻，假定消息隊列中設(shè)有消息。那么，OSQPend()就會調(diào)用OSClearSigna1(OSRunningTaskID())和OS- Sched()這兩個系統(tǒng)函數(shù)，迫使IDX進入休眠態(tài)，同時調(diào)度器調(diào)度下一個最高優(yōu)先級的就緒任務(wù)來運行。假定任務(wù)IDY被選中，且IDY在運行中通過調(diào)用OSQIntPost()函數(shù)向此消息隊列發(fā)送了一則消息。則OSIntPost()將把所有等待這個消息隊列的任務(wù)中優(yōu)先級最高的那個任務(wù)喚醒，并且把它從該消息隊列的等待任務(wù)表中刪除，假定它就是IDX。 當(dāng)任務(wù)IDY進入休眠態(tài)后，操作系統(tǒng)才會調(diào)度IDX來運行。于是IDX從上次被強迫休眠的地方開始運行，即從OSQPend()函數(shù)中緊接著 OSSched()的那條指令開始執(zhí)行。具體來說，OSQPend()將首先查看IDX是否滿足超時條件(用來判斷任務(wù)是因為等待超時被喚醒的還是因為確實取到消息而被喚醒的)，若超時時限尚未到達，OSQPend()再接著檢查消息隊列中是否已經(jīng)有了消息。根據(jù)上面的假定，可以知道任務(wù)IDX確實是因為取到消息而被喚醒的。于是，OSQpend()把IDX從此消息隊列的等待任務(wù)表中刪除，OSQPend()正常返回。這樣，任務(wù)IDX取到消息，接著運行。 以上都沒有什么問題，但是，有一種情況被忽略了，而正是這種情況的出現(xiàn)導(dǎo)致了任務(wù)IDX被長時間掛起，就算隊列中有消息存在，IDX也無法被喚醒，只能等到其超時為止。 為討論方便，不妨仍按上述假定情況來分析。當(dāng)任務(wù)IDX被喚醒且IDY進入休眠狀態(tài)后，系統(tǒng)必將調(diào)度下一個優(yōu)先級最高的就緒任務(wù)來運行。在前面，認為這個任務(wù)就是IDX，然而此時，假定它是另一個比IDX優(yōu)先級更高的任務(wù)IDZ(因為有可能是中斷把IDZ喚醒的，所以中斷退出時，操作系統(tǒng)強制IDY進入休眠態(tài)，轉(zhuǎn)而調(diào)度IDZ運行)。非常巧合的是，IDZ在運行的過程中向同一個消息隊列也申請了消息。由于之前IDY已經(jīng)向消息隊列發(fā)送過一條消息，則IDZ 將正常取到此條消息。于是，消息隊列中的消息數(shù)減為O(Buf[0]==0)。在任務(wù)IDZ進入休 眠后，任務(wù)IDX被操作系統(tǒng)調(diào)入CPU運行。同樣，函數(shù)OSQPend()首先查看IDX是否等待超時。如果沒有超時再檢查消息隊列中是否存在消息。注意到先前已經(jīng)假定消息被任務(wù)IDZ給取走了，所以檢查的結(jié)果當(dāng)然是隊列中不存在消息。IDX就只好再次進入休眠，函數(shù)OSSched()調(diào)度別的任務(wù)運行。 于是問題出現(xiàn)了。IDX是因為暫時取不到消息而被掛起的，但此時這個消息隊列的等待任務(wù)表中已經(jīng)投有IDX的蹤影了，它之前就已被那個發(fā)送消息的IDY在 OSQIntPost()函數(shù)中給刪除了。 結(jié)果，即使后面有任務(wù)再次向隊列中發(fā)送消息，IDX也取不到了，因為消息發(fā)送函數(shù)OSQIntPost()已經(jīng)無法從消息隊列的等待任務(wù)表中找到IDX 了，它將被長時間掛起，直至超時。也就是說，任務(wù)IDX明明可以取到消息的，卻取不到，最后只能以指示其等待超時的代碼返回。 這還是一種相對來說不太嚴(yán)重的錯誤，無非就是任務(wù)沒取到消息，以超時返回而已.如果任務(wù)IDX以無條件方式申請消息，而又恰恰發(fā)生了上面的情況，會有什么樣的后果呢?由于OSQPend()函數(shù)自身的特性，所謂五條件等待就是把超時時間設(shè)為0。結(jié)果任務(wù)IDX被喚醒后，OSQPend()必然會檢測到其已超時，然后又會檢測到隊列中沒有消息，所以就必然以“超時代碼”返回。結(jié)果就發(fā)生了文章開頭所說的一幕;一個必須在取到消息后才能返回的任務(wù)，居然在沒有取到消息的情況下以指示其等待超時的代碼返回了。 2 解決方法 問題已經(jīng)找到，就有解決的辦法.以《嵌入式實時操作系統(tǒng)SmallRT0s5l原理與應(yīng)用》(陳明計，北京航空航天大學(xué)出版社，2004)中程序清單 7.5為例。書中的代碼如下： #if OS_MAX_TASKS<9 //把當(dāng)前任務(wù)加入到此消息隊 //列的等待任務(wù)表中 Buf[3]=OSMapTbl[OSRunnmgTasklD()]; (5) #else if(OSRunningTasklD()<8){ (6) Buf[3]=OSMap Tbl[OSRunningTasklD()]; (7) else{ Buf[4] |= OSMapTbl[OSRunningTasklD( ) %26;amp;()x07]; (8) } #endif while(Buf[O]==0) //消息隊列中暫時投有消息 (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ù)進入休眠 //狀態(tài) (12) OSSched(); //調(diào)度下一個最高優(yōu)先級的就緒任務(wù)運行(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ù)再次運行，如果超時到,退出循環(huán) } } //while(Buf[0]==O) 修改的方法是把(5)"(8)放在(9)后面作為while()循環(huán)的第一步，其他不變。即只有在OSQPend()函數(shù)檢測到?jīng)]有消息可取的情況下，才把任務(wù)添加到對應(yīng)于此消息隊列的等待任務(wù)表中。一來，若隊列中已經(jīng)存在消息，這可以加快。SQPend()的執(zhí)行速度;二來，對于以超時方式申請消息的任務(wù)，不會發(fā)生如前所述的隊列申明明有消息，任務(wù)卻取不到，只能等待至超時為止的情況。即使IDZ搶先一步取走消息，只要尚未超時，IDX會再一次被 OSQPend()添加到消息隊列的等待任務(wù)表中。這樣，以后運行的OSQIntPost()函數(shù)就能夠知道IDX仍然在等待消息，從而使lDX有機會獲得消息。 此法簡單易行，但對于以無條件方式申請消息的任務(wù)并不湊效。因為無條件等待時，任務(wù)被喚醒，其必然滿足超時條件。所以無論其能否取到消息，指令都會跳出 while(Buf[0]==0)循環(huán)，結(jié)果就有可能返回讓人難以理解的超時代碼。這時，需應(yīng)用程序通過額外檢測OSQPend()的返回代碼類型來判斷任務(wù)是否真正取到消息。 另一種方法是仿照uC/OS—II的思路(較復(fù)雜，不推薦)。在發(fā)送消息的OSQInatPost()函數(shù)中，如果檢測到有任務(wù)正在等待此消息，則并不把消息數(shù)(Buf[0])加l，其他部分不變。這樣，即使IDZ搶在IDX再次運行前申請消息，也會因為發(fā)現(xiàn)隊列中沒有消息而被迫進入休眠.但對于正在函數(shù) OSQPCnd()中等待消息的任務(wù)IDX來說，當(dāng)它再次運行時也會發(fā)現(xiàn)消息隊列中的消息數(shù)為O。這時，OSQPend()就需要另外檢測IDX是否仍然在等待任務(wù)表中來判斷任務(wù)到底能否取到消息。若任務(wù)還處在消息隊列的等待任務(wù)表中，則任務(wù)必定是由“超時”喚醒的，可直接返回超時代碼;否則，說明是有別的任務(wù)通過發(fā)送消息將其喚醒的，則可以取到消息。這樣，以無條件方式等待消息的任務(wù)也就不會返回指示其等待超時的代碼了。只是此方法也有一個BUG，那就是如果有任務(wù)搶在IDX取走此消息之前向隊列中又發(fā)送了另一個消息，則新入隊列的消息存放位置將會重疊前一條消息(uC/OS—II中不存在此問題)。也就是說，首先進入隊列的那條消息被覆蓋掉了，而誰也不知道它曾經(jīng)存在過。 同樣的問題也會發(fā)生在互斥型信號量的操作中，感興趣的讀者可以參看相關(guān)代碼分析。 結(jié) 語 需說明一點，以上分析僅僅針對Small RTOS51(V1.12.1)。在本文發(fā)表前，本人曾與《嵌入式實時操作系統(tǒng)Smell RTOS61原理與應(yīng)用》一書的作者陳明計先生就此問題通過E_mail進行過討論。他指出：“V1.12.1的版本確實有此問題，但在V1.20的版本中不會(盡管代碼相似)”。只是筆者在看過V1.20版本后覺得，只有當(dāng)任務(wù)IDX優(yōu)先級較高時，才有可能不發(fā)生此類錯誤，否則就很難保證了。不知廣大愛好者有何見解，希望能與您共同探討，請發(fā)E_mial到nt_chen@163.net或投稿到本刊。