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

時鐘節(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é)束時刻和等待超時時限的順序進(jìn)行排序的，這樣，在處理當(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ù)程序中進(jìn)行時鐘節(jié)拍的處理工作。當(dāng)系統(tǒng)中任務(wù)數(shù)目較多時，會影響系統(tǒng)的實時性，這對于一個實時嵌入式操作系統(tǒng)來說是不完善的地方。在μC／OS—III中，通過增加一個時鐘節(jié)拍系統(tǒng)任務(wù)并采用哈希散列表機制，很好地解決了這兩點問題，即使在系統(tǒng)任務(wù)數(shù)目很多的時候，也可以確保系統(tǒng)的實時性。