VxWorks下的多重定時器設計

?? VxWorks是一種嵌入式實時操作系統(RTOS)，具有內核小、可裁剪、實時性強等特點。VxWorks內核(Wind)提供了共享內存、信號量、消息隊列、套接字通信和定時器等多種機制。為了實現基于UDP網絡的可靠通信，本文利用VxWorks的多種任務間通信機制和看門狗定時器機制，設計了一種多重定時器模型，該模型可以確保數據包的可靠傳遞。

1 VxWOrks的時鐘及定時器機制
1．1 VxWorks延時函數
??? VxWorks既提供了延時功能，也提供了時限約束功能。VxWorks系統有2種延時方式：一種是Wind內核提供的taskDelay()函數；另一種是POSIX函數nanosleep()。
??? taskDelay()函數以tick作為延時單位，默認情況下1個tick為16．67 ms(1／60 s)，可以通過調用sysClkRateSet()函數對tick進行重新設定。taskDelay()函數使調用該函數的任務在指定時間內主動放棄CPU，用于任務調度或等待某一外部事件。nanosleep()函數指定一個以s和ns為單位的睡眠或延時時間。其實，兩個延時函數的精度是相同的，都是以tick為時間基準。不同之處在于，taskDelay(0)有自身意義，用于相同優先級任務間的任務調度，而nanosleep(0)是沒有意義的。
1．2 VxWorks定時器機制
??? VxWorks提供一種看門狗定時器機制(watchdogtimer)，可以用來處理任務的時限約束。看門狗定時器作為系統時鐘中斷服務程序的一部分來維護，因此，看門狗定時器的回調函數以系統時鐘中斷級作為中斷服務程序執行。看門狗定時器回調函數受到中斷服務程序的限制，不能調用可能引起阻塞的函數，比如試圖獲取信號量，調用malloc()和free()等創建和釋放內存函數或執行I／O操作。
??? POSIX定時器也可以處理任務時限。此外，VxWorks中一些函數具有時限控制的功能，semTake()、msgQSend()、msgQReceive()函數中都有設定時限控制的參數。超時參數NO_WAIT意味著立即返回，而WAIT_FOREVER意味著程序永不超時。

2 多重定時器實現要求
??? 在VxWorks系統下，利用網絡套接字建立基于UDP協議的客戶端／服務器通信模式。由于UDP是無連接的協議，發送方并不清楚發出的數據包是否已經正確到達接收方，于是提出一種支持重傳和定時等待確認的協議。
??? 這個協議要求發送方發送的數據包與接收方回復的確認包具有對應的序列號，發送方和接收方都可以通過序列號來判斷是不是想要得到的數據包。序列號是循環的，考慮到如果序列號太小會出現折返情況產生混淆，所以序列號至少大于2。如果用1個字節來表示序列號，則可以設定序列號為256。
??? 發送方送出一個數據包后啟動一個定時器。這時可能會有4種情況發生：
??? ①發送方接收到正確序號的確認包，則發送下一序列號的數據包。
??? ②發送方接收到已經接收過的重復確認包，則丟棄該確認包繼續等待。如果在超時前收到了正確確認包，則發送下一序列號的數據包。
??? ③定時器超時，沒有收到想要的確認包，則重新發送數據包，啟動下一定時器。
??? ④設定的多重定時器超時后，沒有收到想要確認包，則通知網絡管理設備。
??? 接收方在收到所需序列號的數據包后，回復一個確認包給發送方。如果接收方回復的確認包后沒有正確到達發送方，則會引起發送方超時，重新發送原序列號數據包。接收方收到數據包后，需要檢查數據包序列號。如果是重復序列號數據包，則丟棄，但是依舊回復確認包給發送方，以免已發送確認包在發送過程中丟失。這里基于支持重傳和定時等待確認協議。具體要求是，在客戶端通過UDP協議發送數據包后啟動一個定時器，等待接收服務器端回復的ACK(acknowl-edgement)確認包。如果成功接收，則繼續發送下一序列號的數據包；如果超時后還沒有收到需要的確認包，則重新傳輸原序列號的數據包。圖1所示為數據包均按時、正確地接收的情況。

??? 一般情況下，假定啟動定時器30 ms內可以完成從發送數據包到接收ACK確認包的全過程，但是由于某些原因使得30 ms內無法收到確認包，則會重傳原數據包，并啟動一個稍長的40 ms定時器。如果40 ms還無法收到確認，則再次重傳原數據包，并啟動一個考慮到最差情況的60 ms定時器。如果依舊無法收到確認則不再發送，通知網絡管理設備。
??? 出現定時器超時情況有3種可能：發送方發送數據包過程中丟包；接收方發送確認包過程中丟包；從發送數據包到確認包到達發送方過程中，延時時間超過定時時間。造成超時有兩方面原因：一是，雙方終端在接收數據包時由于緩沖問題不能及時處理，使得終端出現延時接收數據包或丟包；二是，通信鏈路發生斷鏈情況，導致雙方無法進行通信。從圖2中可以看到，如果鏈路沒有斷開，則包含3種情況的三重定時器超時情況。

3 多重定時器設計
3．1 設計方案
??? 選用看門狗定時器機制來設計。看門狗定時器操作較為簡單，只有4個函數，即wdCreate()、wdDelete()、wdStart()、wdCancel()。看門狗定時器與調用任務異步執行，并不阻塞調用任務，所以看門狗定時器很適合多任務的非阻塞計時。
??? 當看門狗定時器啟動后，如果在規定的30 ms內收到了正確的確認包，就會將定時器取消掉，繼續發送下面的數據包。如果30 ms規定時間內沒有收到確認數據包ACK，則需要重新發送數據包，并啟動第2個40 ms的定時器。VxWorks中單CPU的任務間常用通信機制是消息隊列。當定時器到時后利用消息隊列向發送任務發送消息，通知發送任務重新發送數據包，啟動下一定時器。看門狗定時器的回調函數可以執行msgQSend()這種向消息隊列發送消息的函數，我們通過msgQSend()函數向主任務發送時限已達消息。但是，將msgQSend()的延時參數設為wAIT_FOREVER時，消息隊列中一旦沒有了可用緩沖，則進入等待狀態。由于中斷服務程序優先級高，而從消息隊列中接收消息的優先級低，當有任務準備從消息隊列中取消息時，要等待中斷服務程序執行完畢，則消息隊列始終處于已滿狀態，造成系統死鎖。如果將msgQSend()函數中的延時參數改為NO_WAIT，則可避免一直等待向消息隊列發消息的情況，一旦消息隊列已滿就將該消息丟棄。但這樣一來，向接收端發送數據包任務接收不到定時器超時消息，不會重發原序列號數據包和啟動下一定時器，所以使用參數NO_WAIT也不可行。

??? 這里提出一種避免上述情況造成系統死鎖的方法，即使用信號量機制來使msgQSend()不在中斷服務程序中執行。通過使用信號量的任務間同步機制來實現這個功能。釋放信號量函數semGive()不像msgQSend()那樣需要在消息隊列中等待，一旦執行就可以馬上釋放信號量，從而避免了沖突。
??? 由于任務中事件發生有一定間隔，不必選用計數器信號量，所以選用最常用的二進制信號量。首先建立3個先進先出的二進制信號量，設定可調用信號量為空。然后在看門狗定時器的回調函數中使用semGive()函數來釋放信號量，重建一個任務在任務起始使用semTake()函數來獲取信號量。當獲得信號量后，通過msgQSend(，，，WAIT_FOREVER，)函數向消息隊列中發送超時消息，而且保證只要消息隊列有可用緩沖，就一定可以將消息送出。本文給出一個多重定時器的任務框架，如圖3所示。

3．2 主要實現代碼
??? 一個三重定時器的主要實現代碼如下：

??? 以上程序中通過sysClkRateSet(100)將最小延時單位tick修改成10 ms，它是幾個定時時間(30 ms、40 ms、60ms)的最大公約數。通過抓包軟件Ethereal抓包，查看發送時間。以30 ms為例，抓包100次的平均定時時間在25 ms左右。出現這種情況的原因是，延時N個tick實際是延時(N-1)tick~N·tick。由于是等可能概率，則它的數學期望是(N+1／2)。對于tick為10 ms，30 ms即N=3，數學期望為25 ms。示意圖如圖4所示。

??? 延時精度為1／N秒，N越大越精確。于是調用函數synClkRateSet(500)，可以使定時的最大誤差不超過2 ms。但是如果時鐘頻率太高，會造成系統在時鐘中斷處理方面開銷太大，影響系統的任務調度，最好通過實驗選用較為合適的時鐘頻率。這里選用sysClkRate-Set(200)。

結 語
??? 本文針對VxWorks下UDP網絡通信中的可靠傳輸問題，提出了一個支持重傳和定時等待確認的協議，并利用VxWorks系統提供的信號量同步、消息隊列和看門狗定時器等多種機制，綜合設計了一種可擴展的三重定時器。針對遇到的具體問題，筆者還進行了一定的優化處理。這種多重定時器模型已在筆者所研究的項目中得到利用，驗證了其可行性和相對穩定性。這種多重定時器模型并不完全適合所有環境，需要根據具體情況改進和優化。