CN101937365B - 并行程序的死锁检测方法和系统 - Google Patents

Abstract

本发明公开一种并行程序的死锁检测方法和系统，其中该方法包括：在并行程序运行过程中确定所述并行程序的锁不再被使用；从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及对所述更新的锁图进行死锁检测。

Description

并行程序的死锁检测方法和系统

技术领域

本发明涉及并行程序，特别涉及并行程序的死锁检测方法和系统。

背景技术

随着计算机技术的飞速发展，单核处理器逐渐被多核处理器所取替。多核处理器通过把多个执行内核集成到一个物理处理器，从而显著地增强计算机的处理能力和计算能力，并把并行计算的优势充分发挥出来。所谓并行计算分为时间上的并行和空间上的并行，时间上的并行就是指流水线技术，而空间上的并行则是指用多个处理器并发的执行计算。通常用并行程序实现并行计算，在并行程序中，任务处理被分成多个部分(线程)，这些线程可并行地执行，并通过访问某些共享数据结构和使用合适的同步方法来彼此通信，以协同并正确地工作。

但是，并行程序中的进程(线程)死锁(deadlock)是一个非常致命的问题。进程(线程)死锁是指是指两个或两个以上的进程(线程)在执行过程中，因竞争共享资源而造成的一种互相等待的现象，除非发生死锁的某个进程(线程)放弃该共享资源，否则死锁中的两个事务都将无限期等待下去。进程(线程)死锁通常会导致整个系统瘫痪。触发进程(线程)死锁的因素很多，其中主要包括：(1)有限的系统资源；(2)进程(线程)运行推进的顺序不合适；(3)资源分配不当。如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。为了避免进程(线程)死锁对整个系统造成的重大危害，提高系统的稳定性，需要有一个有效的方法进行死锁检测，以便及时发现进程(线程)死锁，并采取适当的措施解除死锁，避免系统运行状况进一步恶化。

通常利用锁图(lock graph)来直观地表示死锁的状况，通过记录并行程序执行过程中的锁操作，并在锁图中相应地增加节点和有向边来获得对应于并行程序过程中的锁图，在锁图中，节点表示为资源的锁，从一个节点指向另一个节点的有向边表示已获得某个资源的锁的进程正在请求获得另一个资源的锁。如果锁图中两个或多个节点之间的有向边构成闭合的有向环，说明并行程序中存在死锁，因此可以通过检查锁图中是否存在有向环来检测死锁。图1示出并行程序的死锁状态图，其中线程T1已经获得资源R1的锁，并请求资源R2的锁，线程T2具有资源R2的锁，并请求资源R1的锁，因为这两个线程都需要获得对方已经拥有的资源才能继续执行，而T1和T2拥有的资源又必须等到各自的线程继续执行才会释放出来，所以陷入了死锁状态。

然而，在实际中应用上述方法进行死锁检测并不十分有效，随着程序的运行，越来越多的节点和边被添加到锁图中，图2示出一个并行程序的锁图实例，该锁图中有1014个节点和3051条有向边，在锁图中检测有向环的操作非常慢，耗费掉大量的时间和计算资源，极大地降低了死锁检测的效率。

因此，需要一种改进的死锁检测方法以提高死锁检测的效率。

发明内容

基于上述问题，本发明提供一种并行程序的死锁检测方法和系统。

根据本发明的一个方面，提供一种并行程序的死锁检测方法，包括：在并行程序运行过程中确定所述并行程序的锁不再被使用；从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及对所述更新的锁图进行死锁检测。

根据本发明的一个方面，提供一种并行程序的死锁检测系统，包括：确定装置，被配置为在所述并行程序运行过程中确定所述并行程序的锁不再被使用；锁删除装置，被配置为从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及死锁检测装置，被配置为对所述更新的锁图进行死锁检测。

通过本发明提供的一种并行程序中死锁检测的方法和系统，及时将不再使用的锁节点及其相关的边从并行程序的锁图中删除，从而有效降低了锁图的复杂性(减少大量节点和边)。基于修剪之后的锁图进行有向环的检测以确定是否存在潜在的死锁，能够节约大量时间和计算资源，极大地提高了死锁检测的效率。

附图说明

结合附图，通过参考下列详细的示例性实施例的描述，将会更好地理解本发明本身、优选的实施方式以及本发明的目的和优点，其中：

图1示出并行程序的死锁状态图；

图2示出一个并行程序的锁图实例；

图3示出根据本发明实施例的并行程序的死锁检测方法；

图4a示出对应于第一实施例的多线程并行程序执行过程的锁图；

图4b示出从图4a的锁图上删除互斥锁request_mutex的节点以及与互斥锁request_mutex相关的边后的锁图；

图4c示出从图4b的锁图上删除互斥锁control_mutex的节点以及与互斥锁control_mutex相关的边后的锁图；

图5a示出对应于第二实施例的多线程并行程序执行过程的锁图；

图5b示出从图5a的锁图上删除锁G的节点以及与锁G相关的边后的锁图；

图5c示出从锁图5b上删除锁L1的节点以及与锁L1相关的边后的锁图；

图6a示出对应于第三实施例的Java程序的字节码在JVM上运行过程的锁图；

图6b示出从图6a上删除锁G的节点以及与锁G相关的边后更新的锁图；

图6c示出从图6b上删除锁L1的节点以及与锁L1相关的边后更新的锁图；以及

图7示出根据本发明实施例的并行程序的死锁检测系统的框图。

具体实施方式

以下结合附图描述根据本发明实施例的并行程序的死锁检测方法和系统。图3示出根据本发明实施例的并行程序的死锁检测方法，包括：在步骤S301，在并行程序运行过程中确定所述并行程序的锁不再被使用；在步骤S302，从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及在步骤S303，对所述更新的锁图进行死锁检测。

具体地，在步骤S301，其中在并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括响应于接收到所述并行程序的锁不再被使用的事件通知，确定所述并行程序的锁不再被使用。

在并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括通过对所述并行程序的代码进行扫描，对所述并行程序的锁的生命周期进行分析。

根据本发明的一个实施例，对所述并行程序的锁的生命周期进行分析进一步包括响应于检测到并行程序中存在显式的破坏锁的函数调用，从而识别出在并行程序运行过程中所述并行程序的锁被最后使用的位置。在所述并行程序的锁被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件通知。例如，在Linux上，多线程应用程序常使用的pthread库提供的互斥锁Mutex，其破坏锁的函数为intpthread_mutex_destroy(pthread_mutex_t＊mutex)；而多进程常用来实现互斥的信号量semaphore也是一种特殊的锁，其破坏锁的函数为int semctl(int semid，int semnum，IPC_RMID，...)。

根据本发明的一个实施例，对锁的生命周期进行分析进一步包括识别出并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合，具体地，响应于未检测到并行程序中存在破坏锁的函数调用，对所述并行程序进行数据流分析，确定所述并行程序的锁被定义和被使用的位置，从而识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。在并行程序的锁可能被最后使用的位置附近添加标记，所述标记用于在并行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知，响应于接收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知，确定所述并行程序的锁不再被使用。

根据本发明的一个实施例，可以利用静态代码分析的方法实现对并行程序的锁的生命周期进行分析，静态代码分析就是在不执行代码的情况下进行代码检查(例如进行源代码检查、二进制代码检查或是字节码检查)。静态代码扫描是静态代码分析的首要步骤，以下分别列举针对具有显式破坏锁的函数调用的多线程的并行程序和不具有显式破坏锁的函数调用的多线程的并行程序进行静态代码分析的实例。为了易于理解，下述实施例均采用对源代码进行静态分析的方式。

第一实施例

以下示出对具有显式破坏锁的函数调用的c语言程序example1.c进行静态代码分析的实例，c语言程序example1.c中包含了Linux的pthread库中的互斥锁Mutex，破坏互斥锁Mutex的函数是：intpthread_mutex_destroy(pthread_mutex_t＊mutex)，静态代码分析需要在不执行代码的情况下对源代码example1.c进行扫描，识别出与破坏互斥锁Mutex的函数相匹配的函数代码，进而识别出并行程序运行过程中锁被最后使用的位置，并在锁被最后使用的位置附近添加标记，以在并行程序运行过程中触发锁被破坏的事件通知，从而在并行程序运行过程中发送锁不再被使用的事件通知。

1：#controller thread，named as T12： #include<pthread.h>3：4： pthread_mutex_t list_mutex；5： pthread_mutex_t request_mutex；6： pthread_mutex_t control_mutex；7：8： void controller_thread()9： {10：          ...11：          //create worker_thread12：          pthread_create(&tid2，NULL，requester_thread，NULL)；13：          //create responser_thread14：          pthread_create(&tid3，NULL，responser_thread，NULL)；

15：16： /*control the requester and responser*/17： pthread_mutex_lock(&list_mutex)；18：19： //check the list of request and send out controller message20： pthread_mutex_lock(&request_mutex)；21：22： /*send message to response_thread*/23： pthread_mutex_lock(&control_mutex)；24： send_control_message()；25： pthread_mutex_unlock(&control_mutex)；26： ...27： pthread_mutex_unlock(&request_mutex)；28：29： pthread_mutex_unlock(&list_mutex)；30： .../*other operations*/31：}32：33：#requester_thread，named as T234：void requester_thread()35：{36： pthread_mutex_lock(&list_mutex)；37： if(＜request_in_list＜＝10)38： {39： pthread_mutex_lock(&request_mutex)；40： //trigger a new request41： pthread_mutex_unlock(&request_mutex)；42： pthread_mutex_destroy(&request_mutex)；<Lock_Could_Be Removed_From_Graph>43： }44： pthread_mutex_unlock(&list_mutex)；45：}46：47：#responser_thread，named as T348：void responser_thread()49：{50： pthread_mutex_lock(&list_mutex)；51： pthread_mutex_lock(&control_mutex)；52： //handle the control message from controller53： pthread_mutex_unlock(&control_mutex)；54： pthread_mutex_destroy(&control_mutex)；<Lock_Could_Be_Removed_From_Graph>55： pthread_mutex_unlock(&list_mutex)；56：}

通过静态扫描识别出与互斥锁Mutex的破坏函数相匹配的函数调用分别是位于第42行的pthread_mutex_destroy(&request_mutex)和第54行的pthread_mutex_destroy(&control_mutex)。根据静态扫描的结果确定出在并行程序运行过程中与互斥锁Mutex的函数调用对应的破坏点的位置，如表1所示。

锁

锁破坏点的位置

request_mutex	example1.c<line42_instruction_address>
		control_mutex	example1.c<line54_instruction_address>

表1

接着，在并行程序中互斥锁Mutex所有破坏点的位置附近添加标记，以便在并行程序运行时可以根据添加的标记触发发送互斥锁Mutex不再被使用的事件通知，如下所示，分别在并行程序的第42行和54行之后添加标记“<Lock_Could_Be_Removed_From_Graph>”，从而在并行程序运行过程中由添加的标记触发互斥锁Mutex不再被使用的事件通知。响应于接收到互斥锁Mutex不再被使用的事件通知，在并行程序运行过程中确定互斥锁Mutex不再被使用。

1：#controller thread，named as T1......42：                      pthread_mutex_destroy(&request_mutex)；<Lock_Could_Be_Removed_From_Graph>.......54：          pthread_mutex_destroy(&control_mutex)；<Lock_Could_Be_Removed_From_Graph>55：          pthread_mutex_unlock(&list_mutex)；56：}

图4a示出对应于第一实施例的多线程并行程序执行过程的锁图。在程序运行到第42行的位置，从锁图上删除互斥锁request_mutex的节点以及与互斥锁request_mutex相关的边，如图4b所示。接着，在程序运行到第54行的位置，从锁图上删除互斥锁control_mutex的节点以及与互斥锁control_mutex相关的边，如图4c所示。从简化后的锁图看出只剩下一个互斥锁list_mutex的节点，因此不存在死锁的情况。

第二实施例

以下示出对不具有显式破坏锁的函数调用的Java语言程序Example2.java进行静态代码分析的实例。

/*main in Example2.java*/01：new T1.start()；02   new T2.start()；/*Thread 1，named as T1*/03：synchronized(G){04：     synchronized(L1){05：         synchronized(L2){}06：     }07：}；08：t3＝new T3()；09：t2.start()；10：t3.join()；

11：synchronized(L2){12：    synchronized(L1){}13：}14：/*Thread 2，named as T2*/15：synchronized(G){16：     synchronized(L2){17：         synchronized(L1){}18：     }19：}20：/*Thread 3，named as T3*/21：synchronized(L1){22：     synchronized(L2){}23：}24：

上述的Java语言程序实例没有显式的破坏锁(G，L1和L2)的函数调用，因此要对并行程序的数据流进行分析，确定并行程序中锁被定义和被使用的位置，从而找到并行程序运行过程中锁可能被最后使用的位置的集合。通过静态扫描识别出线程T1在第3行获得锁G，在第7行释放锁G；线程2在第15行获得锁G，在第19行释放锁G；线程T1在第4行获得锁L1，在第6行释放锁L1；线程T1在第12行获得锁L1，在第12行释放锁L1；线程T2在第17行获得锁L1，在第17行释放锁L1；线程T3在第21行获得锁L1，在第23行释放锁L1；线程T1在第5行获得锁L2，在第5行释放锁L2；线程T1在第11行获得锁L2，在第13行释放锁L2；线程T2在第16行获得锁L2，在第18行释放锁L2；线程T3在第22行获得锁L2，在第22行释放锁。根据扫描结果产生对应于锁G、L1和L2的可能被最后使用的位置的集合，如表2所示。

锁	锁可能的锁破坏点的位置集合
		G	T1<line8_instruction_address>T2<line20_instruction_address>
L1	T1<line13_instruction_address>T2<line18_instruction_address>T3<line24_instruction_address>
		L2	T1<line14_instructioN_address>T2<line19_instruction_address>T3<line23_instruction_address>

表2

接着，如下所示，在Java语言并行程序中锁G、L1和L2可能被最后使用的位置附近添加标记，以便在并行程序运行时可以根据添加的标记触发锁G、L1和L2不再被使用的事件通知。如下示出在锁(G、L1和L2)可能被最后使用的位置附近分别添加了标记“<Lock_G_Might_Be_Remoced_From_Graph>”、“<Lock_L1_Might_Be_Removed_From_Graph>”和“<Lock_L3_Might_Be_Removd_From_Graph>”，本发明的实施例选择在锁(G、L1和L2)可能被最后使用的位置之后添加标记，然而并不限于此，本领域技术人员可以理解在锁可能被最后使用的位置之前添加标记也能够实现本发明的目的。在程序执行过程中，由标记触发事件通知，响应于接收到事件通知，更新表2，在不同的平台上，例如Windows、Linux，可以采用不同的事件通知机制。

/*main in Example2.java*/01：new T1.start()；02   new T2.start()；/*Thread 1，named as T1*/03：synchronized(G){04：    synchronized(L1){05：        synchronized(L2){}06：    }07：}；<Lock_G_Might_Be_Removed_From_Graph>08：t3＝new T3()；09：t2.start()；10：t3.join()；11：synchronized(L2){12：    synchronized(L1){}<Lock_L1_Might_Be_Removed_From_Graph>13：}<Lock_L2_Might_Be_Removed_From_Graph>14：/*Thread 2，named as T2*/15：synchronized(G){16：     synchronized(L2){17：         synchronized(L1){}<Lock_L1_Might_Be_Removed_From_Graph>18：    }<Lock_L2_Might_Be_Removed_From_Graph>19：}<Lock_G_Might_Be_Removed_From_Graph>20：/*Thread 3，named as T3*/21：synchronized(L1){22：     synchronized(L2){}<Lock_L2_Might_Be_Removed_From_Graph>23：}24：<Lock_L1_Might_Be_Removed_Frpm_Graph>

根据本发明的实施例，锁G不再被使用需要满足以下两个条件：1)线程T1执行到第8行的指令；2)线程T2执行到第20行的指令。在实际运行中，在线程T1先执行到第8行的指令时，标记触发锁G可能不再被使用的事件通知，通知更新表2，将其中的“T1<line8_instruction_address>”从表2中删除，更新后的表2如表3所示：

锁	锁可能被最后使用的位置集合
		G	T2<line20_instruction_address>
L1	T1<line13_instruction_address>T2<line18_instruction_address>T3<line24_instruction_address>
		L2	T1<line14_instruction_address>T2<line19_instruction_address>T3<line23_instruction_address>

表3

接着，当线程T2执行到第20行的指令时，由标记触发锁G不再被使用的事件通知并更新表3，响应于接收到锁G可能不再被使用的事件通知，将表3中的“T2<line20_instruction_address>”删除，由于已接收到锁G的所有标记触发的锁G可能不再被使用的事件通知，因此确定锁G不再被使用，由于锁G可能被最后使用的位置集合已被更新为空，所以将锁G从表3中删除并通知更新锁图，更新后的表3如表4所示：

锁	锁可能被最后使用的位置集合
		L1	T1<line13_instruction_address>T2<line18_instruction_address>T3<line24_instruction_address>
L2	T1<line14_instruction_address>T2<line19_instruction_address>T3<line23_instruction_address>

表4

图5a示出对应于第二实施例的多线程并行程序执行过程的锁图，相应的，从图5a上删除锁G的节点以及与锁G相关的边，图5b示出更新后的锁图，接着，对更新的锁图5b进行死锁检测。

锁L1不再被使用需要满足以下三个条件：1)线程T1执行到第13行的指令；2)线程T2执行到第18行的指令；以及3)线程T3执行到第24行的指令。在实际运行中，在线程T2先执行到第18行的指令时，标记触发锁L1可能不再被使用的事件通知，通更新表4，将其中的“T2<line18_instruction_address>”从表4中删除，更新后的表4如表5所示：

锁	锁可能被最后使用的位置集合
		L1	T1<line13_instruction_address>T3<line24_instruction_address>
L2	T1<line14_instruction_address>T2<line19_instruction_address>T3<line23_instruction_address>

表5

接着，在线程T1执行到第13行的指令，标记触发锁L1不再被使用的事件通知，通知更新表6，将其中的“T1<line13_instruction_address>”从表5中删除，更新后的表5如表6所示：

锁	锁可能被最后使用的位置集合
		L1	T3<line24_instruction_address>
L2	T1<line14_instruction_address>T2<line19_instruction_address>T3<line23_instruction_address>

表6

最后，在线程T3执行到第24行的指令，标记触发锁L1可能不再被使用的事件通知并更新表6，响应于接收到锁L1不再被使用的事件通知，将其中的“T3<line23_instruction_address>”从表6中删除，更新后的表6如表7所示：

锁	锁可能被最后使用的位置集合
		L2	T1<line14_instruction_address>T2<line19_instruction_address>T3<line23_instruction_address>

表7

由于已接收到锁L1的所有标记触发的锁L1可能不再被使用的事件通知，因此确定锁L1不再被使用，相应的，从锁图5b上删除锁L1的节点以及与锁L1相关的边，图5c示出更新后的锁图，接着，对更新的锁图5c进行死锁检测。

本发明的上述两个实施例利用静态代码扫描实现锁的生命周期的分析，然而，并不仅限于此，本领域技术人员可以理解，也可以在并行程序执行过程中进行代码扫描，以实现锁的生命周期的分析。

根据本发明的另一个实施例，对于支持垃圾回收的运行环境，可以利用虚拟机提供的垃圾回收通知机制确定锁不再被使用，垃圾回收(Garbagecollection，即GC)，或称为内存垃圾回收，是一种常用的自动内存管理方式。垃圾回收器将试图回收对象使用的内存空间，这些内存空间可能不再被对象使用。例如程序不再对一对象进行访问或处理，则为该对象分配的内存空间可以被垃圾回收。由于运行环境可以提供对象被垃圾回收的通知机制，因此可以在运行环境上注册需要通知被垃圾回收的作为锁的对象，响应于在并行程序运行过程中检测到锁被垃圾回收，即接收到运行环境发出的锁被垃圾回收的事件通知，确定这些锁不再被使用。

第三实施例

以下示出利用垃圾回收动态分析Java语言程序Example3.java的字节码在JVM(Java虚拟机)上运行的实例。

/*main in Example3.java*/1：2：3：new T1().start()；//start thread T14：5：T1：6：7：synchronized(G){8： synchronized(L1){9： synchronized(L2){10： }11：}12：new T2().start()；//start thread T213：...14：//lock G is garbage collected at this moment15：16：T2：17：18：synchronized(L1){19： synchronized(L2){}20：}21：...22//lock L1is garbage collected at this moment

首先，在虚拟机上注册需要通知被垃圾回收的锁G、L1和L2的对象，响应于接收到JVM发出的Java程序的字节码执行到第14行指令时锁G被垃圾回收的事件通知，确定锁G不再被使用。图6a示出对应于第三实施例的Java程序的字节码在JVM上运行过程的锁图，从图6a的锁图中删除锁G的节点以及与锁G相关的边，图6b示出从图6a上删除锁G的节点以及与锁G相关的边后更新的锁图，接着，对更新后的锁图6b进行死锁检测。响应于接收到JVM发出的Java程序的字节码在JVM上运行到第22行指令时锁L1被垃圾回收的事件通知，确定锁L1不再被使用，从图6b上删除锁L1的节点以及与锁L1相关的边，图6c示出从图6b上删除锁L1的节点以及与锁L1相关的边后更新的锁图，接着，对更新的锁图6c进行死锁检测。

根据本发明的另一个实施例，对于支持垃圾回收的运行环境，可以将并行程序运行之前的静态代码分析与并行程序运行过程中的动态分析(垃圾回收通知机制)结合起来确定锁不再被使用。对于某些应用程序而言，某些锁可能具有很多可能的最后使用的位置，例如上百个，扫描全部代码需要耗费大量的时间和计算资源，单纯依靠静态代码分析较难有效地确定这些锁不再被使用，为了更有效地确定这些锁不再被使用，可以先通过静态代码分析筛选出需要进行动态分析的锁，在程序运行过程中利用垃圾回收的通知机制确定锁不再被使用，静态分析和动态分析的结合方式可以提高死锁检测的效率。以下示出利用静态分析和动态分析结合的方式对上述第二实施例中的Java语言源代码Example2.java进行分析的实例。本发明的实施例尽管是在被Java标准规范定义的Java虚拟机(JVM)的范围内结合JVM来运行，但是JVM也可以是任何类型的独立于平台的虚拟机，如C#、Smalltalk、Ruby、D语言、nuva，而不仅限于Java虚拟机。

第四实施例

根据上述第二实施例的表2中的对应于锁G、L1和L2的可能被最后使用的位置集合，找出可能被最后使用的位置较多的锁进行动态扫描，例如锁L1，从表2中删除锁L1及其对应的可能被最后使用的位置的集合，并在JVM上注册需要通知被垃圾回收的锁L1，利用第二实施例的静态代码分析的方法在并行程序运行过程中更新表2中的锁G和L2中可能被最后使用的位置，从而在并行程序运行过程中确定锁G和L2不再被使用，相应的，从锁图上删除锁G和L2的节点以及与锁G和锁L2相关的边。同时，在并行程序运行过程中，响应于接收到Java程序的字节码执行到某个位置例如第20行锁L1被垃圾回收的事件通知，确定出锁L1不再被使用，从相应的锁图上删除锁L1的节点以及与锁L1相关的边。

基于同一发明构思，本发明还提供了并行程序的死锁检测系统，图7示出根据本发明实施例的并行程序的死锁检测系统的框图。如图所示，所述并行程序的死锁检测系统，包括：确定装置701，被配置为在并行程序运行过程中确定所述并行程序的锁不再被使用；锁删除装置702，被配置为从相应的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据并行程序的锁操作构建的；以及死锁检测装置703，被配置为对所述更新的锁图进行死锁检测。

其中所述确定装置701进一步被配置为响应于接收到所述并行程序的锁不再被使用的事件通知，在并行程序运行过程中确定所述并行程序的锁不再被使用。

所述确定装置701进一步包括锁的生命周期分析装置，被配置为通过对所述并行程序的代码进行扫描，对所述并行程序的锁的生命周期进行分析。

根据本发明的一个实施例，所述锁的生命周期分析装置进一步被配置为识别出在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。进一步地，所述锁的生命周期分析装置被配置为响应于未检测到所述并行程序中存在破坏锁的函数调用，对所述并行程序进行数据流分析，确定所述并行程序的锁被定义和被使用的位置，从而找到在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置集合。进一步地，所述锁的生命周期分析装置被配置为在并行程序的锁可能被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知。进一步地，所述确定装置701被配置为响应于接收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知，确定所述并行程序的锁不再被使用。

其中所述确定装置进一步被配置为响应于在所述并行程序运行中检测到所述并行程序的锁被垃圾回收，确定出所述并行程序的锁不再被使用。

根据本发明的一个实施例，所述锁的生命周期分析装置进一步被配置为响应于检测到并行程序中存在破坏锁的函数调用，确定出并行程序运行过程中锁被最后使用的位置。进一步地，所述锁的生命周期分析装置被配置为在锁被最后使用的位置附近添加标记，以在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件通知。

根据本发明的一个实施例，所述确定装置进一步被配置为响应于在并行程序运行过程中检测到并行程序的锁被垃圾回收，确定出并行程序的锁不再被使用。

利用本发明实施例的并行程序中死锁检测的方法和系统，基于修剪之后的锁图进行有向环的检测以确定是否存在潜在的死锁，能够节约大量时间和计算资源，假设一个并行程序的锁图有N个节点和E条边，检查锁图中的有向环的算法分为以下两个步骤：1.在锁图中找到所有的强连通分量，算法复杂度为O(N+E)；2.在每个强连通分量中找到所有的有向环，算法复杂度为O(N2)。因此，整个算法复杂度为O(N2+E)。由此可以看出，节点数目的减少，大大减小了算法的复杂度，提高了死锁检测的效率。

应当理解，本发明的至少某些方面可以可替代地以程序产品实现。定义有关本发明的功能的程序可以通过各种信号承载介质被传送到数据存储系统或计算机系统，所述信号承载介质包括但不限于，不可写存储介质(例如，CD-ROM)、可写存储介质(例如，软盘、硬盘驱动器、读/写CD ROM、光介质)以及诸如包括以太网的计算机和电话网络之类的通信介质。因此应当理解，在此类信号承载介质中，当携带或编码有管理本发明中的方法功能的计算机可读指令时，代表本发明的可替代实施例。本发明可以硬件、软件、固件或其组合的方式实现。本发明可以集中的方式在一个计算机系统中实现，或以分布方式实现，在这种分布方式中，不同的部件分布在若干互连的计算机系统中。适于执行本文中描述的方法的任何计算机系统或其它装置都是合适的。优选地，本发明以计算机软件和通用计算机硬件的组合的方式实现，在这种实现方式中，当该计算机程序被加载和执行时，控制该计算机系统而使其执行本发明的方法，或构成本发明的系统。

上面出于举例说明的目的，给出了本发明的优选实施例的说明。优选实施例的上述说明不是穷尽的，也不打算把本发明局限于公开的明确形式，显然鉴于上述教导，许多修改和变化是可能的。对本领域的技术人员来说显而易见的这种修改和变化包括在由附加的权利要求限定的本发明的范围内。

Claims (18)

1.一种并行程序的死锁检测方法，包括：

在并行程序运行过程中确定所述并行程序的锁不再被使用；

从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及

对所述更新的锁图进行死锁检测，

其中在所述并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括通过对所述并行程序的代码进行扫描，对所述并行程序的锁的生命周期进行分析。

2.根据权利要求1所述的死锁检测方法，其中在并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括响应于接收到所述并行程序的锁不再被使用的事件通知，确定所述并行程序的锁不再被使用。

3.根据权利要求1所述的死锁检测方法，其中对所述并行程序的锁的生命周期进行分析进一步包括识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。

4.根据权利要求3所述的死锁检测方法，其中识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合进一步包括响应于未检测到所述并行程序中存在破坏锁的函数调用，对所述并行程序进行数据流分析，确定所述并行程序的锁被定义和被使用的位置，从而识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。

5.根据权利要求4所述的死锁检测方法，进一步包括在所述并行程序的锁可能被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知。

6.根据权利要求5所述的死锁检测方法，其中响应于接收到所述并行程序的锁不再被使用的事件通知确定所述并行程序的锁不再被使用进一步包括响应于接收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知，确定所述并行程序的锁不再被使用。

7.根据权利要求1所述的死锁检测方法，其中对所述并行程序的锁的生命周期进行分析进一步包括响应于检测到所述并行程序中存在破坏锁的函数调用，确定出在所述并行程序运行过程中所述并行程序的锁被最后使用的位置。

8.根据权利要求7所述的死锁检测方法，进一步包括在所述并行程序的锁被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件通知。

9.根据权利要求1或3所述的死锁检测方法，其中在并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括响应于在所述并行程序运行过程中检测到所述并行程序的锁被垃圾回收，确定出所述并行程序的锁不再被使用。

10.一种并行程序的死锁检测系统，包括：

确定装置，被配置为在所述并行程序运行过程中确定所述并行程序的锁不再被使用；

锁删除装置，被配置为从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图，其中所述锁图是根据所述并行程序的锁操作构建的；以及

死锁检测装置，被配置为对所述更新的锁图进行死锁检测，

其中所述确定装置进一步包括锁的生命周期分析装置，被配置为通过对所述并行程序的代码进行扫描，对所述并行程序的锁的生命周期进行分析。

11.根据权利要求10所述的死锁检测系统，其中所述确定装置进一步被配置为响应于接收到所述并行程序的锁不再被使用的事件通知，确定所述并行程序的锁不再被使用。

12.根据权利要求10所述的死锁检测系统，其中所述锁的生命周期分析装置进一步被配置为识别出在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。

13.根据权利要求12所述的死锁检测系统，其中所述锁的生命周期分析装置进一步被配置为响应于未检测到所述并行程序中存在破坏锁的函数调用，对所述并行程序进行数据流分析，确定所述并行程序的锁被定义和被使用的位置，从而找到在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。

14.根据权利要求13所述的死锁检测系统，其中所述锁的生命周期分析装置进一步被配置为在所述并行程序的锁可能被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知。

15.根据权利要求14所述的死锁检测系统，其中所述确定装置进一步被配置为响应于接收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知，确定所述并行程序的锁不再被使用。

16.根据权利要求10所述的死锁检测系统，其中所述锁的生命周期分析装置进一步被配置为响应于检测到所述并行程序中存在破坏锁的函数调用，确定出在所述并行程序运行过程中所述并行程序的锁被最后使用的位置。

17.根据权利要求16所述的死锁检测系统，其中所述锁的生命周期分析装置进一步被配置为在所述并行程序的锁被最后使用的位置附近添加标记，所述标记用于在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件通知。

18.根据权利要求10或12所述的死锁检测系统，其中所述确定装置进一步被配置为响应于在所述并行程序运行过程中检测到所述并行程序的锁被垃圾回收，确定出所述并行程序的锁不再被使用。

Images