版權聲明：本文爲本文爲博主原創文章，轉載請註明出處。如有問題，歡迎指正。博客地址：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 |