【序】

---

不知道你發(fā)現(xiàn)沒有，平時我們討論嵌入式軟件開發(fā)時總繞不開與實時性（ Real Time）相關(guān)的話題。相信不少朋友和我一樣是通過實時性操作系統(tǒng)（ R eal Time Operating System, RTOS）第一次接觸到實時性概念的——我記得那還是大學(xué)時代、參加機器人競賽的時候。工作以后自信地以為加深了不少對實時性的本質(zhì)認(rèn)識——現(xiàn)在看來其實還未摸到門道。就這樣渾渾噩噩一直到畢業(yè)后的第八年，因為工作變動的原因，我被迫要在一周內(nèi)要做一個實時性原理相關(guān)的研究報告，也就在那時，我體會到了瘋狂練功走火入魔的感覺：走路在思考、吃飯在看資料、頭一直發(fā)燒一樣的微微發(fā)熱、甚至連睡覺都在夢中推演模型——頭發(fā)一把一把的掉，幸好有截稿時間，否則真的要禿了。

也就是經(jīng)過那一次，我突然發(fā)現(xiàn)自己之前對實時性的認(rèn)知可謂徒有其表，甚至從未做對實時性模型本身的定量分析——所幸，那次研究報告如期交付，工作變動也如愿以償。然而，3年后我發(fā)現(xiàn)“我又雙叕天真了”——那是有一次，我正跟人討論嵌入式基本范式，就突然一個瞬間，腦海中原本毫不相關(guān)的一些模型猛地被聯(lián)系到了一起（音效請腦補）：

我甚至本能的立即意識到：之前自己在某篇文章中“言之鑿鑿”的推論過程其實存在巨大漏洞——當(dāng)然，那本書從未出版過，而且會閑到對我進(jìn)行深究的人估計也沒有幾個。

今天，即便我非常確信——在前方至少還有幾道數(shù)學(xué)的深谷阻礙著我觸碰“實時性”的圣杯——然而我并不是計算機科學(xué)家，現(xiàn)有結(jié)論對我來說已經(jīng)足夠 裝逼 。回頭看來，根據(jù)我的經(jīng)驗以及與朋友討論的結(jié)果，大致認(rèn)為大部分人對實時性的認(rèn)知過程通常會分以下幾個階段：

• Lv1：“實時性” = “越快越好”，認(rèn)為用好中斷是保證實時性的關(guān)鍵；這類朋友通常最擅長的是裸機下的“前后臺系統(tǒng)”；

• Lv2：“實時性” = RTOS，認(rèn)為選一個好的RTOS，或者會用RTOS就可以保證實時性；這一階段的朋友對RTOS充滿了好奇，以編寫自己的RTOS為“ 終（zhong）極（er）目標(biāo)”；

• Lv3：“實時性” = 任務(wù)拆分，這一階段已經(jīng)能正確的理解實時性窗口的概念，意識到實時性并不意味著越快越好，但也認(rèn)為“在可能的情況下”“快一點響應(yīng)事件沒啥壞處”；這一階段的朋友可能已經(jīng)可以在裸機和RTOS之間自由的反復(fù)橫跳，無論是裸機下的狀態(tài)機還是RTOS下的線程都已了如指掌、任務(wù)間通信更是游刃有余；

• Lv4：這一階段開始思考實時性模型的特點，并逐漸意識到模型本身其實隱含了足以顛覆過往所有關(guān)于實時性認(rèn)知的秘密；到達(dá)這一階段的朋友通常覺得沒必要、也沒心思繼續(xù)思考實時性更本質(zhì)的數(shù)學(xué)意義——因為此時獲得的結(jié)論已經(jīng)足夠了應(yīng)付幾乎所有的工程開發(fā)了。順便說一下，我就在這里。

• Lv5：到了這個階段，不僅腦洞大開、戰(zhàn)斗力驚人、估計打針也沒法阻止你抓破脖子了吧——以上只是暴露年齡的玩笑，但肯定可以水幾篇SCI論文了……

在理解了實時性的模型以后，我 （本能的排除了自己比較笨這個可能性，然后 ） 意識到： 其實這一過程完全沒必要如此漫長和曲折——很多結(jié)論和道理是如此簡單——不僅書本上有，而且解釋和學(xué)習(xí)起來都不費什么力氣 。可能這就是“撓破頭”想通某個道理之后，回頭再看時忍不住要“苦笑”時的感受吧。

按照約定，為了將經(jīng)驗和知識分享給大家，從本文開始，我將以幾篇文章的篇幅： 從基礎(chǔ)模型開始，由淺入深、由理論到實踐，推演關(guān)于實時性的幾個重要結(jié)論——從而直接跳躍到Lv4的認(rèn)知階段。如果你看了這個系列后有什么話想說的、想問的，還請在評論區(qū)寫下您的留言。 求評論、求轉(zhuǎn)發(fā)、求收藏。

【擊碎 “唯快不破” 的神話】

一個標(biāo)準(zhǔn)的實時性模型：

• 基于物理世界客觀法則的限制，很多應(yīng)用在制定需求說明的時候，從某一個事件發(fā)生的時刻計算，會規(guī)定一個死線（Dead Line），即：一旦事件發(fā)生了，如果不在這個死線之前完成整個對事件的處理，就視作失?。?

• 這里，從事件發(fā)生到死線這段時間長度，習(xí)慣上稱為實時性窗口。當(dāng)事件發(fā)生時，只有在死線內(nèi)任意時刻完成了對事件的處理，才能稱為實時性得到了滿足；

• 容易注意到，處理事件的過程也需要消耗時間——一般稱為事件處理時間；

考慮一個有趣的問題：對一個實時性任務(wù)來說，實時性窗口內(nèi)的時間，其價值是一樣的么？換句話說，橫豎處理事件消耗的時間是不變的，早點做遲點做都是做，有什么區(qū)別么？

對比三種情況，可以很清楚的得出結(jié)論：理論上， 從滿足實時性的角度出發(fā)，在時間窗口內(nèi)任意時段完成對事件的處理都滿足實時性要求 ；早做沒有任何額外的好處，“踩著上課鈴到校”也沒有任何懲罰——簡單說就是 早做遲做無所謂 。
你說“我不管，我不管”， 既然什么時候做都一樣為什么不能“盡早做”？ “ 你也說了盡早做沒啥不好 ”，“ 中斷來了，服務(wù)程序執(zhí)行了，我想讓它遲點執(zhí)行也做不到??？ ”

為了回答這個問題，我們不講大道理，先看一個常見的例子：

• 超級循環(huán)里有三個任務(wù)A、B和C；

void main(void){ ... while(1) { task_a(); task_b(); task_c(); }}

• 每個任務(wù)都使用輪詢的方式在等待一個來自芯片外界的事件發(fā)生（先不考慮存在中斷的情況）；

• 當(dāng)一個任務(wù)函數(shù)被執(zhí)行時會檢查對應(yīng)的事件是否已經(jīng)發(fā)生，如果確實已經(jīng)發(fā)生，則執(zhí)行后續(xù)的處理；反之則立即退出任務(wù)函數(shù)——釋放處理器；

• A、B、C三個事件的實時性窗口分別為10ms, 6ms和4ms；處理三個事件的處理程序分別需要4ms、3ms和0.4ms。

• 需要強調(diào)的是，task_a()、task_b()和task_c()三個函數(shù)的策略本質(zhì)上都是一樣的——“一旦檢測到事件立即處理，絕不遲延”！

基于上述事實，容易發(fā)現(xiàn)：假如某一時刻，A、B、C三個函數(shù)都處于觸發(fā)狀態(tài)（等待處理的狀態(tài)），而超級循環(huán)恰巧進(jìn)入task_a()執(zhí)行——這種情況其實比想象中容易發(fā)生，比如從task_a()退出到task_c()執(zhí)行完成期間，事件A觸發(fā)了；從task_b()退出到task_c()執(zhí)行完成期間，事件B觸發(fā)了；在task_c退出()之后恰巧事件C又觸發(fā)了……此時，任務(wù)A會立即響應(yīng)，消耗4ms的時間來完成事件處理；當(dāng)從task_a()函數(shù)退出時，剩余給task_b()的時間窗口只有2ms（6ms-4ms），而事件B的處理函數(shù)需要3ms——顯然事件B的實時性是無法得到保證的——當(dāng)然事件C已經(jīng)死得透透了……

通過上面的例子，我們知道“越快處理越好”是值得反思的——至少會存在情況導(dǎo)致系統(tǒng)在某些時刻無法滿足實時性要求；那么從模型上來說，如何理解這一現(xiàn)象呢？讓我們重新來看模型： 實際上，如果單純從一個實時性任務(wù)自身出發(fā)來看，的確在實時性窗口內(nèi)，任意時間完成事件的處理都是一樣的；然而，通過前面的舉例我們其實可以發(fā)現(xiàn)， 當(dāng)一個系統(tǒng)中存在多個實時性任務(wù)時，雖然一個實時性窗口內(nèi)的任意時間對任務(wù)自己都是等價的，但越靠前的時間對“別人”來說是越寶貴的：

• 當(dāng)你使用“越快越好”策略時，你不會有額外的收益，而實際上是走了別人的路，讓人無路可走——典型的損人不利己；

• 當(dāng)你在別人需要的時候，在自己實時性得到保證的前提下，盡可能讓出對你沒有額外價值的靠前的時間，實際上是一種“利他主義”；

• 當(dāng)所有的任務(wù)都采用這種利他策略時，就變成了“人人為我，我為人人”的合作策略——這種情況下，如果數(shù)學(xué)證明整個系統(tǒng)一定存在一個方案來滿足所有任務(wù)的實時性需求，那么利他策略一定能找到這樣的解決方案。

作為一個系統(tǒng)開發(fā)者，我們顯然是需要從全局考慮的，因此完全沒有必要從單個實時性任務(wù)的自私視角來看問題，因此結(jié)論就變得更為直接： 實時性窗口內(nèi)越靠前的時間價值越高，從總體上來看“單純”越快越好的策略對實時性是有害的。

既然單純的“越快越好”不可取，且“實時性窗口內(nèi)”越靠前的時間越有價值，是否意味著，其實“越靠后越好呢”？

為了驗證另外一個極端“越慢越好（越靠后越好）”是否是正確的，我們不妨以同樣的例子來推演一下，僅僅更新 task_a()、 task_b()和 task_c()的執(zhí)行策略：從“越快越好”變?yōu)椤霸铰胶谩薄@實際上意味著：

• 每一個事件處理任務(wù)都清楚的知道“距離事件發(fā)生已經(jīng)過去了多長時間”；

• 為了做到“卡著上課鈴進(jìn)教室”，不到最后時刻，絕對不執(zhí)行任務(wù)處理。

根據(jù)這一算法，我們推演得到以下的尷尬情形：

不妨分析下過程：首先，task_a()執(zhí)行，在了解到距離自己的最后時刻還有6ms的實時后毅然的決定把寶貴的時間留給他人；于是，CPU來到了下一個任務(wù)函數(shù)，基于類似的原因，task_b()也擺擺手……最終第一輪三個任務(wù)都決定再等一等……

如此謙讓（浪費）了3ms以后，任務(wù)B終于決定下場——在執(zhí)行了3ms任務(wù)處理后，成功的將隨后的任務(wù)C逼上了絕路……隨著A的淪陷，大型翻車現(xiàn)場成就達(dá)成……

從結(jié)論上看，另外一個極端“ 越慢越好”也是走不通的 。那么究竟如何才能從模型分析的角度出發(fā)得出一個令人信服的、容易理解的、滿足所有任務(wù)實時性需求的方法呢？關(guān)于這一點，我們下次再聊。

【小結(jié)】

---

從系統(tǒng)全局來看，實時性窗口內(nèi)的時間越靠前越有價值，應(yīng)該盡可能留給別的更緊急的任務(wù)來使用。事件發(fā)生時 “越快處理越好”的策略直接占用了它人的“生命線”——當(dāng)所有的任務(wù)都試圖“損人不利己”時，那么整個系統(tǒng)沒有一個任務(wù)是可以保證自己的實時性不被它人破壞的。 從結(jié)論上看簡單的“越快越好”策略在實時性系統(tǒng)中是不允許的。