嵌入式操做系統任務管理面試進階

嵌入式操做系統最關鍵的技術點就在於任務管理:一篇講透嵌入式操做系統任務調度 那麼是否是把任務調度理解清楚就能輕鬆應對面試呢?並非,面試官會問一些工程中實際碰到的問題。這裏我分享一個以前項目上解決的案例。面試

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源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索