【寫在前面的話】

---

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

并得出兩個重要的結(jié)論：

• 實時性只關(guān)注“是否能在實時性窗口內(nèi)完成對應(yīng)事件的處理”，而與事件處理的快慢無直接關(guān)系；

• 從應(yīng)用整體的角度來看，實時性窗口內(nèi)越靠前的時間越珍貴；

  
  

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

今天我們繼續(xù)來借助實時性模型來研究一個看似鐵板釘釘?shù)膯栴}：

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

• 當應(yīng)該頻繁的開關(guān)中斷，系統(tǒng)的實時性還有救么？

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

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

【從一個例子開始】

---

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

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

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

• 這只是一個例子，它存在的意義是為我們提供一個討論的起點，請不必在意和猜測它在實際應(yīng)用中的意義；

• 假設(shè) __disable_irq() 消耗一個周期；當它執(zhí)行完成后，全局中斷會被關(guān)閉；

• 假設(shè) __enable_irq() 消耗一個周期；當它執(zhí)行完成后，全局中斷會被打開；

• 假設(shè) 這里的 while(1) {} 導(dǎo)致的循環(huán)跳轉(zhuǎn)（無條件跳轉(zhuǎn)）會消耗一個周期（其實Cortex-M3/M4就是這樣）；

• 函數(shù) do_some_work() 消耗7個周期。

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

• 從執(zhí)行 do_some_work() 開始到 __enable_irq() 執(zhí)行結(jié)束，總共 7+1=8 個周期——在這期間，中斷都是被屏蔽的；

• 自從“無條件跳轉(zhuǎn)”開始到 __disable_irq() 執(zhí)行結(jié)束，總共 1+1=2 個周期——在這期間，全局中斷是可以被響應(yīng)的；

• 整個循環(huán)占用10個周期：其中8個周期中斷被屏蔽。又由于這是main函數(shù)內(nèi)的超級循環(huán)，因此可以大體推斷出：在整個應(yīng)用執(zhí)行期間 80% 的時間中斷是被屏蔽的。

  
  

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

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

---

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

再圖中，由于中斷被屏蔽而導(dǎo)致事件無法被響應(yīng)，這段時間被稱為“ 事件無法響應(yīng)時間”，結(jié)合模型容易得出：
結(jié)論1：

---

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

---

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

---

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

---

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

【CPU資源磨刀霍霍……】

---

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

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

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

結(jié)論3：

---

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

---

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

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

---

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

---

推論2：

---

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

---

【問出正確的問題】

---

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

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

• 當應(yīng)該頻繁的開關(guān)中斷，系統(tǒng)的實時性還有救么？

現(xiàn)在我們知道，這兩個問題都忽略了一個重要的信息，即：這個系統(tǒng)中單次屏蔽中斷最長的時間是多少？一旦我們獲得了這個時間，我們就可以問出正確的問題：

• 已知當前系統(tǒng)中，最大的中斷屏蔽時間長度為 Tmask；系統(tǒng)頻率為 F；對已有的實時性事件處理來說，系統(tǒng)的實時性是否仍然能夠得到保證？

對每一個具體的系統(tǒng)來說，求解過程也很簡單：

• 由于屏蔽中斷的時候，任何實時性事件都有可能發(fā)生，因此我們要重新計算系統(tǒng)的CPU資源占用——評估它是否接近或超過了 100%

• 計算每一個實時性任務(wù)的CPU占用時，都要把“事件無法響應(yīng)”Tmask 加到 “處理事件所需時間” 里——作為分子去除以作為分母的“實時性窗口”：

【小結(jié)】

---

如果上述討論讓你頭疼，那么記住下面的內(nèi)容基本都不會有錯：

• 頻繁開關(guān)中斷并不可怕；

• 別管關(guān)閉中斷的時間總比例是多大，這沒意義；

• 找到系統(tǒng)中關(guān)閉中斷時間最長的那個代碼，測量它占用的時間——它才是罪魁禍首；

• 使用“以小換大策略”——借助一切可能的手段，使用小的屏蔽來替換掉長時間的屏蔽——無論是屏蔽中斷還是RTOS里的屏蔽調(diào)度，道理都是一樣的。

• RTOS里盡可能用 mutex，而不要長時間關(guān)調(diào)度——因為mutex幾乎是RTOS可以提供的屏蔽時間最短的手段了。

• 裸機自求多福。

—— The End?— —?