嵌入式操做系统最关键的技术点就在于任务管理：一篇讲透嵌入式操做系统任务调度 那么是否是把任务调度理解清楚就能轻松应对面试呢？并非，面试官会问一些工程中实际碰到的问题。这里我分享一个以前项目上解决的案例。面试
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源创计划”，欢迎正在阅读的你也加入，一块儿分享。