嵌入式操做系統最關鍵的技術點就在於任務管理：一篇講透嵌入式操做系統任務調度 那麼是否是把任務調度理解清楚就能輕鬆應對面試呢？並非，面試官會問一些工程中實際碰到的問題。這裏我分享一個以前項目上解決的案例。面試
RTOS做爲搶佔性實時操做系統，高優先級的任務優先執行，若是高優先級的任務出現異常佔着CPU不放，低優先級的任務就得不到CPU資源而被餓死。若是被餓死的任務是關鍵任務，例如智能音箱中負責響應「小愛同窗」喚醒詞的任務，就會形成系統「假死」或卡頓，嚴重影響用戶體驗。所以須要一種監控機制，可以恢復系統，而且上報問題幫助排查。算法
目前嵌入式主流的任務排查方式有兩種：微信
一、watchdog方案spa
嵌入式系統常見的watchdog方式，低優先級的任務執行喂狗，喂狗超時則觸發系統reset。這種方式的缺點是：操作系統
1）沒法區分是硬件異常仍是軟件異常。.net
2）對於軟件異常， 沒法指出是哪個任務哪一段代碼出現的問題。設計
二、CPU佔用率分析blog
經過CPU佔用率判斷，若是一段時間內CPU負載太高，直接panic。但這種方式也存在缺點，好比可能執行到一段算法，自己負載就很高，太高的標準很難定義，是95%，仍是99%？容易誤判。資源
夥伴監控get
能夠看出以上兩種已有方案實際效果都不理想，爲了迅速定位問題，咱們設計了夥伴監控機制。
1）爲每個優先級的任務建立一個夥伴任務，固定時間間隔（例如10s）計數器自增。同優先級的任務時間片輪轉分時執行，所以同一個優先級別只須要一個夥伴任務。只要這個優先級的夥伴任務正常計數，就代表這個優先級的全部任務都沒有被餓死。
2）最高優先級的夥伴任務負責喂狗。由於這個任務優先級最高，若是這個任務也不能執行，說明是硬件異常，watchdog觸發系統reset。
3）最高優先級的夥伴任務還負責監控其餘夥伴任務的計數，若是某個關鍵任務（例如智能音箱喚醒任務，或者其餘某個須要確保執行的任務，若是不指定，默認爲最低優先級別的任務）所對應的夥伴任務的計數器長時間得不到響應（例如5分鐘），則斷定系統異常，記錄全部的夥伴任務計數，並讀取當前佔用CPU最多的任務的PC地址，而後觸發panic，系統靜默重啓。重啓以後自動上傳crash report，包含任務計數和佔用CPU最多的任務PC地址。
上圖中Partner_一、Partner_2等爲夥伴任務，最高優先級夥伴任務Partner_1負責喂狗和監測異常，其餘夥伴任務負責計數。
加入優先級爲8的Task_8_A異常進入死循環，致使優先級爲9的關鍵任務Task_9_C被餓死。最高優先級夥伴任務Partner_1，監測到關鍵任務Task_9_C對應的夥伴Partner_9連續5分鐘計數異常，則記錄計數器數值，同時高一個優先級的任務中找到CPU佔用率最高的Task_8_A，記錄PC地址，而後觸發panic，系統重啓。
夥伴監控的優勢
1）多級夥伴任務
使用多個夥伴任務，覆蓋每個不一樣的優先級，能夠快速定位是硬件異常仍是哪個級別的任務出現軟件異常。
2）經過計數準確斷定任務餓死
使用計數器，準確斷定任務餓死，避免了經過CPU負載斷定而形成的誤判。
3）快速定位致使任務餓死的緣由
異常處理採用靜默重啓，使得用戶無感。同時可以上傳crashreport幫助研發人員快速定位問題。
本文分享自微信公衆號 - 機械猿（on_ourway）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。