為了有效管理時鐘節拍并確保系統的實時性，μC／OS—III不僅增加了一個專門的系統任務來管理時鐘節拍，而且采用哈希散列表機制來進一步減少時鐘節拍處理過程所花費的時間。本文討論μC／OS—II在時鐘節拍管理方面的不足，并介紹μC／OS—III中的高效時鐘節拍管理機制。

在嵌入式實時操作系統(RTOS)中，任務可通過調用延時函數(比如μC／OS中的OSTimeDly()函數)將自己延時掛起一段時間。任務在延時的過程中會釋放CPU使用權，也就是說，延時的任務不占用寶貴的CPU資源。延時的任務由時鐘節拍服務跟蹤管理。當任務延時結束并準備運行時，時鐘節拍服務會使該任務恢復運行。時鐘節拍服務定期運行，其運行由周期的時鐘節拍中斷觸發，而時鐘節拍中斷可由硬件定時器產生。

在μC／OS—III中，時鐘節拍服務是在時鐘節拍中斷服務程序中完成的，每次時鐘節拍服務都會遍歷整個任務鏈表，遞減所有延時任務的延時計數器。當任務數目較多時，時鐘節拍服務處理時間很長，會造成中斷延遲時間和任務延遲時間都變得很長，影響系統的實時性。

在μC／OS—III中，時鐘節拍服務不再在時鐘節拍中斷服務程序中完成，而是放到一個時鐘節拍任務中完成。而且，通過采用啥希散列表機制來管理延時任務，每次時鐘節拍服務只需要處理極少數的延時任務，從而大大減少了時鐘節拍服務花費的時間，提高了系統的實時性。

另外，在μC／OS系列RTOS中，時鐘節拍服務除了會跟蹤延時的任務，還會跟蹤那些指定了超時時限的等待任務。也就是說，當指定的超時時限結束時，即使任務等待的事件沒有發生，時鐘節拍服務也會使該任務恢復運行。

1 μC／OS—II中的時鐘節拍管理機制

在μC／OS—II中，每次時鐘節拍服務都會遍歷整個任務鏈表，依次處理各個任務。如果當前處理的任務的延時計數為0，那么跳過該任務，繼續處理下一個任務；否則，把當前任務的延時計數減1，然后，判斷減1后的延時計數是否為0。如果為0，表示任務延時結束了或等待超時了。由于μC／OS-Ⅱ允許其他任務調用OSTaskSuspend()函數強制掛起正在延時的任務，在這種情況下，不僅需要等到任務延時結束，還需要由其他任務調用OSTaskResume()函數解除該任務的強制掛起狀態，該任務才能進入就緒態。因此，在延時計數遞減為0的時候，還需要判斷任務是否被強制掛起。只有任務沒有被強制掛起，才能使該任務進入就緒態；否則，把延時計數設置為1，保持任務的延時狀態。μC／OS—II時鐘節拍服務函數的主要代碼和注釋如下：

在μC／OS—II中，由于每次時鐘節拍服務都要遍歷所有任務，因此，在任務數目較多時，其執行時間可能很長。另外，由于時鐘節拍服務函數OSTimeTICk()由時鐘節拍中斷服務程序OSTicidSR()調用執行，因此當OSTimeTick()執行時間很長時，時鐘節拍中斷服務程序的執行時間也很長。在中斷服務程序執行時，所有任務都無法執行，在這種情況下，系統的實時性會很差。

2 μC／OS-III中的時鐘節拍管理機制

針對μC／OS—II時鐘節拍服務的問題，μC／OS—III主要做了兩點改進：①用時鐘節拍任務來做時鐘節拍處理；②用時鐘節拍輪盤來分類管理延時任務以及指定超時時限的等待任務。

2．1 時鐘節拍任務

在μC／OS—III中，增加了一個系統任務，即時鐘節拍任務OS_TickTask()。該任務是μC／OS-III中兩個總是會創建的系統任務之一。時鐘節拍任務負責處理延時任務和指定超時時限的等待任務，這樣，μC／OS—III就把時鐘節拍的處理工作放到任務級代碼中完成了。時鐘節拍中斷服務程序和時鐘節拍任務之間的關系如圖1所示。

不論在μC／OS—II還是在μC／OS—III中，都需要一個硬件定時器(或其他能產生周期性中斷的外設)來產生幾十到上千赫茲的時鐘節拍中斷。時鐘節拍中斷的具體頻率取決于所用的處理器的性能以及應用需求。時鐘節拍中斷頻率越高，系統的延時精度越高，對處理器的處理能力要求也越高。
? ? 每次產生時鐘節拍中斷，CPU都會跳轉到時鐘節拍中斷服務程序(ISR)中執行。時鐘節拍ISR會調用OSTimeTick()函數。前面提到過，μC ／OS—II的時鐘節拍ISR也會調用OSTimeTick()函數，在這一點上μC／OS—II和μC／OS—III看起來沒有區別，但實際上μC／OS—III中的OS TimeTick()函數與μC／OS—II中的OSTimeTick()函數有很大區別。μC／OS—III中的OSTimeTick()函數主要完成如下操作：向時鐘節拍任務發信號、調用OS_SchedRoundRobin()函數，以及向定時器任務發信號等。其中，后兩點與時鐘節拍的管理無關，這里不詳細介紹。精簡的OSTimeTick()函數如下面這段代碼所示，其中只保留與時鐘節拍管理相關的代碼。
? ??

? ? 在μC／OS—III中，OSTimeTick()函數不需要遍歷任務鏈表，只是通過OSTaskSemPost()函數向時鐘節拍任務發信號。而時鐘節拍任務絕大部分時間內都處于等待該信號的狀態，每次收到該信號時，時鐘節拍任務會恢復運行，調用OS_TiekListUpdate()函數處理延時的任務，然后再次進入等待該信號的狀態，其代碼如下：
? ??
? ??

? ? 相比μC／OS—II的時鐘節拍管理方式，μC／OS—III使用了專門的時鐘節拍任務來處理時鐘節拍，可大大減少時鐘節拍中斷服務程序的執行時間。

μC／OS—III為了提高時鐘節拍的處理速度，采用了哈希散列表機制來管理所有正在延時的任務和指定了超時時限的等待任務。這些任務都記錄在時鐘節拍列表(TICk List)中。時鐘節拍列表包含兩部分：一個稱為時鐘節拍輪盤的數組(OSCfg_TickWheel[])和一個時鐘節拍計數器(OSTickCTR)，如圖2所示。

時鐘節拍列表中的每個任務都有一個延時結束時刻或等待超時時限，假設為TM。比如，一個任務在時鐘節拍計數器數值為OSTickCtr時調用OSTimeDly()延時dly個時鐘節拍，那么該任務的延時結束時刻TM就等于OSTickCtr+dly。然后，用TM和時鐘節拍輪盤的表項個數(OS_CFG_TI CK_WHEEL_SIZE)做取模運算，就可以得到一個余數I(I=TM％OS_CFG_TICK_WHEEL_SIZE)。那么，該延時任務就會放到時鐘節拍輪盤第1個表項指向的任務鏈表中。

時鐘節拍輪盤的每個表項都有3個成員：“．NbrEntriesMax”、“．NbrEntries”和“．FirstPtr”。其中，“．FirstPtr”指向該表項對應的任務鏈表，所有分配到該表項的延時任務或指定超時時限的等待任務都會放到該任務鏈表中。“．NbrEntries”和“．NbrEntries Max”分別記錄任務鏈表中的當前任務數目和歷史最大任務數目。在任務鏈表中，任務按照延時結束時刻或超時時限排序，結束時刻早的任務排在鏈表的前面。

通過采用哈希散列表機制，在每次時鐘節拍服務時，只需要處理時鐘節拍輪盤的某個特定表項所指向的任務鏈表，因為恰好在該時鐘節拍服務時延時結束或等待超時的任務都一定處于該表項所指向的任務鏈表中，而該表項的索引號就等于OSTickCtr％OS_CFG_TICK_WHEEL_SIZ E。另外，由于各個表項指向的任務鏈表中的任務是按照延時結束時刻和等待超時時限的順序進行排序的，這樣，在處理當前任務鏈表時，就可以從位于鏈表頭部的任務開始判斷任務延時結束時刻或等待超時時限是否等于OSTickCtr的當前值。如果等于，說明該任務延時結束或等待超時了，然后，再判斷下一個任務；如果不等于，說明該任務延時沒有結束或等待沒有超時，同時也說明，排在鏈表后面的任務都不可能延時結束或等待超時，因此，可以立即結束對任務鏈表的處理。

由于采用了哈希散列表機制，μC／OS—III中的時鐘節拍服務在大部分情況下只需要判斷極少數任務的延時結束時刻或超時時限，看其是否等于時鐘節拍計數器的當前值，這相比μC／OS—II中需要遍歷整個任務鏈表的時鐘節拍服務，顯然效率要高很多。

結語

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