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

2020-10-01 10:58发布


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


RTOS作为抢占性实时操作系统,高优先级的任务优先执行,如果高优先级的任务出现异常占着CPU不放,低优先级的任务就得不到CPU资源而被饿死。


如果被饿死的任务是关键任务,例如智能音箱中负责响应“小爱同学”唤醒词的任务,就会造成系统“假死”或卡顿,严重影响用户体验。因此需要一种监控机制,能够恢复系统,并且上报问题帮助排查。


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


1、watchdog方案


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


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

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

2、CPU占用率分析


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


2、伙伴监控


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

           

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



登录 后发表评论
0条评论
还没有人评论过~