CN109992439A - 一种看门狗实现方法 - Google Patents

Abstract

本发明涉及一种看门狗实现方法，在应用程序中创建多个看门狗监控点，所述看门狗监控点由看门狗组件统一管理；创建时可指定所述看门狗监控点在狗叫之后的善后处理方案，以及在狗叫后调用的钩子函数。本发明的有益效果是：程序异常时有多种善后处理方案，无需大量检测计数器，减少CPU消耗。

Description

一种看门狗实现方法

技术领域

本发明涉及软件监控技术领域，更具体地，涉及一种看门狗实现方法。

背景技术

现有技术中，看门狗是在主程序中首先创建一个监控线程，它的优先级高于其他线程。监控线程在其他被监控的线程正常工作的情况下，一定时间内对看门狗进行清狗操作，清狗操作通过调用Watch—dog驱动来完成。如果某个线程出现故障，监控线程就不执行清狗操作，也就达到这个线程出现故障时系统自动重启的目的。如果监控线程自身出现故障，不能及时执行清狗操作，看门狗也自动复位重启。具体做法是，主程序首先启动监控线程，然后依次启动N个被监控的线程，每一线程内都设置一计数器。被监控的线程中首先对线程内的计数器初始化为O，在各个线程主循环中，对相应的计数器执行加1操作。监控任务首先启动看门狗，进入循环。每隔M秒对各线程内的计数器进行检验，在M秒内必须要对看门狗清狗，否则系统就会复位重启。查询N个计数器值是否为0，如果全都大于0，则说明对应接受监控的线程正常运行，然后对看门狗清狗，并将N个计数器值清零。如果有任意一个计数器值为O，检测到对应接受监视的线程出现故障需要重启，这时不对看门狗清狗，使得系统复位重启。通用看门狗技术的缺点如下：

依赖硬件看门狗，通用看门狗方案的实现都直接依赖硬件看门狗，当系统中没有硬件看门狗的情况下将不可使用。

当系统异常之后处理的方法只有复位一个选项，没有其他处理方案。

CPU消耗较高，当被监控的线程很多时，维护检测大量计数器需要消耗较多CPU运算能力。

发明内容

本发明的研究目的，是提出一种解决方案，在不依赖硬件的情况下能正常操作。

一种看门狗实现方法，在主程序中创建多个看门狗监控点，创建时指定所述看门狗监控点在狗叫之后的善后处理方案，以及在狗叫后调用的钩子函数。

进一步的，每个看门狗监控点，允许设置独立的超时时间，被监控任务的清狗时间间隔不得超过超时时间，否则,执行狗叫。

进一步的，所有看门狗监控点，依其超时时间排队，队列头部看门狗监控点的超时时间设定为定时器的超时时间。

进一步的，所述的超时队列，在队列头部的看门狗清狗时，重新排序，并同时调整定时器的超时时间。

进一步的，所述定时器超时，即认为看门狗监控点狗叫。

进一步的，狗叫后，执行设置的善后处理方案，并调用钩子函数。

进一步的，所述善后处理方案包括：关闭某个装置、向外发出告警、求救信号。

进一步的，所述钩子函数执行紧急关闭某个装置及向外发出告警或求救信号。

进一步的，所述看门狗监控点能够区分是被监控程序自身错误导致狗叫，还是因CPU被其他线程抢占而没有机会运行而导致狗叫，并区分处理。

本发明的有益效果是：

软件看门狗是一个独立的软件模块，即使没有硬件看门狗，也能起到监视其他软件模块的功能。

当被监控的软件模块异常后，能够立即得到处理，无需等到硬件看门狗溢出。

被监控模块发生异常后的处理方案可以灵活设置，不再只有系统复位。

如果存在硬件看门狗，则硬件看门狗作为看门狗模块的一个看门狗监控点而存在，其驱动程序设计完全独立于软件看门狗模块，提高了模块的独立性。

无需大量检测计数器，减少CPU消耗。

附图说明

图1是本发明的具体实施例的看门狗操作类型示意图。

图2是本发明的具体实施例的看门狗队列示意图。

图3是本发明的具体实施例的监控任务流程示意图。

图4是本发明的具体实施例的看门狗模块工作原理图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的装置和计算方法进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明涉及一种看门狗实现方法，在主程序中创建多个看门狗监控点，创建时指定所述看门狗程序在狗叫之后的善后处理方案，以及在狗叫后调用的钩子函数。

在看门狗系统中，应用程序能看到很多看门狗监控点，且所有的监控点都是平等的，拥有相同的属性，用户像创建信号量一样创建一个监控点。当创建成功后，就可以用此监控点来执行其监视功能了。一般而言，用户对看门狗的用法如图1所示。A是用看门狗检查关键代码有没有定期执行到；B除A的功能外，还检查执行结果是否正确；C比B更彻底，检测到致命问题后，不再清狗，坐等看门狗超时，由看门狗模块做善后处理；D用于监控限期完成的任务。E是一个善后处理函数，应用程序提供，由看门狗模块在检测到清狗异常时调用，应用程序可以在此做各种善后操作，例如发出告警信息或者紧急纠错等。看门狗能够区分被监控程序自身错误导致狗叫，因CPU被其他线程抢占而没有机会运行而导致狗叫，在本发明的具体实施例中能区分处理。

结合图1，本发明的实施例中，看门狗程序代码如下：

typedef u32(*fnYipHook)(void*wdt)；

typedef struct__tagWdt

上述代码中，fnhook,是所述的善后处理函数，当看门狗叫时，能急需关闭某个装置或者向外发出告警或者求救信号，这些功能可以放在该hook中进行；同时该hook的返回值也很重要，详见enum_EN_EXP_DEAL_TYPE_的定义，该值规定看门狗模块采取的下一步行动。

action,当没有注册fnhook或者fnhook的返回值是EN_EXP_DEAL_DEFAULT时候，将会采用action的值作为下一步行动。

cycle,看门狗的周期，即所谓的狗叫周期，相对于最后一次操作看门狗的狗叫期限，该时间为相对时间。

taskownid,看门狗所属的任务的ID(DJYOS的EVENTID号)。

deadtime，看门狗清狗截止期限，该时间是绝对时间，从系统启动时算起的时间，如果在此时间前没有清狗，看门狗就会叫。

runtime,最后一次操作看门狗时，该看门狗任务已经运行的时间的快照。

runtimelevel，看门狗狗叫原因的判断标准；虽然看门狗的狗叫是因为没有及时清狗，但是原因却多种多样，一种是该任务由于调度而被经常打断导致没有时间运行完导致的清狗失败，该种我们称之为EN_WDT_YIPFORSHEDULE——调度原因；另外一种是该任务的运行时间充足，但是因为出现了逻辑错误而出现死循环等，该种我们称之为EN_WDT_YIPFORLOGIC—逻辑原因。就是从最后一次操作看门狗起，到狗叫时止所属任务所获得的CPU时间，如果这段时间大于runtimelevel则证明是时间充足却没有去清狗，即所谓的逻辑错误；否则就是调度原因。本本发明的具体实施例中，看门狗能够区分被监控程序自身错误导致狗叫。

timeoutreason，看门狗叫的原因。

shyiptimes，因为调度原因导致的连续狗叫的次数，当该次数大于sheduletimeslevel的时候fnhook的返回值或者action的值就会被看门狗组件采纳，从而执行相应的动作。

sheduletimeslevel，该系统能够忍耐该看门狗的因为调度原因连续的狗叫次数。

如图2所示，所有的软件看门狗由ppre和pnext成员链接成双向不循环链表，其在链表中的位置按照其自身的deadtime的从小到大的顺序排列，即排在队头的看门狗的狗叫的deadtime是离当前时间最近的。当用户主动操作看门狗(包括清狗)时，都会使该看门狗的deadtime＝ostime+cycle,这样会导致其在看门狗队列中的位置发生变化。

看门狗已经按照自己的deadtime已经排成了有序队列，那么我们如何发现看门狗超时或者没有超时？方法很简单，我们只需要用一个任务来检查当前的看门狗的deadtime，如果大于系统的运行时间OStime，则证明该看门狗还未超时，否则就是超时。当检查看门狗队列时，我们并不一定要检查整个看门狗队列，因为整个队列是按照时间排列的有序队列，因此我们只要处理到第一个不超时的看门狗即可，在此看门狗前面的所有看门狗应该都是不超时的，由看门狗监视任务负责检查。

如图3监视任务的运行流程所示，首先开启监视任务，上述监视任务并不是周期运行的，接着处理所有缓存消息，确定等待时间，主要是看第一个看门狗的timeout距离现在时间点还有多久，指定等待消息，在指定的时间内如果没有消息到达，则执行超时激活，否则执行收到消息激活，如等待成功，则处理消息队列，扫描处理超时的看门狗。如果监视看门狗的时间比较精确，那么该任务会运行的比较密集，而该任务的优先级比较高，因此会占用大量的CPU时间，导致整个系统的性能下降。本发明的具体实施例中采用的是按需等待的事件驱动方式。该任务不仅仅监视看门狗队列是否有看门狗在叫，还接收用户发送的各种操作看门狗的指示，即利用消息队列发送的消息。

从图3中还可以看出，监视任务的运行是按需运行：1，有新消息到来；2，看门狗队列头的deadtime到了。

整个软件看门狗模块的设计如图4所示，从图中可以看出，用户对看门狗的操作需求都是通过发送消息给监视任务，由监视任务完成用户对看门狗的需求操作。这么做的优点很明显：用户需求和看门狗监视任务之间基本无耦合，对看门狗队列的操作只会由监视任务进行，不会引起竞争。当清看门狗时，如果该看门狗的deadtime不影响监视任务的等待时间，就不必发送消息给监视任务，从而提高执行效率。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (9)

1.一种看门狗实现方法，其特征在于，在主程序中创建多个看门狗监控点，创建时指定所述看门狗监控点在狗叫之后的善后处理方案，以及在狗叫后调用的钩子函数。

2.根据权利要求1所述的看门狗实现方法，其特征在于，每个看门狗监控点，允许设置独立的超时时间，被监控任务清狗时间间隔不得超过超时时间，否则,执行狗叫。

3.根据权利要求1所述的看门狗实现方法，其特征在于，所有看门狗监控点，依其超时时间排队，队列头部看门狗监控点的超时时间设定为定时器的超时时间。

4.根据权利要求3所述的看门狗实现方法，其特征在于，所述的超时队列，在队列头部的看门狗监控点清狗时，重新排序，并同时调整定时器的超时时间。

5.根据权利要求3所述的看门狗实现方法，其特征在于，所述定时器超时，即认为看门狗程序狗叫。

6.根据权利要求5所述的看门狗实现方法，其特征在于，狗叫后，执行设置的善后处理方案，并调用钩子函数。

7.根据权利要求6所述的看门狗实现方法，其特征在于，所述善后处理方案包括：关闭某个装置、向外发出告警、求救信号。

8.根据权利要求6所述的看门狗实现方法，其特征在于，所述钩子函数执行紧急关闭某个装置及向外发出告警或求救信号。

9.根据权利要求1所述的看门狗实现方法，其特征在于，所述看门狗监控点能够区分是被监控程序自身错误导致狗叫，还是因CPU被其他线程抢占而没有机会运行而导致狗叫，并区分处理。