當前位置：首頁 > > 小麥大叔

實時性迷思(3)——80%時間屏蔽了中斷，實時性還有救么？

時間：2020-12-29 11:58:44

關鍵字：時間屏蔽開關中斷

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]當應用在運行時有大比例的時間屏蔽了中斷，系統(tǒng)的實時性還有救么？當應該頻繁的開關中斷，系統(tǒng)的實時性還有救么？

【寫在前面的話】

在本系列的第一篇文章《實時性迷思(1)——快是優(yōu)點么？》中，我們介紹了實時性的基本模型：

并得出兩個重要的結論：

實時性只關注“是否能在實時性窗口內完成對應事件的處理”，而與事件處理的快慢無直接關系；
從應用整體的角度來看，實時性窗口內越靠前的時間越珍貴；

這個模型本身并不復雜，但 “你以為你懂了” 和 “能夠回答實際問題” 或者是“能夠得出有意義的推論” 還是有相當的距離的。比如上一篇文章《實時性迷思(2)——“時間片輪轉”的沙子》，我們就推導出了“驚人”的結論： 高頻率的時間片輪轉會浪費大量處理器時間，從最終效果來看對系統(tǒng)的實時性是有害的！

今天我們繼續(xù)來借助實時性模型來研究一個看似鐵板釘釘的問題：

當應用在運行時有大比例的時間屏蔽了中斷，系統(tǒng)的實時性還有救么？
當應該頻繁的開關中斷，系統(tǒng)的實時性還有救么？

這里的兩個問題，其實都沒有切中要害，如果硬要回答的話，有經驗的老鳥會首先說： 你提供的信息不足。

這又是為什么呢？（懶得看中間過程的小伙伴可以直接看文章最后的結論）

【從一個例子開始】

復雜的理論不必多說，我們首先來看一個極端的例子：

int main(void){ ...  while(1) { __disable_irq(); //!?關閉全局中斷 do_some_work(); //!?經過測量，占用了7個周期 __enable_irq(); //! 開啟全局中斷 }}

這個代碼本身并不復雜，事實上，它在前后臺系統(tǒng)中非常典型。作為例子，這里有幾個要點需要首先明確：

這只是一個例子，它存在的意義是為我們提供一個討論的起點，請不必在意和猜測它在實際應用中的意義；
假設 __disable_irq() 消耗一個周期；當它執(zhí)行完成后，全局中斷會被關閉；
假設 __enable_irq() 消耗一個周期；當它執(zhí)行完成后，全局中斷會被打開；
假設這里的 while(1) {} 導致的循環(huán)跳轉（無條件跳轉）會消耗一個周期（其實Cortex-M3/M4就是這樣）；
函數 do_some_work() 消耗7個周期。

基于上述假設，我們很容易發(fā)現，在一次循環(huán)中：

從執(zhí)行 do_some_work() 開始到 __enable_irq() 執(zhí)行結束，總共 7+1=8 個周期——在這期間，中斷都是被屏蔽的；
自從“無條件跳轉”開始到 __disable_irq() 執(zhí)行結束，總共 1+1=2 個周期——在這期間，全局中斷是可以被響應的；
整個循環(huán)占用10個周期：其中8個周期中斷被屏蔽。又由于這是main函數內的超級循環(huán)，因此可以大體推斷出：在整個應用執(zhí)行期間 80% 的時間中斷是被屏蔽的。

這符合本文一開頭所提出的兩個問題的條件，即：大比例的時間屏蔽了中斷 和 頻繁的開關中斷。

【是時候搬出模型了……】

那么，在這個例子中，實時性會受到怎樣的影響呢？我們不妨結合模型，看一個最壞情況，即，剛開始執(zhí)行 do_some_work() 的時候，某一事件發(fā)生——實時性窗口開始計時：

再圖中，由于中斷被屏蔽而導致事件無法被響應，這段時間被稱為“ 事件無法響應時間”，結合模型容易得出：
結論1：

只要“事件無法響應時間”與“處理事件所需時間”的總和超過了“實時性窗口”，當前事件處理的實時性就無法保證了。

正如前面幾篇文章一再強調的那樣，時間的實時性窗口是來自物理世界的，基于物理時間計算的絕對值。這里CPU周期其實是一個相對值——系統(tǒng)頻率越高，8個周期對應的物理時間就越短；系統(tǒng)頻率越低，8個周期對應的物理時間就越長（當然還要考慮處理事件所需的時間也會隨著頻率的變化而變化）。對現今大部分動輒幾十兆赫茲，或者上百兆赫茲的單片機系統(tǒng)來說，8個周期可能連1us都不到（作為參考當系統(tǒng)是 8MHz時，8個周期正好1us）。
結論2：

當且僅當系統(tǒng)頻率已知時，我們才能根據CPU的周期數計算出“ 事件無法響應時間”和“ 處理時間所需時間”——也 只有都換算成相同單位時，與實時性窗口的比較才有意義。

一個應用中往往有多個具有實時性要求的事件，在已知系統(tǒng)頻率的情況下，我們可以將“事件無法響應時間” 拉到每一個實時性窗口中一一比較，只要任何一個不滿足，我們就可以宣告整個系統(tǒng)實時性的破產。然而，如果所有單獨比較的結果都令人滿意，我們是否就可以宣告：由屏蔽中斷所導致的“ 事件無法響應時間”足夠短，不會對系統(tǒng)的實時性造成影響呢？——高興的太早了。

【CPU資源磨刀霍霍……】

一個實時性應用中往往不止一個事件有實時性要求，因此，判斷系統(tǒng)的實時性是否所有保證從來都不是只單純的在每一個實時性窗口內做比較就能解決的。就像上面所說的那樣，由于屏蔽中斷的時候，任何事件都可能發(fā)生，因此，由屏蔽導致的“事件無法響應時間”必須帶入到每一個實時性窗口中去進行比較。
僅僅只是這樣，仍然不夠。由于CPU資源有限，我們還必須確認在“最差情況下”扣除了中斷屏蔽期間所占用的CPU資源后，仍然有足夠的CPU資源來滿足其它實時性窗口的需求。關于如何計算每個實時性任務的CPU資源占用，可以通過文章《實時性迷思(2)——“時間片輪轉”的沙子》來復習，仍然有印象的同學可以直接看下面這張圖片來喚醒記憶：

這里有一個誤區(qū)非常值得闡明：即，在前面的例子中，我們說“系統(tǒng)有80%的時間都在屏蔽中斷”，這是否意味著，屏蔽中斷占用了 80%的CPU資源——只剩下20%的CPU時間用于實時性處理了呢？也許你愣住了。但答案很類似腦經急轉彎——并不是這樣，因為在我們討論的前后臺系統(tǒng)中，其實隱含了一個假設——實時性的響應是通過中斷來進行的——既然是中斷，就是可搶占的，因此，即便8個周期內無法響應， 只要那一個周期開了口子，CPU的資源就被實時性處理程序搶走了。

思考這個問題，實際上直接引出了第三個重要的結論：

結論3：

“事件無法響應時間” 不看積累下來的總量，而 只看單次最大能連續(xù)拖延實時性相應多久。

要理解這個結論，其實并不困難。這就好比PWM，在較長的時間內，占空比相同而頻率不同的PMW，其高電平的總時間是相同的（占空比相同）；但頻率不同的PMW實際上每次高電平的持續(xù)時間是不同的——頻率越低，當然每個周期內高電平時間越長。

套用到屏蔽中斷對實時性的影響上來說：
推論1：

屏蔽中斷并不可怕，哪怕積累下來的時間占比很大，只要每次屏蔽的時間足夠短，就能有效的減小對系統(tǒng)實時性的影響——換句話說，高頻率的開關中斷很可能還是有益實時性的（關鍵還看 推論2）。

推論2：

如果系統(tǒng)中存多個對實時性響應的屏蔽（比如裸機中的屏蔽中斷、RTOS中的關閉調度），根據木桶原理，只 以單次屏蔽時間最長的那個來評估對系統(tǒng)實時性的影響。

【問出正確的問題】

文章的開始部分，我們提出了兩個問題：