<dfn id="w48us"></dfn><ul id="w48us"></ul>
  • <ul id="w48us"></ul>
  • <del id="w48us"></del>
    <ul id="w48us"></ul>
  • uC/OS-II內(nèi)核超時等待機制的分析

    時間:2024-06-20 01:57:33 計算機畢業(yè)論文 我要投稿
    • 相關(guān)推薦

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

    畢業(yè)論文

    摘要:本文從源代碼角度了uC/OS-II內(nèi)核超時等待機制,證實在1定情況下超時時間間隔不準(zhǔn)確,在時間間隔到期的情況下,內(nèi)核仍有可能返回成功,這不符合1般的操作系統(tǒng)原理。另外,結(jié)合超時等待機制的通用模型以及1些主流內(nèi)核的實現(xiàn),提出了這1不足之處的改正方法。
    關(guān)鍵詞:超時等待;資源;內(nèi)核

    Analysis of waiting-timeout in kernel

    Abstract:Waiting-timeout of kernel is analyzed from source code in this paper.It indicates waiting-timeout of uC/OS-II is not correst in some case. 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;resource;kernel

    1  引言

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

    2  超時等待機制的基本原理

        應(yīng)用程序通過操作系統(tǒng)提供的系統(tǒng)調(diào)用接口獲取資源時,在系統(tǒng)調(diào)用的入口參數(shù)里可以指定超時等待的最大時間,通常以毫秒為單位,內(nèi)核會將其轉(zhuǎn)化為系統(tǒng)的時鐘滴嗒數(shù)(tick)。1般內(nèi)核都會執(zhí)行以下流程:
        (1)如果資源能馬上獲取,系統(tǒng)調(diào)用將成功返回。
        (2)如果資源不能馬上獲取,內(nèi)核將設(shè)置1定時器進行計時,把當(dāng)前任務(wù)懸掛在該資源的等待隊列上,該任務(wù)從就緒表中刪除,并進行調(diào)度,讓出CPU的使用權(quán)。
        (3)如果在指定的時間內(nèi)資源變得可以獲取了,定時器應(yīng)馬上停止計時,該任務(wù)從等待隊列里摘下并且重新回到就緒表中等候調(diào)度。
        (4)如果定時器到時,任務(wù)應(yīng)該從等待隊列里摘下并且重新回到就緒表中,系統(tǒng)調(diào)用返回超時信息。
        內(nèi)核在每1個tick都會做1系列的工作,包括任務(wù)的延遲以及超時等待資源的定時器等相關(guān)的檢查操作。1般來講,在指定的時間間隔以外到達的資源和信號被認為是無效的,這也是指定超時時間間隔的原意所在,有些對時間要求苛刻的場合就有這種需求,內(nèi)核必須處理好這方面的。

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

    $False$

    3  uC/OS-II內(nèi)核超時等待機制的

        假設(shè)某任務(wù)T超時等待信號量資源R,先來分析時鐘節(jié)拍函數(shù)的源代碼。
        void OSTimeTick(void)
        {
          OS_TCB *ptcb;
          OSTimeTickHook();
          ptcb=OSTCBList;
          while(ptcb->OSTCBPrio!=OS_IDLE_PRIO){
           OS_ENTER_CRITICAL();
           if(ptcb->OSTCBDly!=0){
            if(--ptcb->OSTCBDly==0){
             if(!(ptcb->OSTCBStat&OS_STAT_SUSPEND)){//(1)
             OSRdyGrp|=ptcb->OSTCBBity; //(2)
             OSRdyTbl[ptcb->OSTCBY]|=ptcb->OSTCBBitX;//(3)
             }else   {
            ptcb->OSTCBDly=1;
          }
         }
        }
       ptcb=ptcb->OSTCBNext;
       OS_EXIT_CRITICAL();
      }
      OS_ENTER_CRITICAL();
      OSTime++;
      OS_EXIT_CRITICAL();
     }
        語句(1),(2),(3)表明:時鐘中斷服務(wù)程序在每1個時鐘中斷在需要的情況下對任務(wù)的延遲項進行減1操作,如果任務(wù)T的定時時間間隔到期(延遲項被減為0),并且任務(wù)T沒有附加的掛起操作,任務(wù)T就會進入就緒表,然而該函數(shù)卻沒有進1步將任務(wù)T移出資源R的等待隊列,也就是說此時任務(wù)T跨了兩個狀態(tài),這兩個狀態(tài)從本質(zhì)上講是矛盾的。雖然任務(wù)T此時處于就緒狀態(tài),但未必馬上就能獲得執(zhí)行權(quán),這取決于任務(wù)T的優(yōu)先級。在任務(wù)T沒有被調(diào)度執(zhí)行之前的這段時間內(nèi),假設(shè)資源R到達了,比如1個中斷服務(wù)程序調(diào)用了OSSemPost函數(shù),會是什么情況呢?我們再來分析OSSemPost函數(shù)。
     void OSSemPost(OS_EVENT *pevent)
     {
      OS_ENTER_CRITICAL();
      if(pevent->OSEventGrp!=0x00){
       OS_EventTaskRdy(pevent,(void*)0,OS_STAT_SEM);//(4)
        OS_EXIT_CRITICAL();
        OS_Sched();
        return(OS_NO_ERR);
      }
      if(pevent->OSEventCnt<65535){
       pevent->OSEventCnt++;
       OS_EXIT_CRITICAL();
       return(OS_NO_ERR);
      }
      OS_EXIT_CRITICAL();
      return(OS_SEM_OVF);
       }
      }
        從語句(4)可以看出,在資源R的等待列表中有等待任務(wù)的情況下,等待表中最高優(yōu)先級的任務(wù)將從等待列表中刪除,并且進入就緒表。如果等待表中的最高優(yōu)先級任務(wù)就是前面講的等待超時的任務(wù)T,這相當(dāng)于任務(wù)T又1次進入就緒表,不過只有1次從等待表中刪除。任務(wù)T獲取到了資源,只不過是在超時時間以外獲取到的。任務(wù)T獲得執(zhí)行權(quán)以后從調(diào)度程序返回將運行函數(shù)OSSemPend()語句(6)處的條件代碼,此時語句(5)處的條件不成立,任務(wù)按獲取到資源對待。
     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->OSEventCnt>0){
       pevent->OSEventCnt--;
       OS_EXIT_CRITICAL();
       *err=OS_NO_ERR;
      }else if(OSIntNesting>0){
       OS_EXIT_CRITICAL();
       *err=OS_ERR_PEND_ISR;
      }else{
       OSTCBCur->OSTCBStat|=OS_STAT_SEM;
       OSTCBCur->OSTCBDly=timeout;
       OSEventTaskWait(pevent);
       OS_EXIT_CRITICAL();
       OSSched();
       OS_ENTER_CRITICAL();
       if(OSTCBCur->OSTCBStat&OS_STAT_SEM){ //(5)
        OSEventTo(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->OSEventTbl[OSTCBCur->OSTCBY]&=~OSTCBCur->OSTCBBitX)==0)
     {
     pevent->OSEventGrp&=~OSTCBBitY;
     }
      OSTCBCur->OSTCBStat=OS_STAT_RDY;
    v OSTCBCur->OSTCBEventPtr=(OS_EVENT*0);}
        如果任務(wù)T由于超時進入就緒態(tài),到T獲得執(zhí)行權(quán)之前,仍沒有獲取到資源R,將運行語句(5)處的條件代碼,由函數(shù)OSEventTo()可以看出,此時任務(wù)T才被從等待表中刪除,最后返回超時狀態(tài)。
        通過分析開放源碼的nucleus內(nèi)核,發(fā)現(xiàn)nucleus在超時到期時執(zhí)行定時器的1個回調(diào)函數(shù),此回調(diào)函數(shù)馬上將等待任務(wù)從等待鏈表中刪除,將返回狀態(tài)定性為超時。這樣在任務(wù)獲得執(zhí)行權(quán)前,即使資源到達,該任務(wù)也不會得到。這樣1來,uC/OS-II內(nèi)核只要在時鐘節(jié)拍函數(shù)里增加代碼將延時期滿的任務(wù)從相應(yīng)的資源等待列表中刪除即可。這1工作很容易實現(xiàn),內(nèi)核任務(wù)控制塊有指向所等待的信號量,消息等事件控制塊的指針,事件控制塊里有相應(yīng)的等待表。對于uC/OS-II新引進的事件標(biāo)志組[2],任務(wù)控制塊有指向相應(yīng)的等待節(jié)點的指針,等待節(jié)點有指向相應(yīng)的事件標(biāo)志組控制塊的指針,刪除1個等待節(jié)點也能實現(xiàn)。

    4  結(jié)論

        uC/OS-II其它資源的等待機制,比如消息以及包括2.5.2版引入的事件標(biāo)志組的實現(xiàn)都存在上述的超時時間不嚴格的,這是由中斷節(jié)拍函數(shù)OSTimeTick()決定的,該函數(shù)只負責(zé)將任務(wù)移入就緒表,而不處理相應(yīng)的等待表。


    [1]Labrosse Jean J.uc/OS-II-源碼公開的實時嵌入式操作系統(tǒng)[M].北京:電力出版社,2001.
    [2]Labrosse Jean J. 嵌入式實時操作系統(tǒng)uc/OS-II[M].北京:北京航空航天大學(xué)出版社,2003.

    【uC/OS-II內(nèi)核超時等待機制的分析】相關(guān)文章:

    uC/OS-II在EP7312上的移植03-18

    uC/OS-II在配電監(jiān)測終端儀表中的應(yīng)用03-18

    uC/OS-II的任務(wù)切換機理及中斷調(diào)度優(yōu)化03-20

    uC/OS-II任務(wù)棧處理的一種改進方法03-18

    使用uC/OS-II操作系統(tǒng)的短信息電話機03-18

    水泥混凝土引起超時緩凝的現(xiàn)象及原因分析03-14

    運用UML分析設(shè)計占先式實時內(nèi)核03-18

    MFC中消息映射機制分析03-18

    RPR與SDH保護機制的對比分析03-20

    主站蜘蛛池模板: 国内精品视频在线观看| 精品国产午夜福利在线观看| 99精品欧美一区二区三区| 亚洲精品国产精品乱码在线观看| …久久精品99久久香蕉国产| 伊人久久大香线蕉精品不卡| 成人国产精品一区二区视频| 国产在线精品一区二区在线观看| 免费精品精品国产欧美在线欧美高清免费一级在线| 99久久久国产精品免费无卡顿| 午夜三级国产精品理论三级 | 久久久精品无码专区不卡| 国产精品嫩草影院AV| 尤物yw午夜国产精品视频| 精品久久久久一区二区三区| 精品久久久久久综合日本| 久久精品午夜一区二区福利| 欧美日韩成人精品久久久免费看| 87国产私拍福利精品视频| 精品成人免费自拍视频| 亚洲欧美日韩久久精品第一区| 久久久久久噜噜精品免费直播| 国产精品久久久久久久久久免费| 国产高清在线精品二区一| 亚洲av永久无码精品国产精品| 欧美日韩精品系列一区二区三区| 国产精品色视频ⅹxxx | 色综合久久综精品| 97热久久免费频精品99| 麻豆aⅴ精品无码一区二区| 亚洲精品97久久中文字幕无码| 国模精品一区二区三区| 国产高清日韩精品欧美激情| 四虎精品影院4hutv四虎| 久久99热这里只有精品国产| 欧美精品人爱c欧美精品| 91探花福利精品国产自产在线 | 国产精品VA在线观看无码不卡| 久久夜色精品国产噜噜噜亚洲AV | 国产高清精品在线| 四虎精品成人免费永久|