<delect id="sj01t"></delect>
  1. <em id="sj01t"><label id="sj01t"></label></em>
  2. <div id="sj01t"></div>
    1. <em id="sj01t"></em>

            <div id="sj01t"></div>

            uC/OS-II內核超時等待機制的分析

            時間:2024-06-20 01:57:33 計算機畢業論文 我要投稿
            • 相關推薦

            uC/OS-II內核超時等待機制的分析

            畢業論文

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

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

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

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

            uC/OS-II內核超時等待機制的分析

            $False$

            3  uC/OS-II內核超時等待機制的

                假設某任務T超時等待信號量資源R,先來分析時鐘節拍函數的源代碼。
                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)表明:時鐘中斷服務程序在每1個時鐘中斷在需要的情況下對任務的延遲項進行減1操作,如果任務T的定時時間間隔到期(延遲項被減為0),并且任務T沒有附加的掛起操作,任務T就會進入就緒表,然而該函數卻沒有進1步將任務T移出資源R的等待隊列,也就是說此時任務T跨了兩個狀態,這兩個狀態從本質上講是矛盾的。雖然任務T此時處于就緒狀態,但未必馬上就能獲得執行權,這取決于任務T的優先級。在任務T沒有被調度執行之前的這段時間內,假設資源R到達了,比如1個中斷服務程序調用了OSSemPost函數,會是什么情況呢?我們再來分析OSSemPost函數。
             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的等待列表中有等待任務的情況下,等待表中最高優先級的任務將從等待列表中刪除,并且進入就緒表。如果等待表中的最高優先級任務就是前面講的等待超時的任務T,這相當于任務T又1次進入就緒表,不過只有1次從等待表中刪除。任務T獲取到了資源,只不過是在超時時間以外獲取到的。任務T獲得執行權以后從調度程序返回將運行函數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->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);}
                如果任務T由于超時進入就緒態,到T獲得執行權之前,仍沒有獲取到資源R,將運行語句(5)處的條件代碼,由函數OSEventTo()可以看出,此時任務T才被從等待表中刪除,最后返回超時狀態。
                通過分析開放源碼的nucleus內核,發現nucleus在超時到期時執行定時器的1個回調函數,此回調函數馬上將等待任務從等待鏈表中刪除,將返回狀態定性為超時。這樣在任務獲得執行權前,即使資源到達,該任務也不會得到。這樣1來,uC/OS-II內核只要在時鐘節拍函數里增加代碼將延時期滿的任務從相應的資源等待列表中刪除即可。這1工作很容易實現,內核任務控制塊有指向所等待的信號量,消息等事件控制塊的指針,事件控制塊里有相應的等待表。對于uC/OS-II新引進的事件標志組[2],任務控制塊有指向相應的等待節點的指針,等待節點有指向相應的事件標志組控制塊的指針,刪除1個等待節點也能實現。

            4  結論

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


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

            【uC/OS-II內核超時等待機制的分析】相關文章:

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

            uC/OS-II在配電監測終端儀表中的應用03-18

            uC/OS-II的任務切換機理及中斷調度優化03-20

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

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

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

            運用UML分析設計占先式實時內核03-18

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

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

            <delect id="sj01t"></delect>
            1. <em id="sj01t"><label id="sj01t"></label></em>
            2. <div id="sj01t"></div>
              1. <em id="sj01t"></em>

                      <div id="sj01t"></div>
                      黄色视频在线观看