A deadlock real-time detection method, device, equipment and storage medium

Abstract

The present application discloses a real-time deadlock detection method, device, equipment and storage medium, and relates to the field of application development technology. The method comprises: when a thread needs to be created, a pre-created first encapsulation interface is called, relevant information of thread creation is recorded through the first encapsulation interface to obtain thread information, the thread information is stored in a first node linked list for counting thread information, and a thread creation function in a dynamic library is called through the first encapsulation interface; when a target thread needs to apply for a thread lock, a pre-encapsulated second encapsulation interface is called, relevant information of thread lock application is recorded through the second encapsulation interface to obtain thread lock information, the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread successfully applies for the thread lock within a preset time length; if the thread lock is not applied for, based on the first node linked list and the second node linked list, whether the target thread is deadlocked is determined according to the deadlock judgment logic. It can realize efficient real-time detection of deadlock.

Description

Technical Field

[0001] The present invention relates to the field of application development technology, and in particular to a deadlock real-time detection method, device, equipment and storage medium. Background Art

[0002] Multithreading refers to the technology of executing multiple threads simultaneously within a single process. Each thread, as the smallest unit of independent execution, can concurrently execute different tasks or functions, effectively utilizing the parallel computing capabilities of multi-core processors to improve the response speed and concurrent processing capabilities of programs. However, the advantages of multithreading concurrency and resource sharing will bring about problems of resource competition and data inconsistency. To address this problem, mutexes came into being. Mutexes are a multithreaded synchronization mechanism used to protect shared resources and ensure that only one thread can access the resource at any time, thereby avoiding data competition and data inconsistency. However, when there are circular dependent resources between multiple threads or processes, deadlock may occur, that is, all participants are waiting for the other party to release resources and cannot continue to execute.

[0003] In the related art, the deadlock phenomenon is detected by modifying the kernel code logic and adding additional detection threads. However, this solution will increase the kernel burden, destroy the kernel stability, and its scalability is not strong. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a deadlock real-time detection method, device, equipment and storage medium, which can realize efficient real-time detection of deadlock. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a real-time deadlock detection method, which is applied to an application program, comprising:

[0006] When a thread needs to be created, a pre-created first encapsulation interface is called, relevant information about thread creation is recorded through the first encapsulation interface to obtain thread information, the thread information is stored in a first node linked list for counting thread information, and a thread creation function in a dynamic library is called through the first encapsulation interface;

[0007] When the target thread needs to apply for a thread lock, the pre-created second encapsulation interface is called, and the relevant information of the thread lock application is recorded through the second encapsulation interface to obtain thread lock information, the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread successfully applies for the thread lock within a preset time period;

[0008] If the thread lock is not applied for, whether the target thread is deadlocked is determined according to the deadlock determination logic based on the first node linked list and the second node linked list.

[0009] Optionally, before calling the pre-created first encapsulation interface, the method further includes:

[0010] encapsulate the first encapsulation interface according to the interface name of the thread creation function interface, so that the first encapsulation interface is called when the application needs to create a thread;

[0011] The second encapsulation interface is encapsulated according to the interface name of the lock application function interface, so that the second encapsulation interface is called when the application needs to apply for a thread lock.

[0012] Optionally, the thread information includes: thread attributes, creation time, thread function address, thread function parameter address, process ID, thread ID, thread stack address and stack size.

[0013] Optionally, recording relevant information of the thread lock application through the second encapsulation interface to obtain thread lock information includes:

[0014] According to the thread identifier of the target thread, acquiring target thread information corresponding to the target thread from the first node linked list;

[0015] Update the state of the target thread to a thread lock request state, and update the number of requests;

[0016] Target thread lock information is generated based on the thread lock request state and the number of requests, and a mapping relationship is established between the target thread information and the target thread lock information.

[0017] Optionally, before calling the pre-created first encapsulation interface when a thread needs to be created, the method further includes:

[0018] When the dynamic library needs to be called, the pre-packaged third encapsulation interface is called, the relevant information of the function call operation executed by the application is recorded through the third encapsulation interface, and the dynamic library is called through the third encapsulation interface.

[0019] Optionally, before calling the pre-packaged third encapsulation interface, the method further includes:

[0020] The third encapsulation interface is encapsulated according to the interface name of the dynamic library interface, so that the third encapsulation interface is called when the application needs to call the dynamic library.

[0021] Optionally, before storing the thread information into the first node linked list for counting thread information, the method further includes:

[0022] Initialize a hash table based on an array and a linked list using the first memory space to obtain the first node linked list;

[0023] Initialize a hash table based on an array and a linked list using the second memory space to obtain the second node linked list;

[0024] Storing the thread information in a first node linked list for counting thread information includes:

[0025] Acquire an idle node from the first node linked list, and use the idle node to store the thread information;

[0026] Storing the thread lock information in a second node linked list for counting lock information includes:

[0027] Obtain an idle node from the second node linked list, and use the idle node to store the thread lock information.

[0028] Optionally, the real-time deadlock detection method further includes:

[0029] When the created thread ends, the thread information corresponding to the created thread in the first node linked list and the thread lock information corresponding to the created thread in the second node linked list are cleared.

[0030] Optionally, based on the first node linked list and the second node linked list, judging whether the target thread is deadlocked according to a deadlock judgment logic includes:

[0031] Determine the thread lock applied for by the target thread by searching the first node linked list and the second node linked list as the first thread lock;

[0032] Determine a thread that currently occupies the first thread lock as a first thread;

[0033] Determine the thread lock applied for by the first thread as the second thread lock;

[0034] Determine a thread that currently occupies the second thread lock as the second thread;

[0035] Determine the thread lock applied for by the second thread as the third thread lock;

[0036] If the first thread lock is the third thread lock, and the first thread and the second thread are not the same thread, it is determined that the target thread is deadlocked; otherwise, no deadlock occurs.

[0037] Optionally, after determining that the target thread is deadlocked, the method further includes:

[0038] A deadlock hint is generated for the target thread.

[0039] Optionally, after determining whether the target thread successfully applies for the thread lock within a preset time period, the method further includes:

[0040] If the target thread successfully applies for the thread lock within the preset time, the state of the target thread is updated to the thread lock occupied state;

[0041] The second node linked list is updated according to the thread lock occupancy state.

[0042] Optionally, determining whether the target thread successfully applies for a thread lock within a preset time period includes:

[0043] The non-blocking timeout return interface is called through the second encapsulation interface, the target thread applies for a thread lock through the non-blocking timeout return interface, and an error response is fed back if the thread lock is not successfully applied for within a preset time period;

[0044] It is determined whether the target thread successfully applies for a thread lock within a preset time period according to the error response.

[0045] In a second aspect, the present application discloses a computer program product, including a computer program, which implements the aforementioned real-time deadlock detection method when executed by a processor.

[0046] In a third aspect, the present application discloses an electronic device, comprising:

[0047] Memory, used to store computer programs;

[0048] The processor is used to execute the computer program to implement the aforementioned deadlock real-time detection method.

[0049] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned real-time deadlock detection method when executed by a processor.

[0050] In the present application, when a thread needs to be created, a pre-created first encapsulation interface is called, and the relevant information of the thread creation is recorded through the first encapsulation interface to obtain thread information, the thread information is stored in a first node linked list for counting thread information, and the thread creation function in the dynamic library is called through the first encapsulation interface; when the target thread needs to apply for a thread lock, a pre-encapsulated second encapsulation interface is called, and the relevant information of the thread lock application is recorded through the second encapsulation interface to obtain thread lock information, the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread has successfully applied for the thread lock within a preset time length; if the thread lock is not applied for, based on the first node linked list and the second node linked list, it is determined whether the target thread is deadlocked according to the deadlock judgment logic.

[0051] It can be seen that by pre-creating the first encapsulation interface, the application program first calls the first encapsulation interface when it needs to create a thread, so as to record the thread information through the first encapsulation interface, and then call the actual thread creation function; by pre-creating the second encapsulation interface, the thread first calls the second encapsulation interface when it needs to apply for a thread lock, so as to record the thread lock information through the second encapsulation interface, and then call the actual thread lock application function; when the target thread fails to successfully apply for the thread lock within the preset time, it indicates that a deadlock may occur. At this time, based on the thread information counted in the first node linked list and the thread lock information counted in the second node linked list, a deadlock analysis can be performed according to the deadlock judgment logic; efficient real-time detection of deadlock can be achieved, and the entire process does not require modification of the kernel, and has strong scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0053] Figure 1 A flow chart of a real-time deadlock detection method provided by this application;

[0054] Figure 2 A specific deadlock real-time detection method flow chart provided in this application;

[0055] Figure 3 A specific deadlock real-time detection method flow chart provided in this application;

[0056] Figure 4 A specific deadlock real-time detection method flow chart provided in this application;

[0057] Figure 5 A structural diagram of an electronic device provided for this application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0059] In the related art, the deadlock phenomenon is detected by modifying the kernel code logic and adding additional detection threads, but this solution will increase the kernel burden, destroy the kernel stability, and its scalability is not strong. In order to overcome the above technical problems, this application proposes a real-time deadlock detection method that can achieve efficient real-time deadlock detection.

[0060] The embodiment of the present application discloses a real-time deadlock detection method. In different operating systems and programming environments, the implementation of mutex locks may be different, but the locking and unlocking operations are usually implemented based on the underlying hardware primitives; in addition to the standard mutex lock, there are some variants such as recursive locks (i.e., allowing the same thread to lock the lock multiple times), read-write locks (i.e., allowing multiple threads to read data at the same time, but only allowing one thread to write data), etc., all of which can be applied to the present application.

[0061] See also Figure 1 As shown, the deadlock real-time detection method may include the following steps:

[0062] Step S11: When a thread needs to be created, the pre-created first encapsulation interface is called, the relevant information of thread creation is recorded through the first encapsulation interface to obtain thread information, the thread information is stored in a first node linked list for counting thread information, and the thread creation function in the dynamic library is called through the first encapsulation interface.

[0063] In this embodiment, before calling the pre-created first encapsulation interface, it can also include: encapsulating the first encapsulation interface according to the interface name of the thread creation function interface, so that the first encapsulation interface can be called when the application needs to create a thread. That is, the first encapsulation interface is created in advance to record the relevant information of thread creation to obtain thread information. In order to obtain the relevant information when the thread is created, the application needs to call the above-mentioned first encapsulation interface when it needs to create a thread. Therefore, the first encapsulation interface is encapsulated according to the interface name of the thread creation function interface, and then the actual thread creation function interface is called by the first encapsulation interface, so that the relevant information is recorded through the first encapsulation interface when the thread is created through the thread creation function interface; and the upper layer is unaware of this process.

[0064] In this embodiment, before calling the pre-created first encapsulation interface when a thread needs to be created, it also includes: calling the pre-encapsulated third encapsulation interface when a dynamic library needs to be called, recording the relevant information of the function call operation performed by the application through the third encapsulation interface, and calling the dynamic library through the third encapsulation interface. Before calling the pre-encapsulated third encapsulation interface, the third encapsulation interface is encapsulated according to the interface name of the dynamic library interface, so that the third encapsulation interface is called when the application needs to call the dynamic library. It can be understood that in the application development process, the application creates threads and related lock resources by calling the function interface in the general dynamic library. In this application, through the third encapsulation interface pre-created according to the dynamic library interface, the application calls the pre-encapsulated interface when calling the general dynamic library interface, and records all relevant call information through the encapsulation interface.

[0065] Furthermore, before storing the thread information in the first node linked list for counting thread information, it may also include: using the first memory space to initialize a hash table based on an array and a linked list to obtain the first node linked list; using the second memory space to initialize a hash table based on an array and a linked list to obtain the second node linked list; that is, generating the first node linked list and the second node linked list by applying for statistical node resources to store thread information and thread lock information. Specifically, during the application startup process, it is necessary to pre-link and load a dynamic library, apply for statistical node resources (i.e., memory resources) during the initialization process of dynamic library loading, and then initialize this memory into a node form of a hash array plus a linked list. Correspondingly, storing the thread information in the first node linked list for counting thread information may include: obtaining an idle node from the first node linked list, and using the idle node to store the thread information; storing the thread lock information in the second node linked list for counting lock information includes: obtaining an idle node from the second node linked list, and using the idle node to store the thread lock information.

[0066] The thread information includes: thread attributes, creation time, thread function address, thread function parameter address, process ID, thread ID, thread stack address and stack size. In some embodiments, recording the relevant information of thread creation through the first encapsulation interface to obtain thread information may include: obtaining the incoming parameters of thread creation through the first encapsulation interface; the incoming parameters include thread attributes, creation time, thread function address, thread function parameter address; obtaining the creation information generated by thread creation through the first encapsulation interface; the creation information includes process ID, thread ID, thread stack address and stack size; and obtaining the thread information based on the incoming parameters and the creation information. It can be understood that when an application applies to create a thread, it will include certain parameters, such as thread attributes, creation time, thread function address, thread function parameter address, etc.; after the thread is created, some parameters will be generated, such as process ID, thread ID, thread stack address and stack size, etc.; that is, by obtaining thread-related information at the two times of thread creation request and thread creation, complete thread information can be obtained.

[0067] That is, for example Figure 2 As shown, when creating a thread (pthread_create), first call the first encapsulation interface to create a thread statistics node (create_info_node). Specifically, obtain the idle record node (entry_node) in the first node list, record the attributes (detach_state) and thread stack size (stack_size) of the thread to be created, and can also record the call stack information (backtrac) of the current thread, as well as the arg parameter in the PTREAD_HANDLED structure, the thread entry function (start_rtn) and other related information, and then call the thread creation function (libc_pthread_create) to execute the thread creation task. The thread function is the tool library encapsulation function pthread_handler_func. Among them, the implementation method of the function pthread_handler_func is to refresh the process ID (pid) and thread ID (tid) information in thread_info through the system method pthread_self, syscall (SYS_gettid), refresh the obtained stack address (stack_addr) and thread stack size according to the thread information, add the node to the hash list, and execute the thread entry function.

[0068] The nodes in the first node linked list are called thread statistics nodes, and the information recorded by the nodes includes but is not limited to: node, thread number, thread function, thread name, detach state (detach_state), stack size, caller address, occupied lock list, requested lock, and creation time.

[0069] It can be seen that in this application, by defining an encapsulation interface that is the same as the thread creation function interface declaration, an idle node is obtained in the first node linked list, the separation attribute and creation time of the thread creation are obtained and recorded, the parameters passed in for thread creation are recorded, and then the original thread creation function of the thread library is called (specifically, it can be found through the dlsym function), and the process ID, thread ID, thread stack address and stack size corresponding to the thread are recorded at the same time, and then the thread is executed.

[0070] Step S12: When the target thread needs to apply for a thread lock, the pre-created second encapsulation interface is called, and the relevant information of the thread lock application is recorded through the second encapsulation interface to obtain the thread lock information, and the thread lock information is stored in the second node linked list used to count the lock information, and it is determined whether the target thread successfully applies for the thread lock within a preset time length.

[0071] In this embodiment, a second encapsulation interface that is the same as the lock application function interface declaration is encapsulated in advance according to the interface name of the lock application function interface, so that when the application needs to apply for a thread lock, the second encapsulation interface is first called, and the second encapsulation interface records the relevant information of the thread lock application to obtain thread lock information, and the thread lock information is stored in a second node linked list for counting lock information. The nodes in the second node linked list are called lock statistics nodes, and the actual lock application function is called through the second encapsulation interface, and it is determined whether the target thread successfully applies for the thread lock within a preset time length.

[0072] In some embodiments, obtaining thread lock information by recording relevant information of thread lock application through the second encapsulation interface may include: obtaining target thread information corresponding to the target thread from the first node linked list according to the thread identifier of the target thread; updating the state of the target thread to the thread lock request state and updating the number of requests; generating target thread lock information based on the thread lock request state and the number of requests, and establishing a mapping relationship between the target thread information and the target thread lock information. That is, first find the thread statistics node where the relevant target thread information is located according to the thread PID, then obtain the idle node in the second node linked list, associate it with the above-mentioned thread statistics node, update the state of the target thread to the request state through the obtained idle node, and add one to the original number of requests of the target thread.

[0073] In this embodiment, judging whether the target thread has successfully applied for the thread lock within the preset time length includes: calling the non-blocking timeout return interface through the second encapsulation interface, the target thread applies for the thread lock through the non-blocking timeout return interface, and feeding back an error response when the thread lock is not successfully applied for within the preset time length; judging whether the target thread has successfully applied for the thread lock within the preset time length according to the error response. In some embodiments, after judging whether the target thread has successfully applied for the thread lock within the preset time length, it may also include: if the target thread has successfully applied for the thread lock within the preset time length, updating the state of the target thread to the thread lock occupied state; and updating the second node linked list according to the thread lock occupied state.

[0074] For example Figure 3 As shown in the figure, by calling the non-blocking timeout return interface (pthread_mutex_timedlock) of the thread library lock application, the target thread applies for the thread lock through the non-blocking timeout return interface, and an error response can be returned when the lock is not applied within the preset time. If the thread lock is successfully acquired, the state of the lock statistics node and the associated thread statistics node is modified, and the request state is changed to the occupied state; if an error is returned within the agreed time, the deadlock monitoring mechanism is executed.

[0075] Specific, for example Figure 4As shown in the figure, when calling the thread lock (pthread_mutex_lock), first call the second encapsulation interface, obtain the current pid number according to the system method pthread_self, find the relevant thread statistics node in the first node list by the hash algorithm, and then call the record_lock_status library function to refresh the lock-related statistics node information in the second node list to the request state. The lock state is divided into the request state and the occupied state; then call the original function pthread_mutex_timedlock of the non-blocking lock resource application to execute the lock application; assuming that the longest waiting event is set to 20 seconds, if the thread lock is still not requested after 20 seconds, it is a timeout application failure, and call the monitoring tool function interface check_lock_dead_loop to check whether a deadlock has occurred. If successful, call the record_lock_status interface to refresh the lock statistics node information to the occupied state. In the record_lock_status interface, first call the internal interface get_lock_record_node to obtain the lock information statistics node lock_info. Its implementation logic is to quickly find out whether there is the statistics node information of the lock in the table through the hash algorithm. If not, select an idle node to record this lock information and add it to the hash list. When the lock state is requested, the lock's statistical node is recorded in the current thread's statistical node field request_lock, and the request_node field in the lock's statistical node is mounted to the global list inRequestList, and the request_nums field is increased by one; when the lock state is occupied, the lock's statistical node field occupy_node is mounted to the current thread's statistical node occupied lock linked list occupy_list, and the current thread's statistical node address is filled into the owner_pth field of the lock statistical node, and finally the other extended information fields of the lock statistical node information are refreshed.

[0076] In this embodiment, when the created thread ends, the thread information corresponding to the created thread in the first node linked list and the thread lock information corresponding to the created thread in the second node linked list are cleared. That is, deadlock only occurs in the executing thread. For the executed thread, the corresponding information of the thread in the first node linked list and the second node linked list can be cleared to recycle the node resources.

[0077] Step S13: If the thread lock is not applied for, then based on the first node linked list and the second node linked list, determine whether the target thread is deadlocked according to the deadlock determination logic.

[0078] It is understandable that if the thread lock is not successfully applied for, it may be that you still need to wait, or a deadlock may have occurred, so further testing is needed to eliminate the deadlock.

[0079] The above-mentioned method of determining whether the target thread is deadlocked based on the first node linked list and the second node linked list according to the deadlock judgment logic may specifically include: determining the thread lock applied for by the target thread as the first thread lock by searching the first node linked list and the second node linked list; determining the thread currently occupying the first thread lock as the first thread; determining the thread lock applied for by the first thread as the second thread lock; determining the thread currently occupying the second thread lock as the second thread; determining the thread lock applied for by the second thread as the third thread lock; if the first thread lock is the third thread lock, and the first thread and the second thread are not the same thread, then determining that the target thread is deadlocked, otherwise, no deadlock occurs. That is, the above-mentioned deadlock detection mechanism searches for the relevant lock statistics node in the first node linked list according to the lock address, records the thread lock applied for by the target thread as LOCK1, obtains the thread occupying LOCK1 according to the information of the lock statistics node, records it as TREAD1; obtains the lock being requested by TREAD1, records it as LOCK2; if LOCK2 exists and is not equal to LOCK1, obtains the occupying thread of LOCK2, records it as TREAD2; obtains the lock being applied for by the TREAD2 thread, records it as LOCK3. When LOCK3 is equal to LOCK1, and THREAD1 and THREAD2 are not the same thread, a deadlock occurs.

[0080] Specific, for example Figure 4 The deadlock detection mechanism (check_lock_dead_loop) shown in the figure searches for the current lock statistics node through the interface get_lock_record_node to obtain LOCK1 (the first thread lock), obtains the owner_pth field of LOCK1 to obtain PHREAD1 (the first thread); obtains LOCK2 according to the request_lock field of PHTREAD1, and when it is determined that LOCK2 exists and is not equal to LOCK1, the owner_pth field of LOCK2 is recorded as PHREAD2, and the request_lock field of PHREAD2 is recorded as LOCK3; when LOCK3 is equal to LOCK1, a deadlock occurs.

[0081] In some embodiments, after determining that the target thread is deadlocked, the process may further include: generating a deadlock prompt for the target thread, and specifically printing related thread and lock information to help developers locate the problem.

[0082] In this application, the real-time monitoring method of mutual exclusion deadlock during multi-threaded concurrency based on dynamic libraries is completely based on the application level, without modifying the target application logic or kernel code, and can detect deadlocks in real time and print deadlock-related thread information. It is linked to the target program in the form of a dynamic library, and only the target code dynamic library link compilation item needs to be modified, without modifying the code logic of the target program. The mutual exclusion deadlock of the target program can be monitored in real time, and the root cause of the deadlock can be quickly located. The implementation process is simple and efficient, with good scalability and little impact on the performance of the target process. Linking to the target program can help check whether there is a deadlock in the program running in various scenarios, and avoid serious code vulnerabilities.

[0083] As can be seen from the above, in this embodiment, when a thread needs to be created, a pre-created first encapsulation interface is called, and relevant information of thread creation is recorded through the first encapsulation interface to obtain thread information, and the thread information is stored in a first node linked list for counting thread information, and a thread creation function in a dynamic library is called through the first encapsulation interface; when a target thread needs to apply for a thread lock, a pre-encapsulated second encapsulation interface is called, and relevant information of the thread lock application is recorded through the second encapsulation interface to obtain thread lock information, and the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread has successfully applied for the thread lock within a preset time length; if the thread lock is not applied for, based on the first node linked list and the second node linked list, it is determined whether the target thread is deadlocked according to the deadlock judgment logic. It can be seen that by pre-creating the first encapsulation interface, the application program first calls the first encapsulation interface when it needs to create a thread, so as to record the thread information through the first encapsulation interface, and then call the actual thread creation function; by pre-creating the second encapsulation interface, the thread first calls the second encapsulation interface when it needs to apply for a thread lock, so as to record the thread lock information through the second encapsulation interface, and then call the actual thread lock application function; when the target thread fails to successfully apply for the thread lock within the preset time, it indicates that a deadlock may occur. At this time, based on the thread information counted in the first node linked list and the thread lock information counted in the second node linked list, a deadlock analysis can be performed according to the deadlock judgment logic; efficient real-time detection of deadlock can be achieved, and the entire process does not require modification of the kernel, and has strong scalability.

[0084] Correspondingly, the embodiment of the present application further discloses a deadlock real-time detection device, which includes:

[0085] A thread information recording module, used for calling a pre-created first encapsulation interface when a thread needs to be created, recording relevant information of thread creation through the first encapsulation interface to obtain thread information, storing the thread information in a first node linked list for counting thread information, and calling a thread creation function in a dynamic library through the first encapsulation interface;

[0086] A thread lock information recording module is used to call a pre-created second encapsulation interface when a target thread needs to apply for a thread lock, obtain thread lock information by recording relevant information of the thread lock application through the second encapsulation interface, store the thread lock information in a second node linked list for counting lock information, and determine whether the target thread successfully applies for the thread lock within a preset time length;

[0087] The deadlock judgment module is used to judge whether the target thread is deadlocked according to the deadlock judgment logic based on the first node linked list and the second node linked list if the thread lock is not applied for.

[0088] As can be seen from the above, in this embodiment, when a thread needs to be created, a pre-created first encapsulation interface is called, and relevant information of thread creation is recorded through the first encapsulation interface to obtain thread information, and the thread information is stored in a first node linked list for counting thread information, and a thread creation function in a dynamic library is called through the first encapsulation interface; when a target thread needs to apply for a thread lock, a pre-encapsulated second encapsulation interface is called, and relevant information of the thread lock application is recorded through the second encapsulation interface to obtain thread lock information, and the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread has successfully applied for the thread lock within a preset time length; if the thread lock is not applied for, based on the first node linked list and the second node linked list, it is determined whether the target thread is deadlocked according to the deadlock judgment logic. It can be seen that by pre-creating the first encapsulation interface, the application program first calls the first encapsulation interface when it needs to create a thread, so as to record the thread information through the first encapsulation interface, and then call the actual thread creation function; by pre-creating the second encapsulation interface, the thread first calls the second encapsulation interface when it needs to apply for a thread lock, so as to record the thread lock information through the second encapsulation interface, and then call the actual thread lock application function; when the target thread fails to successfully apply for the thread lock within the preset time, it indicates that a deadlock may occur. At this time, based on the thread information counted in the first node linked list and the thread lock information counted in the second node linked list, a deadlock analysis can be performed according to the deadlock judgment logic; efficient real-time detection of deadlock can be achieved, and the entire process does not require modification of the kernel, and has strong scalability.

[0089] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0090] A first encapsulation interface creation unit is used to encapsulate the first encapsulation interface according to the interface name of the thread creation function interface before calling the pre-created first encapsulation interface, so that the first encapsulation interface can be called when the application needs to create a thread;

[0091] The second encapsulation interface creation unit is used to encapsulate the second encapsulation interface according to the interface name of the lock application function interface, so that the second encapsulation interface can be called when the application needs to apply for a thread lock.

[0092] In some specific embodiments, the thread information includes: thread attributes, creation time, thread function address, thread function parameter address, process ID, thread ID, thread stack address and stack size.

[0093] In some specific embodiments, the thread lock information recording module 12 may specifically include:

[0094] a target thread information determining unit, configured to obtain target thread information corresponding to the target thread from the first node linked list according to the thread identifier of the target thread;

[0095] An updating unit, used for updating the state of the target thread to a thread lock request state, and updating the number of requests;

[0096] The target thread lock information determining unit is used to generate the target thread lock information based on the thread lock request state and the request number, and establish a mapping relationship between the target thread information and the target thread lock information.

[0097] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0098] A function call recording unit is used to call a pre-encapsulated third encapsulation interface when a dynamic library needs to be called before calling a pre-created first encapsulation interface when a thread needs to be created, record relevant information of the function call operation executed by the application through the third encapsulation interface, and call the dynamic library through the third encapsulation interface.

[0099] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0100] The third encapsulation interface creation unit is used to encapsulate the third encapsulation interface according to the interface name of the dynamic library interface before calling the pre-encapsulated third encapsulation interface, so that the application program can call the third encapsulation interface when calling the dynamic library.

[0101] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0102] A first node linked list creation unit is used to obtain a hash table based on an array and a linked list by using a first memory space to initialize the hash table before storing the thread information in the first node linked list for counting thread information, so as to obtain the first node linked list;

[0103] A second node linked list creating unit, configured to obtain a hash table based on an array and a linked list by initializing the second memory space, and obtain the second node linked list;

[0104] The thread information recording module may specifically include:

[0105] A thread information storage unit, used to obtain an idle node from the first node linked list, and use the idle node to store the thread information;

[0106] The thread lock information recording module may specifically include:

[0107] The thread lock information unit is used to obtain an idle node from the second node linked list and use the idle node to store the thread lock information.

[0108] In some specific embodiments, the deadlock real-time detection device may further include:

[0109] The information clearing unit is used to clear the thread information corresponding to the created thread in the first node linked list and the thread lock information corresponding to the created thread in the second node linked list after the created thread ends.

[0110] In some specific embodiments, the deadlock determination module may specifically include:

[0111] A first thread lock determining unit, configured to determine the thread lock applied for by the target thread as the first thread lock by searching the first node linked list and the second node linked list;

[0112] A first thread determination unit, configured to determine a thread currently occupying the first thread lock as a first thread;

[0113] A second thread lock determining unit, configured to determine the thread lock applied for by the first thread as a second thread lock;

[0114] A second thread determination unit, configured to determine a thread currently occupying the second thread lock as a second thread;

[0115] A third thread lock determining unit, configured to determine the thread lock applied for by the second thread as a third thread lock;

[0116] The first thread lock determining unit is configured to determine that a deadlock occurs in the target thread if the first thread lock is the third thread lock and the first thread and the second thread are not the same thread, and otherwise, that no deadlock occurs.

[0117] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0118] The prompt unit is used to generate a deadlock prompt for the target thread after determining that the target thread is deadlocked.

[0119] In some specific embodiments, the real-time deadlock detection device may specifically include:

[0120] A state updating unit, configured to, after determining whether the target thread has successfully applied for the thread lock within a preset time period, update the state of the target thread to a thread lock occupied state if the target thread has successfully applied for the thread lock within the preset time period;

[0121] The second node linked list updating unit is used to update the second node linked list according to the thread lock occupancy state.

[0122] In some specific embodiments, the thread lock information recording module may specifically include:

[0123] A non-blocking timeout return interface calling unit, configured to call the non-blocking timeout return interface through the second encapsulation interface, wherein the target thread applies for a thread lock through the non-blocking timeout return interface, and feeds back an error response when the thread lock is not successfully applied for within a preset time period;

[0124] The lock application judgment is used to judge whether the target thread successfully applies for the thread lock within a preset time period according to the error response.

[0125] Furthermore, the present application also discloses an electronic device, see Figure 5 As shown, the contents in the drawings should not be considered as any limitation on the scope of use of the present application.

[0126] Figure 5 The present invention is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the real-time deadlock detection method disclosed in any of the aforementioned embodiments.

[0127] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0128] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon include an operating system 221, a computer program 222, and data 223 including thread information, etc. The storage method can be temporary storage or permanent storage.

[0129] The operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, so as to realize the operation and processing of the massive data 223 in the memory 22 by the processor 21, and it can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the real-time deadlock detection method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0130] Furthermore, an embodiment of the present application also discloses a computer storage medium, in which computer executable instructions are stored. When the computer executable instructions are loaded and executed by a processor, the steps of the real-time deadlock detection method disclosed in any of the aforementioned embodiments are implemented.

[0131] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0132] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0133] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0134] The above is a detailed introduction to a deadlock real-time detection method, device, equipment and storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for a person skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A real-time deadlock detection method, characterized in that: Applied to applications including: When a thread needs to be created, a pre-created first encapsulation interface is called, relevant information about thread creation is recorded through the first encapsulation interface to obtain thread information, the thread information is stored in a first node linked list for counting thread information, and a thread creation function in a dynamic library is called through the first encapsulation interface; When the target thread needs to apply for a thread lock, the pre-created second encapsulation interface is called, and the relevant information of the thread lock application is recorded through the second encapsulation interface to obtain thread lock information, the thread lock information is stored in a second node linked list for counting lock information, and it is determined whether the target thread successfully applies for the thread lock within a preset time period; If the thread lock is not applied for, determining whether the target thread is deadlocked according to the deadlock determination logic based on the first node linked list and the second node linked list; Based on the first node linked list and the second node linked list, judging whether the target thread is deadlocked according to a deadlock judgment logic includes: Determine the thread lock applied for by the target thread by searching the first node linked list and the second node linked list as the first thread lock; Determine the thread currently occupying the first thread lock as the first thread; determine the thread lock applied for by the first thread as the second thread lock; determine the thread currently occupying the second thread lock as the second thread; determine the thread lock applied for by the second thread as the third thread lock; If the first thread lock is the third thread lock, and the first thread and the second thread are not the same thread, it is determined that the target thread is deadlocked; otherwise, no deadlock occurs.

2. The real-time deadlock detection method according to claim 1, characterized in that: Before calling the pre-created first encapsulation interface, it also includes: encapsulate the first encapsulation interface according to the interface name of the thread creation function interface, so that the first encapsulation interface is called when the application needs to create a thread; The second encapsulation interface is encapsulated according to the interface name of the lock application function interface, so that the second encapsulation interface is called when the application needs to apply for a thread lock.

3. The real-time deadlock detection method according to claim 1, characterized in that: The thread information includes: thread attributes, creation time, thread function address, thread function parameter address, process ID, thread ID, thread stack address and stack size.

4. The real-time deadlock detection method according to claim 1, characterized in that: The thread lock information is obtained by recording the relevant information of the thread lock application through the second encapsulation interface, including: According to the thread identifier of the target thread, acquiring target thread information corresponding to the target thread from the first node linked list; Update the state of the target thread to a thread lock request state, and update the number of requests; Target thread lock information is generated based on the thread lock request state and the number of requests, and a mapping relationship is established between the target thread information and the target thread lock information.

5. The real-time deadlock detection method according to claim 1, characterized in that: Before calling the pre-created first encapsulation interface when a thread needs to be created, it also includes: When the dynamic library needs to be called, the pre-packaged third encapsulation interface is called, the relevant information of the function call operation executed by the application is recorded through the third encapsulation interface, and the dynamic library is called through the third encapsulation interface.

6. The real-time deadlock detection method according to claim 5, characterized in that: Before calling the pre-packaged third package interface, it also includes: The third encapsulation interface is encapsulated according to the interface name of the dynamic library interface, so that the third encapsulation interface is called when the application needs to call the dynamic library.

7. The real-time deadlock detection method according to claim 1, characterized in that: Before storing the thread information into the first node linked list for counting thread information, the method further includes: Initialize a hash table based on an array and a linked list using the first memory space to obtain the first node linked list; Initialize a hash table based on an array and a linked list using the second memory space to obtain the second node linked list; Storing the thread information in a first node linked list for counting thread information includes: Acquire an idle node from the first node linked list, and use the idle node to store the thread information; Storing the thread lock information in a second node linked list for counting lock information includes: Obtain an idle node from the second node linked list, and use the idle node to store the thread lock information.

8. The real-time deadlock detection method according to claim 1, characterized in that: Also includes: When the created thread ends, the thread information corresponding to the created thread in the first node linked list and the thread lock information corresponding to the created thread in the second node linked list are cleared.

9. The real-time deadlock detection method according to claim 1, characterized in that: After determining that the target thread is deadlocked, the method further includes: A deadlock hint is generated for the target thread.

10. The real-time deadlock detection method according to claim 1, characterized in that: After determining whether the target thread successfully applies for the thread lock within the preset time, the method further includes: If the target thread successfully applies for the thread lock within the preset time, the state of the target thread is updated to the thread lock occupied state; The second node linked list is updated according to the thread lock occupancy state.

11. The real-time deadlock detection method according to any one of claims 1 to 10, characterized in that: Determining whether the target thread successfully applies for a thread lock within a preset time period includes: The non-blocking timeout return interface is called through the second encapsulation interface, the target thread applies for a thread lock through the non-blocking timeout return interface, and an error response is fed back if the thread lock is not successfully applied for within a preset time period; It is determined whether the target thread successfully applies for a thread lock within a preset time period according to the error response.

12. A computer program product, characterized in that It comprises a computer program, which, when executed by a processor, implements the real-time deadlock detection method according to any one of claims 1 to 11.

13. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the real-time deadlock detection method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: Used to store computer programs; wherein when the computer programs are executed by a processor, the real-time deadlock detection method according to any one of claims 1 to 11 is implemented.

Images