《并行程序的死锁检测方法和系统.pdf》由会员分享,可在线阅读,更多相关《并行程序的死锁检测方法和系统.pdf(20页完整版)》请在专利查询网上搜索。
1、(10)申请公布号 CN 101937365 A (43)申请公布日 2011.01.05 CN 101937365 A *CN101937365A* (21)申请号 200910139821.2 (22)申请日 2009.06.30 G06F 9/46(2006.01) G06F 9/54(2006.01) G06F 11/36(2006.01) (71)申请人 国际商业机器公司 地址 美国纽约 (72)发明人 齐尧 郑勇 罗志达 (74)专利代理机构 北京市中咨律师事务所 11247 代理人 于静 李峥 (54) 发明名称 并行程序的死锁检测方法和系统 (57) 摘要 本发明公开一种并行程。
2、序的死锁检测方法和 系统, 其中该方法包括 : 在并行程序运行过程中 确定所述并行程序的锁不再被使用 ; 从对应于所 述并行程序运行过程的锁图中删除与不再被使用 的锁对应的节点以及与不再被使用的锁相关的边 以获得更新的锁图, 其中所述锁图是根据所述并 行程序的锁操作构建的 ; 以及对所述更新的锁图 进行死锁检测。 (51)Int.Cl. (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 2 页 说明书 13 页 附图 4 页 CN 101937366 A1/2 页 2 1. 一种并行程序的死锁检测方法, 包括 : 在并行程序运行过程中确定所述并行程序的锁不再被使用 ; 从。
3、对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与 不再被使用的锁相关的边以获得更新的锁图, 其中所述锁图是根据所述并行程序的锁操作 构建的 ; 以及 对所述更新的锁图进行死锁检测。 2. 根据权利要求 1 所述的死锁检测方法, 其中在并行程序运行过程中确定所述并行程 序的锁不再被使用进一步包括响应于接收到所述并行程序的锁不再被使用的事件通知, 确 定所述并行程序的锁不再被使用。 3. 根据权利要求 2 所述的死锁检测方法, 其中在所述并行程序运行过程中确定所述并 行程序的锁不再被使用进一步包括通过对所述并行程序的代码进行扫描, 对所述并行程序 的锁的生命周期进行分析。 4。
4、. 根据权利要求 3 所述的死锁检测方法, 其中对所述并行程序的锁的生命周期进行分 析进一步包括识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置 的集合。 5. 根据权利要求 4 所述的死锁检测方法, 其中识别出所述并行程序运行过程中所述并 行程序的锁可能被最后使用的位置的集合进一步包括响应于未检测到所述并行程序中存 在破坏锁的函数调用, 对所述并行程序进行数据流分析, 确定所述并行程序的锁被定义和 被使用的位置, 从而识别出所述并行程序运行过程中所述并行程序的锁可能被最后使用的 位置的集合。 6. 根据权利要求 5 所述的死锁检测方法, 进一步包括在所述并行程序的锁可能被最后。
5、 使用的位置附近添加标记, 所述标记用于在所述并行程序运行过程中触发所述并行程序的 锁可能不再被使用的事件通知。 7. 根据权利要求 6 所述的死锁检测方法, 其中响应于接收到所述并行程序的锁不再被 使用的事件通知确定所述并行程序的锁不再被使用进一步包括响应于接收到所有所述标 记触发的所述并行程序的锁可能不再被使用的事件通知, 确定所述并行程序的锁不再被使 用。 8. 根据权利要求 3 所述的死锁检测方法, 其中对所述并行程序的锁的生命周期进行分 析进一步包括响应于检测到所述并行程序中存在破坏锁的函数调用, 确定出在所述并行程 序运行过程中所述并行程序的锁被最后使用的位置。 9. 根据权利要求。
6、 8 所述的死锁检测方法, 进一步包括在所述并行程序的锁被最后使用 的位置附近添加标记, 所述标记用于在所述并行程序运行过程中触发所述并行程序的锁不 再被使用的事件通知。 10.根据权利要求1或4所述的死锁检测方法, 其中在并行程序运行过程中确定所述并 行程序的锁不再被使用进一步包括响应于在所述并行程序运行过程中检测到所述并行程 序的锁被垃圾回收, 确定出所述并行程序的锁不再被使用。 11. 一种并行程序的死锁检测系统, 包括 : 确定装置, 被配置为在所述并行程序运行过程中确定所述并行程序的锁不再被使用 ; 锁删除装置, 被配置为从对应于所述并行程序运行过程的锁图中删除与不再被使用的 权 利。
7、 要 求 书 CN 101937365 A CN 101937366 A2/2 页 3 锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图, 其中所述锁图是根据所 述并行程序的锁操作构建的 ; 以及 死锁检测装置, 被配置为对所述更新的锁图进行死锁检测。 12. 根据权利要求 11 所述的死锁检测系统, 其中所述确定装置进一步被配置为响应于 接收到所述并行程序的锁不再被使用的事件通知, 确定所述并行程序的锁不再被使用。 13. 根据权利要求 12 所述的死锁检测系统, 其中所述确定装置进一步包括锁的生命周 期分析装置, 被配置为通过对所述并行程序的代码进行扫描, 对所述并行程序的锁的生命。
8、 周期进行分析。 14. 根据权利要求 13 所述的死锁检测系统, 其中所述锁的生命周期分析装置进一步被 配置为识别出在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集 合。 15. 根据权利要求 14 所述的死锁检测系统, 其中所述锁的生命周期分析装置进一步被 配置为响应于未检测到所述并行程序中存在破坏锁的函数调用, 对所述并行程序进行数据 流分析, 确定所述并行程序的锁被定义和被使用的位置, 从而找到在所述并行程序运行过 程中所述并行程序的锁可能被最后使用的位置的集合。 16. 根据权利要求 15 所述的死锁检测系统, 其中所述锁的生命周期分析装置进一步被 配置为在所述并行程。
9、序的锁可能被最后使用的位置附近添加标记, 所述标记用于在所述并 行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知。 17. 根据权利要求 16 所述的死锁检测系统, 其中所述确定装置进一步被配置为响应于 接收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知, 确定所述并行 程序的锁不再被使用。 18. 根据权利要求 13 所述的死锁检测方法, 其中所述锁的生命周期分析装置进一步被 配置为响应于检测到所述并行程序中存在破坏锁的函数调用, 确定出在所述并行程序运行 过程中所述并行程序的锁被最后使用的位置。 19. 根据权利要求 18 所述的死锁检测系统, 其中所述锁的生命周。
10、期分析装置进一步被 配置为在所述并行程序的锁被最后使用的位置附近添加标记, 所述标记用于在所述并行程 序运行过程中触发所述并行程序的锁不再被使用的事件通知。 20.根据权利要求11或14所述的死锁检测系统, 其中所述确定装置进一步被配置为响 应于在所述并行程序运行过程中检测到所述并行程序的锁被垃圾回收, 确定出所述并行程 序的锁不再被使用。 权 利 要 求 书 CN 101937365 A CN 101937366 A1/13 页 4 并行程序的死锁检测方法和系统 技术领域 0001 本发明涉及并行程序, 特别涉及并行程序的死锁检测方法和系统。 背景技术 0002 随着计算机技术的飞速发展, 。
11、单核处理器逐渐被多核处理器所取替。多核处理器 通过把多个执行内核集成到一个物理处理器, 从而显著地增强计算机的处理能力和计算能 力, 并把并行计算的优势充分发挥出来。 所谓并行计算分为时间上的并行和空间上的并行, 时间上的并行就是指流水线技术, 而空间上的并行则是指用多个处理器并发的执行计算。 通常用并行程序实现并行计算, 在并行程序中, 任务处理被分成多个部分 ( 线程 ), 这些线 程可并行地执行, 并通过访问某些共享数据结构和使用合适的同步方法来彼此通信, 以协 同并正确地工作。 0003 但是, 并行程序中的进程 ( 线程 ) 死锁 (deadlock) 是一个非常致命的问题。进 程 。
12、( 线程 ) 死锁是指是指两个或两个以上的进程 ( 线程 ) 在执行过程中, 因竞争共享资源 而造成的一种互相等待的现象, 除非发生死锁的某个进程(线程)放弃该共享资源, 否则死 锁中的两个事务都将无限期等待下去。进程 ( 线程 ) 死锁通常会导致整个系统瘫痪。触发 进程 ( 线程 ) 死锁的因素很多, 其中主要包括 : (1) 有限的系统资源 ; (2) 进程 ( 线程 ) 运 行推进的顺序不合适 ; (3) 资源分配不当。如果系统资源充足, 进程的资源请求都能够得到 满足, 死锁出现的可能性就很低, 否则就会因争夺有限的资源而陷入死锁。其次, 进程运行 推进顺序与速度不同, 也可能产生死锁。
13、。为了避免进程 ( 线程 ) 死锁对整个系统造成的重 大危害, 提高系统的稳定性, 需要有一个有效的方法进行死锁检测, 以便及时发现进程 ( 线 程 ) 死锁, 并采取适当的措施解除死锁, 避免系统运行状况进一步恶化。 0004 通常利用锁图 (lock graph) 来直观地表示死锁的状况, 通过记录并行程序执行 过程中的锁操作, 并在锁图中相应地增加节点和有向边来获得对应于并行程序过程中的锁 图, 在锁图中, 节点表示为资源的锁, 从一个节点指向另一个节点的有向边表示已获得某个 资源的锁的进程正在请求获得另一个资源的锁。 如果锁图中两个或多个节点之间的有向边 构成闭合的有向环, 说明并行程。
14、序中存在死锁, 因此可以通过检查锁图中是否存在有向环 来检测死锁。图 1 示出并行程序的死锁状态图, 其中线程 T1 已经获得资源 R1 的锁, 并请求 资源 R2 的锁, 线程 T2 具有资源 R2 的锁, 并请求资源 R1 的锁, 因为这两个线程都需要获得 对方已经拥有的资源才能继续执行, 而 T1 和 T2 拥有的资源又必须等到各自的线程继续执 行才会释放出来, 所以陷入了死锁状态。 0005 然而, 在实际中应用上述方法进行死锁检测并不十分有效, 随着程序的运行, 越来 越多的节点和边被添加到锁图中, 图 2 示出一个并行程序的锁图实例, 该锁图中有 1014 个 节点和 3051 条。
15、有向边, 在锁图中检测有向环的操作非常慢, 耗费掉大量的时间和计算资 源, 极大地降低了死锁检测的效率。 0006 因此, 需要一种改进的死锁检测方法以提高死锁检测的效率。 说 明 书 CN 101937365 A CN 101937366 A2/13 页 5 发明内容 0007 基于上述问题, 本发明提供一种并行程序的死锁检测方法和系统。 0008 根据本发明的一个方面, 提供一种并行程序的死锁检测方法, 包括 : 在并行程序运 行过程中确定所述并行程序的锁不再被使用 ; 从对应于所述并行程序运行过程的锁图中删 除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的锁图, 其中。
16、 所述锁图是根据所述并行程序的锁操作构建的 ; 以及对所述更新的锁图进行死锁检测。 0009 根据本发明的一个方面, 提供一种并行程序的死锁检测系统, 包括 : 确定装置, 被 配置为在所述并行程序运行过程中确定所述并行程序的锁不再被使用 ; 锁删除装置, 被配 置为从对应于所述并行程序运行过程的锁图中删除与不再被使用的锁对应的节点以及与 不再被使用的锁相关的边以获得更新的锁图, 其中所述锁图是根据所述并行程序的锁操作 构建的 ; 以及死锁检测装置, 被配置为对所述更新的锁图进行死锁检测。 0010 通过本发明提供的一种并行程序中死锁检测的方法和系统, 及时将不再使用的锁 节点及其相关的边从并。
17、行程序的锁图中删除, 从而有效降低了锁图的复杂性 ( 减少大量节 点和边)。 基于修剪之后的锁图进行有向环的检测以确定是否存在潜在的死锁, 能够节约大 量时间和计算资源, 极大地提高了死锁检测的效率。 附图说明 0011 结合附图, 通过参考下列详细的示例性实施例的描述, 将会更好地理解本发明本 身、 优选的实施方式以及本发明的目的和优点, 其中 : 0012 图 1 示出并行程序的死锁状态图 ; 0013 图 2 示出一个并行程序的锁图实例 ; 0014 图 3 示出根据本发明实施例的并行程序的死锁检测方法 ; 0015 图 4a 示出对应于第一实施例的多线程并行程序执行过程的锁图 ; 00。
18、16 图 4b 示出从图 4a 的锁图上删除互斥锁 request_mutex 的节点以及与互斥锁 request_mutex 相关的边后的锁图 ; 0017 图 4c 示出从图 4b 的锁图上删除互斥锁 control_mutex 的节点以及与互斥锁 control_mutex 相关的边后的锁图 ; 0018 图 5a 示出对应于第二实施例的多线程并行程序执行过程的锁图 ; 0019 图 5b 示出从图 5a 的锁图上删除锁 G 的节点以及与锁 G 相关的边后的锁图 ; 0020 图 5c 示出从锁图 5b 上删除锁 L1 的节点以及与锁 L1 相关的边后的锁图 ; 0021 图 6a 示出。
19、对应于第三实施例的 Java 程序的字节码在 JVM 上运行过程的锁图 ; 0022 图 6b 示出从图 6a 上删除锁 G 的节点以及与锁 G 相关的边后更新的锁图 ; 0023 图 6c 示出从图 6b 上删除锁 L1 的节点以及与锁 L1 相关的边后更新的锁图 ; 以及 0024 图 7 示出根据本发明实施例的并行程序的死锁检测系统的框图。 具体实施方式 0025 以下结合附图描述根据本发明实施例的并行程序的死锁检测方法和系统。图 3 示 出根据本发明实施例的并行程序的死锁检测方法, 包括 : 在步骤 S301, 在并行程序运行过 程中确定所述并行程序的锁不再被使用 ; 在步骤 S302。
20、, 从对应于所述并行程序运行过程的 说 明 书 CN 101937365 A CN 101937366 A3/13 页 6 锁图中删除与不再被使用的锁对应的节点以及与不再被使用的锁相关的边以获得更新的 锁图, 其中所述锁图是根据所述并行程序的锁操作构建的 ; 以及在步骤 S303, 对所述更新 的锁图进行死锁检测。 0026 具体地, 在步骤 S301, 其中在并行程序运行过程中确定所述并行程序的锁不再被 使用进一步包括响应于接收到所述并行程序的锁不再被使用的事件通知, 确定所述并行程 序的锁不再被使用。 0027 在并行程序运行过程中确定所述并行程序的锁不再被使用进一步包括通过对所 述并行程。
21、序的代码进行扫描, 对所述并行程序的锁的生命周期进行分析。 0028 根据本发明的一个实施例, 对所述并行程序的锁的生命周期进行分析进一步包括 响应于检测到并行程序中存在显式的破坏锁的函数调用, 从而识别出在并行程序运行过程 中所述并行程序的锁被最后使用的位置。 在所述并行程序的锁被最后使用的位置附近添加 标记, 所述标记用于在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件 通知。 例如, 在Linux上, 多线程应用程序常使用的pthread库提供的互斥锁Mutex, 其破坏 锁的函数为 intpthread_mutex_destroy(pthread_mutex_t mutex。
22、) ; 而多进程常用来实 现互斥的信号量semaphore也是一种特殊的锁, 其破坏锁的函数为int semctl(int semid, int semnum, IPC_RMID, .)。 0029 根据本发明的一个实施例, 对锁的生命周期进行分析进一步包括识别出并行程序 运行过程中所述并行程序的锁可能被最后使用的位置的集合, 具体地, 响应于未检测到并 行程序中存在破坏锁的函数调用, 对所述并行程序进行数据流分析, 确定所述并行程序的 锁被定义和被使用的位置, 从而识别出所述并行程序运行过程中所述并行程序的锁可能被 最后使用的位置的集合。在并行程序的锁可能被最后使用的位置附近添加标记, 所述。
23、标记 用于在并行程序运行过程中触发所述并行程序的锁可能不再被使用的事件通知, 响应于接 收到所有所述标记触发的所述并行程序的锁可能不再被使用的事件通知, 确定所述并行程 序的锁不再被使用。 0030 根据本发明的一个实施例, 可以利用静态代码分析的方法实现对并行程序的锁的 生命周期进行分析, 静态代码分析就是在不执行代码的情况下进行代码检查 ( 例如进行源 代码检查、 二进制代码检查或是字节码检查 )。静态代码扫描是静态代码分析的首要步骤, 以下分别列举针对具有显式破坏锁的函数调用的多线程的并行程序和不具有显式破坏锁 的函数调用的多线程的并行程序进行静态代码分析的实例。为了易于理解, 下述实施。
24、例均 采用对源代码进行静态分析的方式。 0031 第一实施例 0032 以下示出对具有显式破坏锁的函数调用的 c 语言程序 example1.c 进行静态代码 分析的实例, c 语言程序 example1.c 中包含了 Linux 的 pthread 库中的互斥锁 Mutex, 破坏 互斥锁 Mutex 的函数是 : intpthread_mutex_destroy(pthread_mutex_t mutex), 静态代 码分析需要在不执行代码的情况下对源代码 example1.c 进行扫描, 识别出与破坏互斥锁 Mutex 的函数相匹配的函数代码, 进而识别出并行程序运行过程中锁被最后使用的。
25、位置, 并在锁被最后使用的位置附近添加标记, 以在并行程序运行过程中触发锁被破坏的事件通 知, 从而在并行程序运行过程中发送锁不再被使用的事件通知。 0033 说 明 书 CN 101937365 A CN 101937366 A4/13 页 7 0034 说 明 书 CN 101937365 A CN 101937366 A5/13 页 8 0035 通过静态扫描识别出与互斥锁 Mutex 的破坏函数相匹配的函数调用分别是位 于 第 42 行 的 pthread_mutex_destroy(&request_mutex) 和 第 54 行 的 pthread_mutex_ destroy(&。
26、control_mutex)。根据静态扫描的结果确定出在并行程序运行过程中与互斥锁 Mutex 的函数调用对应的破坏点的位置, 如表 1 所示。 0036 说 明 书 CN 101937365 A CN 101937366 A6/13 页 9 锁 锁破坏点的位置 request_mutex example1.c control_mutex example1.c 0037 0038 表 1 0039 接着, 在并行程序中互斥锁 Mutex 所有破坏点的位置附近添加标记, 以便在并行 程序运行时可以根据添加的标记触发发送互斥锁 Mutex 不再被使用的事件通知, 如下所 示, 分别在并行程序的第 。
27、42 行和 54 行之后添加标记 “” , 从而在并行程序运行过程中由添加的标记触发互斥锁 Mutex 不再被使用的事件 通知。响应于接收到互斥锁 Mutex 不再被使用的事件通知, 在并行程序运行过程中确定互 斥锁 Mutex 不再被使用。 0040 0041 图 4a 示出对应于第一实施例的多线程并行程序执行过程的锁图。在程序运行到 第 42 行的位置, 从锁图上删除互斥锁 request_mutex 的节点以及与互斥锁 request_mutex 相关的边, 如图4b所示。 接着, 在程序运行到第54行的位置, 从锁图上删除互斥锁control_ mutex 的节点以及与互斥锁 cont。
28、rol_mutex 相关的边, 如图 4c 所示。从简化后的锁图看出 只剩下一个互斥锁 list_mutex 的节点, 因此不存在死锁的情况。 0042 第二实施例 0043 以下示出对不具有显式破坏锁的函数调用的 Java 语言程序 Example2.java 进行 静态代码分析的实例。 0044 说 明 书 CN 101937365 A CN 101937366 A7/13 页 10 0045 0046 上述的 Java 语言程序实例没有显式的破坏锁 (G, L1 和 L2) 的函数调用, 因此要对 并行程序的数据流进行分析, 确定并行程序中锁被定义和被使用的位置, 从而找到并行程 序运行。
29、过程中锁可能被最后使用的位置的集合。通过静态扫描识别出线程 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, 在第。
30、 13 行释放锁 L2 ; 线程 T2 在第 16 行获得锁 L2, 在第 18 行释放锁 L2 ; 线程 T3 在第 22 行获得 锁 L2, 在第 22 行释放锁。根据扫描结果产生对应于锁 G、 L1 和 L2 的可能被最后使用的位 置的集合, 如表 2 所示。 0047 说 明 书 CN 101937365 A CN 101937366 A8/13 页 11 0048 表 2 0049 接着, 如下所示, 在 Java 语言并行程序中锁 G、 L1 和 L2 可能被最后使用的位置附 近添加标记, 以便在并行程序运行时可以根据添加的标记触发锁 G、 L1 和 L2 不再被使用的 事件通知。。
31、 如下示出在锁(G、 L1和L2)可能被最后使用的位置附近分别添加了标记 “” 、“” 和 “” , 本发明的实施例选择在锁 (G、 L1 和 L2) 可能 被最后使用的位置之后添加标记, 然而并不限于此, 本领域技术人员可以理解在锁可能被 最后使用的位置之前添加标记也能够实现本发明的目的。在程序执行过程中, 由标记触发 事件通知, 响应于接收到事件通知, 更新表 2, 在不同的平台上, 例如 Windows、 Linux, 可以 采用不同的事件通知机制。 0050 0051 根据本发明的实施例, 锁 G 不再被使用需要满足以下两个条件 : 1) 线程 T1 执行到 说 明 书 CN 1019。
32、37365 A CN 101937366 A9/13 页 12 第8行的指令 ; 2)线程T2执行到第20行的指令。 在实际运行中, 在线程T1先执行到第8行 的指令时, 标记触发锁 G 可能不再被使用的事件通知, 通知更新表 2, 将其中的 “T1” 从表 2 中删除, 更新后的表 2 如表 3 所示 : 0052 0053 表 3 0054 接着, 当线程 T2 执行到第 20 行的指令时, 由标记触发锁 G 不再被使用的事件通 知并更新表 3, 响应于接收到锁 G 可能不再被使用的事件通知, 将表 3 中的 “T2” 删除, 由于已接收到锁G的所有标记触发的锁G可能不再被使用的 事件通知。
33、, 因此确定锁 G 不再被使用, 由于锁 G 可能被最后使用的位置集合已被更新为空, 所以将锁 G 从表 3 中删除并通知更新锁图, 更新后的表 3 如表 4 所示 : 0055 0056 表 4 0057 图 5a 示出对应于第二实施例的多线程并行程序执行过程的锁图, 相应的, 从图 5a 上删除锁 G 的节点以及与锁 G 相关的边, 图 5b 示出更新后的锁图, 接着, 对更新的锁图 5b 进行死锁检测。 0058 锁L1不再被使用需要满足以下三个条件 : 1)线程T1执行到第13行的指令 ; 2)线 程 T2 执行到第 18 行的指令 ; 以及 3) 线程 T3 执行到第 24 行的指令。
34、。在实际运行中, 在线 程 T2 先执行到第 18 行的指令时, 标记触发锁 L1 可能不再被使用的事件通知, 通更新表 4, 将其中的 “T2” 从表 4 中删除, 更新后的表 4 如表 5 所示 : 0059 0060 表 5 0061 接着, 在线程 T1 执行到第 13 行的指令, 标记触发锁 L1 不再被使用的事件通知, 通 知更新表 6, 将其中的 “T1” 从表 5 中删除, 更新后的表 5 如表 6 所示 : 说 明 书 CN 101937365 A CN 101937366 A10/13 页 13 0062 0063 表 6 0064 最后, 在线程 T3 执行到第 24 行。
35、的指令, 标记触发锁 L1 可能不再被使用的事件 通知并更新表 6, 响应于接收到锁 L1 不再被使用的事件通知, 将其中的 “T3” 从表 6 中删除, 更新后的表 6 如表 7 所示 : 0065 0066 表 7 0067 由于已接收到锁 L1 的所有标记触发的锁 L1 可能不再被使用的事件通知, 因此确 定锁 L1 不再被使用, 相应的, 从锁图 5b 上删除锁 L1 的节点以及与锁 L1 相关的边, 图 5c 示 出更新后的锁图, 接着, 对更新的锁图 5c 进行死锁检测。 0068 本发明的上述两个实施例利用静态代码扫描实现锁的生命周期的分析, 然而, 并 不仅限于此, 本领域技术。
36、人员可以理解, 也可以在并行程序执行过程中进行代码扫描, 以实 现锁的生命周期的分析。 0069 根据本发明的另一个实施例, 对于支持垃圾回收的运行环境, 可以利用虚拟机提 供的垃圾回收通知机制确定锁不再被使用, 垃圾回收 (Garbagecollection, 即 GC), 或称为 内存垃圾回收, 是一种常用的自动内存管理方式。垃圾回收器将试图回收对象使用的内存 空间, 这些内存空间可能不再被对象使用。 例如程序不再对一对象进行访问或处理, 则为该 对象分配的内存空间可以被垃圾回收。由于运行环境可以提供对象被垃圾回收的通知机 制, 因此可以在运行环境上注册需要通知被垃圾回收的作为锁的对象, 。
37、响应于在并行程序 运行过程中检测到锁被垃圾回收, 即接收到运行环境发出的锁被垃圾回收的事件通知, 确 定这些锁不再被使用。 0070 第三实施例 0071 以下示出利用垃圾回收动态分析 Java 语言程序 Example3.java 的字节码在 JVM(Java 虚拟机 ) 上运行的实例。 0072 说 明 书 CN 101937365 A CN 101937366 A11/13 页 14 0073 首先, 在虚拟机上注册需要通知被垃圾回收的锁G、 L1和L2的对象, 响应于接收到 JVM 发出的 Java 程序的字节码执行到第 14 行指令时锁 G 被垃圾回收的事件通知, 确定锁 G 不再被。
38、使用。图 6a 示出对应于第三实施例的 Java 程序的字节码在 JVM 上运行过程的锁 图, 从图 6a 的锁图中删除锁 G 的节点以及与锁 G 相关的边, 图 6b 示出从图 6a 上删除锁 G 的节点以及与锁 G 相关的边后更新的锁图, 接着, 对更新后的锁图 6b 进行死锁检测。响应 于接收到 JVM 发出的 Java 程序的字节码在 JVM 上运行到第 22 行指令时锁 L1 被垃圾回收 的事件通知, 确定锁 L1 不再被使用, 从图 6b 上删除锁 L1 的节点以及与锁 L1 相关的边, 图 6c 示出从图 6b 上删除锁 L1 的节点以及与锁 L1 相关的边后更新的锁图, 接着,。
39、 对更新的锁 图 6c 进行死锁检测。 0074 根据本发明的另一个实施例, 对于支持垃圾回收的运行环境, 可以将并行程序运 行之前的静态代码分析与并行程序运行过程中的动态分析 ( 垃圾回收通知机制 ) 结合起 来确定锁不再被使用。对于某些应用程序而言, 某些锁可能具有很多可能的最后使用的位 置, 例如上百个, 扫描全部代码需要耗费大量的时间和计算资源, 单纯依靠静态代码分析较 难有效地确定这些锁不再被使用, 为了更有效地确定这些锁不再被使用, 可以先通过静态 代码分析筛选出需要进行动态分析的锁, 在程序运行过程中利用垃圾回收的通知机制确定 锁不再被使用, 静态分析和动态分析的结合方式可以提高。
40、死锁检测的效率。以下示出利用 静态分析和动态分析结合的方式对上述第二实施例中的 Java 语言源代码 Example2.java 进行分析的实例。本发明的实施例尽管是在被 Java 标准规范定义的 Java 虚拟机 (JVM) 的范围内结合 JVM 来运行, 但是 JVM 也可以是任何类型的独立于平台的虚拟机, 如 C#、 Smalltalk、 Ruby、 D 语言、 nuva, 而不仅限于 Java 虚拟机。 0075 第四实施例 0076 根据上述第二实施例的表 2 中的对应于锁 G、 L1 和 L2 的可能被最后使用的位置集 合, 找出可能被最后使用的位置较多的锁进行动态扫描, 例如锁L。
41、1, 从表2中删除锁L1及其 说 明 书 CN 101937365 A CN 101937366 A12/13 页 15 对应的可能被最后使用的位置的集合, 并在 JVM 上注册需要通知被垃圾回收的锁 L1, 利用 第二实施例的静态代码分析的方法在并行程序运行过程中更新表 2 中的锁 G 和 L2 中可能 被最后使用的位置, 从而在并行程序运行过程中确定锁G和L2不再被使用, 相应的, 从锁图 上删除锁 G 和 L2 的节点以及与锁 G 和锁 L2 相关的边。同时, 在并行程序运行过程中, 响应 于接收到 Java 程序的字节码执行到某个位置例如第 20 行锁 L1 被垃圾回收的事件通知, 确。
42、 定出锁 L1 不再被使用, 从相应的锁图上删除锁 L1 的节点以及与锁 L1 相关的边。 0077 基于同一发明构思, 本发明还提供了并行程序的死锁检测系统, 图 7 示出根据本 发明实施例的并行程序的死锁检测系统的框图。 如图所示, 所述并行程序的死锁检测系统, 包括 : 确定装置 701, 被配置为在并行程序运行过程中确定所述并行程序的锁不再被使用 ; 锁删除装置 702, 被配置为从相应的锁图中删除与不再被使用的锁对应的节点以及与不再 被使用的锁相关的边以获得更新的锁图, 其中所述锁图是根据并行程序的锁操作构建的 ; 以及死锁检测装置 703, 被配置为对所述更新的锁图进行死锁检测。 。
43、0078 其中所述确定装置 701 进一步被配置为响应于接收到所述并行程序的锁不再被 使用的事件通知, 在并行程序运行过程中确定所述并行程序的锁不再被使用。 0079 所述确定装置 701 进一步包括锁的生命周期分析装置, 被配置为通过对所述并行 程序的代码进行扫描, 对所述并行程序的锁的生命周期进行分析。 0080 根据本发明的一个实施例, 所述锁的生命周期分析装置进一步被配置为识别出在 所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置的集合。进一步地, 所 述锁的生命周期分析装置被配置为响应于未检测到所述并行程序中存在破坏锁的函数调 用, 对所述并行程序进行数据流分析, 确定所述。
44、并行程序的锁被定义和被使用的位置, 从而 找到在所述并行程序运行过程中所述并行程序的锁可能被最后使用的位置集合。进一步 地, 所述锁的生命周期分析装置被配置为在并行程序的锁可能被最后使用的位置附近添加 标记, 所述标记用于在所述并行程序运行过程中触发所述并行程序的锁可能不再被使用的 事件通知。进一步地, 所述确定装置 701 被配置为响应于接收到所有所述标记触发的所述 并行程序的锁可能不再被使用的事件通知, 确定所述并行程序的锁不再被使用。 0081 其中所述确定装置进一步被配置为响应于在所述并行程序运行中检测到所述并 行程序的锁被垃圾回收, 确定出所述并行程序的锁不再被使用。 0082 根据。
45、本发明的一个实施例, 所述锁的生命周期分析装置进一步被配置为响应于检 测到并行程序中存在破坏锁的函数调用, 确定出并行程序运行过程中锁被最后使用的位 置。 进一步地, 所述锁的生命周期分析装置被配置为在锁被最后使用的位置附近添加标记, 以在所述并行程序运行过程中触发所述并行程序的锁不再被使用的事件通知。 0083 根据本发明的一个实施例, 所述确定装置进一步被配置为响应于在并行程序运行 过程中检测到并行程序的锁被垃圾回收, 确定出并行程序的锁不再被使用。 0084 利用本发明实施例的并行程序中死锁检测的方法和系统, 基于修剪之后的锁图进 行有向环的检测以确定是否存在潜在的死锁, 能够节约大量时。
46、间和计算资源, 假设一个并 行程序的锁图有 N 个节点和 E 条边, 检查锁图中的有向环的算法分为以下两个步骤 : 1. 在 锁图中找到所有的强连通分量, 算法复杂度为 O(N+E) ; 2. 在每个强连通分量中找到所有的 有向环, 算法复杂度为 O(N2)。因此, 整个算法复杂度为 O(N2+E)。由此可以看出, 节点数目 的减少, 大大减小了算法的复杂度, 提高了死锁检测的效率。 说 明 书 CN 101937365 A CN 101937366 A13/13 页 16 0085 应当理解, 本发明的至少某些方面可以可替代地以程序产品实现。定义有关本发 明的功能的程序可以通过各种信号承载介。
47、质被传送到数据存储系统或计算机系统, 所述信 号承载介质包括但不限于, 不可写存储介质(例如, CD-ROM)、 可写存储介质(例如, 软盘、 硬 盘驱动器、 读/写CD ROM、 光介质)以及诸如包括以太网的计算机和电话网络之类的通信介 质。 因此应当理解, 在此类信号承载介质中, 当携带或编码有管理本发明中的方法功能的计 算机可读指令时, 代表本发明的可替代实施例。本发明可以硬件、 软件、 固件或其组合的方 式实现。 本发明可以集中的方式在一个计算机系统中实现, 或以分布方式实现, 在这种分布 方式中, 不同的部件分布在若干互连的计算机系统中。适于执行本文中描述的方法的任何 计算机系统或其。
48、它装置都是合适的。优选地, 本发明以计算机软件和通用计算机硬件的组 合的方式实现, 在这种实现方式中, 当该计算机程序被加载和执行时, 控制该计算机系统而 使其执行本发明的方法, 或构成本发明的系统。 0086 上面出于举例说明的目的, 给出了本发明的优选实施例的说明。优选实施例的上 述说明不是穷尽的, 也不打算把本发明局限于公开的明确形式, 显然鉴于上述教导, 许多修 改和变化是可能的。 对本领域的技术人员来说显而易见的这种修改和变化包括在由附加的 权利要求限定的本发明的范围内。 说 明 书 CN 101937365 A CN 101937366 A1/4 页 17 图 1 图 2 说 明 书 附 图 CN 101937365 A CN 101937366 A2/4 页 18 图 3 图 4a 说 明 书 附 图 CN 101937365 A CN 101937366 A3/4 页 19 图 4b 图 4c 图 5a 图 5b 图 5c 说 明 书 附 图 CN 101937365 A CN 101937366 A4/4 页 20 图 6a 图 6b 图 6c 图 7 说 明 书 附 图 CN 101937365 A 。