嵌入式操作系统任务管理面试进阶

嵌入式操作系统最关键的技术点就在于任务管理：一篇讲透嵌入式操作系统任务调度 那么是不是把任务调度理解清楚就能轻松应对面试呢？并不是，面试官会问一些工程中实际碰到的问题。这里我分享一个之前项目上解决的案例。

RTOS作为抢占性实时操作系统，高优先级的任务优先执行，如果高优先级的任务出现异常占着CPU不放，低优先级的任务就得不到CPU资源而被饿死。如果被饿死的任务是关键任务，例如智能音箱中负责响应“小爱同学”唤醒词的任务，就会造成系统“假死”或卡顿，严重影响用户体验。因此需要一种监控机制，能够恢复系统，并且上报问题帮助排查。

目前嵌入式主流的任务排查方式有两种：

1、watchdog方案

嵌入式系统常见的watchdog方式，低优先级的任务执行喂狗，喂狗超时则触发系统reset。这种方式的缺点是：

1）无法区分是硬件异常还是软件异常。

2）对于软件异常， 无法指出是哪一个任务哪一段代码出现的问题。

2、CPU占用率分析

通过CPU占用率判断，如果一段时间内CPU负载过高，直接panic。但这种方式也存在缺点，比如可能执行到一段算法，本身负载就很高，过高的标准很难定义，是95%，还是99%？容易误判。

伙伴监控

可以看出以上两种已有方案实际效果都不理想，为了迅速定位问题，我们设计了伙伴监控机制。

               

           

1）为每一个优先级的任务创建一个伙伴任务，固定时间间隔（例如10s）计数器自增。同优先级的任务时间片轮转分时执行，因此同一个优先级别只需要一个伙伴任务。只要这个优先级的伙伴任务正常计数，就表明这个优先级的所有任务都没有被饿死。

2）最高优先级的伙伴任务负责喂狗。因为这个任务优先级最高，如果这个任务也不能执行，说明是硬件异常，watchdog触发系统reset。

3）最高优先级的伙伴任务还负责监控其他伙伴任务的计数，如果某个关键任务（例如智能音箱唤醒任务，或者其他某个需要确保执行的任务，如果不指定，默认为最低优先级别的任务）所对应的伙伴任务的计数器长时间得不到响应（例如5分钟），则判定系统异常，记录所有的伙伴任务计数，并读取当前占用CPU最多的任务的PC地址，然后触发panic，系统静默重启。重启之后自动上传crash report，包含任务计数和占用CPU最多的任务PC地址。

上图中Partner_1、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帮助研发人员快速定位问题。