uCOS-II內(nèi)核超時等待機制的分析

1、uC/OS-II內(nèi)核超時等待機制的分析摘要：本文從源代碼角度分析了uC/OS-II內(nèi)核超時等待機制，證實在一定情況下超時時間間隔不準確，在時間間隔到期的情況下，內(nèi)核仍有可能返回成功，這不符合一般的操作系統(tǒng)原理。另外，結(jié)合超時等待機制的通用模型以及一些主流內(nèi)核的實現(xiàn)方法，提出了這一不足之處的改正方法。關(guān)鍵詞：超時等待；資源；內(nèi)核Analysis of waiting-timeout in kernelAbstract:Waiting-timeout of kernel is analyzed from source code in this paper.It indicates waiting-

2、timeout of uC/OS-II is not correst in some case.The kernel can return success while it is time out.This is not correst.Based on the general type of Waiting-timeout of kernel and the other main real-time kernel ,a method is advanced to resolve this problem in the end.Key words: waiting-timeout;resour

3、ce;kernel 1引言uC/OS-II是著名的源碼公開的實時內(nèi)核1，是專為嵌入式應用設計的，可用于各類8位16位和32位單片機或DSP。現(xiàn)在有很多使用者正在或已經(jīng)將其移植到各種類型的芯片。因為源碼公開，uC/OS-II也經(jīng)常被作為嵌入式實時內(nèi)核的教材，為專業(yè)人員提供了學習實時內(nèi)核的難得機會。在實際使用中不管基于何種操作系統(tǒng)平臺，應用程序經(jīng)常會等待一些系統(tǒng)資源，如信號量，事件標志，消息等。等待類型共有三種：(1)如果不能馬上獲取，懸掛等待；(2)不管是否能獲取資源，馬上返回，不會等待；(3) 如果不能馬上獲取資源，將進行有限時間的等待，即超時等待。2超時等待機制的基本原理應用程序通過操作系統(tǒng)

4、提供的系統(tǒng)調(diào)用接口獲取資源時，在系統(tǒng)調(diào)用的入口參數(shù)里可以指定超時等待的最大時間，通常以毫秒為單位，內(nèi)核會將其轉(zhuǎn)化為系統(tǒng)的時鐘滴嗒數(shù)(tick)。一般內(nèi)核都會執(zhí)行以下流程：(1)如果資源能馬上獲取，系統(tǒng)調(diào)用將成功返回。(2)如果資源不能馬上獲取，內(nèi)核將設置一定時器進行計時，把當前任務懸掛在該資源的等待隊列上，該任務從就緒表中刪除，并進行調(diào)度，讓出CPU的使用權(quán)。(3)如果在指定的時間內(nèi)資源變得可以獲取了，定時器應馬上停止計時，該任務從等待隊列里摘下并且重新回到就緒表中等候調(diào)度。(4)如果定時器到時，任務應該從等待隊列里摘下并且重新回到就緒表中，系統(tǒng)調(diào)用返回超時信息。內(nèi)核在每一個tick都會做一系

5、列的工作，包括任務的延遲以及超時等待資源的定時器等相關(guān)的檢查操作。一般來講，在指定的時間間隔以外到達的資源和信號被認為是無效的，這也是指定超時時間間隔的原意所在，有些對時間要求苛刻的場合就有這種需求，內(nèi)核必須處理好這方面的問題。3uC/OS-II內(nèi)核超時等待機制的分析假設某任務T超時等待信號量資源R，先來分析時鐘節(jié)拍函數(shù)的源代碼。void OSTimeTick(void)OS_TCB *ptcb;OSTimeTickHook();ptcb=OSTCBList;while(ptcb-OSTCBPrio!=OS_IDLE_PRIO)OS_ENTER_CRITICAL();if(ptcb-OSTCB

6、Dly!=0)if(-ptcb-OSTCBDly=0)if(!(ptcb-OSTCBStat&OS_STAT_SUSPEND)/(1)OSRdyGrp|=ptcb-OSTCBBity; /(2)OSRdyTblptcb-OSTCBY|=ptcb-OSTCBBitX;/(3)else ptcb-OSTCBDly=1;ptcb=ptcb-OSTCBNext;OS_EXIT_CRITICAL();OS_ENTER_CRITICAL();OSTime+;OS_EXIT_CRITICAL();語句(1),(2),(3)表明：時鐘中斷服務程序在每一個時鐘中斷在需要的情況下對任務的延遲項進行減1操作，如果任

7、務T的定時時間間隔到期（延遲項被減為0），并且任務T沒有附加的掛起操作，任務T就會進入就緒表，然而該函數(shù)卻沒有進一步將任務T移出資源R的等待隊列，也就是說此時任務T跨了兩個狀態(tài)，這兩個狀態(tài)從本質(zhì)上講是矛盾的。雖然任務T此時處于就緒狀態(tài)，但未必馬上就能獲得執(zhí)行權(quán)，這取決于任務T的優(yōu)先級。在任務T沒有被調(diào)度執(zhí)行之前的這段時間內(nèi)，假設資源R到達了，比如一個中斷服務程序調(diào)用了OSSemPost函數(shù)，會是什么情況呢？我們再來分析OSSemPost函數(shù)。void OSSemPost(OS_EVENT *pevent)OS_ENTER_CRITICAL();if(pevent-OSEventGrp!=0x0

8、0)OS_EventTaskRdy(pevent,(void*)0,OS_STAT_SEM);/(4)OS_EXIT_CRITICAL();OS_Sched();return(OS_NO_ERR);if(pevent-OSEventCntOSEventCnt+;OS_EXIT_CRITICAL();return(OS_NO_ERR);OS_EXIT_CRITICAL();return(OS_SEM_OVF);從語句(4)可以看出，在資源R的等待列表中有等待任務的情況下，等待表中最高優(yōu)先級的任務將從等待列表中刪除，并且進入就緒表。如果等待表中的最高優(yōu)先級任務就是前面講的等待超時的任務T，這相當于

9、任務T又一次進入就緒表，不過只有一次從等待表中刪除。任務T獲取到了資源，只不過是在超時時間以外獲取到的。任務T獲得執(zhí)行權(quán)以后從調(diào)度程序返回將運行函數(shù)OSSemPend()語句(6)處的條件代碼，此時語句(5)處的條件不成立，任務按獲取到資源對待。void OSSemPend(OS_EVENT *pevent,INT16U timeout,INT8U *err)OS_ENTER_CRITICAL();if(pevent-OSEventType!=OS_EVENT_TYPE_SEM)OS_EXIT_CRITICAL();*err=OS_ERR_EVENT_TYPE;if(pevent-OSEven

10、tCnt0)pevent-OSEventCnt-;OS_EXIT_CRITICAL();*err=OS_NO_ERR;else if(OSIntNesting0)OS_EXIT_CRITICAL();*err=OS_ERR_PEND_ISR;elseOSTCBCur-OSTCBStat|=OS_STAT_SEM;OSTCBCur-OSTCBDly=timeout;OSEventTaskWait(pevent);OS_EXIT_CRITICAL();OSSched();OS_ENTER_CRITICAL();if(OSTCBCur-OSTCBStat&OS_STAT_SEM) /(5)OSEve

11、ntTo(pevent);OS_EXIT_CRITICAL();*err=OS_TIMEOUT;else /(6)OSTCBCur-OSTCBEventPtr=(OS_EVENT*0);OS_EXIT_CRITICAL();*err=OS_NO_ERR;void OSEventTo(OS_EVENT *pevent)if(pevent-OSEventTblOSTCBCur-OSTCBY&=OSTCBCur-OSTCBBitX)=0)pevent-OSEventGrp&=OSTCBBitY;OSTCBCur-OSTCBStat=OS_STAT_RDY;vOSTCBCur-OSTCBEventPtr=(OS_EVENT*0);如果任務T由于超時進入就緒態(tài)，到T獲得執(zhí)行權(quán)之前，仍沒有獲取到資源R，將運行語句(5)處的條件代碼，由函數(shù)OSEventTo()可以看出，此時任務T才被從等待表中刪除，最后返回超時狀態(tài)。通過分析開放源碼的nucleus內(nèi)核，發(fā)現(xiàn)nucleus在超時到期時執(zhí)行定時器的一個回調(diào)函數(shù)，此回調(diào)函數(shù)馬上將等待任務從等待鏈表中刪除，將返回狀態(tài)定性為超時。這樣在任務獲得執(zhí)行權(quán)前，即使資源到達，該任務也不會得到。