|
Small RTOS51是一款重要的小型實時內核，消息隊列是其提供的重要任務間通信的機制。針對其消息隊列實現代碼中的缺陷以及可能導致的消息丟失這一嚴重問題，從操作系統等待與喚醒機制理論的角度出發，剖析Small RTOS51內核在消息隊列甚至互斥型信號量等實現機制上的漏洞所在；進一步指出原內核實現方式的修改方法，以及《Small RTOS51中消息隊列的一處隱患》作者提出的第2種修改方法的完美實現。 貴刊2005年第7期《Small RTOS51中消息隊列的一處隱患》一文，對Small RTOS51V1.12.1版本的消息隊列機制進行了周密的分析，不但找出了問題所在，也提出了相應的兩種解決方法。實時嵌入式系統對于安全性有很高的要求，作為實時嵌入式系統的內核，不但要求精簡高效，更要加強安全，防止因操作系統出錯而在應用領域導致災難性的后果。因此原文作者所做的工作極有價值，同時也感謝貴刊對這一領域的高度重視。 因為這一問題涉及到內核的等待與喚醒機制，并且正是由于對內核的等待與喚醒機制的理解與運用不同，才導致了問題的出現，所以本文從操作系統理論的高度以及目前主流的實時內核的實現方法兩方面入手論述這一問題，并揭示如何才能完美實現原文的第2種方法。 1 內核喚醒機制的三種模型 當利用系統調用接口獲取資源時，如果資源不滿足，系統調用可以返回錯誤，也可以根據選項懸掛等待；當有任務釋放資源從而資源可以滿足時，就要將資源等待隊列中的相關任務喚醒。喚醒模型有三種： 第1種，將該資源等待隊列中的任務全部喚醒，讓這些任務與系統中的其他任務平等竟爭資源。這種策略會使系統在一段時間內繁忙，因為最終只有一個任務獲取到資源，其他任務可能將經歷一個從就緒態到運行態再到阻塞態的過程。這種現象在操作系統理論上稱為“千軍萬馬奔騰”。就目前的一些主流實時內核VxWorks、Nucleus、uC/OS II等來講，都沒有采用這種策略。 第2種，將該資源等待隊列中的一個任務喚醒，依據所采用的策略不同，可以是等待任務中優先級最高的，也可以是第1個進入等待隊列中的任務。這個任務被喚醒后將和系統中的其他任務一起競爭這個資源。如果這個任務最終沒有競爭到這個資源，它將再次進入該資源的等待隊列并進行任務調度。 第3種，將該資源等待隊列中的一個任務喚醒，依據所采用的策略不同，可以是等待任務中優先級最高的，也可以是第1個進入等待隊列中的任務，這點和第2種方法是一樣的。和第2種情況不同的是，這個任務被指定為資源的獲得者。主流實時內核VxWorks、Nucleus、uC/OS?II等都采用這種策略。以VxWorks為例，其內核文檔指出：“任務或ISR調用msgQSend()向消息隊列發送消息。此時如果沒有任務在等待該隊列中的消息，那么該消息進入消息隊列的緩沖；如果有任務等待該隊列的消息，那么這個消息立即提交給第1個等待的任務。”這段話有兩方面的含義：① 明確指出第1個等待的任務獲得資源；② 第1個等待的任務獲得資源的方式是直接從消息的發送者那里獲得，也就是說這個消息將不進入消息隊列進行緩沖，消息在發送者和接收者之間進行手把手的傳遞。對于這種機制的實現，可以以著名的源代碼公開的實時嵌入式操作系統Nucleus為例。下面是Nucleus內核關于接收消息的一段精彩的代碼： else { /* 消息隊列為空，決定是否懸掛等待*/ if (suspend) { /* 增加等待該消息隊列的任務數量 */ queue -> qu_tasks_waiting++; /* 填充懸掛塊數據結構并且懸掛該任務*/ suspend_ptr =%26;amp;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; /* 判斷該消息隊列的等待方式是先進先出還是按任務 的優先級 */ if (queue -> qu_fifo_suspend) { /* 是先進先出等待方式，將懸掛塊鏈入消息隊列 的等待鏈表 */ CSC_Place_On_List((CS_NODE **) %26;amp;(queue -> qu_suspension_list), %26;amp;(suspend_ptr -> qu_suspend_link)); } else { /* 按優先級方式將懸掛塊鏈入任務等待鏈表的 合適位置 */ suspend_ptr -> qu_suspend_link.cs_priority = TCC_Task_Priority(task); CSC_Priority_Place_On_List((CS_NODE **) %26;amp;(queue -> qu_suspension_list), %26;amp;(suspend_ptr -> qu_suspend_link)); } /* 懸掛調用任務，并自動取消該消息隊列的臨界區 保護 */ TCC_Suspend_Task((NU_TASK *) task, NU_QUEUE_SUSPEND, QUC_Cleanup, suspend_ptr, suspend); /* 獲取該系統調用要求的返回狀態以及返回值*/ status =suspend_ptr -> qu_return_status; *actual_size =suspend_ptr -> qu_actual_size; } else /* 在消息隊列為空以及不等待的方式下，返回狀態 指示消息隊列為空*/ status =NU_QUEUE_EMPTY; } 這段代碼是處理消息隊列中沒有消息時的情況的，并且在不進行懸掛等待時返回碼是NU_QUEUE_EMPTY，提示隊列為空。我們注意到在選擇懸掛等待的情況下，填充了suspend_ptr指針所指的一個懸掛塊結構，suspend_ptr -> qu_message_area填充的是接收任務指定的接收緩沖區指針，suspend_ptr -> qu_message_size填充的是接收任務指定的接收消息長度。接下來依據不同的等待策略（任務優先級或FIFO）,將填充好的消息隊列懸掛塊鏈入該消息隊列的懸掛等待鏈表中，進行任務調度。正是有了這個消息隊列懸掛塊數據結構，將來發送消息的任務依據這個懸掛塊中指定的接收消息緩沖區指針，把消息從發送任務直接復制到接收任務。當接收消息的任務被喚醒并獲得執行權后，只是簡單地依據懸掛塊中的相關域的內容返回系統調用而已。從上述分析可以看出，懸掛塊數據結構起著重要的作用，它不僅標明了是哪個任務在等待，也標明了等待任務的一些詳細信息，同時也有結果狀態域。通過對Nucleus內核定時器機制的分析得知，在任務等待資源超時的情況下，懸掛等待塊的結果狀態域將被填充NU_TIMEOUT。 2 針對Small RTOS51消息隊列的分析 有了上述三種模型的分析，很容易看出Small RTOS51V1.12.1版消息隊列所采用的是第2種模型，只是在實現時出現重大遺漏，被喚醒的任務沒有競爭到資源時應重新進入等待表，而其內核代碼卻沒有體現到這一點。這一點《Small RTOS51中消息隊列的一處隱患》的作者已經分析得很清楚，其提出的第1種解決方案也很正確。重點是第2種解決方案。第2種解決方案屬于第3種模型，但其實現技術欠佳。正如原文作者所指出的那樣，第2種方案具有其自身不可調和的矛盾：“在發送消息的OSQIntPost（）函數中，如果檢測到有任務正在等待此消息，則并不把消息數(buf\[0\])加1”，但這個消息畢竟進入消息隊列了，這就造成了一種矛盾狀態，消息數與消息隊列中的實際消息不相符。為了實現第3種模型的效果，即被喚醒的等待任務獲取資源，在消息數為0的情況下，原文作者通過進一步判斷該任務是否還處在消息隊列的等待任務表中，來決定該任務是否從消息隊列中獲取消息；但消息數為0而消息隊列中還有消息卻為發送消息帶來隱患。要想解決這一矛盾，OSQIntPost（）在喚醒等待任務的同時就應該將該消息傳遞給這個任務，這樣消息數仍然為0才不留隱患。uC/OS II實現這一策略的技術是任務被喚醒后檢查任務控制塊中的OSTCBCur->OSTCBMsg這一數據域，獲取到的消息指針在此。注意,OSQPost（）在有等待任務的情況下,如下處理： if (pevent->OSEventGrp != 0x00) { /* 判斷是否有任務懸掛在消息隊列的等待表中*/28OS_EventTaskRdy(pevent, msg,OS_STAT_Q); /*將等待表中最高優先級任務喚醒*/ OS_EXIT_CRITICAL(); OS_Sched(); /* 進行任務調度，運行最高優先級任務*/ return (OS_NO_ERR); } 即消息指針沒有進消息隊列并且消息指針通過OS_EventTaskRdy(pevent, msg, OS_STAT_Q)傳給被喚醒的任務。這一作法符合第3種模型。 由此可見，Small RTOS51V1.12.1要想實現第3種模型，其內核的數據結構需要有一些變化，像原文第2種方案那樣修改代碼，是不能最終解決問題的。同Nucleus相比，實現消息隊列時，uC/OSII雖然沒有引入懸掛等待塊的概念，但其通過在任務控制塊中引入相應數據項來最終實現第3種模型，并且結果是在任務被喚醒后進行判斷的。 3 結論 雖然各種各樣的實時嵌入式操作系統千差萬別，但從操作系統理論的角度分析,很容易將它們納入到某一具體的模型;實現細節有很大的不同，但其實現的功能應符合通用原理。在操作系統理論的指導下，結合具體的實例源代碼分析、理解和應用，才能有更大的把握。 |
