關(guān)注+星標(biāo)公眾號，不錯過精彩內(nèi)容

作者 |?傻孩子

轉(zhuǎn)自?|?裸機思維

下面分享一篇王工（網(wǎng)名：傻孩子）整理的文章：

【序】

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

• 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)知的秘密；到達這一階段的朋友通常覺得沒必要、也沒心思繼續(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ā)、求收藏。

• 基于物理世界客觀法則的限制，很多應(yīng)用在制定需求說明的時候，從某一個事件發(fā)生的時刻計算，會規(guī)定一個死線（Dead Line），即：一旦事件發(fā)生了，如果不在這個死線之前完成整個對事件的處理，就視作失敗；
• 這里，從事件發(fā)生到死線這段時間長度，習(xí)慣上稱為實時性窗口。當(dāng)事件發(fā)生時，只有在死線內(nèi)任意時刻完成了對事件的處理，才能稱為實時性得到了滿足；
• 容易注意到，處理事件的過程也需要消耗時間——一般稱為事件處理時間；
  

圖1?實時性基本模型

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

圖2 實時性窗口內(nèi)不同時間段完成事件響應(yīng)

對比圖2所示的三種情況，可以很清楚的得出結(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。如圖3所示：

圖3?三個事件的實時性窗口和事件處理時間示意圖

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

圖 4?“越快處理越好” 導(dǎo)致其它任務(wù)無法滿足實時性要求

通過上面的例子，我們知道“越快處理越好”是值得反思的——至少會存在情況導(dǎo)致系統(tǒng)在某些時刻無法滿足實時性要求；那么從模型上來說，如何理解這一現(xiàn)象呢？

讓我們重新來看圖1所示的模型：

實際上，如果單純從一個實時性任務(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)越靠前的時間價值越高，從總體上來看“單純”越快越好的策略對實時性是有害的。

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

• 每一個事件處理任務(wù)都清楚的知道“距離事件發(fā)生已經(jīng)過去了多長時間”；
• 為了做到“卡著上課鈴進教室”，不到最后時刻，絕對不執(zhí)行任務(wù)處理。

圖 6?過于謙讓的后果……

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

【小結(jié)】

精選匯總 | 專欄 | 目錄 | 搜索

精選匯總 | ARM、Cortex-M

精選匯總?| ST工具、下載編程工具

點擊“閱讀原文”查看更多分享，歡迎點分享、收藏、點贊、在看。