一种嵌入式实时操作系统死锁自动检测方法、系统及介质

摘要

本发明适用于操作系统技术领域，涉及一种嵌入式实时操作系统死锁自动检测方法，包括：S10、当线程Thread_a获取锁Mutex_b失败时，查看锁的持有者P；S20、若锁的持有者P为线程Thread_a，则为线程多次获取同一个互斥锁死锁情况，系统进入死锁异常处理；S30、若锁的持有者P为线程Thread_b，则查看线程Thread_b是否在等待锁资源；S40、若线程Thread_b不在等待锁资源，则无死锁，若线程B在等待锁资源，则查看等待的锁Mutex_a的持有者P是否为线程Thread_a，若是，则系统进入死锁异常处理，否则无死锁。本发明可快速定位系统死锁，提高系统的安全性能和开发人员的排查效率。

说明书

技术领域

本发明属于操作系统技术领域，尤其涉及一种嵌入式实时操作系统死锁自动检测方法、系统及介质。

背景技术

进入21世纪以来，以计算机技术、通信技术和软件技术为核心的信息技术取得了迅猛的发展，各种装备与设备上嵌入式计算与系统的广泛应用大大地推动了行业的渗透性应用。嵌入式实时操作系统使用包括物联网、工业控制、机器人、边缘计算、电力行业、航天航空等等，软件系统越来越复杂，往往涉及到多线程编程，资源保护大量使用锁保护但是很多程序由于系统死锁问题(死锁是指多个线程或进程因竞争资源而造成的一种互相等待的僵局，若无外力作用，这些线程或进程都将无法向前推进)导致系统崩溃，排查起来非常困难也很难复现，消耗了大量人力资源的同时也给系统安全留下隐患。

为了解决上述技术问题，现有技术中第一种方法通常通过代码调试日志分析或有经验的程序员从代码编码进行规避掉，但这种方法需要花费大量时间去排查而且需要对操作系统非常深入了解的资深工程师，无法全部排除死锁风险的代码；第二种方法是通过软件看门狗和硬件看门狗来复位系统，通过最低优先级任务来喂狗，硬件看门狗同时查询各个任务切换状态，如果在规定的时间内任务没有切换就重启系统，此种方法需要增加软件复杂度，对编程人员要求高且同样无法从根本解决问题，对安全性要求高的系统可能不允许重启；第三种方法是通过设置锁超时规定时间无法获取此锁自动退出，此种方法严重影响系统性能，会因为死锁超时导致线程在这段时间无法工作，由于这段时间无法响应可能导致系统异常，严重时还会出现安全事故。

公开号为CN102253859A的专利提供了一种嵌入式设备系统死锁调试装置及方法，通过在系统死锁发生后产生按键中断或芯片电平拉高中断的中断方式，运行中断程序，在中断处理程序中将系统程序执行状态用LCD屏幕直观地显示出来，让用户根据CPU寄存器参数数据，查找系统软件编译时的obj或map目标文件来定位故障。此种方法需要人工对系统软件编译时的obj或map目标文件进行排查定位，精确度难以保证的同时也耗费了大量的时间与人力成本。

因此，如何提供一种可快速检测定位系统死锁的方法是本技术领域人员亟待解决的问题。

发明内容

针对现有技术的不足，本发明的目的是提供一种嵌入式实时操作系统死锁自动检测方法，以解决现有技术中无法快速定位系统死锁以致开发人员的排查效率和系统安全性能低下的问题；另外本发明还提供了一种嵌入式实时操作系统死锁自动检测系统及介质。

为了解决上述技术问题，本发明采用了如下的技术方案：

第一方面，本发明提供了一种嵌入式实时操作系统死锁自动检测方法，包括以下步骤：

S10、当线程Thread_a获取锁Mutex_b失败时，查看锁的持有者P；

S20、若锁的持有者P为所述线程Thread_a，则为线程多次获取同一个互斥锁死锁情况，系统进入死锁异常处理；

S30、若锁的持有者P为线程Thread_b，则查看所述线程Thread_b是否在等待锁资源；

S40、若所述线程Thread_b不在等待锁资源，则无死锁，若线程B在等待锁资源，则查看等待的锁Mutex_a的持有者P是否为线程Thread_a，若是，则系统进入死锁异常处理，否则无死锁。

进一步的，操作系统锁的数据结构含有记录锁的持有线程的数据项，若锁被线程持有时，则所述锁的数据项指向所述线程，若所述锁没有被所述线程持有时，则所述锁的数据项指向无效值。

进一步的，操作系统线程的数据结构含有记录等待锁的数据项，若线程在等待锁，则所述线程的数据项指向所述锁，若所述线程没有等待所述锁，则此线程数据项指向无效值。

进一步的，所述线程和所述锁的信息由死锁检测模块输出。

进一步的，所述步骤S10中锁的持有者P表示为mutex_b->holder_thread_p。

进一步的，所述步骤S30中，查看所述线程Thread_b是否在等待锁资源的判断依据为thread_b->wait_mutex_p是否指向有效值。

进一步的，所述步骤S40中，线程Thread_b不在等待锁资源的依据为thread_b->wait_mutex_p指向无效值。

进一步的，所述步骤S40中，查看等待的锁Mutex_a的持有者P表示为thread_b->wait_mutex_p->holder_thread_p。

第二方面，本发明还提供了一种嵌入式实时操作系统死锁自动检测系统，包括：保护模块，具有互斥锁功能，用于资源互斥保护；记录模块，用于记录当前获取锁的线程信息、线程获取锁失败时锁的信息；死锁判断模块，用于系统运行时监测是否发生死锁并输出相关信息；告警模块，用于系统进入死锁异常处理时输出告警信息；所述保护模块、记录模块、死锁判断模块和告警模块依次连接。

第三方面，本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上所述的一种嵌入式实时操作系统死锁自动检测方法。

本发明提供的一种嵌入式实时操作系统死锁自动检测方法、系统及介质与现有技术相比，至少具有如下有益效果：

本发明可自动检测系统互斥锁死锁并输出死锁线程信息，包括线程名字和互斥锁名字，方便开发人员定位系统死锁，提高排查效率和系统安全性能。

附图说明

为了更清楚地说明本发明的方案，下面将对实施例描述中所需要使用的图作一个简单的介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种嵌入式实时操作系统死锁自动检测方法的流程图；

图2为本发明实施例提供的一种嵌入式实时操作系统死锁自动检测方法中线程交叉死锁时线程和锁数据结构状态图；

图3为本发明实施例提供的一种嵌入式实时操作系统死锁自动检测方法中线程多次获取同一锁死锁时线程和锁数据结构状态图；

图4为本发明实施例提供的一种嵌入式实时操作系统死锁自动检测系统结构图。

具体实施方式

除非另有定义，本文所使用的所有技术和科学术语与属于本发明技术领域的技术人员通常理解的含义相同；本文在说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明，例如，术语“长度”、“宽度”、“上”、“下”、“左”、“右”、“前”、“后”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置为基于附图所示的方位或位置，仅是便于描述，不能理解为对本技术方案的限制。

本发明的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含；本发明的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。本发明的说明书和权利要求书及上述附图说明中，当元件被称为“固定于”或“安装于”或“设置于”或“连接于”另一个元件上，它可以是直接或间接位于该另一个元件上。例如，当一个元件被称为“连接于”另一个元件上，它可以是直接或间接连接到该另一个元件上。

此外，在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本发明提供了一种嵌入式实时操作系统死锁自动检测方法，应用于实时操作系统如FreeRTOS、μCOS等，首先需要声明的是，操作系统锁的数据结构必须含有(holder_thread_p)记录锁的持有线程的数据项，如果操作系统无此数据项需要添加，若锁被线程持有时，则所述锁的数据项指向所述线程，若所述锁没有被所述线程持有时，则所述锁的数据项指向无效值(NULL)；操作系统线程的数据结构必须含有(wait_mutex_p)记录等待锁的数据项，如果操作系统无此数据项需要添加，若线程在等待锁，则所述线程的数据项指向所述锁，若所述线程没有等待所述锁，则此线程数据项指向无效值(NULL)；本实施例中，结合图1、图2和图3，包括以下步骤：

S10、向操作系统互斥锁数据结构添加holder_thread_p数据项用于记录当前锁拥有者线程信息，当线程获取锁失败时可以通过锁的此数据结构查看哪个线程拥有该锁，进一步可以获取到拥有此锁线程信息从而来分析死锁；

S20、向操作系统线程数据结构添加wait_mutex_p数据项，用于记录当前线程在等待锁的信息，当发生死锁时候可以通过此数据结构查看当前线程拥有锁的情况而进行分析是否存在死锁；

S30、当线程Thread_a获取锁Mutex_b失败时，查看锁的持有者P；

具体地，锁的持有者P表示为mutex_b->holder_thread_p，由于死锁发生在系统获取锁失败的时候，所以当获取锁失败需要查看是否因死锁导致，要排查是否是死锁，必须获取当前锁拥有者线程信息，而当前锁拥有者信息可以通过步骤S10中添加的锁数据结构中的holder_thread_p数据项获取到，通过此数据项可以获取到拥有此锁的线程信息，从而用于进一步分析死锁；

S40、若锁的持有者P为线程Thread_a，则为图3中的线程多次获取同一个互斥锁死锁情况，系统进入死锁异常处理；

具体地，死锁存在两种情况，一种是交叉死锁，另外一种是本线程多次获取同一锁导致死锁，所以先排查当前死锁的锁拥有者是否是本线程，通过当前锁数据结构holder_thread_p寻找到拥有此锁的线程信息，从而查看此锁拥有者是不是当前线程Thread_a，如果是就说明已死锁，且是同一线程存在多次获取此锁的情况，此时系统可以输出警告日志信息通知使用者存在死锁，警告信息包括但不限于如下信息：

a.当前锁的信息如锁的名字；

b.当前线程信息如线程的名字；

c.死锁类型为同一锁被线程多次获取；

S50、若锁的持有者P为线程Thread_b，则查看线程Thread_b是否在等待锁资源；

具体地，查看所述线程Thread_b是否在等待锁资源的判断依据为thread_b->wait_mutex_p是否指向有效值，可以查看线程Thread_b的数据结构wait_mutex_p数据项，此数据项通过步骤S20添加，记录了此线程是否在等待锁，此操作可以通过wait_mutex_p数据项内容进一步查看是否是交叉死锁情况；

S40、若线程Thread_b不在等待锁资源，线程Thread_b不在等待锁资源的依据为thread_b->wait_mutex_p指向无效值(NULL)，则无死锁，退出检测，若线程B在等待锁资源，则查看等待的锁Mutex_a的持有者P是否为线程Thread_a，若不是，则无死锁，退出检测，若是，则为图2的系统进入死锁异常处理并输出相关警告处理，查看等待的锁Mutex_a的持有者P表示为thread_b->wait_mutex_p->holder_thread_p，警告信息包括但不限于如下信息：

a.交叉死锁的信息比如锁的名字Mutex_a、Mutex_b；

b.交叉线程信息比如线程名字Thread_a、Thread_b；

c.死锁类型为交叉死锁；

本发明实施例还提供了一种嵌入式实时操作系统死锁自动检测系统，如图4所示，包括保护模块，具有互斥锁功能，用于资源互斥保护；记录模块，用于记录当前获取锁的线程信息、线程获取锁失败时锁的信息；死锁判断模块，用于系统运行时监测是否发生死锁并输出相关信息；告警模块，用于系统进入死锁异常处理时输出告警信息；所述保护模块、记录模块、死锁判断模块和告警模块依次连接。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本实施例中任一项方法。

本实施例中的计算机可读存储介质，本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过计算机程序相关的硬件来完成。前述的计算机程序可以存储于一计算机可读存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

现有技术中如通过代码调试日志分析或需要人员从代码编码中进行规避、通过软件看门狗和硬件看门狗来复位系统、通过设置锁超时，规定时间无法获取锁则自动退出等方法均增加了开发人员的排查负担并影响系统性能，以上实施例所述的一种嵌入式实时操作系统死锁自动检测方法，可自动检测系统互斥锁死锁并输出死锁线程信息，包括线程名字和互斥锁名字，系统只要出现死锁问题即可自动定位并进入死锁异常处理，可以降低系统开发难度，减少开发人员因死锁导致系统异常问题排查时间，大大提高了系统的安全性能。

显然，以上所描述的实施例仅仅是本发明较佳实施例，而不是全部的实施例，附图中给出了本发明的较佳实施例，但并不限制本发明的专利范围。本发明可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本发明的公开内容的理解更加透彻全面。尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本发明说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本发明专利保护范围之内。