μC／OS-III中的高效時鐘節(jié)拍管理機制

摘要：為了有效管理時鐘節(jié)拍并確保系統(tǒng)的實時性，μC／OS—III不僅增加了一個專門的系統(tǒng)任務(wù)來管理時鐘節(jié)拍，而且采用哈希散列表機制來進一步減少時鐘節(jié)拍處理過程所花費的時間。本文討論μC／OS—II在時鐘節(jié)拍管理方面的不足，并介紹μC／OS—III中的高效時鐘節(jié)拍管理機制。
關(guān)鍵詞：μC／OS—III；時鐘節(jié)拍管理；哈希散列表

引言
    在嵌入式實時操作系統(tǒng)(RTOS)中，任務(wù)可通過調(diào)用延時函數(shù)(比如μC／OS中的OSTimeDly()函數(shù))將自己延時掛起一段時間。任務(wù)在延時的過程中會釋放CPU使用權(quán)，也就是說，延時的任務(wù)不占用寶貴的CPU資源。延時的任務(wù)由時鐘節(jié)拍服務(wù)跟蹤管理。當(dāng)任務(wù)延時結(jié)束并準備運行時，時鐘節(jié)拍服務(wù)會使該任務(wù)恢復(fù)運行。時鐘節(jié)拍服務(wù)定期運行，其運行由周期的時鐘節(jié)拍中斷觸發(fā)，而時鐘節(jié)拍中斷可由硬件定時器產(chǎn)生。
    在μC／OS—III中，時鐘節(jié)拍服務(wù)是在時鐘節(jié)拍中斷服務(wù)程序中完成的，每次時鐘節(jié)拍服務(wù)都會遍歷整個任務(wù)鏈表，遞減所有延時任務(wù)的延時計數(shù)器。當(dāng)任務(wù)數(shù)目較多時，時鐘節(jié)拍服務(wù)處理時間很長，會造成中斷延遲時間和任務(wù)延遲時間都變得很長，影響系統(tǒng)的實時性。
    在μC／OS—III中，時鐘節(jié)拍服務(wù)不再在時鐘節(jié)拍中斷服務(wù)程序中完成，而是放到一個時鐘節(jié)拍任務(wù)中完成。而且，通過采用啥希散列表機制來管理延時任務(wù)，每次時鐘節(jié)拍服務(wù)只需要處理極少數(shù)的延時任務(wù)，從而大大減少了時鐘節(jié)拍服務(wù)花費的時間，提高了系統(tǒng)的實時性。
    另外，在μC／OS系列RTOS中，時鐘節(jié)拍服務(wù)除了會跟蹤延時的任務(wù)，還會跟蹤那些指定了超時時限的等待任務(wù)。也就是說，當(dāng)指定的超時時限結(jié)束時，即使任務(wù)等待的事件沒有發(fā)生，時鐘節(jié)拍服務(wù)也會使該任務(wù)恢復(fù)運行。

1 μC／OS—II中的時鐘節(jié)拍管理機制
    在μC／OS—II中，每次時鐘節(jié)拍服務(wù)都會遍歷整個任務(wù)鏈表，依次處理各個任務(wù)。如果當(dāng)前處理的任務(wù)的延時計數(shù)為0，那么跳過該任務(wù)，繼續(xù)處理下一個任務(wù)；否則，把當(dāng)前任務(wù)的延時計數(shù)減1，然后，判斷減1后的延時計數(shù)是否為0。如果為0，表示任務(wù)延時結(jié)束了或等待超時了。由于μC／OS-Ⅱ允許其他任務(wù)調(diào)用OSTaskSuspend()函數(shù)強制掛起正在延時的任務(wù)，在這種情況下，不僅需要等到任務(wù)延時結(jié)束，還需要由其他任務(wù)調(diào)用OSTaskResume()函數(shù)解除該任務(wù)的強制掛起狀態(tài)，該任務(wù)才能進入就緒態(tài)。因此，在延時計數(shù)遞減為0的時候，還需要判斷任務(wù)是否被強制掛起。只有任務(wù)沒有被強制掛起，才能使該任務(wù)進入就緒態(tài)；否則，把延時計數(shù)設(shè)置為1，保持任務(wù)的延時狀態(tài)。μC／OS—II時鐘節(jié)拍服務(wù)函數(shù)的主要代碼和注釋如下：
    [!--empirenews.page--]
    在μC／OS—II中，由于每次時鐘節(jié)拍服務(wù)都要遍歷所有任務(wù)，因此，在任務(wù)數(shù)目較多時，其執(zhí)行時間可能很長。另外，由于時鐘節(jié)拍服務(wù)函數(shù)OSTimeTick()由時鐘節(jié)拍中斷服務(wù)程序OSTicidSR()調(diào)用執(zhí)行，因此當(dāng)OSTimeTick()執(zhí)行時間很長時，時鐘節(jié)拍中斷服務(wù)程序的執(zhí)行時間也很長。在中斷服務(wù)程序執(zhí)行時，所有任務(wù)都無法執(zhí)行，在這種情況下，系統(tǒng)的實時性會很差。

2 μC／OS-III中的時鐘節(jié)拍管理機制
    針對μC／OS—II時鐘節(jié)拍服務(wù)的問題，μC／OS—III主要做了兩點改進：①用時鐘節(jié)拍任務(wù)來做時鐘節(jié)拍處理；②用時鐘節(jié)拍輪盤來分類管理延時任務(wù)以及指定超時時限的等待任務(wù)。
2．1 時鐘節(jié)拍任務(wù)
    在μC／OS—III中，增加了一個系統(tǒng)任務(wù)，即時鐘節(jié)拍任務(wù)OS_TickTask()。該任務(wù)是μC／OS-III中兩個總是會創(chuàng)建的系統(tǒng)任務(wù)之一。時鐘節(jié)拍任務(wù)負責(zé)處理延時任務(wù)和指定超時時限的等待任務(wù)，這樣，μC／OS—III就把時鐘節(jié)拍的處理工作放到任務(wù)級代碼中完成了。時鐘節(jié)拍中斷服務(wù)程序和時鐘節(jié)拍任務(wù)之間的關(guān)系如圖1所示。

    不論在μC／OS—II還是在μC／OS—III中，都需要一個硬件定時器(或其他能產(chǎn)生周期性中斷的外設(shè))來產(chǎn)生幾十到上千赫茲的時鐘節(jié)拍中斷。時鐘節(jié)拍中斷的具體頻率取決于所用的處理器的性能以及應(yīng)用需求。時鐘節(jié)拍中斷頻率越高，系統(tǒng)的延時精度越高，對處理器的處理能力要求也越高。
    每次產(chǎn)生時鐘節(jié)拍中斷，CPU都會跳轉(zhuǎn)到時鐘節(jié)拍中斷服務(wù)程序(ISR)中執(zhí)行。時鐘節(jié)拍ISR會調(diào)用OSTimeTick()函數(shù)。前面提到過，μC ／OS—II的時鐘節(jié)拍ISR也會調(diào)用OSTimeTick()函數(shù)，在這一點上μC／OS—II和μC／OS—III看起來沒有區(qū)別，但實際上μC／OS—III中的OS TimeTick()函數(shù)與μC／OS—II中的OSTimeTick()函數(shù)有很大區(qū)別。μC／OS—III中的OSTimeTick()函數(shù)主要完成如下操作：向時鐘節(jié)拍任務(wù)發(fā)信號、調(diào)用OS_SchedRoundRobin()函數(shù)，以及向定時器任務(wù)發(fā)信號等。其中，后兩點與時鐘節(jié)拍的管理無關(guān)，這里不詳細介紹。精簡的OSTimeTick()函數(shù)如下面這段代碼所示，其中只保留與時鐘節(jié)拍管理相關(guān)的代碼。
    
    在μC／OS—III中，OSTimeTick()函數(shù)不需要遍歷任務(wù)鏈表，只是通過OSTaskSemPost()函數(shù)向時鐘節(jié)拍任務(wù)發(fā)信號。而時鐘節(jié)拍任務(wù)絕大部分時間內(nèi)都處于等待該信號的狀態(tài)，每次收到該信號時，時鐘節(jié)拍任務(wù)會恢復(fù)運行，調(diào)用OS_TiekListUpdate()函數(shù)處理延時的任務(wù)，然后再次進入等待該信號的狀態(tài)，其代碼如下：
    
    
    相比μC／OS—II的時鐘節(jié)拍管理方式，μC／OS—III使用了專門的時鐘節(jié)拍任務(wù)來處理時鐘節(jié)拍，可大大減少時鐘節(jié)拍中斷服務(wù)程序的執(zhí)行時間。[!--empirenews.page--]
2．2 延時任務(wù)管理
    μC／OS—III為了提高時鐘節(jié)拍的處理速度，采用了哈希散列表機制來管理所有正在延時的任務(wù)和指定了超時時限的等待任務(wù)。這些任務(wù)都記錄在時鐘節(jié)拍列表(Tick List)中。時鐘節(jié)拍列表包含兩部分：一個稱為時鐘節(jié)拍輪盤的數(shù)組(OSCfg_TickWheel[])和一個時鐘節(jié)拍計數(shù)器(OSTickCtr)，如圖2所示。

    時鐘節(jié)拍列表中的每個任務(wù)都有一個延時結(jié)束時刻或等待超時時限，假設(shè)為TM。比如，一個任務(wù)在時鐘節(jié)拍計數(shù)器數(shù)值為OSTickCtr時調(diào)用OSTimeDly()延時dly個時鐘節(jié)拍，那么該任務(wù)的延時結(jié)束時刻TM就等于OSTickCtr+dly。然后，用TM和時鐘節(jié)拍輪盤的表項個數(shù)(OS_CFG_TI CK_WHEEL_SIZE)做取模運算，就可以得到一個余數(shù)I(I=TM％OS_CFG_TICK_WHEEL_SIZE)。那么，該延時任務(wù)就會放到時鐘節(jié)拍輪盤第1個表項指向的任務(wù)鏈表中。
    時鐘節(jié)拍輪盤的每個表項都有3個成員：“．NbrEntriesMax”、“．NbrEntries”和“．FirstPtr”。其中，“．FirstPtr”指向該表項對應(yīng)的任務(wù)鏈表，所有分配到該表項的延時任務(wù)或指定超時時限的等待任務(wù)都會放到該任務(wù)鏈表中。“．NbrEntries”和“．NbrEntries Max”分別記錄任務(wù)鏈表中的當(dāng)前任務(wù)數(shù)目和歷史最大任務(wù)數(shù)目。在任務(wù)鏈表中，任務(wù)按照延時結(jié)束時刻或超時時限排序，結(jié)束時刻早的任務(wù)排在鏈表的前面。
    通過采用哈希散列表機制，在每次時鐘節(jié)拍服務(wù)時，只需要處理時鐘節(jié)拍輪盤的某個特定表項所指向的任務(wù)鏈表，因為恰好在該時鐘節(jié)拍服務(wù)時延時結(jié)束或等待超時的任務(wù)都一定處于該表項所指向的任務(wù)鏈表中，而該表項的索引號就等于OSTickCtr％OS_CFG_TICK_WHEEL_SIZ E。另外，由于各個表項指向的任務(wù)鏈表中的任務(wù)是按照延時結(jié)束時刻和等待超時時限的順序進行排序的，這樣，在處理當(dāng)前任務(wù)鏈表時，就可以從位于鏈表頭部的任務(wù)開始判斷任務(wù)延時結(jié)束時刻或等待超時時限是否等于OSTickCtr的當(dāng)前值。如果等于，說明該任務(wù)延時結(jié)束或等待超時了，然后，再判斷下一個任務(wù)；如果不等于，說明該任務(wù)延時沒有結(jié)束或等待沒有超時，同時也說明，排在鏈表后面的任務(wù)都不可能延時結(jié)束或等待超時，因此，可以立即結(jié)束對任務(wù)鏈表的處理。
    由于采用了哈希散列表機制，μC／OS—III中的時鐘節(jié)拍服務(wù)在大部分情況下只需要判斷極少數(shù)任務(wù)的延時結(jié)束時刻或超時時限，看其是否等于時鐘節(jié)拍計數(shù)器的當(dāng)前值，這相比μC／OS—II中需要遍歷整個任務(wù)鏈表的時鐘節(jié)拍服務(wù)，顯然效率要高很多。

結(jié)語
    μC／OS—II中的時鐘節(jié)拍服務(wù)有兩個不足之處：一是需要遍歷整個任務(wù)鏈表，二是需要在時鐘節(jié)拍中斷服務(wù)程序中進行時鐘節(jié)拍的處理工作。當(dāng)系統(tǒng)中任務(wù)數(shù)目較多時，會影響系統(tǒng)的實時性，這對于一個實時嵌入式操作系統(tǒng)來說是不完善的地方。在μC／OS—III中，通過增加一個時鐘節(jié)拍系統(tǒng)任務(wù)并采用哈希散列表機制，很好地解決了這兩點問題，即使在系統(tǒng)任務(wù)數(shù)目很多的時候，也可以確保系統(tǒng)的實時性。