μC/OS—Ⅱ任務延時管理的改進

許璐璐　鄭吉洲

[摘要]嵌入式實時操作系統μC/OS-Ⅱ在時鐘節拍服務中，需要遍歷任務控制塊鏈表中的所有任務控制塊，對任務的延時進行管理，效率比較低。針對這個問題，論文提出了一種改進方法，使用增量鏈表對任務延時進行高效管理，并給出了增量鏈表的實現及其在μC/OS-Ⅱ任務延時管理中的運用。

[關鍵詞]μC/OS-Ⅱ；任務延時管理；增量鏈表

1 引言

μC/OS-Ⅱ是一個源碼開放的嵌入式實時操作系統，具有結構精簡、可裁剪、可移植性強、多任務可剝奪實時內核等特點，穩定性和安全性能好，在嵌入式領域應用廣泛。任務延時是嵌入式實時操作系統中的一個常用操作，可能發生在任務主動讓出CPU、等待某一事件發生等情況下。每個需要延時的任務都有自己特定的延時請求，操作系統必須維護申請延時任務的集合，對任務的延時狀態、延時時間進行管理。

數據結構的設計對操作系統任務延時管理的效率有很大的影響。本文分析了μC/OS-Ⅱ對任務延時管理的缺點，提出了一個基于增量鏈表的改進方案，能夠實現對延時任務的高效管理。

2 μC/OS-Ⅱ任務延時管理分析

μC/OS-Ⅱ中調用OSTimeDly（）可實現對任務的延時，任務的延時時間保存在任務控制塊里的OSTCBDly變量中，在時鐘節拍服務程序OSTimeTick（）中對任務的延時狀態進行更新，其部分代碼如下（參照μC/OS-Ⅱv2，86版本）：

從代碼可以知道。需要遍歷任務控制塊鏈表中的所有任務控制塊，對其中的延時任務進行狀態更新，當系統中任務數比較多時，這是個很耗時的操作，效率比較低。

3 使用增量鏈表對任務延時進行有效管理

3.1 增量鏈表概述

使計算更高效的方法是使用相對時間而非絕對時間。增量鏈表包含一個延時任務集合，并且鏈表是按每個任務的延時時間進行排序，但是每個節點存儲的不是任務延時的絕對時間，而是在增量鏈表中存儲任務相對于前一個任務必須延遲的多余的時間。

因此，增量鏈表中第一個任務的延時鍵值指定了相對于當前的時間，該任務需要等待的時鐘滴答數，其他每一個任務的鍵值指定了相對于各自的前一個任務。該任務需要等待的時鐘滴答數。任務延遲的絕對時間等于增量鏈表中該任務的鍵值與該任務之前的所有任務的鍵值之和。

例如，假設任務A、B、C、D分別請求延遲5、20、50、100個時鐘滴答，且假設這樣的請求在幾乎相同時間做出（即在一個時鐘滴答內），圖1顯示了使用增量鏈表存儲這4個延時任務的情況。

給定一個增量鏈表，可以通過計算部分鍵值的和得到每個任務的延時時間。

使用了增量鏈表后，由于鏈表中所有后續任務的延時時間都是與第一個延時相關的。因此在時鐘節拍服務程序中，只需要遞減增量鏈表第一項的延時鍵值，不需要掃描整個鏈表，效率有了很大的提高。當第一項的鍵值變為0時，表明該任務延時時間已到，需要將其放入就緒表。

3.2 增量鏈表的實現

為了實現增量鏈表，在任務控制塊中添加項：

聲明延時增量鏈表

SO_TCB*OSDelayList。

插入鏈表操作，需要計算一個相對延遲，將指定的任務插入到OSDelayList中合適的位置。搜索過程從鏈表頭開始遍歷鏈表，將待插入節點的相對延時值與鏈表中的節點的值比較，當發現待插入節點的值小于鏈表中某一節點時，則在該位置插入新節點。每當跳過一個節點時，需要將待插入節點的值減去該節點的值，得到相對延遲量。而當插入一個新節點時，必須在鏈表的剩余節點中減去由于插入新節點而導致的延時值的改變。即在下一個節點的值中減去新插入節點的值。

例如，假設某一時刻延時鏈表如圖1所示，待插入任務E的延時值為30，則插入過程如圖2所示。

插入鏈表操作關鍵代碼如下：

使用了延時增量鏈表后，在原來的OSTimeDly（）中，延時操作OSTCBCur->OSTCBDly=ticks

則變為：

insert（OSTCBCur，ticks）；

在時鐘節拍服務程序中，只需遞減延時鏈表第一個節點的鍵值，當其變為0時，表明其延時時間已到，需要將該任務喚醒：

函數wakeup（）需要將延時鏈表中從第一項開始延時鍵值為0的所有任務喚醒：

{

清等待狀態標志：

if（任務狀態為ready）

任務放入就緒表；

ptcb=ptcb->delay_next；

}

OSDelayList=ptcb；

}

當某個任務要取消延時，需將其從延時增量鏈表中移除，且需要將鏈表中該節點之后的剩余節點加上由于移除節點而導致的相對延時值的改變，即在下一個節點的鍵值中加上被移除節點的鍵值。

4 結束語

增量鏈表通過使用相對時間而非絕對時間。實現了對延時任務的高效管理，在對時間效率要求較高的實時系統中，有良好的應用效果，也可將其借鑒到其他的應用場景中。