CN103246552A - 防止线程出现阻塞的方法和装置 - Google Patents

Abstract

本发明公开了防止线程出现阻塞的方法和装置：系统启动后，替换系统中所有用于等待事件触发的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定其设定的等待时长为无限长，则修改为一个预定值；或，系统启动后，替换系统中所有用于结束线程的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则释放；或，周期性地进行线程轮询，如果确定一线程的阻塞时长超过预定时长，且该线程阻塞在用于占用临界区的应用程序接口函数的调用上，则释放所调用的应用程序接口函数的第一个参数对应的临界区。应用本发明所述方案，能够确保程序的顺利执行。

Description

防止线程出现阻塞的方法和装置

技术领域

本发明涉及计算机技术，特别涉及防止线程出现阻塞的方法和装置。

背景技术

每个正在系统上运行的程序都是一个进程，每个进程中可包括一个或多个线程，线程是程序执行流的最小单元。

每个线程内的指令执行顺序都是固定的。图1为现有一线程内的指令执行方式示意图。如图1所示，首先执行指令1，之后执行指令2，依次类推，一直到执行完指令n(假设n大于2)，结束。

通常，将包括多个线程的程序称为多线程程序。在多线程程序中，当多个线程需要对同一片数据，即共享数据进行访问时，由于指令的执行顺序是不一样的，因此需要使用锁来实现互斥访问。

图2为现有多线程程序中使用锁来实现互斥访问的示意图。如图2所示，当线程B需要获取锁时，如果线程A正占用着锁，那么线程B将出现阻塞，只有等到线程A释放锁后，线程B才能进行后续处理。

虽然使用锁可以实现互斥访问，但在实际应用中也会引起一些问题，如引起死锁和锁遗弃等，进而导致线程出现不希望的阻塞。

图3为现有多线程程序中由于死锁而导致线程出现阻塞的示意图。如图3所示，线程A占用着锁A请求获取锁B，线程B占用着锁B请求获取锁A，由于锁B已经被线程B占用，因此线程A需要等到线程B释放锁B之后才能获取到锁B，同样，由于锁A已经被线程A占用，因此线程B需要等到线程A释放锁A之后才能获取到锁A，也就是说，两个线程之间会出现一个互相等待的状况，从而造成死锁，进而导致两个线程均出现阻塞。

图4为现有多线程程序中由于锁遗弃而导致线程出现阻塞的示意图。如图4所示，当线程A占用着锁A进行相关处理时，如果被一线程强行结束掉，那么就会导致锁A未被释放，从而出现锁遗弃的问题，如果之后线程B请求获取锁A，由于锁A已经被遗弃，因此将不能被线程B获取到，从而导致线程B出现阻塞。

在实际应用中，除了死锁和锁遗弃外，等待事件触发也会导致线程出现不希望的阻塞。

图5为现有多线程程序中由于等待事件触发而导致线程出现阻塞的示意图。如图5所示，假设线程A中设置的是只有当事件B被触发后，才能触发事件A，但由于某种原因，事件B一直未被触发，那么线程A将无限等待事件B的触发，相应地，也就无法触发事件A，而线程B设置的是只有等到事件A被触发之后，才能进行后续处理，因此，线程B将无限等待事件A的触发，从而导致线程B出现阻塞等。

无论是死锁、锁遗弃还是等待事件触发而导致的阻塞，均会导致程序不能被顺利执行。

发明内容

有鉴于此，本发明提供了防止线程出现阻塞的方法和装置，能够确保程序的顺利执行。

为达到上述目的，本发明的技术方案是这样实现的：

一种防止线程出现阻塞的方法，包括：

当系统启动后，替换系统中所有用于等待事件触发的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

一种防止线程出现阻塞的方法，包括：

当系统启动后，替换系统中所有用于结束线程的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则进行释放。

一种防止线程出现阻塞的方法，包括：

周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上，如果是，则释放所调用的应用程序接口函数的第一个参数对应的临界区。

一种防止线程出现阻塞的装置，包括：

第一处理模块，用于当系统启动后，替换系统中所有用于等待事件触发的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

一种防止线程出现阻塞的装置，包括：

第二处理模块，用于当系统启动后，替换系统中所有用于结束线程的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则进行释放。

一种防止线程出现阻塞的装置，包括：

第三处理模块，用于周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上，如果是，则释放所调用的应用程序接口函数的第一个参数对应的临界区。

可见，采用本发明所述方案，通过替换相关的应用程序接口函数，可将等待时长设定为无限长的线程中的等待时长修改为有限长度的预定值，从而克服了由于等待事件触发而导致的线程出现阻塞；同样，通过替换相关的应用程序接口函数，当一线程结束时，如果确定其占用的临界区未释放，则可进行释放，从而克服了由于锁遗弃而导致的线程出现阻塞；再有，如果确定一线程阻塞在了用于占用临界区的应用程序接口函数的调用上，则可释放所调用的应用程序接口函数的第一个参数对应的临界区，从而克服了由于死锁而导致的线程出现阻塞。总之，采用本发明所述方案，能够确保程序的顺利执行。而且，本发明所述方案实现起来简单方便，便于普及和推广。

附图说明

图1为现有一线程内的指令执行方式示意图。

图2为现有多线程程序中使用锁来实现互斥访问的示意图。

图3为现有多线程程序中由于死锁而导致线程出现阻塞的示意图。

图4为现有多线程程序中由于锁遗弃而导致线程出现阻塞的示意图。

图5为现有多线程程序中由于等待事件触发而导致线程出现阻塞的示意图。

具体实施方式

针对现有技术中存在的问题，本发明中提出一种在多线程程序中防止线程出现阻塞的方案。

基于之前的介绍可知，线程出现阻塞可能是由各种原因引起的，如死锁、锁遗弃和等待事件触发等，本发明针对上述几种原因，分别给出了相应的解决方法，以下分别进行介绍。

在Windows系统中，通常采用临界区来实现锁的功能。

1)等待事件触发

为克服由于等待事件触发而导致的线程出现阻塞，可采用以下处理方式：当系统启动后，替换(HOOK)系统中所有用于等待事件触发的应用程序接口(API，Application Programming Interface)函数，使得当任一被HOOK后的API函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

如何进行HOOK为现有技术。

在实际应用中，当一线程等待事件触发时，会调用一个用于等待事件触发的API函数，并会传送给所调用的API函数一个参数，用于说明所设定的等待时长，所设定的等待时长有可能是一个有限长度的时长，也可能是无限长(INFINITE)，表示会无限等待，从而即可能会引起图5所示问题。

用于等待事件触发的API函数通常包括：

WaitForSingleObject/WaitForSingleObjectEx；

WaitForMultipleObjects/WaitForMultipleObjectsEx；

MsgWaitForMultipleObjects/MsgWaitForMultipleObjectsEx。

其中，“/”之前的没有以Ex结尾的API函数会调用“/”之后的以Ex结尾的API函数来完成其功能。

通常，当一线程需要等待一个事件的触发时，会调用WaitForSingleObject函数，当需要同时等待多个事件的触发时，会调用WaitForMultipleObjects函数，当在等待多个事件的触发的同时，还需要处理窗口消息时，则会调用MsgWaitForMultipleObjects函数，各函数的具体功能均为本领域公知。

当系统启动后，可HOOK上面所提到的三个API函数，使得当一被HOOK后的函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值，该预定值的具体取值可根据实际需要而定，通常会较大，以便尽可能地等待事件触发，但又能避免无限等待事件触发。

另外，采用上述方式后，相当于强制结束了线程对事件的等待，可能会造成一些隐藏的问题，如影响后续流程的执行等，为此，在将线程的等待时长修改为一个有限长度的预定值之前，可先确定该线程是否为可信任线程，如果是，则将该线程的等待时长修改为一个有限长度的预定值，否则，可不进行修改。比如，对于内部线程，其可被设计为允许强制结束对事件的等待，之后的流程仍可执行，那么这些线程即为可信任线程。

2)锁遗弃

为克服由于锁遗弃而导致的线程出现阻塞，可采用以下处理方式：当系统启动后，HOOK系统中所有用于结束线程的API函数，使得当任一被HOOK后的API函数被一线程调用时，如果确定要结束的线程所占用的临界区未被释放，则进行释放。

上述线程结束可以是指线程自己结束，也可以是指被其它线程强行结束。

在实际应用中，当需要结束线程时，会调用用于结束线程的API函数，包括：ExitThread函数和TerminateThread函数等。

当ExitThread函数和TerminateThread函数被HOOK后，某一线程再调用ExitThread函数或TerminateThread函数时，调用的就将是HOOK后的ExitThread函数或TerminateThread函数；相应地，HOOK后的ExitThread函数或TerminateThread函数会确定要结束的线程所占用的临界区是否已被释放，如果未被释放，则进行释放。

举例说明：

当线程A结束时，会调用HOOK后的ExitThread函数，如果HOOK后的ExitThread函数确定出线程A所占用的临界区未被释放，则会进行释放；

当线程A要强行结束线程B时，会调用HOOK后的TerminateThread函数，如果HOOK后的TerminateThread函数确定出线程B所占用的临界区未被释放，则会进行释放。

在Windows系统中，当一线程需要占用一临界区时，可通过调用EnterCriticalSection函数等来请求独占临界区，等当前占用着临界区的线程释放临界区之后，该线程即可占用临界区。

当HOOK后的ExitThread函数或TerminateThread函数确定要结束的线程所占用的临界区未被释放后，可采用以下方式进行释放：确定临界区列表的列表头的位置，通过遍历临界区列表，找到需要释放的临界区，并进行释放(方式一)，或者，当系统启动后，实时记录每个线程所占用的临界区的位置，根据所记录的位置找到需要释放的临界区，并进行释放(方式二)，以下对这两种释放方式分别进行说明。

方式一

在系统调用动态链接库，即ntdll.dll文件中，保存有一个临界区列表，其中记录有当前各线程所占用的所有临界区。

通常，ntdll.dll文件的起始位置是已知的，那么如果知道临界区列表相对于ntdll.dll文件的起始位置的偏移量，即可知道临界区列表的列表头的位置，即临界区列表中的第一个临界区的位置。

对于不同版本的ntdll.dll文件来说，其中的临界区列表的列表头的位置可能是不一样的，因此，可维护一个表一所示的表格：

ntdll.dll版本	偏移量
		6.1.7600.*	0x000d8118
......	......

表一不同版本的ntdll.dll文件分别对应的偏移量

由于所用的ntdll.dll文件的版本是可知的，那么根据其起始位置以及对应的偏移量即可得到临界区列表的列表头的位置。

或者，在实际应用中，也可通过符号ntdll！RtlCriticalSectionLock来得到所用的ntdll.dll文件的版本对应的偏移量。

在得到临界区列表的列表头的位置之后，即可通过遍历临界区列表来找到所要释放的临界区，并调用LeaveCritical Section函数进行释放。

方式二

当系统启动后，可HOOK系统中所有的临界区操作函数，包括EnterCritical Section函数和LeaveCritical Section函数等，通过HOOK后的临界区操作函数来实时记录下每个线程所占用的临界区的位置，即当前有哪些线程正占用着哪些临界区，以及这些临界区的位置，这样，当需要释放某一临界区时，直接根据所记录的位置找到该临界区，并调用LeaveCriticalSection函数进行释放即可，省去了遍历等过程。

3)死锁

为克服由于死锁而导致的线程出现阻塞，可采用以下处理方式：周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的API函数的调用上，如果是，则释放所调用的API函数的第一个参数对应的临界区。

其中，需要进行检测的所有线程可以是指全部已启动的线程，或者是指全部已启动的线程中的部分指定线程，如比较重要的线程。

所述用于占用临界区的API函数通常为EnterCriticalSection函数。

如果一线程请求占用一个临界区，那么其会调用EnterCriticalSection函数，如果出现死锁的状况，那么该线程就会阻塞在EnterCriticalSection函数的调用上。

假设第一次轮询时发现一线程处于阻塞状态，第二次轮询时发现该线程仍处于阻塞状态，那么则可认为该线程的阻塞时长为两次轮询之间间隔的时长，如果该时长超过预定时长，则可通过调用SuspendThread函数来暂停该线程，并可通过调用StackWalk64函数来检测该线程的执行堆栈，以确定该线程是否阻塞在EnterCriticalSection函数的调用上，如果是，则释放EnterCriticalSection函数的第一个参数对应的临界区，即该线程请求占用的临界区。

如果在第二次轮询之后，发现该线程的阻塞时长未超过预定时长，那么则可在第三次轮询之后，如果该线程仍处于阻塞状态，将第三次轮询到第一次轮询之间间隔的时长作为该线程的阻塞时长，并确定是否超过预定时长，依次类推。所述预定时长的具体取值可根据实际需要而定。

上述为克服由于死锁而导致的线程出现阻塞的方式同样适用于由于锁遗弃而导致的线程出现阻塞。

基于上述介绍，本发明公开了在多线程程序中防止线程出现阻塞的装置，包括：

第一处理模块，用于当系统启动后，替换系统中所有用于等待事件触发的API函数，使得当任一被替换后的API函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

或者，所述装置包括：

第二处理模块，用于当系统启动后，替换系统中所有用于结束线程的API函数，使得当任一被替换后的API函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则进行释放。

或者，所述装置包括：

第三处理模块，用于周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的API函数的调用上，如果是，则释放所调用的API函数的第一个参数对应的临界区。

上述装置实施例的具体工作流程请参照前述相应说明，此处不再赘述。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (12)

1.一种防止线程出现阻塞的方法，其特征在于，包括：

当系统启动后，替换系统中所有用于等待事件触发的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

2.根据权利要求1所述的方法，其特征在于，所述将其修改为一个有限长度的预定值之前，进一步包括：

确定该线程是否为可信任线程，如果是，则将该线程的等待时长修改为一个有限长度的预定值。

3.一种防止线程出现阻塞的方法，其特征在于，包括：

当系统启动后，替换系统中所有用于结束线程的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则进行释放。

4.根据权利要求3所述的方法，其特征在于，所述进行释放包括：

确定临界区列表的列表头的位置，通过遍历所述临界区列表，找到需要释放的临界区，并进行释放；

或者，当系统启动后，实时记录每个线程所占用的临界区的位置，根据所记录的位置找到需要释放的临界区，并进行释放。

5.根据权利要求4所述的方法，其特征在于，所述确定确定临界区列表的列表头的位置包括：

获取系统调用动态链接库的起始位置以及所述临界区列表相对于所述系统调用动态链接库的起始位置的偏移量，根据所述系统调用动态链接库的起始位置以及所述偏移量得到所述临界区列表的列表头的位置。

6.根据权利要求5所述的方法，其特征在于，所述实时记录每个线程所占用的临界区的位置包括：

当系统启动后，替换系统中所有的临界区操作函数，通过替换后的临界区操作函数来实时记录每个线程所占用的临界区的位置。

7.一种防止线程出现阻塞的方法，其特征在于，包括：

周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上，如果是，则释放所调用的应用程序接口函数的第一个参数对应的临界区。

8.根据权利要求7所述的方法，其特征在于，所述确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上包括：

暂停该线程，并通过检测该线程的执行堆栈来确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上。

9.根据权利要求7所述的方法，其特征在于，所述需要进行检测的所有线程为：全部已启动的线程，或者，全部已启动的线程中的部分指定线程。

10.一种防止线程出现阻塞的装置，其特征在于，包括：

第一处理模块，用于当系统启动后，替换系统中所有用于等待事件触发的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定该线程中设定的等待时长为无限长，则将其修改为一个有限长度的预定值。

11.一种防止线程出现阻塞的装置，其特征在于，包括：

第二处理模块，用于当系统启动后，替换系统中所有用于结束线程的应用程序接口函数，使得当任一被替换后的应用程序接口函数被一线程调用时，如果确定要结束的线程所占用的临界区未释放，则进行释放。

12.一种防止线程出现阻塞的装置，其特征在于，包括：

第三处理模块，用于周期性地轮询需要进行检测的所有线程，如果确定一线程的阻塞时长超过预定时长，则进一步确定该线程是否阻塞在用于占用临界区的应用程序接口函数的调用上，如果是，则释放所调用的应用程序接口函数的第一个参数对应的临界区。

Images