CN103246552B - 防止线程出现阻塞的方法和装置 - Google Patents
防止线程出现阻塞的方法和装置 Download PDFInfo
- Publication number
- CN103246552B CN103246552B CN201210032791.7A CN201210032791A CN103246552B CN 103246552 B CN103246552 B CN 103246552B CN 201210032791 A CN201210032791 A CN 201210032791A CN 103246552 B CN103246552 B CN 103246552B
- Authority
- CN
- China
- Prior art keywords
- thread
- critical zone
- application program
- program interface
- determined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
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,ApplicationProgramming 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系统中所有的临界区操作函数,包括EnterCriticalSection函数和LeaveCritical Section函数等,通过HOOK后的临界区操作函数来实时记录下每个线程所占用的临界区的位置,即当前有哪些线程正占用着哪些临界区,以及这些临界区的位置,这样,当需要释放某一临界区时,直接根据所记录的位置找到该临界区,并调用LeaveCriticalSection函数进行释放即可,省去了遍历等过程。
3)死锁
为克服由于死锁而导致的线程出现阻塞,可采用以下处理方式:周期性地轮询需要进行检测的所有线程,如果确定一线程的阻塞时长超过预定时长,则进一步确定该线程是否阻塞在用于占用临界区的API函数的调用上,如果是,则释放所调用的API函数的第一个参数对应的临界区。
其中,需要进行检测的所有线程可以是指全部已启动的线程,或者是指全部已启动的线程中的部分指定线程,如比较重要的线程。
所述用于占用临界区的API函数通常为EnterCriticalSection函数。
如果一线程请求占用一个临界区,那么其会调用EnterCriticalSection函数,如果出现死锁的状况,那么该线程就会阻塞在EnterCriticalSection函数的调用上。
假设第一次轮询时发现一线程处于阻塞状态,第二次轮询时发现该线程仍处于阻塞状态,那么则可认为该线程的阻塞时长为两次轮询之间间隔的时长,如果该时长超过预定时长,则可通过调用SuspendThread函数来暂停该线程,并可通过调用StackWalk64函数来检测该线程的执行堆栈,以确定该线程是否阻塞在EnterCriticalSection函数的调用上,如果是,则释放EnterCriticalSection函数的第一个参数对应的临界区,即该线程请求占用的临界区。
如果在第二次轮询之后,发现该线程的阻塞时长未超过预定时长,那么则可在第三次轮询之后,如果该线程仍处于阻塞状态,将第三次轮询到第一次轮询之间间隔的时长作为该线程的阻塞时长,并确定是否超过预定时长,依次类推。所述预定时长的具体取值可根据实际需要而定。
上述为克服由于死锁而导致的线程出现阻塞的方式同样适用于由于锁遗弃而导致的线程出现阻塞。
基于上述介绍,本发明公开了在多线程程序中防止线程出现阻塞的装置,包括:
第一处理模块,用于当系统启动后,替换系统中所有用于等待事件触发的API函数,使得当任一被替换后的API函数被一线程调用时,如果确定该线程中设定的等待时长为无限长,则将其修改为一个有限长度的预定值。
或者,所述装置包括:
第二处理模块,用于当系统启动后,替换系统中所有用于结束线程的API函数,使得当任一被替换后的API函数被一线程调用时,如果确定要结束的线程所占用的临界区未释放,则进行释放。
或者,所述装置包括:
第三处理模块,用于周期性地轮询需要进行检测的所有线程,如果确定一线程的阻塞时长超过预定时长,则进一步确定该线程是否阻塞在用于占用临界区的API函数的调用上,如果是,则释放所调用的API函数的第一个参数对应的临界区。
上述装置实施例的具体工作流程请参照前述相应说明,此处不再赘述。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (7)
1.一种防止线程出现阻塞的方法,其特征在于,包括:
当系统启动后,替换系统中所有用于等待事件触发的应用程序接口函数,使得当任一被替换后的应用程序接口函数被一线程调用时,如果确定该线程中设定的等待时长为无限长,则将其修改为一个有限长度的预定值;
所述将其修改为一个有限长度的预定值之前,进一步包括:
确定该线程是否为可信任线程,如果是,则将该线程的等待时长修改为一个有限长度的预定值。
2.一种防止线程出现阻塞的方法,其特征在于,包括:
当系统启动后,替换系统中所有用于结束线程的应用程序接口函数,使得当任一被替换后的应用程序接口函数被一线程调用时,如果确定要结束的线程所占用的临界区未释放,则进行释放。
3.根据权利要求2所述的方法,其特征在于,所述进行释放包括:
确定临界区列表的列表头的位置,通过遍历所述临界区列表,找到需要释放的临界区,并进行释放;
或者,当系统启动后,实时记录每个线程所占用的临界区的位置,根据所记录的位置找到需要释放的临界区,并进行释放。
4.根据权利要求3所述的方法,其特征在于,所述确定临界区列表的列表头的位置包括:
获取系统调用动态链接库的起始位置以及所述临界区列表相对于所述系统调用动态链接库的起始位置的偏移量,根据所述系统调用动态链接库的起始位置以及所述偏移量得到所述临界区列表的列表头的位置。
5.根据权利要求4所述的方法,其特征在于,所述实时记录每个线程所占用的临界区的位置包括:
当系统启动后,替换系统中所有的临界区操作函数,通过替换后的临界区操作函数来实时记录每个线程所占用的临界区的位置。
6.一种防止线程出现阻塞的装置,其特征在于,包括:
第一处理模块,用于当系统启动后,替换系统中所有用于等待事件触发的应用程序接口函数,使得当任一被替换后的应用程序接口函数被一线程调用时,如果确定该线程中设定的等待时长为无限长,则将其修改为一个有限长度的预定值;而且,所述第一处理模块在将该线程的等待时长修改为一个有限长度的预定值之前,还确定该线程是否为可信任线程,如果是,则将该线程的等待时长修改为一个有限长度的预定值。
7.一种防止线程出现阻塞的装置,其特征在于,包括:
第二处理模块,用于当系统启动后,替换系统中所有用于结束线程的应用程序接口函数,使得当任一被替换后的应用程序接口函数被一线程调用时,如果确定要结束的线程所占用的临界区未释放,则进行释放。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210032791.7A CN103246552B (zh) | 2012-02-14 | 2012-02-14 | 防止线程出现阻塞的方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210032791.7A CN103246552B (zh) | 2012-02-14 | 2012-02-14 | 防止线程出现阻塞的方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103246552A CN103246552A (zh) | 2013-08-14 |
CN103246552B true CN103246552B (zh) | 2018-03-09 |
Family
ID=48926083
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210032791.7A Active CN103246552B (zh) | 2012-02-14 | 2012-02-14 | 防止线程出现阻塞的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103246552B (zh) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105989632B (zh) * | 2015-02-27 | 2019-05-10 | 深圳市金溢科技股份有限公司 | 一种自由流系统及其交易方法及装置 |
CN106325980A (zh) * | 2015-06-30 | 2017-01-11 | 中国石油化工股份有限公司 | 一种多线程并发系统 |
CN107291558B (zh) * | 2016-03-30 | 2020-11-24 | 阿里巴巴集团控股有限公司 | 一种应用程序接口死锁监控方法和装置 |
CN105975325A (zh) * | 2016-04-22 | 2016-09-28 | 浙江工业大学 | 一种自动跳出阻塞式代码段的控制方法 |
CN106506279B (zh) * | 2016-11-11 | 2019-12-13 | 盛科网络(苏州)有限公司 | 网络死锁状态检测方法及装置 |
WO2018165952A1 (zh) * | 2017-03-16 | 2018-09-20 | 深圳大趋智能科技有限公司 | iOS线程恢复的方法及装置 |
CN109213576B (zh) * | 2017-07-01 | 2022-04-08 | 武汉斗鱼网络科技有限公司 | 程序死锁检测方法、存储介质、设备及系统 |
CN107678945B (zh) * | 2017-09-04 | 2020-04-21 | 清华大学 | 一种网页应用阻塞的判断方法及装置 |
CN110023907B (zh) * | 2017-10-09 | 2021-08-20 | 华为技术有限公司 | 一种处理方法及装置 |
CN107967177B (zh) * | 2017-11-30 | 2022-02-22 | 努比亚技术有限公司 | 基于核心进程的内存优化方法、移动终端及可读存储介质 |
CN107967181B (zh) * | 2017-12-19 | 2021-11-16 | 北京小米移动软件有限公司 | 临界区的控制方法及装置 |
CN111192809B (zh) * | 2018-11-15 | 2024-06-04 | 北京中科信电子装备有限公司 | 一种特种离子注入机自动引束的方法 |
CN111459462B (zh) * | 2019-01-20 | 2023-05-09 | 华为技术有限公司 | 分散式重锁降级 |
CN110750348A (zh) * | 2019-10-23 | 2020-02-04 | 神州数码融信软件有限公司 | 批量作业调度方法及装置 |
CN111782410B (zh) * | 2020-06-30 | 2023-06-27 | 抖音视界有限公司 | 锁堵塞的监控方法、装置、电子设备及计算机可读介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1478230A (zh) * | 2001-03-05 | 2004-02-25 | 皇家菲利浦电子有限公司 | 用于从阻塞任务收回预算资源的方法和系统 |
CN1917504A (zh) * | 2005-08-20 | 2007-02-21 | 中兴通讯股份有限公司 | 一种避免资源数据共享访问导致死锁的加锁方法 |
CN101046755A (zh) * | 2006-03-28 | 2007-10-03 | 郭明南 | 一种计算机自动内存管理的系统及方法 |
CN101976203A (zh) * | 2010-09-26 | 2011-02-16 | 清华大学 | 并行化仿真多线程管理方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5987492A (en) * | 1997-10-31 | 1999-11-16 | Sun Microsystems, Inc. | Method and apparatus for processor sharing |
US7313673B2 (en) * | 2005-06-16 | 2007-12-25 | International Business Machines Corporation | Fine grained multi-thread dispatch block mechanism |
CN101334742B (zh) * | 2008-08-05 | 2011-06-01 | 中国科学院软件研究所 | 一种Java EE应用服务器并发处理方法 |
CN101504658B (zh) * | 2009-01-23 | 2011-09-28 | 北京搜狗科技发展有限公司 | 一种实现多标签应用程序中进行消息交互的方法及系统 |
-
2012
- 2012-02-14 CN CN201210032791.7A patent/CN103246552B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1478230A (zh) * | 2001-03-05 | 2004-02-25 | 皇家菲利浦电子有限公司 | 用于从阻塞任务收回预算资源的方法和系统 |
CN1917504A (zh) * | 2005-08-20 | 2007-02-21 | 中兴通讯股份有限公司 | 一种避免资源数据共享访问导致死锁的加锁方法 |
CN101046755A (zh) * | 2006-03-28 | 2007-10-03 | 郭明南 | 一种计算机自动内存管理的系统及方法 |
CN101976203A (zh) * | 2010-09-26 | 2011-02-16 | 清华大学 | 并行化仿真多线程管理方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103246552A (zh) | 2013-08-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103246552B (zh) | 防止线程出现阻塞的方法和装置 | |
US20220214930A1 (en) | Systems and Methods for Performing Concurrency Restriction and Throttling over Contended Locks | |
US11726838B2 (en) | Generic concurrency restriction | |
Warner et al. | Sevoflurane and halothane reduce focal ischemic brain damage in the rat. Possible influence on thermoregulation. | |
US8544020B1 (en) | Cooperative preemption | |
US8020166B2 (en) | Dynamically controlling the number of busy waiters in a synchronization object | |
US20130160028A1 (en) | Method and apparatus for low latency communication and synchronization for multi-thread applications | |
WO2010095198A1 (ja) | 資源排他制御方法および資源排他制御装置 | |
US9778962B2 (en) | Method for minimizing lock contention among threads when tasks are distributed in multithreaded system and apparatus using the same | |
TW200928968A (en) | A thread group management method for a process | |
US20130081062A1 (en) | Scalable, Parallel Processing of Messages While Enforcing Custom Sequencing Criteria | |
KR20140131961A (ko) | 저장 풀에서의 디스크 소유권 중재 기법 | |
TW201346625A (zh) | 在具有安全網域與較不安全網域之資料處理設備之例外處理 | |
EP3037303B1 (en) | Vehicle control device | |
EP2664989A1 (en) | Task scheduling | |
US8051417B2 (en) | Target thread selection in a multi-threaded process | |
Short | The case for non-preemptive, deadline-driven scheduling in real-time embedded systems | |
US20100037086A1 (en) | Robust critical section design in multithreaded applications | |
TW200905567A (en) | Notifying user mode scheduler of blocking events | |
US8850095B2 (en) | Livelock prevention mechanism in a ring shaped interconnect utilizing round robin sampling | |
CN107544843A (zh) | 一种分区系统调度算法 | |
Hong et al. | Locking Based Concurrency Control for Integrated Real-Time Database Systems. | |
US20160328309A1 (en) | Method and apparatus for monitoring a control flow of a computer program | |
CN109324916B (zh) | 一种任务执行方法和装置 | |
Hart et al. | Requeue-pi: Making glibc condvars pi-aware |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |