深入探討《Small RTOS51中消息隊列的一處隱患》

摘要：Small RTOS51是一款重要的小型實(shí)時(shí)內核，消息隊列是其提供的重要任務(wù)間通信的機制。針對其消息隊列實(shí)現代碼中的缺陷以及可能導致的消息丟失這一嚴重問(wèn)題，從操作系統等待與喚醒機制理論的角度出發(fā)，剖析Small RTOS51內核在消息隊列甚至互斥型信號量等實(shí)現機制上的漏洞所在；進(jìn)一步指出原內核實(shí)現方式的修改方法，以及《Small RTOS51中消息隊列的一處隱患》作者提出的第2種修改方法的完美實(shí)現。

關(guān)鍵詞：Small RTOS51 消息隊列 喚醒模型 隱患分析

引言

　　貴刊2005年第7期《Small RTOS51中消息隊列的一處隱患》一文，對Small RTOS51V1.12.1版本的消息隊列機制進(jìn)行了周密的分析，不但找出了問(wèn)題所在，也提出了相應的兩種解決方法[1]。實(shí)時(shí)嵌入式系統對于安全性有很高的要求，作為實(shí)時(shí)嵌入式系統的內核，不但要求精簡(jiǎn)高效，更要加強安全，防止因操作系統出錯而在應用領(lǐng)域導致災難性的后果。因此原文作者所做的工作極有價(jià)值，同時(shí)也感謝貴刊對這一領(lǐng)域的高度重視。

　　因為這一問(wèn)題涉及到內核的等待與喚醒機制，并且正是由于對內核的等待與喚醒機制的理解與運用不同，才導致了問(wèn)題的出現，所以本文從操作系統理論的高度以及目前主流的實(shí)時(shí)內核的實(shí)現方法兩方面入手論述這一問(wèn)題，并揭示如何才能完美實(shí)現原文的第2種方法。

1 內核喚醒機制的三種模型

　　當利用系統調用接口獲取資源時(shí)，如果資源不滿(mǎn)足，系統調用可以返回錯誤，也可以根據選項懸掛等待；當有任務(wù)釋放資源從而資源可以滿(mǎn)足時(shí)，就要將資源等待隊列中的相關(guān)任務(wù)喚醒。喚醒模型有三種[2]：
第1種，將該資源等待隊列中的任務(wù)全部喚醒，讓這些任務(wù)與系統中的其他任務(wù)平等竟爭資源。這種策略會(huì )使系統在一段時(shí)間內繁忙，因為最終只有一個(gè)任務(wù)獲取到資源，其他任務(wù)可能將經(jīng)歷一個(gè)從就緒態(tài)到運行態(tài)再到阻塞態(tài)的過(guò)程。這種現象在操作系統理論上稱(chēng)為“千軍萬(wàn)馬奔騰”。就目前的一些主流實(shí)時(shí)內核VxWorks、Nucleus、uC/OS?II等來(lái)講，都沒(méi)有采用這種策略。

　　第2種，將該資源等待隊列中的一個(gè)任務(wù)喚醒，依據所采用的策略不同，可以是等待任務(wù)中優(yōu)先級最高的，也可以是第1個(gè)進(jìn)入等待隊列中的任務(wù)。這個(gè)任務(wù)被喚醒后將和系統中的其他任務(wù)一起競爭這個(gè)資源。如果這個(gè)任務(wù)最終沒(méi)有競爭到這個(gè)資源，它將再次進(jìn)入該資源的等待隊列并進(jìn)行任務(wù)調度。

　　第3種，將該資源等待隊列中的一個(gè)任務(wù)喚醒，依據所采用的策略不同，可以是等待任務(wù)中優(yōu)先級最高的，也可以是第1個(gè)進(jìn)入等待隊列中的任務(wù)，這點(diǎn)和第2種方法是一樣的。和第2種情況不同的是，這個(gè)任務(wù)被指定為資源的獲得者。主流實(shí)時(shí)內核VxWorks、Nucleus、uC/OS?II等都采用這種策略。以VxWorks為例，其內核文檔指出[3]：“任務(wù)或ISR調用msgQSend()向消息隊列發(fā)送消息。此時(shí)如果沒(méi)有任務(wù)在等待該隊列中的消息，那么該消息進(jìn)入消息隊列的緩沖；如果有任務(wù)等待該隊列的消息，那么這個(gè)消息立即提交給第1個(gè)等待的任務(wù)?！边@段話(huà)有兩方面的含義：① 明確指出第1個(gè)等待的任務(wù)獲得資源；② 第1個(gè)等待的任務(wù)獲得資源的方式是直接從消息的發(fā)送者那里獲得，也就是說(shuō)這個(gè)消息將不進(jìn)入消息隊列進(jìn)行緩沖，消息在發(fā)送者和接收者之間進(jìn)行手把手的傳遞。對于這種機制的實(shí)現，可以以著(zhù)名的源代碼公開(kāi)的實(shí)時(shí)嵌入式操作系統Nucleus為例。下面是Nucleus內核關(guān)于接收消息的一段精彩的代碼：
else {
　　/* 消息隊列為空，決定是否懸掛等待*/
　　if (suspend) {
　　　　/* 增加等待該消息隊列的任務(wù)數量 */
　　　　queue -> qu_tasks_waiting++;
　　　　/* 填充懸掛塊數據結構并且懸掛該任務(wù)*/
　　　　suspend_ptr =suspend_block;
　　　　suspend_ptr -> qu_queue=queue;
　　　　suspend_ptr -> qu_suspend_link.cs_next=NU_NULL;
　　　　suspend_ptr -> qu_suspend_link.cs_previous=NU_NULL;
　　　　suspend_ptr -> qu_message_area=
　　　　　　　　　　　　　　(UNSIGNED_PTR) message;
　　　　suspend_ptr -> qu_message_size=size;
　　　　task=(TC_TCB *) TCT_Current_Thread();
　　　　suspend_ptr -> qu_suspended_task=task;
　　　　/* 判斷該消息隊列的等待方式是先進(jìn)先出還是按任務(wù)
　　　　的優(yōu)先級 */
　　　　if (queue -> qu_fifo_suspend) {
　　　　　　/* 是先進(jìn)先出等待方式，將懸掛塊鏈入消息隊列
　　　　　　的等待鏈表 */
　　　　　　CSC_Place_On_List((CS_NODE **)
　　　　　　　　　　(queue -> qu_suspension_list),
　　　　　　　　　　(suspend_ptr -> qu_suspend_link));
　　　　}
　　　　else {
　　　　　　/* 按優(yōu)先級方式將懸掛塊鏈入任務(wù)等待鏈表的
　　　　　　合適位置 */
　　　　　　suspend_ptr -> qu_suspend_link.cs_priority =
　　　　　　　　　　　　　　TCC_Task_Priority(task);
　　　　　　CSC_Priority_Place_On_List((CS_NODE **)
　　　　　　　　　　　　(queue -> qu_suspension_list),
　　　　　　　　　　　　(suspend_ptr -> qu_suspend_link));
　　　　}
　　　　/* 懸掛調用任務(wù)，并自動(dòng)取消該消息隊列的臨界區
　　　　保護 */
　　　　TCC_Suspend_Task((NU_TASK *) task,
　　　　　　　　　　　　NU_QUEUE_SUSPEND,
　　　　　　　　　　　　QUC_Cleanup, suspend_ptr, suspend);
　　　　/* 獲取該系統調用要求的返回狀態(tài)以及返回值*/
　　　　status =suspend_ptr -> qu_return_status;
　　　　*actual_size =suspend_ptr -> qu_actual_size;
　　　　}
　　　　else
　　　　/* 在消息隊列為空以及不等待的方式下，返回狀態(tài)
　　　　指示消息隊列為空*/
　　　　status =NU_QUEUE_EMPTY;
}

　　這段代碼是處理消息隊列中沒(méi)有消息時(shí)的情況的，并且在不進(jìn)行懸掛等待時(shí)返回碼是NU_QUEUE_EMPTY，提示隊列為空。我們注意到在選擇懸掛等待的情況下，填充了suspend_ptr指針所指的一個(gè)懸掛塊結構，suspend_ptr -> qu_message_area填充的是接收任務(wù)指定的接收緩沖區指針，suspend_ptr -> qu_message_size填充的是接收任務(wù)指定的接收消息長(cháng)度。接下來(lái)依據不同的等待策略（任務(wù)優(yōu)先級或FIFO）,將填充好的消息隊列懸掛塊鏈入該消息隊列的懸掛等待鏈表中，進(jìn)行任務(wù)調度。正是有了這個(gè)消息隊列懸掛塊數據結構，將來(lái)發(fā)送消息的任務(wù)依據這個(gè)懸掛塊中指定的接收消息緩沖區指針，把消息從發(fā)送任務(wù)直接復制到接收任務(wù)。當接收消息的任務(wù)被喚醒并獲得執行權后，只是簡(jiǎn)單地依據懸掛塊中的相關(guān)域的內容返回系統調用而已。從上述分析可以看出，懸掛塊數據結構起著(zhù)重要的作用，它不僅標明了是哪個(gè)任務(wù)在等待，也標明了等待任務(wù)的一些詳細信息，同時(shí)也有結果狀態(tài)域。通過(guò)對Nucleus內核定時(shí)器機制的分析得知，在任務(wù)等待資源超時(shí)的情況下，懸掛等待塊的結果狀態(tài)域將被填充N(xiāo)U_TIMEOUT。

2 針對Small RTOS51消息隊列的分析

　　有了上述三種模型的分析，很容易看出Small RTOS51V1.12.1版消息隊列所采用的是第2種模型，只是在實(shí)現時(shí)出現重大遺漏，被喚醒的任務(wù)沒(méi)有競爭到資源時(shí)應重新進(jìn)入等待表，而其內核代碼卻沒(méi)有體現到這一點(diǎn)。這一點(diǎn)《Small RTOS51中消息隊列的一處隱患》的作者已經(jīng)分析得很清楚，其提出的第1種解決方案也很正確。重點(diǎn)是第2種解決方案。第2種解決方案屬于第3種模型，但其實(shí)現技術(shù)欠佳。正如原文作者所指出的那樣，第2種方案具有其自身不可調和的矛盾：“在發(fā)送消息的OSQIntPost（）函數中，如果檢測到有任務(wù)正在等待此消息，則并不把消息數(buf[0])加1”，但這個(gè)消息畢竟進(jìn)入消息隊列了，這就造成了一種矛盾狀態(tài)，消息數與消息隊列中的實(shí)際消息不相符。為了實(shí)現第3種模型的效果，即被喚醒的等待任務(wù)獲取資源，在消息數為0的情況下，原文作者通過(guò)進(jìn)一步判斷該任務(wù)是否還處在消息隊列的等待任務(wù)表中，來(lái)決定該任務(wù)是否從消息隊列中獲取消息；但消息數為0而消息隊列中還有消息卻為發(fā)送消息帶來(lái)隱患。要想解決這一矛盾，OSQIntPost（）在喚醒等待任務(wù)的同時(shí)就應該將該消息傳遞給這個(gè)任務(wù)，這樣消息數仍然為0才不留隱患。uC/OS?II實(shí)現這一策略的技術(shù)是任務(wù)被喚醒后檢查任務(wù)控制塊中的OSTCBCur->OSTCBMsg這一數據域[4,5]，獲取到的消息指針在此。注意,OSQPost（）在有等待任務(wù)的情況下,如下處理：
　　if (pevent->OSEventGrp != 0x00) { /* 判斷是否有任務(wù)懸掛在消息隊列的等待表中　　　　　　　　　　　　*/28OS_EventTaskRdy(pevent, msg,OS_STAT_Q); /*將等待表中最高優(yōu)先級任務(wù)喚醒*/
　　　　OS_EXIT_CRITICAL();
　　　　OS_Sched(); /* 進(jìn)行任務(wù)調度，運行最高優(yōu)先級任務(wù)*/
　　　　return (OS_NO_ERR);
　　}

　　即消息指針沒(méi)有進(jìn)消息隊列并且消息指針通過(guò)OS_EventTaskRdy(pevent, msg, OS_STAT_Q)傳給被喚醒的任務(wù)。這一作法符合第3種模型。

　　由此可見(jiàn)，Small RTOS51V1.12.1要想實(shí)現第3種模型，其內核的數據結構需要有一些變化，像原文第2種方案那樣修改代碼，是不能最終解決問(wèn)題的。同Nucleus相比，實(shí)現消息隊列時(shí)，uC/OS?II雖然沒(méi)有引入懸掛等待塊的概念，但其通過(guò)在任務(wù)控制塊中引入相應數據項來(lái)最終實(shí)現第3種模型，并且結果是在任務(wù)被喚醒后進(jìn)行判斷的。

3 結論

　　雖然各種各樣的實(shí)時(shí)嵌入式操作系統千差萬(wàn)別，但從操作系統理論的角度分析,很容易將它們納入到某一具體的模型;實(shí)現細節有很大的不同，但其實(shí)現的功能應符合通用原理。在操作系統理論的指導下，結合具體的實(shí)例源代碼分析、理解和應用，才能有更大的把握。

　　　　　　　　　　　　　　　　　參考文獻

1 陳皓. Small RTOS51中消息隊列的一處隱患. 單片機與嵌入式系統應用，2005(7)
2 Jim Mauro,Richard McDougall.Solaris內核結構.北京：機械工業(yè)出版社，2001
3 孔祥營(yíng),等. 嵌入式實(shí)時(shí)操作系統VxWorks及其開(kāi)發(fā)環(huán)境Tornado. 北京：中國電力出版社，2001
4 Labrosse Jean J.uC/OS?II――源碼公開(kāi)的實(shí)時(shí)嵌入式操作系統.北京：中國電力出版社，2001
5 Labrosse Jean J.嵌入式實(shí)時(shí)操作系統uC/OS?II.北京：北京航空航天大學(xué)出版社，2003

韓明峰：碩士，主要研究方向為實(shí)時(shí)嵌入式系統。