引言
μC/OS是一個基于優(yōu)先級調(diào)度的可剝奪型實時多任務(wù)內(nèi)核,。在多任務(wù)的實時內(nèi)核中,信號量是常用的機制,,可以用來實現(xiàn)對共享資源的訪問,、任務(wù)之間的通信和同步,以及任務(wù)和中斷的同步等功能,。μC/OS—II中提供了等待和釋放信號量等最基本的服務(wù),,而在μC/OS—III中,對信號量的使用增加了一些可選的模式,,如非阻塞等待,、釋放但不進行任務(wù)調(diào)度等,提高了使用的靈活性,。更重要的是,,在μC/OS—III中還新增了任務(wù)內(nèi)嵌的信號量,用戶程序無需建立信號量便可和任務(wù)直接通信,,比普通信號量更加簡單高效,。本文將分析對比μC/OS—II和μC/OS—III中信號量內(nèi)部結(jié)構(gòu)的差異以及μC/OS—III新增的特性。
1 μC/OS—II中信號量內(nèi)部結(jié)構(gòu)
在μC/OS—II中,信號量直接使用內(nèi)核的數(shù)據(jù)結(jié)構(gòu)OS EVENT,,其內(nèi)部結(jié)構(gòu)如下:
其中,,和信號量相關(guān)的最重要的就是OSEventCnt、OSEventGrp和OSEventTbl[],。OSEventCnt記錄的是信號量的有效值,。OSEventTbl[]是一個位映射表,以64級優(yōu)先級為例,,OSEventTbl[]將是一個8×8的位映射表,,如果某優(yōu)先級下有任務(wù)在等待該事件,則OSEventTbl[]中對應(yīng)的位將被置1,。為了加快查詢過程,,又將64級優(yōu)先級分為8組,用一個8位的整型OSEventGrp來記錄每一組的狀態(tài),??梢姡琌SEventGrp和OSEve ntTbl[]跟就緒表中的OSRdyGrp和OSRdyTbl[]結(jié)構(gòu)是一模一樣的,,區(qū)別僅僅在于前者記錄的是等待該事件的任務(wù)的狀態(tài),而后者記錄的是系統(tǒng)中就緒的任務(wù)的狀態(tài),。而兩者的查找過程是一樣的,,都是通過“掩碼表”來快速得到列表中優(yōu)先級最高的任務(wù)。
μC/OS—II提供的信號量相關(guān)的最常用的幾個API函數(shù)如下:
在使用信號量前必須先新建一個信號量,,并指定其初始值,。當(dāng)信號量用于對共享資源的訪問時,該值應(yīng)初始化為實際可用的共享資源數(shù),;當(dāng)信號量用來實現(xiàn)任務(wù)的同步,,則初始值應(yīng)設(shè)為0。調(diào)用等待信號量的OSSemPend()函數(shù)時可以指定超時選項timeout,,在指定的時間內(nèi)如果沒有獲得信號量則任務(wù)會超時返回,。釋放信號量時,如果有任務(wù)在等待,,內(nèi)核會通過查找OSEventGrp和OSEventTbl[]獲得等待任務(wù)中優(yōu)先級最高的任務(wù),,該任務(wù)將獲得信號量從而轉(zhuǎn)入就緒態(tài),內(nèi)核會進行任務(wù)調(diào)度,。如果獲得信號量的任務(wù)比正在執(zhí)行的任務(wù)優(yōu)先級還高,,則會進行任務(wù)切換。
2 μC/OS-Ⅲ中信號量內(nèi)部結(jié)構(gòu)
在μC/OS—III中,,信號量類型的結(jié)構(gòu)有所變化,,并沒有和μC/OS—II一樣繼續(xù)采用和“就緒表”類似的結(jié)構(gòu),而是采用一個“等待列表”的數(shù)據(jù)結(jié)構(gòu)來記錄等待信號量的任務(wù)。其數(shù)據(jù)結(jié)構(gòu)如下:
從上述結(jié)構(gòu)可以看出,,μC/OS—III的信號量結(jié)構(gòu)中新增了一個時間戳TS,,用來記錄最近一次釋放信號量(或者是取消等待、刪除信號量)的時間,。而等待信號量的任務(wù)列表則通過一個新的數(shù)據(jù)結(jié)構(gòu)OS_PEND_LIST來記錄,,如圖1所示。
OS_PEND_LIST包括3個數(shù)據(jù)域:NbrEntries用來記錄等待列表中的條目數(shù),,也就是等待的任務(wù)數(shù)目,;HeadPtr和TailPtr構(gòu)成一個雙向鏈表,指向的是OS_PEND_DATA類型的結(jié)構(gòu)體,。OS_PEND_DATA是μC/OS—III內(nèi)部的一個數(shù)據(jù)類型,,每當(dāng)任務(wù)因等待信號量而被掛起時,內(nèi)核就會新建一個對應(yīng)的OS_PEND_DATA類型的數(shù)據(jù)塊并插入到信號量的等待列表OS_PEND_LIST所包含的雙向鏈表中,。OS_PEND_DATA結(jié)構(gòu)體包含指向等待任務(wù)的OS_TCB的指針以及其他數(shù)據(jù)域,。在這里,最重要的細節(jié)是,,μC/OS-III是按照任務(wù)優(yōu)先級從高到低的順序來排列雙向鏈表中的OS_PE ND_DATA數(shù)據(jù)塊的,。也就是說,每當(dāng)有一個新的OS_PEND_DATA數(shù)據(jù)塊需要插入到雙向鏈表時(也就是任務(wù)因等待信號量而被掛起時),,內(nèi)核會從鏈表頭部開始掃描各個OSPEND_DATA數(shù)據(jù)塊所對應(yīng)的等待任務(wù)的優(yōu)先級(通過OS_PEND_DATA數(shù)據(jù)塊內(nèi)部的TCBPtr指針可以從任務(wù)控制塊內(nèi)部獲得任務(wù)的優(yōu)先級),,直到找到比當(dāng)前需要插入的任務(wù)的優(yōu)先級低的任務(wù),然后把新的OS PEND_DATA數(shù)據(jù)塊插入到該位置前,。如果鏈表中已有和需要插入的任務(wù)優(yōu)先級相同的任務(wù),,則新插入的任務(wù)放到優(yōu)先級相同的任務(wù)后。道理很簡單,,優(yōu)先級相同,,晚到的任務(wù)沒有任何理由比早到的任務(wù)先獲得信號量?;谏鲜雠帕蟹椒?,位于雙向鏈表頭部的任務(wù)總是等待的任務(wù)中優(yōu)先級最高的。因此,,當(dāng)用戶釋放信號量時,,總是雙向鏈表頭部的任務(wù)獲得信號量,而不必再執(zhí)行“查找最高優(yōu)先級”的過程了,。
μC/OS—III提供的信號量相關(guān)的最常用的幾個API函數(shù)如下:
OSSemCreate()函數(shù)和μC/OS—II中的類似,,需要指定信號量的初始值,還需額外指定信號量的名稱以便于調(diào)試,。
OSSemPend()函數(shù)多了兩個參數(shù):opt和p_ts,。p_ts是指向時間戳的指針,,當(dāng)任務(wù)獲得信號量(或者任務(wù)取消等待或信號量被刪除)返回時,內(nèi)核會把釋放信號量(或者任務(wù)取消等待或信號量被刪除)時刻的時間戳保存到該指針指向的變量中,,該時間戳用戶可以計算從信號量被釋放到實際獲得信號量的時間,。opt參數(shù)用來指定該等待操作是否是阻塞的。在μC/OS—II中,,當(dāng)用戶對信號量執(zhí)行Pend操作而信號量無效時任務(wù)會被掛起,,而μC/OS—III通過opt參數(shù)支持以“非阻塞”的方式調(diào)用。這種情況下,,即使等待的信號量無效,,任務(wù)也會返回,而不是被掛起,,內(nèi)核會通過返回代碼告訴用戶此時信號量無效,。“非阻塞”方式可以應(yīng)用于對共享資源的訪問,比如當(dāng)某資源不可用時用戶可能并不希望任務(wù)被掛起,,而是執(zhí)行其他操作,,等待一段時間后再次查詢資源。但如果要實現(xiàn)任務(wù)間的同步,,則必須用“阻塞”方式,。這里順便提一下,μC/OS—II中提供了一個信號量查詢函數(shù)OSSemQuery(),,可以用來獲得信號量內(nèi)部的計數(shù)值和等待列表,,用戶可使用“查詢信號量”的辦法來實現(xiàn)類似“非阻塞”的等待方式。而在μC/OS-III中,,由于OSSemPend()函數(shù)本身就支持“非阻塞”模式,因此并沒有再提供查詢信號量的函數(shù),,這也比“查詢信號量”的辦法更加高效,。
OSSemPost()同樣增加了一個opt參數(shù),除了普通的Post操作外,,還允許“廣播模式”和“不調(diào)度模式”,。“廣播模式”是指所有在等待該信號量的任務(wù)都將獲得信號量而轉(zhuǎn)入就緒態(tài);而“不調(diào)度模式”是指該次Post操作后不進行任務(wù)調(diào)度,,當(dāng)用戶連續(xù)執(zhí)行多個Post操作,,只需在最后一次Post完成后才進行任務(wù)調(diào)度。前面提到,,信號量的等待列表中的任務(wù)已經(jīng)按照優(yōu)先級從高到低的順序排序了,,因此當(dāng)執(zhí)行OSSem Post()操作時如果有任務(wù)在等待信號量,則位于等待列表首部的任務(wù)會獲得信號量從而轉(zhuǎn)入就緒態(tài),。當(dāng)然,,如果是“廣播模式”則所有任務(wù)都被喚醒,。
3 μC/OS-Ⅲ中任務(wù)內(nèi)嵌的信號量
在很多應(yīng)用中,信號量被用作任務(wù)和中斷程序同步的手段,。舉一個常見的例子,,有一個串口設(shè)備,通過串口接收來自主機的命令并執(zhí)行相應(yīng)的任務(wù),。串口每當(dāng)收到數(shù)據(jù)就會產(chǎn)生一個接收中斷,,當(dāng)收到回車符時表示主機端的用戶已輸入一串命令,這時串口中斷服務(wù)例程會給另外一個串口服務(wù)任務(wù)發(fā)信號量,,由該任務(wù)來處理接收到的命令并實現(xiàn)相應(yīng)功能,。在這種情況下,等待該信號量的只有一個任務(wù),,而且串口中斷服務(wù)例程也清楚地知道向哪個任務(wù)發(fā)信號量,。這種應(yīng)用對信號量的功能需求實際被簡化了,如果使用普通的信號量來實現(xiàn)該應(yīng)用,,從功能上是完全可以的,,但是在μC/OS—III中針對這種情況有更加高效的方法,那就是任務(wù)內(nèi)嵌的信號量,。
在μC/OS—III中每個任務(wù)都有內(nèi)嵌的信號量,,當(dāng)任務(wù)被創(chuàng)建時,任務(wù)內(nèi)嵌的信號量會被自動創(chuàng)建,,且初始計數(shù)為零,。在μC/OS—III中,任務(wù)內(nèi)嵌信號量相關(guān)的服務(wù)函數(shù)都是以O(shè)STaskSem???()的形式開頭,,以區(qū)別于普通的信號量,。
任務(wù)內(nèi)嵌的信號量相關(guān)的API函數(shù)如下:
和普通的信號量相比,當(dāng)調(diào)用Pend操作時,,無需指定等待的信號量,,也無需指定等待的任務(wù),因為默認要等待信號量的就是當(dāng)前任務(wù),,而等待的就是其內(nèi)嵌的信號量,。而opt參數(shù)、p_ts參數(shù)和普通信號量的調(diào)用參數(shù)一樣,。前面提到,,對于普通的信號量,任務(wù)調(diào)用OSSemPend()而被掛起時,,內(nèi)核會新建一個OS_PEND_DATA類型的數(shù)據(jù)塊,,然后填寫相關(guān)的數(shù)據(jù)域,并根據(jù)等待任務(wù)的優(yōu)先級將數(shù)據(jù)塊插入到信號量的等待列表OS_PEND_LIST中對應(yīng)的位置,。任務(wù)內(nèi)嵌的信號量不像普通的信號量那樣擁有OS_SEM類型結(jié)構(gòu)體的各個數(shù)據(jù)域,,而是只有信號量計數(shù)值SemCtr變量,。因為對于任務(wù)內(nèi)嵌的信號量,只有該任務(wù)本身能對其進行等待操作,,所以不需要普通信號量中的等待列表OS_PEND_LIST,。當(dāng)任務(wù)調(diào)用OSTaskSemPend()而被掛起時,也不需要OS_PEND_DATA類型的數(shù)據(jù)塊,,內(nèi)核要做的,,除了把任務(wù)從就緒表中移除外,只需簡單地把任務(wù)OS_TCB里的PendOn數(shù)據(jù)域置為OS_TASK_PEND_ON_TASK_SEM就可以了,。PendOn數(shù)據(jù)域用來指示任務(wù)在等待什么,,如普通信號量、消息隊列,、事件標(biāo)志組等,,而OS_TASK_PEND_ON_TASK_SEM表示任務(wù)等待的是任務(wù)內(nèi)嵌的信號量。
OSTaskSemPost()需要傳遞一個指向OS_TCB的指針,,表示對哪個任務(wù)的內(nèi)嵌信號量進行Post操作,。opt參數(shù)同樣支持“不調(diào)度模式”,但與普通信號量的OSSemPost()相比,,沒有“廣播模式”,。原因很簡單,任務(wù)內(nèi)嵌的信號量最多只有1個任務(wù)(就是該任務(wù)本身)在等待,,因此不存在“廣播”的必要性,。當(dāng)別的任務(wù)或者中斷服務(wù)程序調(diào)用OSTaskSemPost()對某個任務(wù)的內(nèi)嵌信號量進行“發(fā)信號量”操作時,如果該任務(wù)在等待其內(nèi)嵌的信號量,,則內(nèi)核會把其狀態(tài)改為就緒,,這比普通信號量的Post操作又進一步簡化了。
結(jié)語
μC/OS—III改進了信號量的使用,,用戶可以使用“非阻塞”方式等待信號量,,而釋放信號量則可以選擇“廣播模式”以及“不調(diào)度模式”,提高了使用的靈活性,。除此之外,每個任務(wù)都有一個內(nèi)部的信號量,。和普通信號量相比,,任務(wù)內(nèi)部信號量的操作簡化了,因此,,在只有一個任務(wù)等待信號量的情況下使用任務(wù)內(nèi)嵌的信號量,,可以大大提高通信效率。