版權宣告：本文為本文為博主原創文章，轉載請註明出處。如有問題，歡迎指正。部落格地址：https://www.cnblogs.com/wsg1100/
可能大部分人一直好奇VxWorks與xenomai對比，實時性孰優孰劣，正好筆者最近要做一個這方面的對比。宣告：下面資料，僅供個人參考，有不對的地方還請指出。
本文繼上一篇文章【原創】xenomai與VxWorks實時性對比（Jitter對比），主要對比VxWorks與xenomai兩個硬實時作業系統在對各類資源操作時，任務搶佔切換的耗時。
一、環境
簡單介紹一下環境：
硬體平臺：雙核cortex-A15處理器，CPU頻率1.5GHZ,記憶體2GB。
xenomai：Linux-4.19+xenomai 3.1，具體配置：略;
VxWorks：VxWorks 7，具體配置：略;
注：
- 由於VxWorks benchmark測試包含很多測試項，以下資料為其中包含的幾項，每項測試2萬次；xenomai與其一致。
- 既然對比，那麼測試方法、資料處理就得和VxWorks一致，所以xenomai測試用例實現參考VxWorks benchmark測試用例。
- xenomai的資料為使用者態測試，VxWorks資料為核心態測試，測試本身xenomai就處於劣勢，哈哈，有興趣的小夥伴可以將測試用例在xenomai核心態寫一份看看。
- xenomai測試用例使用Alchemy API編寫，Alchemy API是一層posix介面的封裝，所以Alchemy API效能可能弱於POSIX介面。
二、 指標概念
任務切換時間(task switching time)，定義為系統在兩個獨立的、處於就緒態並且具有相同優先順序的任務之間切換所需要的時間。
切換所需的時間主要取決於儲存任務上下文所用的資料結構以及作業系統採用的排程演算法的效率。產生任務切換的原因可以是資源可得，訊號量的獲取等。任務切換是任一多工系統中基本效率的測量點，它是同步的，非搶佔的。影響任務切換的因素有：主機CPU的結構，指令集以及CPU特性等
2.1 單核CPU
即測試相關的任務執行在同一CPU核上，這裡表示單核上的上下文切換。
2.1.1 訊號量響應上下文切換時間
訊號量響應時間是指從一個任務釋放訊號量到另一個等待該訊號量的任務被啟用的時間延遲。 在RTOS中，通常有許多工同時競爭某一共享資源，基於訊號量的互斥訪問保證了任一時刻只有一個任務能夠訪問公共資源。訊號量響應時間反映了與互斥有關的時間開銷，因此也是衡量RTOS實時效能的一個重要指標。
- bmCtxSempend
① 建立兩個任務：高優先順序任務$Task1$ 和 優先順序任務$Task2$；
②$Task1$先非阻塞獲取訊號量，確保訊號量為空。
③$Task1$記錄當前時間T1，再次獲取訊號量導致掛起；
④ 上下文切換到低優先順序任務$Task2$執行，$Task2$讀取時間T2，再釋放訊號量；
⑤$Task1$得到訊號量恢復執行。計算切換時間$T = T2 - T1$,反覆進行②~⑤操作。
⑥最終統計最大值、最小值、平均值。
- bmCtxSemunpend
① 建立兩個任務：高優先順序任務$Task1$ 和 優先順序任務$Task2$；
②$Task1$獲取訊號量導致掛起；
③上下文切換到低優先順序任務$Task2$執行，$Task2$讀取時間$T_1$，再釋放訊號量；
④ 高優先順序$Task1$得到訊號量恢復執行，讀取時間$T_2$。進入下一次迴圈，反覆進行②~⑤操作。
⑤ 最終統計最大值、最小值、平均值。
2.1.2 訊息佇列響應上下文切換時間
與訊號量響應時間類似，是指從一個任務傳送訊息佇列到另一個等待該訊息佇列的任務被啟用的時間延遲。
- bmCtxMsgQPend
① 建立兩個任務：高優先順序任務$Task1$ 和 優先順序任務$Task2$；
② $Task1$記錄當前時間T1，獲取讀取訊息佇列導致阻塞掛起；
③ 上下文切換到低優先順序任務$Task2$執行，$Task2$讀取時間T2，再向訊息佇列傳送Byte資料，傳送後阻塞；
④ $Task1$訊息可用恢復執行。計算切換時間$T = T2 - T1$,反覆進行②~⑤操作。
⑤ 最終統計最大值、最小值、平均值。
- bmCtxMsgQunPend
① 建立兩個任務：高優先順序任務$Task1$ 和 優先順序任務$Task2$；
②$Task1$接收訊息導致掛起；
③上下文切換到低優先順序任務$Task2$執行，$Task2$讀取時間T1，傳送1Byte訊息；
④ 高優先順序$Task1$訊息可用恢復執行，讀取時間T2。進入下一次迴圈，反覆進行②~⑤操作。
⑤ 最終統計最大值、最小值、平均值。
2.1.3 事件響應上下文切換時間
也就是對於event操作的上下文切換，與上面兩種類似不再說明。
2.1.4 任務上下文切換時間
以上測試中，在資源上任務切換，下面是單純的優先順序排程下的任務切換。
需要注意的是：VxWorks中priority數值越高，優先順序越低，xenomai相反。
① 優先順序為50的任務$Task1$ 建立更高優先順序40的任務$Task2$；
② $Task2$建立後立即搶佔，$Task2$執行後立即降低自身優先順序為60，比$Task1$優先順序低
③$Task1$此時為最高優先順序得到執行，讀取時間T1，提升$Task2$優先順序為40；
④ $Task2$此時為最高優先順序搶佔執行，發生一次上下文切換；
⑤ $Task2$執行後立即降低自身優先順序為60；
⑥$Task1$此時為最高優先順序得到執行，發生一次上下文切換；
測試時間$T=T_2-T_1$，包含了1次提升優先順序操作耗時$T_r$、1次降低優先順序操作耗時$T_l$、2次任務切換$T_{sw}$、2次讀取時間戳耗時$T_{rt}$。所以上下文切換時間$T_{sw}=\frac{T-T_r-T_l-2T_{rt}}{2}$。
2.1 SMP
實時任務分別執行在不同CPU上，其任務切換在上述的基礎上，還包含了多核間IPI 通訊（Interrupt-Procecesorr Interrupt處理器間的中斷）耗時。
以bmCtxSemunpend示例如下，其餘的類似不再贅述。
三、 結果對比
3.1 單核
| Vxworks | avg | min | max |
|---|---|---|---|
| bmCtxSemPend | 1.387 | 0.162 | 5.205 |
| bmCtxSemUnpend | 1.389 | 0.162 | 5.205 |
| bmCtxMsgQPend | 1.719 | 0.325 | 6.181 |
| bmCtxMsgQUnpend | 2.183 | 0.487 | 7.807 |
| bmCtxEventPend | 1.349 | 0.000 | 5.042 |
| bmCtxEventUnpend | 1.466 | 0.162 | 5.367 |
| bmCtxTaskSwitch | 0.975 | 0.000 | 4.635 |
| Xenomai | avg | min | max |
|---|---|---|---|
| bmCtxSemPend | 3.597 | 3.252 | 6.345 |
| bmCtxSemUnpend | 3.735 | 3.415 | 7.482 |
| bmCtxMsgQPend | 4.228 | 3.903 | 6.833 |
| bmCtxMsgQUnpend | 5.368 | 5.042 | 8.622 |
| bmCtxEventPend | - | - | - |
| bmCtxEventUnpend | - | - | - |
| bmCtxTaskSwitch | 8.365 | 0.326 | 63.522 |
可以看到xenomaibmCtxTaskSwitch資料比較差，為什麼什麼會這樣呢？VxWorks測試程式與核心都處於核心態（同一地址空間），而xenomai測試則是在使用者態測試，可以回到2.1.4小節，其中$T=T_2-T_1$這段時間內的每一個操作都是必須發起實時系統呼叫來完成的，其中修改優先順序還涉及Linux執行緒部分，除此之外由於系統呼叫路徑複雜，每個系統呼叫時間不是確定的，比如前後兩次修改優先順序操作的時間是不等的，這就造成計算出的$T_{sw}$失真。通俗的說這個測試方法不適合xenomai使用者態，將該測試放到xenomai核心態才與VxWorks具有可比性。
另外，本測試基於xenomai 3.1。xenomai任務對event資源不會發生阻塞喚醒（非搶佔）了，xenomai3.0.8不存在這個問題，所以這兩項沒有測試資料。有興趣的小夥伴可以研究一下，順便還能向社群提個issue或patch，呵呵~~。
3.2 SMP
VxWorks沒有啟用SMP，所以這部分沒有VxWorks的資料，只有xenomai的。
| Xenomai | avg | min | max |
|---|---|---|---|
| CtxSmpAffinitySemUnPend | 3.826 | 3.578 | 8.296 |
| CtxSmpAffinityMsgQUnPend | 5.262 | 4.879 | 8.133 |
| CtxSmpNoAffinitySemUnPend | 3.766 | 3.415 | 6.181 |
| CtxSmpNoAffinityMsgQUnPend | 5.322 | 5.042 | 9.597 |