μC／OS- -III對信號量的改進

黃土琛，宮輝，邵貝貝

（1.清華大學 工程物理系，北京100084；2.清華大學 粒子技術與輻射成像教育部重點實驗室）

引 言

μC／OS是一個基于優(yōu)先級調度的可剝奪型實時多任務內核。在多任務的實時內核中，信號量是常用的機制，可以用來實現(xiàn)對共享資源的訪問、任務之間的通信和同步，以及任務和中斷的同步等功能。μC／OS -II中提供了等待和釋放信號量等最基本的服務，而在μC／OS -III中，對信號量的使用增加了一些可選的模式，如非阻塞等待、釋放但不進行任務調度等，提高了使用的靈活性。更重要的是，在μC／OS -III中還新增了任務內嵌的信號量，用戶程序無需建立信號量便可和任務直接通信，比普通信號量更加簡單高效。本文將分析對比μC／OS -II和μC／OSIII中信號量內部結構的差異以及μC／OS -III新增的特性。

1 μC／OS -II中信號量內部結構

在μC／OS -II中，信號量直接使用內核的數(shù)據結構OS＿EVENT，其內部結構如下：

其中，和信號量相關的最重要的就是OSEventCnt、OSEventGrp和OSEventTbl［］。OSEventCnt記錄的是信號量的有效值。OSEventTbl［］是一個位映射表，以64級優(yōu)先級為例，OSEventTbl［］將是一個8×8的位映射表，如果某優(yōu)先級下有任務在等待該事件，則OSEventTbl［］中對應的位將被置1。為了加快查詢過程，又將64級優(yōu)先級分為8組，用一個8位的整型OSEventGrp來記錄每一組的狀態(tài)。可見，OSEventGrp和OSEventTbl［］跟就緒表中的OSRdyGrp和OSRdyTbl［］結構是一模一樣的，區(qū)別僅僅在于前者記錄的是等待該事件的任務的狀態(tài)，而后者記錄的是系統(tǒng)中就緒的任務的狀態(tài)。而兩者的查找過程是一樣的，都是通過“掩碼表”來快速得到列表中優(yōu)先級最高的任務。

μC／OS-II提供的信號量相關的最常用的幾個API函數(shù)如下：

在使用信號量前必須先新建一個信號量，并指定其初始值。當信號量用于對共享資源的訪問時，該值應初始化為實際可用的共享資源數(shù)；當信號量用來實現(xiàn)任務的同步，則初始值應設為0。調用等待信號量的OSSemPend（）函數(shù)時可以指定超時選項timeout，在指定的時間內如果沒有獲得信號量則任務會超時返回。釋放信號量時，如果有任務在等待，內核會通過查找OSEventGrp和OSEvent－Tbl［］獲得等待任務中優(yōu)先級最高的任務，該任務將獲得信號量從而轉入就緒態(tài)，內核會進行任務調度。如果獲得信號量的任務比正在執(zhí)行的任務優(yōu)先級還高，則會進行任務切換。

2 μC／OS -III中信號量內部結構

在μC／OS -III中，信號量類型的結構有所變化，并沒有和μC／OS -II一樣繼續(xù)采用和“就緒表”類似的結構，而是采用一個“等待列表”的數(shù)據結構來記錄等待信號量的任務。其數(shù)據結構如下：

從上述結構可以看出，μC／OS -III的信號量結構中新增了一個時間戳TS，用來記錄最近一次釋放信號量（或者是取消等待、刪除信號量）的時間。而等待信號量的任務列表則通過一個新的數(shù)據結構OS＿PEND＿LIST來記錄，如圖1所示。

OS＿PEND＿LIST包括3個數(shù)據域：NbrEntries用來記錄等待列表中的條目數(shù)，也就是等待的任務數(shù)目；HeadPtr和TailPtr構成一個雙向鏈表，指向的是OS＿PEND＿DATA類型的結構體。OS＿PEND＿DATA是μC／OS -III內部的一個數(shù)據類型，每當任務因等待信號量而被掛起時，內核就會新建一個對應的OS＿PEND＿DATA類型的數(shù)據塊并插入到信號量的等待列表OS＿PEND＿LIST所包含的雙向鏈表中。OS＿PEND＿DATA結構體包含指向等待任務的OS＿TCB的指針以及其他數(shù)據域。在這里，最重要的細節(jié)是，μC／OS -III是按照任務優(yōu)先級從高到低的順序來排列雙向鏈表中的OS＿PEND＿DATA數(shù)據塊的。也就是說，每當有一個新的OS＿PEND＿DATA數(shù)據塊需要插入到雙向鏈表時（也就是任務因等待信號量而被掛起時），內核會從鏈表頭部開始掃描各個OS＿PEND＿DATA數(shù)據塊所對應的等待任務的優(yōu)先級（通過OS＿PEND＿DATA數(shù)據塊內部的TCBPtr指針可以從任務控制塊內部獲得任務的優(yōu)先級），直到找到比當前需要插入的任務的優(yōu)先級低的任務，然后把新的OS＿PEND＿DATA數(shù)據塊插入到該位置前。如果鏈表中已有和需要插入的任務優(yōu)先級相同的任務，則新插入的任務放到優(yōu)先級相同的任務后。道理很簡單，優(yōu)先級相同，晚到的任務沒有任何理由比早到的任務先獲得信號量?；谏鲜雠帕蟹椒?，位于雙向鏈表頭部的任務總是等待的任務中優(yōu)先級最高的。因此，當用戶釋放信號量時，總是雙向鏈表頭部的任務獲得信號量，而不必再執(zhí)行“查找最高優(yōu)先級”的過程了。

圖1 信號量內部的OS＿PEND＿LIST結構

μC／OS-III提供的信號量相關的最常用的幾個API函數(shù)如下：

OSSemCreate（）函數(shù)和μC／OS -II中的類似，需要指定信號量的初始值，還需額外指定信號量的名稱以便于調試。

OSSemPend（）函數(shù)多了兩個參數(shù)：opt和p＿ts。p＿ts是指向時間戳的指針，當任務獲得信號量（或者任務取消等待或信號量被刪除）返回時，內核會把釋放信號量（或者任務取消等待或信號量被刪除）時刻的時間戳保存到該指針指向的變量中，該時間戳用戶可以計算從信號量被釋放到實際獲得信號量的時間。opt參數(shù)用來指定該等待操作是否是阻塞的。在μC／OS -II中，當用戶對信號量執(zhí)行Pend操作而信號量無效時任務會被掛起，而μC／OS -III通過opt參數(shù)支持以“非阻塞”的方式調用。這種情況下，即使等待的信號量無效，任務也會返回，而不是被掛起，內核會通過返回代碼告訴用戶此時信號量無效。“非阻塞”方式可以應用于對共享資源的訪問，比如當某資源不可用時用戶可能并不希望任務被掛起，而是執(zhí)行其他操作，等待一段時間后再次查詢資源。但如果要實現(xiàn)任務間的同步，則必須用“阻塞”方式。這里順便提一下，μC／OS -II中提供了一個信號量查詢函數(shù)OSSemQuery（），可以用來獲得信號量內部的計數(shù)值和等待列表，用戶可使用“查詢信號量”的辦法來實現(xiàn)類似“非阻塞”的等待方式。而在μC／OS III中，由于OSSemPend（）函數(shù)本身就支持“非阻塞”模式，因此并沒有再提供查詢信號量的函數(shù)，這也比“查詢信號量”的辦法更加高效。

OSSemPost（）同樣增加了一個opt參數(shù)，除了普通的Post操作外，還允許“廣播模式”和“不調度模式”?！皬V播模式”是指所有在等待該信號量的任務都將獲得信號量而轉入就緒態(tài)；而“不調度模式”是指該次Post操作后不進行任務調度，當用戶連續(xù)執(zhí)行多個Post操作，只需在最后一次Post完成后才進行任務調度。前面提到，信號量的等待列表中的任務已經按照優(yōu)先級從高到低的順序排序了，因此當執(zhí)行OSSemPost（）操作時如果有任務在等待信號量，則位于等待列表首部的任務會獲得信號量從而轉入就緒態(tài)。當然，如果是“廣播模式”則所有任務都被喚醒。

3 μC／OS -III中任務內嵌的信號量

在很多應用中，信號量被用作任務和中斷程序同步的手段。舉一個常見的例子，有一個串口設備，通過串口接收來自主機的命令并執(zhí)行相應的任務。串口每當收到數(shù)據就會產生一個接收中斷，當收到回車符時表示主機端的用戶已輸入一串命令，這時串口中斷服務例程會給另外一個串口服務任務發(fā)信號量，由該任務來處理接收到的命令并實現(xiàn)相應功能。在這種情況下，等待該信號量的只有一個任務，而且串口中斷服務例程也清楚地知道向哪個任務發(fā)信號量。這種應用對信號量的功能需求實際被簡化了，如果使用普通的信號量來實現(xiàn)該應用，從功能上是完全可以的，但是在μC／OS -III中針對這種情況有更加高效的方法，那就是任務內嵌的信號量。

在μC／OS -III中每個任務都有內嵌的信號量，當任務被創(chuàng)建時，任務內嵌的信號量會被自動創(chuàng)建，且初始計數(shù)為零。在μC／OS -III中，任務內嵌信號量相關的服務函數(shù)都是以OSTaskSem？？？（）的形式開頭，以區(qū)別于普通的信號量。

任務內嵌的信號量相關的API函數(shù)如下：

和普通的信號量相比，當調用Pend操作時，無需指定等待的信號量，也無需指定等待的任務，因為默認要等待信號量的就是當前任務，而等待的就是其內嵌的信號量。而opt參數(shù)、p＿ts參數(shù)和普通信號量的調用參數(shù)一樣。前面提到，對于普通的信號量，任務調用OSSemPend（）而被掛起時，內核會新建一個OS＿PEND＿DATA類型的數(shù)據塊，然后填寫相關的數(shù)據域，并根據等待任務的優(yōu)先級將數(shù)據塊插入到信號量的等待列表OS＿PEND＿LIST中對應的位置。任務內嵌的信號量不像普通的信號量那樣擁有OS＿SEM類型結構體的各個數(shù)據域，而是只有信號量計數(shù)值SemCtr變量。因為對于任務內嵌的信號量，只有該任務本身能對其進行等待操作，所以不需要普通信號量中的等待列表OS＿PEND＿LIST。當任務調用OSTaskS－emPend（）而被掛起時，也不需要OS＿PEND＿DATA類型的數(shù)據塊，內核要做的，除了把任務從就緒表中移除外，只需簡單地把任務OS＿TCB里的PendOn數(shù)據域置為OS＿TASK＿PEND＿ON＿TASK＿SEM 就可以了。PendOn數(shù)據域用來指示任務在等待什么，如普通信號量、消息隊列、事件標志組等，而OS＿TASK＿PEND＿ON＿TASK＿SEM 表示任務等待的是任務內嵌的信號量。

OSTaskSemPost（）需要傳遞一個指向OS＿TCB的指針，表示對哪個任務的內嵌信號量進行Post操作。opt參數(shù)同樣支持“不調度模式”，但與普通信號量的OSSemPost（）相比，沒有“廣播模式”。原因很簡單，任務內嵌的信號量最多只有1個任務（就是該任務本身）在等待，因此不存在“廣播”的必要性。當別的任務或者中斷服務程序調用OSTaskSemPost（）對某個任務的內嵌信號量進行“發(fā)信號量”操作時，如果該任務在等待其內嵌的信號量，則內核會把其狀態(tài)改為就緒，這比普通信號量的Post操作又進一步簡化了。

結 語

μC／OS-III改進了信號量的使用，用戶可以使用“非阻塞”方式等待信號量，而釋放信號量則可以選擇“廣播模式”以及“不調度模式”，提高了使用的靈活性。除此之外，每個任務都有一個內部的信號量。和普通信號量相比，任務內部信號量的操作簡化了，因此，在只有一個任務等待信號量的情況下使用任務內嵌的信號量，可以大大提高通信效率。

［1］Jean J Labrosse.μC／OS -II源碼公開的實時嵌入式操作系統(tǒng)［M］.邵貝貝，等譯.北京：中國電力出版社，2001.

［2］Jean J Labrosse.嵌入式實時操作系統(tǒng)μC／OS -II［M］.邵貝貝，等譯.2版.北京：北京航空航天出版社，2003.

［3］Jean J Labrosse.μC／OS -III the Real Time Kernel for the Freescale Kinetis［EB／OL］.［2012 09 -25］.http：／／micrium.com／page／downloads／os -iii＿projects.