當(dāng)前位置:首頁 > 嵌入式 > 嵌入式硬件
[導(dǎo)讀]摘要:Small RTOS51是一款重要的小型實時內(nèi)核,消息隊列是其提供的重要任務(wù)間通信的機制。針對其消息隊列實現(xiàn)代碼中的缺陷以及可能導(dǎo)致的消息丟失這一嚴(yán)重問題,從操作系統(tǒng)

摘要:Small RTOS51是一款重要的小型實時內(nèi)核,消息隊列是其提供的重要任務(wù)間通信的機制。針對其消息隊列實現(xiàn)代碼中的缺陷以及可能導(dǎo)致的消息丟失這一嚴(yán)重問題,從操作系統(tǒng)等待與喚醒機制理論的角度出發(fā),剖析Small RTOS51內(nèi)核在消息隊列甚至互斥型信號量等實現(xiàn)機制上的漏洞所在;進一步指出原內(nèi)核實現(xiàn)方式的修改方法,以及《Small RTOS51中消息隊列的一處隱患》作者提出的第2種修改方法的完美實現(xiàn)。 關(guān)鍵詞:Small RTOS51 消息隊列 喚醒模型 隱患分析 引言   貴刊2005年第7期《Small RTOS51中消息隊列的一處隱患》一文,對Small RTOS51V1.12.1版本的消息隊列機制進行了周密的分析,不但找出了問題所在,也提出了相應(yīng)的兩種解決方法\[1\]。實時嵌入式系統(tǒng)對于安全性有很高的要求,作為實時嵌入式系統(tǒng)的內(nèi)核,不但要求精簡高效,更要加強安全,防止因操作系統(tǒng)出錯而在應(yīng)用領(lǐng)域?qū)е聻?zāi)難性的后果。因此原文作者所做的工作極有價值,同時也感謝貴刊對這一領(lǐng)域的高度重視。   因為這一問題涉及到內(nèi)核的等待與喚醒機制,并且正是由于對內(nèi)核的等待與喚醒機制的理解與運用不同,才導(dǎo)致了問題的出現(xiàn),所以本文從操作系統(tǒng)理論的高度以及目前主流的實時內(nèi)核的實現(xiàn)方法兩方面入手論述這一問題,并揭示如何才能完美實現(xiàn)原文的第2種方法。 1 內(nèi)核喚醒機制的三種模型   當(dāng)利用系統(tǒng)調(diào)用接口獲取資源時,如果資源不滿足,系統(tǒng)調(diào)用可以返回錯誤,也可以根據(jù)選項懸掛等待;當(dāng)有任務(wù)釋放資源從而資源可以滿足時,就要將資源等待隊列中的相關(guān)任務(wù)喚醒。喚醒模型有三種\[2\]:第1種,將該資源等待隊列中的任務(wù)全部喚醒,讓這些任務(wù)與系統(tǒng)中的其他任務(wù)平等竟?fàn)庂Y源。這種策略會使系統(tǒng)在一段時間內(nèi)繁忙,因為最終只有一個任務(wù)獲取到資源,其他任務(wù)可能將經(jīng)歷一個從就緒態(tài)到運行態(tài)再到阻塞態(tài)的過程。這種現(xiàn)象在操作系統(tǒng)理論上稱為“千軍萬馬奔騰”。就目前的一些主流實時內(nèi)核 VxWorks、Nucleus、uC/OS?II等來講,都沒有采用這種策略。   第2種,將該資源等待隊列中的一個任務(wù)喚醒,依據(jù)所采用的策略不同,可以是等待任務(wù)中優(yōu)先級最高的,也可以是第1個進入等待隊列中的任務(wù)。這個任務(wù)被喚醒后將和系統(tǒng)中的其他任務(wù)一起競爭這個資源。如果這個任務(wù)最終沒有競爭到這個資源,它將再次進入該資源的等待隊列并進行任務(wù)調(diào)度。   第3種,將該資源等待隊列中的一個任務(wù)喚醒,依據(jù)所采用的策略不同,可以是等待任務(wù)中優(yōu)先級最高的,也可以是第1個進入等待隊列中的任務(wù),這點和第2 種方法是一樣的。和第2種情況不同的是,這個任務(wù)被指定為資源的獲得者。主流實時內(nèi)核VxWorks、Nucleus、uC/OS?II等都采用這種策略。以VxWorks為例,其內(nèi)核文檔指出\[3\]:“任務(wù)或ISR調(diào)用msgQSend()向消息隊列發(fā)送消息。此時如果沒有任務(wù)在等待該隊列中的消息,那么該消息進入消息隊列的緩沖;如果有任務(wù)等待該隊列的消息,那么這個消息立即提交給第1個等待的任務(wù)。”這段話有兩方面的含義:① 明確指出第1個等待的任務(wù)獲得資源;② 第1個等待的任務(wù)獲得資源的方式是直接從消息的發(fā)送者那里獲得,也就是說這個消息將不進入消息隊列進行緩沖,消息在發(fā)送者和接收者之間進行手把手的傳遞。對于這種機制的實現(xiàn),可以以著名的源代碼公開的實時嵌入式操作系統(tǒng)Nucleus為例。下面是Nucleus內(nèi)核關(guān)于接收消息的一段精彩的代碼: else {   /* 消息隊列為空,決定是否懸掛等待*/   if (suspend) {     /* 增加等待該消息隊列的任務(wù)數(shù)量 */     queue -> qu_tasks_waiting++;     /* 填充懸掛塊數(shù)據(jù)結(jié)構(gòu)并且懸掛該任務(wù)*/     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;     /* 判斷該消息隊列的等待方式是先進先出還是按任務(wù)    的優(yōu)先級 */     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 {       /* 按優(yōu)先級方式將懸掛塊鏈入任務(wù)等待鏈表的      合適位置 */       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));     }     /* 懸掛調(diào)用任務(wù),并自動取消該消息隊列的臨界區(qū)    保護 */     TCC_Suspend_Task((NU_TASK *) task,             NU_QUEUE_SUSPEND,             QUC_Cleanup, suspend_ptr, suspend);     /* 獲取該系統(tǒng)調(diào)用要求的返回狀態(tài)以及返回值*/     status =suspend_ptr -> qu_return_status;     *actual_size =suspend_ptr -> qu_actual_size;     }     else     /* 在消息隊列為空以及不等待的方式下,返回狀態(tài)    指示消息隊列為空*/     status =NU_QUEUE_EMPTY; }   這段代碼是處理消息隊列中沒有消息時的情況的,并且在不進行懸掛等待時返回碼是NU_QUEUE_EMPTY,提示隊列為空。我們注意到在選擇懸掛等待的情況下,填充了suspend_ptr指針?biāo)傅囊粋€懸掛塊結(jié)構(gòu),suspend_ptr -> qu_message_area填充的是接收任務(wù)指定的接收緩沖區(qū)指針,suspend_ptr -> qu_message_size填充的是接收任務(wù)指定的接收消息長度。接下來依據(jù)不同的等待策略(任務(wù)優(yōu)先級或FIFO),將填充好的消息隊列懸掛塊鏈入該消息隊列的懸掛等待鏈表中,進行任務(wù)調(diào)度。正是有了這個消息隊列懸掛塊數(shù)據(jù)結(jié)構(gòu),將來發(fā)送消息的任務(wù)依據(jù)這個懸掛塊中指定的接收消息緩沖區(qū)指針,把消息從發(fā)送任務(wù)直接復(fù)制到接收任務(wù)。當(dāng)接收消息的任務(wù)被喚醒并獲得執(zhí)行權(quán)后,只是簡單地依據(jù)懸掛塊中的相關(guān)域的內(nèi)容返回系統(tǒng)調(diào)用而已。從上述分析可以看出,懸掛塊數(shù)據(jù)結(jié)構(gòu)起著重要的作用,它不僅標(biāo)明了是哪個任務(wù)在等待,也標(biāo)明了等待任務(wù)的一些詳細(xì)信息,同時也有結(jié)果狀態(tài)域。通過對Nucleus內(nèi)核定時器機制的分析得知,在任務(wù)等待資源超時的情況下,懸掛等待塊的結(jié)果狀態(tài)域?qū)⒈惶畛銷U_TIMEOUT。 [b] 2 針對Small RTOS51消息隊列的分析[/b]   有了上述三種模型的分析,很容易看出Small RTOS51V1.12.1版消息隊列所采用的是第2種模型,只是在實現(xiàn)時出現(xiàn)重大遺漏,被喚醒的任務(wù)沒有競爭到資源時應(yīng)重新進入等待表,而其內(nèi)核代碼卻沒有體現(xiàn)到這一點。這一點《Small RTOS51中消息隊列的一處隱患》的作者已經(jīng)分析得很清楚,其提出的第1種解決方案也很正確。重點是第2種解決方案。第2種解決方案屬于第3種模型,但其實現(xiàn)技術(shù)欠佳。正如原文作者所指出的那樣,第2種方案具有其自身不可調(diào)和的矛盾:“在發(fā)送消息的OSQIntPost()函數(shù)中,如果檢測到有任務(wù)正在等待此消息,則并不把消息數(shù)(buf\[0\])加1”,但這個消息畢竟進入消息隊列了,這就造成了一種矛盾狀態(tài),消息數(shù)與消息隊列中的實際消息不相符。為了實現(xiàn)第3種模型的效果,即被喚醒的等待任務(wù)獲取資源,在消息數(shù)為0的情況下,原文作者通過進一步判斷該任務(wù)是否還處在消息隊列的等待任務(wù)表中,來決定該任務(wù)是否從消息隊列中獲取消息;但消息數(shù)為0而消息隊列中還有消息卻為發(fā)送消息帶來隱患。要想解決這一矛盾,OSQIntPost()在喚醒等待任務(wù)的同時就應(yīng)該將該消息傳遞給這個任務(wù),這樣消息數(shù)仍然為0才不留隱患。uC/OS?II實現(xiàn)這一策略的技術(shù)是任務(wù)被喚醒后檢查任務(wù)控制塊中的 OSTCBCur->OSTCBMsg這一數(shù)據(jù)域\[4,5\],獲取到的消息指針在此。注意,OSQPost()在有等待任務(wù)的情況下,如下處理:  if (pevent->OSEventGrp != 0x00) { /* 判斷是否有任務(wù)懸掛在消息隊列的等待表中            */28OS_EventTaskRdy(pevent, msg,OS_STAT_Q); /*將等待表中最高優(yōu)先級任務(wù)喚醒*/     OS_EXIT_CRITICAL();     OS_Sched(); /* 進行任務(wù)調(diào)度,運行最高優(yōu)先級任務(wù)*/     return (OS_NO_ERR);   }   即消息指針沒有進消息隊列并且消息指針通過OS_EventTaskRdy(pevent, msg, OS_STAT_Q)傳給被喚醒的任務(wù)。這一作法符合第3種模型。   由此可見,Small RTOS51V1.12.1要想實現(xiàn)第3種模型,其內(nèi)核的數(shù)據(jù)結(jié)構(gòu)需要有一些變化,像原文第2種方案那樣修改代碼,是不能最終解決問題的。同 Nucleus相比,實現(xiàn)消息隊列時,uC/OS?II雖然沒有引入懸掛等待塊的概念,但其通過在任務(wù)控制塊中引入相應(yīng)數(shù)據(jù)項來最終實現(xiàn)第3種模型,并且結(jié)果是在任務(wù)被喚醒后進行判斷的。 3 結(jié)論   雖然各種各樣的實時嵌入式操作系統(tǒng)千差萬別,但從操作系統(tǒng)理論的角度分析,很容易將它們納入到某一具體的模型;實現(xiàn)細(xì)節(jié)有很大的不同,但其實現(xiàn)的功能應(yīng)符合通用原理。在操作系統(tǒng)理論的指導(dǎo)下,結(jié)合具體的實例源代碼分析、理解和應(yīng)用,才能有更大的把握。                  參考文獻 1 陳皓. Small RTOS51中消息隊列的一處隱患. 單片機與嵌入式系統(tǒng)應(yīng)用,2005(7) 2 Jim Mauro,Richard McDougall.Solaris內(nèi)核結(jié)構(gòu).北京:機械工業(yè)出版社,2001 3 孔祥營,等. 嵌入式實時操作系統(tǒng)VxWorks及其開發(fā)環(huán)境Tornado. 北京:中國電力出版社,2001 4 Labrosse Jean J.uC/OS?II——源碼公開的實時嵌入式操作系統(tǒng).北京:中國電力出版社,2001 5 Labrosse Jean J.嵌入式實時操作系統(tǒng)uC/OS?II.北京:北京航空航天大學(xué)出版社,2003 韓明峰:碩士,主要研究方向為實時嵌入式系統(tǒng)。

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉