μC/OS－ll中任務調度算法的改進

時間：2007-01-21 22:35:00

關鍵字：調度算法 OS BSP 程序員

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]μC/OS－ll中任務調度算法的改進

摘要：介紹μC／OS—II嵌入式實時操作系統(tǒng)的特點，分析單一的基于優(yōu)先級調度算法存在的不足。根據嵌入式應用不同的實時性要求，將應用劃分為實時任務、分時任務和后臺任務三種類型。針對分時任務，新增加時間片調度算法，給出調度算法的實現(xiàn)方法，同時增加任務創(chuàng)建和銷毀的接口；降低基于μC／OS—1I操作系統(tǒng)的嵌入式產品開發(fā)難度和設計成本，有利于該操作系統(tǒng)的應用推廣。

關鍵詞：μC／OS—II 嵌入式系統(tǒng) 任務調度算法時間片調度

引言

目前，操作系統(tǒng)內核的軟件中，μC，0S-II稱得上是小型實時操作系統(tǒng)。它由Jean J．Labrosse于1992年推出第l版，立刻在嵌入式系統(tǒng)領域引起強烈反響。μC／OS II是一個基于搶占式的實時多任務內核，可固化、可剪裁、具有高穩(wěn)定性和可靠性。它最鮮明特點就是源碼公開，便于移植和維護，而且對于學校研究完全免費，只有在應用于盈利項目時才需要支付少量的版權費，特別適合一般使用者的學習、研究和開發(fā)。自問世以來，其穩(wěn)定性和可靠性得到了廣泛的認可，現(xiàn)已經通過美國FAA認證。在嵌入式領域，μc／OS憑借優(yōu)越特性得到了越來越廣泛的應用，眾多的研究開發(fā)者將其作為操作系統(tǒng)的樣板，移植到各種硬件平臺，其外圍的應用也越來越多。

1 μC／0S在嵌入式產品應用中存在的問題

隨著移動通信、信息家電以及工業(yè)控制等領域的快速發(fā)展，嵌入式軟件產業(yè)迎來了極佳的發(fā)展時機。強勁的市場需求帶來了研發(fā)的快速增長，越來越多的軟件公司投入到嵌入式產品的研發(fā)中。但另一方面，大部分軟件公司卻缺乏嵌入式操作系統(tǒng)這個嵌入式產品的核心技術，無法提供給各種應用多任務等現(xiàn)代操作系統(tǒng)所必備的功能，極大地限制了產品的性能和發(fā)展。μC／OS具有源碼公開，商業(yè)授權費極低等特點，成為嵌入式產品開發(fā)的一種選擇。

μC／OS—II在設計時強調實時性。它采用單一的基于優(yōu)先級的搶先式調度算法，有效地保證了實時性的要求。在各種嵌入式操作系統(tǒng)中，其任務切換帶來的時延窗口很小。非常適合強實時性的任務要求，但是對于大部分周期性和實時性要求不高的任務來說，μC／O一II還存在一些不足：

①缺乏時間片調度，低優(yōu)先級的任務很難得到執(zhí)行。μC／OS—II不支持時間片調度，優(yōu)先級高的任務如果不主動放棄CPU，低優(yōu)先級任務永遠都不可能運行。這對于那些分別編寫，但叉可能同時運行的任務來說，只能通過任務之間的同步等動作來完成交替運行。這不但增加了編程難度，而且破壞了模塊的獨立性。

②任務創(chuàng)建和銷毀的接口復雜。μC／OS—ll的上層軟件開發(fā)需要關心底層具體實現(xiàn)，接口比較復雜。對于經驗不多的程序員來說，第一，創(chuàng)建任務時需要用戶自行指定優(yōu)先級。這必然牽涉到如何管理分配優(yōu)先級的問題。第二，μC／OS—II中任務的?？臻g完全由用戶管理，系統(tǒng)只是簡單地要求用戶創(chuàng)建任務時傳人棧地址，而不參與?？臻g的申請和釋放。為了簡化μC／OS的示例程序，更是簡單地以靜態(tài)數(shù)組作為任務棧。?？臻g的放任自流在帶來一定靈活性的同時也會帶來問題的隱患。第三，因為μC／OS—II規(guī)定任務必須為無限循環(huán)或自銷毀形式，所以其任務在結束時，需要手工調用OSTaskDel，使該任務進入睡眠態(tài)，不能簡單地返回。與現(xiàn)在流行的大多數(shù)操作系統(tǒng)用法差異較大。

結合國內的產業(yè)現(xiàn)狀，從程序員素質和應用程序的實時性分類，在數(shù)量上都呈現(xiàn)金字塔狀；而且往往是高級程序員負責開發(fā)實時應用，普通程序員開發(fā)非實時應用。如果希望能在包括數(shù)目龐大的非實時應用的產品中利用μC／OS—II，則必須對它作出擴充，在保留實時任務支持的前提下，增添時間片調度，并對任務的接口作出簡化處理。

2 μC／OS調度算法的改進

μC／OS中的每個任務具有一個任務控制塊0S_TCB，任務控制塊記錄任務執(zhí)行的環(huán)境，包括任務的優(yōu)先級、任務的堆棧指針、任務的相關事件控制塊指針等。內核將系統(tǒng)中處于就緒態(tài)的任務在就緒表中進行標注，通過就緒表中的兩個變量OSRdyGrp和OSRdyTbl[]可快速查找系統(tǒng)中就緒的任務。在μC／OS—II中每個任務有唯一的優(yōu)先級，因此任務的優(yōu)先級也是任務的唯一標識。內核可用控制塊優(yōu)先級表OSTCBPrioTbl[]通過任務的優(yōu)先級查到任務控制塊的地址。μC／OS—II主要就是利用任務控制快OS_TCB、就緒表和控制塊優(yōu)先級表0STCBPrioTbl[]來進行任務調度。任務調度程序OSSched()首先由就緒表中找到當前系統(tǒng)中處于就緒態(tài)的優(yōu)先級最高的任務，然后根據其優(yōu)先級由控制塊優(yōu)先級表0STCBPrioTbl[]取得相應任務控制塊的地址，由OS_TASK—SW()程序進行運行環(huán)境的切換。若在任務運行時發(fā)生中斷，則轉向執(zhí)行中斷程序，執(zhí)行完畢后不是簡單地返回中斷調用處，而是由OSIntExit()程序進行任務調度，執(zhí)行當前系統(tǒng)中優(yōu)先級最高的就緒態(tài)任務。

本文擬在不破壞μC／OS實時性的前提下，增加時間片調度，以適于非實時性場合，并參考Windows和Linux多種通用操作系統(tǒng)任務調用接口函數(shù)，對μC／0S任務接口作出改進，提供通用簡單的編程接口,降低應用軟件開發(fā)難度，增加系統(tǒng)穩(wěn)定性和可靠性。

2.1 時間片調度算法的設計與實現(xiàn)

μC／OS中共有64個任務，其中作者保留了8個任務以備將來使用，因此用戶可以有多達56個應用任務。將這些任務劃分為3個層次，如圖l所示。

實時任務保留原本設計的絕對優(yōu)先級調度，對系統(tǒng)驅動或通信等實時性要求高的場合提供支持，任務的創(chuàng)建接口保持不變，由高級程序員編寫相應程序；在分時任務空間采用時間片調度，各種任務輪流執(zhí)行，適用于事務性處理或實時性要求不高的場合，普通程序員在此區(qū)間內編寫任務，并對此空間任務的創(chuàng)建和銷毀提供了新的編程接口，使之適合普通程序員的編程習慣；后臺任務是指idle任務、統(tǒng)計任務等在系統(tǒng)空閑時運行的任務，其在實時任務和分時任務都沒有就緒時才有機會運行，此區(qū)間也采用絕對優(yōu)先級調度。

分時任務在μC／OS原先的五種狀態(tài)中添加了等待態(tài)，定義為OS_STAT_WAITSLICE，表示正在等待時間片的重新產生。增添新狀態(tài)后的狀態(tài)遷移如圖2所示。

其中睡眠態(tài)(dormant)異于多數(shù)操作系統(tǒng)的定義，是指任務駐留在程序空間之中，還沒有交給μC／OS—II管理。所有任務開始于睡眠態(tài)，通過調用任務創(chuàng)立函數(shù)把任務交給μC／0S—II。當任務一旦建立，就進入就緒態(tài)準備運行。在任務銷毀時，可以通過調用OSTaskDel()返回到睡眠態(tài)。其余阻塞態(tài)、就緒態(tài)、運行態(tài)和中斷態(tài)較常見，這里不再詳述，可以參考文獻[1]第3章。

圖2中，如果處于運行態(tài)的任務時間片消耗完畢，則該任務進入等待狀態(tài) 如果全部分時任務都進入等待狀態(tài)，則系統(tǒng)會為其全部重新分配時間片，并使它們都返回就緒態(tài)。除此之外，其余狀態(tài)關系與μC／0S—Il相同。

為了實現(xiàn)分時任務時間片調度算法，首先在OS_TCB結構中添加OSTCBTimeSlices，以存儲任務剩余的時間片數(shù)；同時定義OS-NORMAL_PRIO_START和OS_NOR-MAL_PRIO_START，表示分時任務區(qū)間的大小；還必須修改μC／0S的時鐘服務程序，即函數(shù)OSTimeTick()，來處理與時鐘相關的任務狀態(tài)。修改后處理流程如圖3所示。

圖3中，模塊②之前的流程與在μC／()S—II中幾乎完全相同，主要負責對所有任務時延值的處理。模塊②判斷處于就緒態(tài)的分時任務是否時間片用完，如是，則將其設置為等待態(tài)。模塊③查出就緒的最高優(yōu)先級任務。如果低于分時任務區(qū)間，說明沒有分時任務或所有的分時任務都處于等待態(tài)，此時為所有的分時任務重新分配新的時間片，并將其變更為就緒態(tài)。模塊④中，如果當前任務是分時任務，則說明該任務已經消耗了一個時間片，將該任務時間片減1。

從改進后的處理流程可以看出，實時任務優(yōu)先級高，調度不受影響，不會進入新加入的部分；分時任務在運行態(tài)時，其時間片會不停減少，直到剩余時間片為零，則進入等待態(tài)。當系統(tǒng)的所有分時任務都進入了等待態(tài)，則對在等待態(tài)的分時任務重新計算剩余時間片，并把它們都設為就緒態(tài)，則新的一輪分時任務交替運行又開始了。所有的后臺任務的調度也不受影響。

OSTimeTick處理十分頻繁，必須盡可能地減少運算開銷，改進方案對其增加分時任務的處理。在有實時任務運行時，延時基本沒有增加；只有在所有分時任務都進入等待態(tài)后，才會有較大的計算量，經試驗效果良好。

2.2 任務接口的改進

為了簡化應用編程接口，屏蔽低層任務管理細節(jié)，為用戶提供新的任務接口OSNTaskCreate和OSNTaskDel。0SNTaskCreate用于創(chuàng)建分時任務，該函數(shù)在分時區(qū)間自動分配優(yōu)先級，代替用戶申請棧空間，并在初始化棧內容時壓人OSNTaskDel地址。在用戶任務退出后，就會自動調用()SNTaskDel，以釋放?？臻g，并調用()STaskDel。如此更符合用戶在Windows等系統(tǒng)的情況，任務結束后只是簡單返回，減小了錯誤出現(xiàn)的機會。改進后的OSNTaskCreate偽碼如下：