CN105022692A - 一种死锁检测验证方法 - Google Patents

Abstract

本发明公开了一种死锁检测验证方法，包括：提取出待测进程的状态、状态转移关系；建立不同的死锁检测模板；将进程的状态、状态转移关系以及建模属性按照类别分别写入XML配置文件；读取XML配置文件，选择相应的死锁检测模板进行模型检测：生成时态逻辑表达式CTL，将进程的状态和状态转移关系及时态逻辑表达式CTL转换为SMV模型；执行SMV模型，分析执行结果中时态逻辑表达式CTL的真值，判断设计文档是否包含死锁。本发明通过自动分析死锁检测相关信息的输入自动选择相应模板转换为SMV模型的原型，降低了死锁检测的难度；本方法不受软件开发语言限制，可以在***设计阶段对设计方案进行死锁检测，比在软件开发阶段再发现死锁更能减少不必要的损失。

Description

一种死锁检测验证方法

技术领域

本发明涉及软件设计技术领域，具体为一种死锁检测验证方法。

背景技术

死锁是并发***中比较常见的软件设计缺陷，也是非常典型的解决并发安全所需关注的问题。死锁的发生会导致程序无限等待或资源严重消耗，使整个***没有可用资源而陷于瘫痪，严重影响***安全性和可靠性。

SMV工具是美国CMU计算机学院的L.McMillan博士于1992年开发出的模型检验工具软件，它基于符号模型检验(Symbolic Model Checking)技术，目前为国际上广为流行的分析有限状态***的常用工具，SMV有多个版本，如：CMU-SMV、Cadence-SMV、NuSMV等。

死锁检测的方法主要可以分为静态和动态两大类。静态方法最基本的是代码检查，而所有直接在源程序上做静态死锁检测的技术，都会使用静态程序分析技术。静态程序分析技术是对并发程序的源代码或者规格说明进行人工或者自动化分析，然后通过分析获得程序各个模块的数据依赖关系。静态方法能取得一定的效果，但如果出现并发缺陷如死锁和活锁，其产生来源于特定的程序状态，而且并发软件状态空间非常庞大，这就会使得以人工为主的代码检查难以胜任。

动态方法则是通过并发程序在真实环境或模拟环境中运行，通过检测软件对运行信息进行收集，然后利用收集到的信息进行死锁检测。动态分析方法可以分为测试和监控两大类。动态方法只能覆盖到有限的软件运行情况，对于死锁这类出现概率低的缺陷，并不能有效的检测。

模型检测是静态死锁检测方法中的一种，基本方法是使用并发的模型来描述***，在模型验证时如果模型处于某个非终止状态且没有可达的后继状态时，则发现了死锁。对于模型检测来说，因为并发软件各并发进程之间庞大的交织状态空间，使得模型过于庞大复杂，难以手动构造。所以除了状态空间***问题外，模型的构造也是需要解决的问题。

发明内容

针对上述问题，本发明的目的在于提供一种死锁检测验证方法，该方法可以在***设计阶段对设计方案进行死锁检测，比较容易发现并发缺陷。技术方案如下：

一种死锁检测验证方法，包括：

从并发***设计文档中提取出待测进程的状态、状态转移关系；

根据进程的执行方式及并发控制中的项目建立不同的死锁检测模板；

将进程的状态、状态转移关系以及建模属性按照类别分别写入XML配置文件；

读取XML配置文件，选择相应的死锁检测模板进行模型检测：分析进程的状态及状态转移关系，生成时态逻辑表达式CTL，将进程的状态和状态转移关系及时态逻辑表达式CTL转换为SMV模型；

执行SMV模型，并将执行结果存入文本文档；

读取文本文档，分析执行结果中时态逻辑表达式CTL的真值；

根据通过算法分析CTL的真值判断设计文档是否包含死锁：

若时态逻辑表达式CTL为TRUE，则设计文档没有产生死锁；

若时态逻辑表达式CTL为FALSE，则设计文档产生死锁。

进一步的，所述死锁检测模板建立的方法包括：

将进程同步执行和异步执行抽象为第一组的两个模型检测模板；

将并发控制中的条件变量、互斥锁和信号变量抽象为第二组的三个模型检测模板；

将第一组中的模型检测模板和第二组中的模型检测模板一一组合生成六个死锁检测模板。

更进一步的，还包括：若设计文档产生死锁，则输出产生死锁的执行路径。

更进一步的，还包括选择模型检测工具NuSMV作为模型检测的建模和验证工具。

本发明的有益效果是：本发明通过自动分析死锁检测相关信息的输入自动选择相应模板转换为SMV模型的原型，降低了死锁检测的难度；本方法不受软件开发语言限制，可以在***设计阶段对设计方案进行死锁检测，比在软件开发阶段再发现死锁更能减少不必要的损失。

附图说明

图1为本发明死锁检测验证方法的流程框图。

具体实施方式

下面结合具体实施例对本发明做进一步说明。提出了一种基于模型检测工具NuSMV对死锁进行检测的方法，本方法能够有效的对同步和异步这两种模式下的信号量、条件变量、互斥锁机制引发的死锁进行检测，并且可以在***架构设计阶段就可对抽象出的并发信息进行死锁检测，无需获取源代码。

选择模型检测工具NuSMV作为模型检测的建模和验证工具，并借助于NuSMV对状态空间的穷举搜索，对设计模板进行验证。在设计时选取XML文件作为中间载体对相关信息存储，对用户输入的建模属性和状态转移关系按类别输入到XML文件当中，然后针对生成的XML文件再次读取，对属性分析处理然后转换成NuSMV可识别的SMV模型。

在基于NuSMV进行死锁检测时可以对进程同步执行和异步执行抽象为两个模型检测模板，在对并发控制中使用条件变量、互斥锁和信号量又可以抽象为3个模型检测模板，这样针对同步和异步以及这两种模式下的条件变量、互斥锁和信号量总共可以抽象出6个针对不同模式的死锁检测模板，只需根据并发模式把并发进程的状态及状态转移关系相关信息输入到算法，就会自动转换为用于死锁检测的SMV模型。

具体过程如下：

1.建立模型：从并发***设计文档中提取出待测进程的状态及状态转移关系。

2.根据进程的执行方式及并发控制中的项目建立不同的死锁检测模板。

具体在步骤为：

将进程同步执行和异步执行抽象为第一组的两个模型检测模板；

将并发控制中的条件变量、互斥锁和信号变量抽象为第二组的三个模型检测模板；

将第一组中的模型检测模板和第二组中的模型检测模板一一组合生成六个死锁检测模板。

3.将进程的状态、状态转移关系以及建模属性按照类别分别写入XML配置文件。这样可以根据XML配置文件的属性名称更容易区分状态和转移关系。

4.读取XML配置文件，根据XML配置文件中的属性名称获取进程的状态及状态转移关系。根据获得的并发类型自动选择相应死锁检测模板，然后进行模型检测：分析进程的状态及状态转移关系，根据临界区状态生成用于验证死锁的时态逻辑表达式CTL，将进程的状态和状态转移关系及时态逻辑表达式CTL转换为NuSMV可执行的SMV模型。

5.通过自动化执行SMV模型，并将执行结果存入文本文档。

6.读取文本文档，通过算法分析执行结果中时态逻辑表达式CTL的真值。

7.根据通过算法分析CTL的真值判断设计文档是否包含死锁：

若时态逻辑表达式CTL为TRUE，则设计文档没有产生死锁；

若时态逻辑表达式CTL为FALSE，则设计文档产生死锁，则输出产生死锁的执行路径。

具体实施例如下：

用一个同步互斥锁的例子来完成死锁检测步骤的分析：有两个石匠在同一个生产线雕刻一个雕像，但是只有一套工具，如果石匠空闲，他就可以继续休息或者准备一下去工作，准备工作完成后如果工具可以使用，那么他就可以去生产线工作，工作完成一个阶段后他可以选择休息或者继续工作，如果选择休息他就会把自己手中的工具放下，另外一名石匠可以拿起去工作。

(1)分析***设计文档，对***进行抽象。该实施例是一个同步互斥锁的例子，通过分析例子中的设计需求，得到有两个进程(工人)，进程的工作状态分空闲状态、准备状态、工作状态三个状态。初始状态为空闲状态，工作完成后就解锁(放下工具)。空闲状态的下一个状态可以是继续空闲状态或者变为准备状态，如果处于准备状态且互斥锁可用的话，就可以工作，否则处于准备状态等待获得锁。工作之后状态变为空闲并释放锁。

首先针对以上信息进行具体化，把抽象中的状态及状态转移关系抽象为代码级别的原语。

状态(state)：rest(休息)、prepare(准备)、work(工作)，临界区为work

互斥锁：mutex

进程状态转移关系：rest→{rest,prepare}；

prepare&mutex→work；

work→rest；

TRUE→state；

互斥锁状态转移关系：work→FALSE；

！work&mutex！＝TRUE→TRUE；

TRUE→mutex；

(2)把上一步中的状态及状态转移关系输入到死锁检测原型并选择相应要检测死锁类型，生成用于信息记录的XML配置文件。XML配置文件中记录了并发的方式、进程名称初始化状态以及按照属性分类的状态转移信息。生成的XML配置文件格式如下：

(3)根据第一步中抽象出来的进程状态和临界区，生成时态逻辑表达式CTL，用来判断状态是否可达，从而进一步判断是否有死锁产生。生成的时态逻辑表达式如下：

SPEC EF(job1.state＝work)；

SPEC EF！(job1.state＝work&job2.state＝work)

SPEC AG(job1.state＝prepare→AF job1.state＝work)

(4)根据时态逻辑表达式CTL和XML配置文件生成SMV模型。本例子中转换之后的SMV模型如下所示：

(5)执行生成的SMV模型，并把结果输出到文本文档保存，再次读取文本文档，对结果进行分析，找到时态逻辑表达式，根据时态逻辑表达式显示检测结果，其检测结果如下：

其中分析时态逻辑表达式为：

EF job1.state＝work is true

EF！(job1.state＝work&job2.state＝work)is true

AG(job1.state＝prepare->AF job1.state＝work)is false

检测结果显示该例子产生了死锁，当job1处于准备状态时，有一条执行路径将导致他永远也不能进入工作状态。

分析：第四步中，当job2占有了互斥锁之后变为rest状态，但是他没有去释放资源，自己又误认为已经释放资源等待其他进程释放资源，job1也在等待job2释放资源，两个进程将一直等待下去。

Claims (4)

1.一种死锁检测验证方法，其特征在于，包括：

从并发***设计文档中提取出待测进程的状态、状态转移关系；

根据进程的执行方式及并发控制中的项目建立不同的死锁检测模板；

将进程的状态、状态转移关系以及建模属性按照类别分别写入XML配置文件；

读取XML配置文件，选择相应的死锁检测模板进行模型检测：分析进程的状态及状态转移关系，生成时态逻辑表达式CTL，将进程的状态和状态转移关系及时态逻辑表达式CTL转换为SMV模型；

执行SMV模型，并将执行结果存入文本文档；

读取文本文档，分析执行结果中时态逻辑表达式CTL的真值；

根据通过算法分析CTL的真值判断设计文档是否包含死锁：

若时态逻辑表达式CTL为TRUE，则设计文档没有产生死锁；

若时态逻辑表达式CTL为FALSE，则设计文档产生死锁。

2.根据权利要求1所述的死锁检测验证方法，其特征在于，所述死锁检测模板建立的方法包括：

将进程同步执行和异步执行抽象为第一组的两个模型检测模板；

将并发控制中的条件变量、互斥锁和信号变量抽象为第二组的三个模型检测模板；

将第一组中的模型检测模板和第二组中的模型检测模板一一组合生成六个死锁检测模板。

3.根据权利要求1所述的死锁检测验证方法，其特征在于，还包括：若设计文档产生死锁，则输出产生死锁的执行路径。

4.根据权利要求1所述的死锁检测验证方法，其特征在于，还包括选择模型检测工具NuSMV作为模型检测的建模和验证工具。