頻繁中斷狂轟亂炸，操作系統很難招架

6

疾風知勁草，板蕩識忠臣，考驗灑家能耐的時刻到了！

顯然，任務和信號這些概念必須保留下來，皮之不存，毛將焉附？如果沒有了這些概念，所有基于信號進行控制的代碼都要通通改寫！且不說時間是否來得及，單是忙活多日，一覺醒來，卻發現繞回了原點，灑家脆弱的心靈也頗有些難以承受。

不過，沒有了ucos的框架，還要使用在其框架下的概念，就必須找出裸機形式下新的類似框架！既然是照葫蘆畫瓢，我們首先要提取出這顆“葫蘆”的主要特征。

透過代碼的重重迷霧，灑家百般搜索，千般思量，最終認定，新瓢和老葫蘆的共同之處乃是：任務的數據結構和調度機制。

敲敲黑板，畫畫重點。任務是操作系統執行所有功能的載體，操作系統的作用無非是建立各個任務的數據結構，然后設計一個調度機制，讓系統資源在這些任務的執行體里面來回切換、輪轉而已。顯然，新的框架要解決兩個問題，“任務”的數據結構、“任務調度”機制。

在ucos的機制中，每個任務都有自己的消息隊列，向該任務里發信號，就是把信號內容放到這個消息隊列里。Ucos的主要調度機制是每個時鐘滴答下檢查一下是否存在就緒態任務，如果有，進行任務上下文切換，跳轉到新任務體里執行即可。

既如此，我們完全可以設計一種“邏輯任務”，每個任務都有自己的消息隊列，任務執行體里面檢查自己的消息隊列里是否存在新的信號，有信號就執行，和ucos下的形式一模一樣。至于“任務調度”，中斷太頻繁，顯然不可能再照搬著搞任務上下文的存儲和恢復那一套了，裸機形式下的整個系統只有一個上下文，所謂調度完全可以借鑒簡單操作系統里面的按時間片調度，弄成循環執行的方式，依次執行每個任務即可。

如此一來，所有控制任務的執行代碼都不需要進行任何改動，穿梭在各個“邏輯任務”之間的信號依然是之前代碼里定義好的那些信號，最大程度上做到了程序的復用。

更難得的是，在裸機形式的系統里，建立了任務和消息的機制，模塊之間的低耦合強內聚特性得到了保留，為后續代碼的開發和維護提供了大大的方便。

結語

去年桃花此門中，桃花人面相映紅，人面不知何處去，桃花依舊笑春風。Ucos雖然不知跑到那里去了，但是大部分代碼的骨架還在，任務-消息-模塊的神韻猶在。我們唯一需要牢牢記住的只是：頻繁中斷狂轟亂炸，操作系統很難招架。