Deadlock detection method and computer equipment

Abstract

The invention provides a deadlock detection method and computer equipment, can be applied to the technical field of computers, and comprises the steps that a standard HB relation and n lock holding event pairs are determined according to an event log during software operation, hypothetical point events corresponding to the n lock holding event pairs are determined, each lock holding event pair comprises a first event and a second event, and the first event and the second event are corresponding to each other; the first event is to hold a first mutual exclusion lock, the second event is to acquire a second mutual exclusion lock, the hypothetical point event is a previous event of a thread where each first event is located, and finally determining a deadlock sequence based on the standard HB relationship, the n lock holding event pairs and the n hypothetical point events. A hypothetical point event is added before all first events, it is considered that subsequent lock release operation can follow the hypothetical point event, if the hypothetical point event does not have an HB relation with another lock holding event pair in an OV ring, it can be considered that the OV ring can actually occur, and therefore a deadlock prediction mechanism without false alarm and with low missing report is achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a deadlock detection method and computer equipment. Background Art

[0002] Concurrency issues have always been a significant factor impacting software quality. They can cause serious program errors, directly impacting user experience and even product correctness. However, concurrency issues are characterized by low probability, difficulty in triggering, difficulty in locating, and a high likelihood of slipping into production environments. Among these concurrency issues, deadlock is the most common and directly impacts software quality. Deadlock occurs when a series of threads are in a state where each thread holds some mutexes and blocks waiting to acquire others, resulting in a circular wait that blocks all threads. Deadlock blocks applications and prevents them from continuing, often leading to serious errors.

[0003] There are multiple technical approaches to addressing deadlock, including deadlock prediction, deadlock detection, and deadlock prevention. Deadlock prediction uses static or dynamic methods to detect deadlocks before they occur. Deadlock detection detects deadlocks promptly after they occur and implements countermeasures to resolve them. Deadlock prevention records resource status and resource acquisition information to predict the likelihood of deadlock during resource acquisition and prevent resource acquisition if a deadlock is likely. Most existing solutions focus on deadlock prediction. Deadlock prediction has three important metrics: false positive rate (i.e., a deadlock is reported as such when it is not), false negative rate (i.e., a deadlock is not detected), and the time complexity of deadlock prediction. These three metrics directly impact the application suitability of deadlock prediction technology. A high false positive rate requires significant human effort to troubleshoot false alarms, while a false negative rate directly impacts the effectiveness of deadlock prediction mechanisms in detecting deadlocks. Furthermore, the complexity of deadlock prediction limits its applicable scenarios.

[0004] Based on the prediction principle, deadlock prediction can be divided into static deadlock prediction (i.e., static analysis based on program source code), dynamic deadlock prediction (i.e., determining whether a deadlock exists at runtime based on the recorded lock acquisition order), and deadlock prediction using both dynamic information and static analysis techniques. Static deadlock prediction often provides a more thorough analysis of control flow but suffers from a high level of missed detections. Dynamic deadlock detection generally only considers violations of the lock acquisition order, referred to as Order Violation (OV). However, in real-world applications, OV is too large and the analysis time is long, resulting in a high false positive rate, such as the Lockdep deadlock prediction mechanism. A combination of dynamic and static methods generally uses dynamically acquired runtime records (logs) combined with static analysis to attempt to avoid false positives and reduce missed detections. However, such deadlock prediction mechanisms often have a high time complexity (e.g., the square of the number of threads), making them difficult to directly apply to existing large-scale software. In addition, the standard Happen Before (HB) relationship cannot be directly used for deadlock detection. This is because the standard HB relationship records the HB relationship between lock acquisition and release operations. Therefore, the order of all lock operations is determined at runtime and cannot be used for deadlock detection. Summary of the Invention

[0005] The present application provides a deadlock detection method and computer device for finding a deadlock sequence (also called a hypothesis point mechanism) based on the proposed various hypothesis point events and the standard HB relationship. The hypothesis point mechanism adds a hypothesis point event before the first event in all pairs of lock holding events (that is, before all OV events), and assumes that the subsequent lock release operation can occur immediately after the hypothesis point event. If the hypothesis point event has no HB relationship with another pair of lock holding events in the OV loop, it can be assumed that the OV loop can actually occur. Based on this, all real deadlock sequences can be found, thereby realizing a deadlock prediction mechanism with no false positives and low missed positives.

[0006] Based on this, the embodiments of the present application provide the following technical solutions:

[0007] In the first aspect, the present application first provides a deadlock detection method, which specifically includes: first, obtaining a lock-related event log (Log) when the software is running, and determining a standard HB relationship based on it, wherein the event log is used to record various events that occur in chronological order, that is, all locking operations and unlocking operations are recorded in the chronological order of occurrence, and each operation corresponds to an event, and the standard HB relationship is used to reflect the HB relationship between the various events; in addition, after obtaining the event log during software runtime, n (n≥2) lock event pairs are determined based on the event log, wherein each lock event pair includes two events, respectively referred to as a first event and a second event, the first event is holding a certain mutex lock (which can be called a first mutex lock), and the second event is acquiring another mutex lock (which can be called a second mutex lock), and the lock event pair is used to characterize: the first mutex lock is already held and the second mutex lock needs to be acquired. After obtaining n lock event pairs, we can determine the corresponding hypothetical point events for each of the n lock event pairs, thereby obtaining n hypothetical point events (also referred to as hypothetical points). Each hypothetical point event is the previous event of the thread in which each first event occurs. Finally, based on the standard HB relation obtained above, the n lock event pairs, and the n hypothetical point events, we determine the deadlock sequence.

[0008] In the above-mentioned embodiment of the present application, a deadlock sequence (also called a hypothetical point mechanism) is found by assuming a point event and a standard HB relationship. The hypothetical point mechanism adds a hypothetical point event before the first event in all pairs of lock events, assuming that the subsequent release operation can occur immediately after the hypothetical point event. If the hypothetical point event has no HB relationship with another pair of lock events in the OV loop, it can be assumed that the OV loop can actually occur, and all real deadlock sequences can be found accordingly. The present application can predict the existence of deadlocks before they occur, thereby effectively improving code quality, reducing deadlock problem troubleshooting time, and improving deadlock problem troubleshooting efficiency.

[0009] In one possible implementation of the first aspect, based on the aforementioned standard HB relationship, n lock event pairs, and n hypothetical point events, a specific implementation method for determining a deadlock sequence may be as follows: first, read the first lock event pair from the n lock event pairs, and determine a second lock event pair from the n lock event pairs based on a preset condition, wherein the mutex to be acquired by the first lock event pair is the mutex already held by the second lock event pair. Then, using the second lock event pair as the new first lock event pair, the above steps are repeated until p lock event pairs are determined, such that the mutexes involved in the p lock event pairs form an OV loop, and the mutexes involved in the p lock event pairs form a deadlock sequence, where p ≥ 2.

[0010] In the above-mentioned embodiment of the present application, the conditions that need to be met for determining the deadlock sequence are specifically described. Based on these conditions, the OV loops that actually constitute the deadlock sequence are screened out, thus avoiding traversal, saving time, and improving the efficiency of deadlock detection.

[0011] In a possible implementation of the first aspect, an implementation method for determining n lock event pairs based on an event log may be: first, directly determine m initial lock event pairs based on the event log, and determine q (q ≥ 1) OV sets based on the event log, the OV sets can be simply referred to as OV sets or OV families, wherein each OV set includes at least two mutexes; finally, based on the q OV sets, determine n lock event pairs from the m initial lock event pairs, so that each of the n lock event pairs satisfies: the first mutex and the second mutex involved are both from the same OV set. In this way, once a lock holder in an OV set attempts to acquire another lock in the OV set, it will be considered as an event in the OV loop that may cause a deadlock.

[0012] In the above implementation of this application, since the OV scale is too large in real applications, the deadlock prediction analysis time is long, resulting in a high false positive rate. Therefore, the lock event pairs are screened in advance through the constructed OV set, saving subsequent deadlock detection process and time.

[0013] In a possible implementation of the first aspect, an implementation method for determining q OV sets based on an event log may be: first, simplifying the event log to obtain each third event and a simplified lock relationship graph that has an association relationship with the third event, for example, where the third event is a lock acquisition operation; then, determining q strongly connected subgraphs based on the lock relationship graph, and the mutually exclusive locks included in each strongly connected subgraph constitute an OV set.

[0014] In the above-mentioned embodiment of the present application, the OV set is obtained by constructing a simplified lock relationship graph, thereby simplifying the subsequent deadlock detection steps.

[0015] In a possible implementation of the first aspect, determining a standard HB relationship based on an event log during software runtime may include: upon determining that the current target event is of the target event type, updating the first local clock tree corresponding to the target event on the target thread to a second local clock tree by merging the first local clock tree with the variable clock tree recorded at the target variable to obtain the second local clock tree. That is, the second local clock tree = the first local clock tree + the variable clock tree, where "+" represents merging. Subsequently, the events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event is reached. Finally, a standard HB relationship is determined based on each second local clock tree.

[0016] In the above embodiment of the present application, a method of updating the local clock tree on the target thread where the target event is located when the target event is a target event type is specifically described. By merging the two clock trees, the accuracy is improved and the missed deadlock is avoided.

[0017] In a possible implementation manner of the first aspect, the target event type includes: a read operation, or an acquire lock operation.

[0018] In the above-mentioned embodiments of the present application, several typical types of target events are specifically described to provide flexibility.

[0019] In a possible implementation of the first aspect, the method may further include: when determining that the current target event is a write operation, updating the first variable clock tree recorded at the target variable to the first variable clock tree and the second variable clock tree, by copying the local clock tree corresponding to the target event on the target thread to the target variable to obtain the second variable clock tree. That is, the variable clock tree at the variable is increased from one to two, wherein the added second variable clock tree is copied from the local clock tree, and the first variable clock tree remains unchanged. Thereafter, the events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event is reached.

[0020] In the above embodiment of the present application, for conflicting write operations of two threads, a false HB relationship is no longer constructed. Instead, the clock trees of the two write operations are recorded simultaneously, so that the two trees can be merged in subsequent read operations, thereby improving accuracy and reducing deadlock omissions.

[0021] In a possible implementation of the first aspect, the method may further include: when determining that the current target event is a lock release operation, updating the first variable clock tree recorded at the target variable to a third variable clock tree, wherein the updating method is to merge the local clock tree corresponding to the target event on the target thread with the first variable clock tree to obtain the third variable clock tree. That is, the third variable clock tree = the first variable clock tree + the local clock tree. In this case, the target variable still records a single variable clock tree. The "+" represents merging. Thereafter, the events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event.

[0022] In the above-mentioned embodiment of the present application, it is specifically explained how the variable clock tree recorded at the variable should be updated when releasing the lock operation. The purpose is to correctly maintain the HB relationship of the previous write operation during the subsequent read operation / lock acquisition operation on the target variable, thereby reducing the time complexity.

[0023] A second aspect of the present application provides a computer device having the functionality to implement the method of the first aspect or any possible implementation of the first aspect. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functionality described above.

[0024] The third aspect of the present application provides a computer device, which may include a memory, a processor, and a bus system, wherein the memory is used to store a computer program (also referred to as a program, computer-readable instructions), and the processor is used to call the program stored in the memory to execute the method of the first aspect of the embodiment of the present application or any possible implementation method of the first aspect.

[0025] The fourth aspect of the present application provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer, the computer can execute the method of the above-mentioned first aspect or any possible implementation of the first aspect.

[0026] The fifth aspect of the present application provides a computer program or a computer program product containing instructions, which, when executed on a computer, enables the computer to execute the method of the first aspect or any possible implementation of the first aspect.

[0027] In a sixth aspect, the present application provides a chip comprising at least one processor and at least one interface circuit, the interface circuit being coupled to the processor, the at least one interface circuit being used to perform transceiver functions and to send instructions to the at least one processor, the at least one processor being used to run a computer program or instruction, which has the function of implementing the method of the first aspect or any possible implementation of the first aspect, the function being implemented by hardware, software, or a combination of hardware and software, the hardware or software including one or more modules corresponding to the above functions. In addition, the interface circuit is used to communicate with other modules outside the chip.

[0028] In some implementations of the present application, some of the one or more processors may implement some steps of the above method through dedicated hardware. For example, processing involving a neural network model may be implemented by a dedicated neural network processor or a graphics processor.

[0029] The method provided in the embodiment of the present application can be implemented by one chip or by multiple chips working together. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A schematic diagram of a simple lock diagram provided in an embodiment of the present application;

[0031] Figure 2 A flowchart of a deadlock detection method provided in an embodiment of the present application;

[0032] Figure 3 An example diagram of a vector clock detection mechanism provided in an embodiment of the present application;

[0033] Figure 4 A schematic diagram of a process for generating a standard HB relationship using the forest clock detection mechanism provided in an embodiment of the present application;

[0034] Figure 5 A flowchart of a thread-local clock tree update provided in an embodiment of the present application;

[0035] Figure 6 A schematic diagram of the OV clustering method provided in an embodiment of the present application;

[0036] Figure 7 A basic flow chart for finding all OV sets using the OV clustering method provided in an embodiment of the present application;

[0037] Figure 8 A schematic diagram of deadlock prediction using an assumption point to support a standard HB relationship provided in an embodiment of the present application;

[0038] Figure 9 A flowchart of generating a deadlock sequence based on a hypothetical point event and combining an OV set and a standard HB relationship according to an embodiment of the present application;

[0039] Figure 10 An example diagram of a deadlock detection method provided in an embodiment of the present application;

[0040] Figure 11 An example diagram of using HB relationship judgment provided in an embodiment of the present application;

[0041] Figure 12 A basic flow chart of the deadlock detection method provided in an embodiment of the present application;

[0042] Figure 13 A schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0043] Figure 14 Another structural diagram of the computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] An embodiment of the present application provides a deadlock detection method and a computer device for finding a deadlock sequence based on the proposed various hypothetical point events and the standard HB relationship. The specific implementation is: adding a hypothetical point event before the first event in all pairs of lock holding events (that is, before all OV events), and assuming that the subsequent lock release operation can occur immediately after the hypothetical point event. If the hypothetical point event has no HB relationship with another pair of lock holding events in the OV loop, it can be considered that the OV loop can actually occur. Based on this, all real deadlock sequences can be found, thereby realizing a deadlock prediction mechanism with no false positives and low missed positives.

[0045] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0046] The embodiments of this application involve knowledge related to mutual exclusion locks. In order to better understand the solutions of the embodiments of this application, the following first introduces the relevant terms and concepts that may be involved in the embodiments of this application. It should be understood that the interpretation of relevant terms and concepts may be limited by the specific circumstances of the embodiments of this application, but it does not mean that this application is limited to only such specific circumstances. The specific circumstances of different embodiments may also vary, which is not specifically limited here.

[0047] (1) Mutex

[0048] Mutex locks are a common synchronization primitive. They are used to provide mutually exclusive access guarantees in multi-threaded applications. When multiple threads need to modify shared data (such as the same entry in a database), they use a mutex lock to ensure that only one thread can modify the shared data at a time.

[0049] (2) Deadlock

[0050] A deadlock occurs when two or more threads, during execution, become blocked due to competition for resources or communication with each other. Without external intervention, neither thread can proceed. In the embodiments of this application, the resource blocking examined primarily comes from competing for a mutex lock. A typical deadlock occurs when one thread first acquires lock A, then lock B; another thread first acquires lock B, then lock A. When these two threads interleave, a circular wait occurs, leading to a deadlock.

[0051] (3)OV

[0052] If all threads strictly follow a predetermined lock order to acquire mutexes, deadlock will not occur. However, if different threads acquire mutexes in different orders, for example, thread 1 acquires lock A and then locks lock B, and thread 2 acquires lock B and then locks A, deadlock may occur. This situation is called OV.

[0053] In addition, if Figure 1 In the lock graph shown, for thread 1, holding lock A and acquiring lock B, this is reflected in the lock graph as an edge from lock A to lock B, with the arrow of this edge pointing from lock A to lock B. Similarly, for thread 2, holding lock B and acquiring lock A, this is reflected in the lock graph as an edge from lock B to lock A, with the arrow of this edge pointing from lock B to lock A. If the mutex locks involved and the corresponding arrowed edges form a closed loop, then the closed loop is an OV loop, as shown in Figure 1 shown.

[0054] (4) HB relationship

[0055] The HB relationship defines a partial order. When an HB relationship exists between events, it indicates that there is a definite order in which these two events occur. For events without an HB relationship, the order in which they occur is not strictly constrained. Specifically, an HB relationship exists between different events when:

[0056] ①PO program order: Every operation in a thread has a HB relationship with any subsequent operation in the thread.

[0057] ②Monitor-related order: Unlocking a lock has a HB relationship with the subsequent locking of the same lock.

[0058] ③ Volatile variable reading and writing: Writing to a volatile variable has a HB relationship with subsequent read operations on the variable.

[0059] ④ Transitivity: If A HB B, B HB C, then A HB C.

[0060] ⑤ Thread startup, termination, interruption, variable initialization and destruction all have HB relationships.

[0061] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0062] Please refer to the following for details: Figure 2 , Figure 2A flowchart of a deadlock detection method provided in an embodiment of the present application may include the following steps:

[0063] 201. Determine a standard HB relationship based on an event log during software runtime.

[0064] First, when the software is running, a lock-related event log is obtained and the standard HB relationship is determined based on it. The event log is used to record various events that occur in chronological order. That is, all locking and releasing operations are recorded in the chronological order of occurrence, and each operation corresponds to an event.

[0065] It should be noted that in the embodiments of the present application, the recording process of the event log is not the core content of the present application. Specifically, for user-state applications, all locking and unlocking operations in the existing Pthread library can be replaced with weak symbols in a manner similar to the preload library, and the event log is output. For kernel-state applications, it is necessary to replace the implementation of the lock to support the function of recording the corresponding event log for the locking and unlocking operations.

[0066] It should be noted that, in the embodiment of the present application, the standard HB relationship is used to reflect the HB relationship between the various events recorded in the event log. In the embodiment of the present application, the detection of the standard HB relationship includes but is not limited to the following methods:

[0067] A. Vector Clock Detection Mechanism

[0068] The vector clock detection mechanism is as follows: the local clock of each thread records the events that occur locally in the thread, and at each clock update, a full comparison is performed with the ticks of all threads recorded locally to determine the standard HB relationship. Figure 3 , Figure 3 This is an example diagram of the vector clock detection mechanism provided by an embodiment of the present application, in which events e1, e2, and e3 occur in sequence. Events e1 and e3 are located in thread t1, and event e2 is located in thread t2. Ce1-t1 represents the local vector clock recorded on thread t1 when event e1 occurs, Ce3-t1 represents the local vector clock recorded on thread t1 when event e3 occurs, and Ce2-t2 represents the local vector clock recorded on thread t2 when event e2 occurs. Figure 3As can be seen, event e3 in thread t1 and event e2 in thread t2 form a HB relationship. When using this vector clock detection mechanism, it is necessary to traverse Ce2-t2 stored in t2 and then compare the local clock of the corresponding thread to see if it is greater than the clock stored in t2. This determines whether Ce3-t1 stored in t1 needs to be updated. Since each event corresponds to a Cei-tj (i ≥ 1, j ≥ 1), the standard HB relationship for each event is finally determined based on each Cei-tj.

[0069] B. Forest Clock Detection Mechanism

[0070] The forest clock detection mechanism specifically records the local clocks of each relevant thread and the sources from which these threads' clocks are obtained. This allows the system to determine whether to traverse and check significantly earlier sources when passing clocks to other threads. Furthermore, for conflicting write operations between two threads, the clock trees for both write operations are recorded simultaneously. These two clock trees are then merged during subsequent read operations, improving accuracy and preventing missed deadlocks.

[0071] In some embodiments of the present application, the specific implementation of the detection mechanism can be as follows: Figure 4 As shown, Figure 4 A flowchart of generating a standard HB relationship using the forest clock detection mechanism provided in an embodiment of the present application may include the following steps:

[0072] Step 1: Initialize the thread-local clock tree and variable clock tree, and start from the first event.

[0073] First, initialize the local clock tree of each thread (local clock is 0) and the variable clock tree recorded at the variable, and traverse downward from the first event in the event log. In the embodiment of the present application, the thread currently being processed can be called the target thread, the current event is called the target event, the target thread is the thread where the target event is located, and the operation object of the target event is called the target variable.

[0074] Step 2: Perform different local clock tree update or variable clock tree update operations for different types of events. The specific update operation method is as follows:

[0075] 1) If the current target event is determined to be of the target event type (e.g., a read operation, a lock acquisition operation, etc.), the first local clock tree corresponding to the target event on the target thread is updated to a second local clock tree. This update is performed by merging the first local clock tree with the variable clock tree recorded at the target variable to obtain the second local clock tree. Specifically, the second local clock tree = the first local clock tree + the variable clock tree, where the "+" represents merging.

[0076] 2) If the current target event is determined to be a write operation, the first variable clock tree recorded at the target variable is updated to the first and second variable clock trees. This update is performed by copying the local clock tree corresponding to the target event on the target thread to the target variable to obtain the second variable clock tree. This means that the variable clock tree at the variable is changed from one to two, with the added second variable clock tree copied from the local clock tree, while the first variable clock tree remains unchanged.

[0077] 3) If the current target event is determined to be a lock release operation, the first variable clock tree recorded at the target variable is updated to a third variable clock tree. This update is performed by merging the local clock tree corresponding to the target event on the target thread with the first variable clock tree to obtain the third variable clock tree. That is, the third variable clock tree = the first variable clock tree + the local clock tree. At this point, the target variable still records a single variable clock tree. The "+" indicates merging.

[0078] Step ③: Determine whether the current target event is the last event. If so, execute step ⑤; if not, execute step ④.

[0079] Determine whether the target event currently being executed is the last event in the event log. If so, execute step 5; if not, execute step 4. This step essentially takes the events included in the event log as the target events in sequence and repeats the operation of step 2 above until the last event is reached.

[0080] Step 4: The local node clock of the current thread increases by 1 and moves to the next event.

[0081] Increment the local node clock of the current thread by 1, move to the next event, and then jump to step ②.

[0082] Step 5: End the detection of the standard HB relationship.

[0083] In the above step ②, if there are multiple target events of read operations or lock acquisition operations, multiple second local clock trees can be obtained. Finally, the standard HB relationship is determined based on the multiple obtained second local clock trees.

[0084] It should be noted that in the embodiment of the present application, when the thread local clock tree is updated, the variable clock tree of the variable it accesses needs to be updated to the thread local. If there are multiple clock trees, these clock trees need to be merged. As an example, the update method of the local clock tree of the target thread can be as follows: Figure 5 As shown, Figure 5 A flowchart of updating the local clock tree of a thread (e.g., thread A) provided in an embodiment of the present application may include the following steps:

[0085] Step 1: Get the local clock tree of the read variable, add all clock trees to the traversal queue, and take out the first one.

[0086] First, obtain the local clock tree of the read variable (there may be multiple at the same time), add all trees to the traversal queue, and take the first one from the queue.

[0087] Step 2: Get the root node of the current subtree, the thread corresponding to the root node, and the clock.

[0088] Afterwards, the root node of the current subtree is further obtained, and the thread and clock (eg, thread X) corresponding to the root node are obtained.

[0089] Step ③: Determine whether the thread's local thread clock is greater than the node clock. If so, execute step ⑥; if not, execute step ④.

[0090] Determine whether the local clock of the thread (i.e., thread A) is greater than the node clock. If so, execute step ⑥; if not, execute step ④.

[0091] Step 4: Update the thread-local clock for the node and place the node according to the clock source (parent node).

[0092] Afterwards, the thread (ie, thread A) updates the local clock of the node and places the node according to the clock source (parent node): that is, the node is placed under the parent node of the clock source.

[0093] Step 5: Add all subtrees of the node to the traversal queue and record the parent node information.

[0094] All subtrees of the node are added to the traversal queue and the parent node information is recorded. The recorded parent node information is mainly used to find the location to place the node in step ④.

[0095] Step 6: Determine whether there are any subtrees that have not been traversed in the traversal queue. If so, execute step 7; if not, execute step 8.

[0096] Next, further determine whether there are any subtrees that have not been traversed in the traversal queue. If so, execute step ⑦; if not, execute step ⑧.

[0097] Step 7: Take out a subtree.

[0098] Take out a subtree and jump to step ②.

[0099] Step 8: End the thread's local clock tree update.

[0100] End the local clock tree update of the thread (i.e., thread A).

[0101] 202. Determine n lock event pairs based on the event log, each lock event pair including a first event and a second event, the first event being the holding of the first mutex lock and the second event being the acquisition of the second mutex lock. The lock event pair is used to indicate that the first mutex lock is held and the second mutex lock needs to be acquired, where n≥2.

[0102] In addition, after obtaining the event log during software runtime, n lock event pairs can be determined based on the event log, where each lock event pair includes two events, referred to as the first event and the second event. The first event is holding a certain mutex (which can be called the first mutex), and the second event is acquiring another mutex (which can be called the second mutex). The lock event pair is used to represent: the first mutex is already held and the second mutex needs to be acquired.

[0103] As an example, a lock event pair can be written as<ei1,ei2> , where ei1 is the first event, ei2 is the second event, ei1.lock is the mutex lock held by the lock event, ei2.lock is the mutex lock that the lock event needs to acquire, and the lock event<ei1,ei2> This means that the mutex lock ei1.lock is already held and ei2.lock needs to be acquired.

[0104] It should be noted that, in real applications, the OV scale is too large, and the deadlock prediction analysis time is long, which will lead to a high false alarm rate. Therefore, the n lock event pairs described in this application can be determined from m initial lock event pairs (m≥n). Specifically, the determination method can be: first, directly determine the m initial lock event pairs based on the event log, and determine q (q≥1) OV sets based on the event log. The OV set can be referred to as an OV set or an OV family (hereinafter referred to as an OV set), where each OV set includes at least two mutexes; finally, based on the q OV sets, determine n lock event pairs from the m initial lock event pairs, so that each lock event pair in the n lock event pairs satisfies: the first mutex and the second mutex involved are both from the same OV set. In this way, once a lock in the OV set is held and attempts to obtain another lock in the OV set, it will be considered as an event in the OV loop that may cause a deadlock. Therefore, the OV set is used to filter lock event pairs, saving subsequent deadlock detection processes and time.

[0105] As an example, this application proposes an OV clustering method for identifying OV sets. Specifically, the event log is first simplified to obtain each third event and a simplified lock relationship graph associated with the third event, for example, where the third event is a lock acquisition operation. Then, q strongly connected subgraphs are determined based on the lock relationship graph, and the mutually exclusive locks included in each strongly connected subgraph constitute an OV set.

[0106] Figure 6 An example of OV clustering is shown. On the left is the trace of the collected event log, and on the right is the constructed lock relationship graph. As you can see, tracing all the loops in the graph requires traversing all possibilities, which is very time-consuming. In addition, there are multiple different paths to reach e and f, but these paths are unlikely to form loops, which also wastes time. Therefore, the OV clustering method will Figure 6 The strongly connected subgraph in is taken as an OV set, that is Figure 6 {L1, La, Lb, Lc, L2, Ld} is considered an OV set. Once a lock in the OV set attempts to acquire another lock, it is considered a lock-holding event pair in an OV loop. The standard HB relationship is then used to filter lock-holding event pairs that can form an OV loop. This method eliminates e and f (otherwise, all paths involving e and f would be traversed, and paths involving e and f would not form a loop at all), avoiding traversal and significantly simplifying the complexity of the lock relationship graph.

[0107] It should be noted that, in some embodiments of the present application, the lock relationship diagram may record the most recent locking operation and the relationship with the locking operation. Figure 6 The first line of the trace on the left is L1, La, unLa, and L2. UnLa represents a lock release operation on La, so the corresponding edge in the lock relationship graph is L1→L2. Another example is L1, La, Lb, unLa, unLb, and L2. UnLb represents a lock release operation on Lb, so the corresponding edge in the lock relationship graph is L1→L2. This application does not elaborate on this in detail.

[0108] For ease of understanding, Figure 7 The basic process of finding all OV sets through the OV clustering method is shown, which can include the following steps:

[0109] Step 1: Read the next event in the event log.

[0110] Step ②: Determine whether the current event is a lock release operation. If so, execute step ③; if not, execute step ④.

[0111] Step 3: Delete the lock from the lock stack and go to step 7.

[0112] Step 4: Determine whether it is a lock acquisition operation. If so, execute step 5; if not, execute step 7.

[0113] Step 5: Record an edge from the top lock to the event of the current lock holder.

[0114] Step 6: Push the lock into the lock holding stack.

[0115] Step 7: Determine whether it is an empty event (end of Log). If so, execute step 8; if not, execute step 1.

[0116] Step ⑧: Find the strongly connected subgraph in the lock graph.

[0117] Step 9: Output all OV sets.

[0118] The lock nodes in a strongly connected subgraph constitute an OV set, and all OV sets are output.

[0119] It should be noted that in the embodiment of the present application, there is no order of execution between step 201 and step 202. Step 201 can be executed first and then step 202, or step 202 can be executed first and then step 201. Step 201 and step 202 can also be executed at the same time. This application does not limit this.

[0120] 203. Determine the hypothetical point events corresponding to each of the n lock holding event pairs to obtain n hypothetical point events, where each hypothetical point event is the previous event of the thread where each first event is located.

[0121] After obtaining n lock holding event pairs, the corresponding hypothetical point events of each of the n lock holding event pairs can be determined, thereby obtaining n hypothetical point events, which can also be referred to as hypothetical points. Each hypothetical point event is the previous event of the thread where each first event is located.

[0122] In the embodiments of this application, the purpose of proposing a hypothetical point event is to overcome the limitation of the standard HB relationship that cannot detect deadlocks (because all lock release operations and subsequent lock operations are constrained by the standard HB relationship). By adding a hypothetical point before all OV events, it is assumed that subsequent lock operations can occur immediately after this hypothetical point. If this hypothetical point does not have an HB relationship with another pair of events in the OV loop, it can be assumed that the OV loop can actually occur.

[0123] As an example, Figure 8 Shows examples of using assumption points to support the standard HB relation to predict deadlocks. Figure 8In the example, e1 to e8 are used to represent events that occur in chronological order. Lock A and Lock B represent the operations of acquiring lock A and acquiring lock B, respectively. Unlock A and Unlock B represent the operations of releasing lock A and releasing lock B, respectively. In this example, e3 and e5 have a HB relationship, which makes it impossible to construct the simplest ABBA deadlock. This application will create a hypothetical point immediately before e5 (assuming it is event e4.5, which is actually the previous event of the subsequent locking operation (i.e., Lock B) in the thread where the locking operation is located (i.e., thread 2)). This hypothetical point 4.5 is after the preceding event of e5 and before e5. Therefore, in principle, the program should allow e5 to occur at e4.5. Therefore, when performing deadlock detection, there is no need to check the HB relationship between e3 and e5. Instead, the HB relationship between e3 and e4.5 should be checked. If these two events do not have an HB relationship, it is considered that e5 may occur before e3, thus causing a deadlock.

[0124] 204. Determine a deadlock sequence based on the standard HB relation, n lock event pairs, and n assumption point events.

[0125] Finally, based on the standard HB relationship obtained above, n lock event pairs, and n hypothetical point events, a specific implementation method for determining a deadlock sequence can be as follows: first, read the first lock event pair from the n lock event pairs, and determine the second lock event pair from these n lock event pairs based on a preset condition, wherein the mutex to be acquired by the first lock event pair is the mutex already held by the second lock event pair. Then, using the second lock event pair as the new first lock event pair, repeat the above steps until p lock event pairs are determined, such that the mutexes involved in the p lock event pairs form an OV loop, and the mutexes involved in the p lock event pairs form a deadlock sequence, where p ≥ 2.

[0126] It should be noted that, in the embodiment of the present application, the preset conditions include at least: 1) the second event in the second locking event pair has no HB relationship with the first hypothetical point event corresponding to the first locking event pair; 2) the second event in the second locking event pair has no program order (PO) relationship with the first event in the first locking event pair; 3) the second event in the first locking event pair has no HB relationship with the second hypothetical point event corresponding to the second locking event pair; 4) the second event in the first locking event pair has no PO relationship with the first event in the second locking event pair; 5) the second event in the first locking event pair has no HB relationship with the second event in the second locking event pair.

[0127] It should also be noted that in the embodiments of this application, the n lock event pairs may or may not be selected from the m initial lock event pairs, and this application does not limit this. For ease of explanation, the following example uses the case where n lock event pairs can be selected from the m initial lock event pairs, and no further details are given.

[0128] Further, to facilitate understanding of the process of step 204, a specific example is used as an example for explanation. Figure 9 and Figure 10 ,in, Figure 9 A flowchart of generating a deadlock sequence based on a hypothetical point event and combining an OV set and a standard HB relationship according to an embodiment of the present application is provided. Figure 10 The embodiment of this application provides Figure 9 An example diagram is shown, which may include the following steps:

[0129] Step 1: Read the current lock event in the Log<ei1,ei2> .

[0130] First, read the current lock event pair in the Log (i.e., the event log, which includes n lock event pairs).<ei1,ei2> , that is, the first lock event pair mentioned above. Among them, ei1 is the first event, ei2 is the second event, and ei1.lock is the lock event pair.<ei1,ei2> The mutex lock held, ei2.lock is the lock event<ei1,ei2> The mutex lock that needs to be acquired, the lock event<ei1,ei2> Indicates that the mutex lock ei1.lock is already held and ei2.lock needs to be acquired.

[0131] Step 2: Determine if the lock event is<ei1,ei2> Are all the mutexes involved in the OV set from the same OV set? If so, execute step ③; if not, execute step ④.

[0132] After that, further judge the lock event<ei1,ei2> Are the mutex locks involved (i.e., ei1.lock and ei2.lock) from the same OV set? If so, proceed to step ③; if not, proceed to step ④.

[0133] Step 3: Traverse all logs and find all lock event pairs d1, ..., dk as suspected deadlock sets, where d1 represents the current lock event pair.<ei1,ei2> , so that the following conditions are met:

[0134] 1) The mutexes involved in d1, ..., dk eventually form an OV loop. Figure 10The mutex locks a, b, and c involved in d1, d2, and d3 form an OV loop.

[0135] 2) For any lock event<ek1,ek2> and<e(k+1)1,e(k+1)2> , that is, the first lock event<ek1,ek2> (When i=k) and the second lock event pair<e(k+1)1,e(k+1)2> , ek2.lock=e(k+1)1.lock: that is, the mutex held by the next lock event pair (i.e., the second lock event pair) is the mutex that the current lock event pair (i.e., the first lock event pair) needs to acquire, for example Figure 10 The lock in b.

[0136] 3) For any lock event<ek1,ek2> , ek1.lock and ek2.lock both belong to the OV set: that is, the mutex locks involved in the lock event are all in the OV set.

[0137] 4) There is no HB relationship between ek2 and e(k+1)1-0.5 (i.e., the hypothetical point event): that is, the possibility of the occurrence is determined by the HB relationship between the hypothetical point event and the event. The specific method for determining the HB relationship is to check the local clock tree before the e(k+1) event occurs, and whether the clock of the thread where the ek2 event occurs is earlier than the clock where the ek2 event occurs. If it is earlier, it is considered that there is no HB relationship, otherwise there is an HB relationship. Figure 10 shown.

[0138] 5) ek2 has no PO relationship with e(k+1)1: that is, it is not a multiple lock event local to the program.

[0139] 6) e(k+1)2 and ek1-0.5 (i.e., the hypothetical point event) have no HB relationship: that is, to determine whether the other side has an HB relationship. The determination method is similar to the above and will not be repeated here. Figure 10 shown.

[0140] 7) e(k+1)2 has no PO relationship with ek1: that is, determine whether the other side has a PO relationship. The judgment method is similar to the above and will not be repeated here.

[0141] 8) ek2 and e(k+1)2 have no HB relationship: that is, to determine whether blocking and waiting in T1 is possible. For details, please refer to Figure 11 , Figure 11 An example diagram of the use of HB relationship judgment provided in the embodiment of the present application reflects whether blocking and waiting in T1 may occur by judging whether ek2 and e(k+1)2 have HB relationship, and thus it can be ruled out. Figure 11 This situation shown, Figure 11 T1 is thread 1 and T2 is thread 2.

[0142] Step 4: Determine whether it is the end of the log. If so, execute step 5; if not, jump to step 1.

[0143] Step 5: End deadlock detection.

[0144] End deadlock detection and obtain the corresponding deadlock sequence (if any).

[0145] In summary, the basic process of the deadlock detection method provided in the embodiment of the present application can be summarized as follows: Figure 12 As shown, Figure 12 This is a basic flow chart of the deadlock detection method provided in an embodiment of the present application. First, the event log (also called log or trace) generated by the software is collected. This event log is then used to construct a lock relationship graph and detect standard HB relationships in the program. For example, the lock relationship graph can be constructed based on OV clustering technology, and suspected OV loops can be identified by loop detection. The standard HB relationships in the program are then detected using the forest clock. Finally, the standard HB relationships are used to filter out OV loops that may actually cause deadlocks.

[0146] The embodiments of the present application can be used in all software that may cause deadlock, such as operating system kernel, system software, and normal user-mode applications. The embodiments of the present application are used to collect test run logs before the software is released, and analyze offline whether deadlock may occur. The embodiments of the present application can be integrated into the continuous integration (CI) gate of the project to detect whether the newly added code causes new deadlocks, and can also be used to detect whether there are still undiscovered deadlocks in the stock software. The specific application scenario is not limited in this application.

[0147] On the basis of the above corresponding embodiments, in order to better implement the above solutions of the embodiments of the present application, the following also provides related devices for implementing the above solutions. Figure 13 , Figure 13A structural diagram of a computer device provided in an embodiment of the present application, wherein the computer device 1300 may specifically include: a first determination module 1301, a second determination module 1302, a third determination module 1303, and a deadlock detection module 1304, wherein the first determination module 1301 is used to determine the HB relationship of a standard event according to an event log during software runtime, wherein the event log is used to record various events occurring in chronological order, and the standard HB relationship is used to reflect the HB relationship between the various events; the second determination module 1302 is used to determine n lock event pairs according to the event log. Each lock event pair includes a first event and a second event, the first event is holding the first mutex lock, and the second event is acquiring the second mutex lock, and the lock event pair is used to represent that the first mutex lock is already held and the second mutex lock needs to be acquired, n ≥ 2; the third determination module 1303 is used to determine the hypothetical point events corresponding to each of the n lock event pairs, and obtain n hypothetical point events, each hypothetical point event is the previous event of each thread where the first event is located; the deadlock detection module 1304 is used to determine the deadlock sequence based on the standard HB relationship, the n lock event pairs, and the n hypothetical point events.

[0148] In one possible design, the deadlock detection module 1304 is specifically used to: read the first locking event pair among the n locking event pairs; determine the second locking event pair from the n locking event pairs according to preset conditions, and the mutex lock that the first locking event pair needs to acquire is the mutex lock already held by the second locking event pair; use the second locking event pair as the new first locking event pair, and repeat the above steps until p locking event pairs are determined, so that the mutex locks involved in the p locking event pairs constitute an OV loop, and the mutex locks involved in the p locking event pairs constitute a deadlock sequence, p≥2.

[0149] The preset conditions include: the second event in the second locking event pair has no HB relationship with the first assumption point event corresponding to the first locking event pair; the second event in the second locking event pair has no program order PO relationship with the first event in the first locking event pair; the second event in the first locking event pair has no HB relationship with the second assumption point event corresponding to the second locking event pair; the second event in the first locking event pair has no PO relationship with the first event in the second locking event pair; the second event in the first locking event pair has no HB relationship with the second event in the second locking event pair.

[0150] In one possible design, the second determination module 1302 is specifically used to: determine m initial lock event pairs based on the event log, m≥n; determine q OV sets based on the event log, each OV set includes at least two mutexes, q≥1; based on the q OV sets, determine n lock event pairs from the m initial lock event pairs, and the first mutex and the second mutex involved in each lock event pair are from the same OV set.

[0151] In one possible design, the second determination module 1302 is further specifically used to: simplify the event log to obtain each third event and a lock relationship graph associated with the third event, where the third event is a lock acquisition operation; determine q strongly connected subgraphs based on the lock relationship graph; determine q OV sets based on the q strongly connected subgraphs, and the mutually exclusive locks included in a strongly connected subgraph constitute an OV set.

[0152] In one possible design, the first determination module 1301 is specifically used to: when it is determined that the target event is a target event type, update the first local clock tree corresponding to the target event on the target thread to a second local clock tree, and the updating method is to merge the first local clock tree with the variable clock tree recorded at the target variable to obtain the second local clock tree, the target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event; take the events included in the event log as the target event in sequence, and repeat the above steps until the last event; determine the HB relationship based on each of the second local clock trees.

[0153] In a possible design, the target event type includes: a read operation, or a lock acquisition operation.

[0154] In one possible design, the first determination module 1301 is further specifically used to: when it is determined that the target event is a write operation, update the first variable clock tree recorded at the target variable to the first variable clock tree and the second variable clock tree, and the updating method is to copy the local clock tree corresponding to the target event on the target thread to the target variable to obtain the second variable clock tree, the target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event; take the events included in the event log as the target event in sequence, and repeat the above steps until the last event.

[0155] In one possible design, the first determination module 1301 is further specifically used to: when it is determined that the target event is a lock release operation, update the first variable clock tree recorded at the target variable to a third variable clock tree, and the updating method is to merge the local clock tree corresponding to the target event on the target thread with the first variable clock tree to obtain the third variable clock tree, the target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event; the events included in the event log are used as the target events in sequence, and the above steps are repeated until the last event.

[0156] It should be noted that the information interaction, execution process, etc. between the modules / units in the device 1300 are based on the same concept as the above-mentioned method embodiments in this application. For specific contents, please refer to the description in the method embodiments shown above in this application, and will not be repeated here.

[0157] Next, we will introduce a computer device provided by an embodiment of the present application. Figure 14 , Figure 14 A schematic diagram of a computer device provided in an embodiment of the present application is provided. The computer device 1400 may be deployed with Figure 13 The modules described in the corresponding embodiment are used to implement Figure 13 The functions of the computer device 1300 in the corresponding embodiment. Specifically, the computer device 1400 is implemented by one or more servers. The computer device 1400 may have relatively large differences due to different configurations or performances. It may include one or more central processing units (CPUs) 1422 and memories 1432, and one or more storage media 1430 (for example, one or more mass storage devices) storing application programs 1442 or data 1444. Among them, the memories 1432 and storage media 1430 can be temporary storage or permanent storage. The program stored in the storage medium 1430 may include one or more modules (not shown in the figure), each module may include a series of instruction operations in the computer device 1400. Furthermore, the central processing unit 1422 can be configured to communicate with the storage medium 1430 to execute a series of instruction operations in the storage medium 1430 on the computer device 1400.

[0158] The computer device 1400 may also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input and output interfaces 1458, and / or one or more operating systems 1441, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0159] In the embodiment of the present application, the central processing unit 1422 is used to execute the steps in the above-mentioned method embodiment. The specific implementation method of the central processing unit 1422 executing each of the above-mentioned steps is based on the same concept as the above-mentioned method embodiment in the present application, and the technical effects brought about are also the same as those in the above-mentioned embodiment of the present application. For specific details, please refer to the description of the method embodiment shown above in the present application, and will not be repeated here.

[0160] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0161] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, or a combination of a software product and a hardware product, and the computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., and includes a number of instructions for causing a computer device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0162] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0163] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a training device or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, a computer, a training device or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A deadlock detection method, characterized in that: include: Determine a standard event occurrence HB relationship based on an event log during software runtime, wherein the event log is used to record events occurring in chronological order, and the standard HB relationship is used to reflect the HB relationship between the events; Determine n lock event pairs according to the event log, each lock event pair including a first event and a second event, the first event being a holding of a first mutex lock, the second event being an acquisition of a second mutex lock, the lock event pair being used to indicate that the first mutex lock has been held and the second mutex lock needs to be acquired, and n ≥ 2; Determine the hypothetical point events corresponding to the n lock holding event pairs, to obtain n hypothetical point events, each hypothetical point event being a previous event of the thread where each first event is located; A deadlock sequence is determined based on the standard HB relationship, the n lock event pairs, and the n assumption point events.

2. The method according to claim 1, characterized in that The determining of the deadlock sequence based on the standard HB relationship, the n locking event pairs, and the n assumption point events includes: Reading a first lock event pair among the n lock event pairs; Determine a second lock event pair from the n lock event pairs according to a preset condition, wherein the mutex lock that needs to be acquired by the first lock event pair is the mutex lock already held by the second lock event pair; The second lock event pair is used as the new first lock event pair, and the above steps are repeated until p lock event pairs are determined, so that the mutex locks involved in the p lock event pairs form a lock order violation (OV) loop, and the mutex locks involved in the p lock event pairs form a deadlock sequence, and p ≥ 2; The preset conditions include: The second event in the second lock holding event pair has no HB relationship with the first hypothesis point event corresponding to the first lock holding event pair; The second event in the second lock holding event pair has no program order (PO) relationship with the first event in the first lock holding event pair; The second event in the first locking event pair has no HB relationship with the second hypothesis point event corresponding to the second locking event pair; The second event in the first lock holding event pair has no PO relationship with the first event in the second lock holding event pair; The second event in the first lock-holding event pair has no HB relationship with the second event in the second lock-holding event pair.

3. The method according to any one of claims 1 to 2, characterized in that Determining n lock event pairs according to the event log includes: Determine m initial lock event pairs according to the event log, where m≥n; Determine q OV sets according to the event log, each OV set includes at least two mutexes, q≥1; According to the q OV sets, n lock event pairs are determined from the m initial lock event pairs, and the first mutex and the second mutex involved in each lock event pair are from the same OV set.

4. The method according to claim 3, characterized in that Determining q OV sets according to the event log includes: Simplifying the event log to obtain each third event and a lock relationship graph associated with the third event, wherein the third event is a lock acquisition operation; Determine q strongly connected subgraphs according to the lock relationship graph; Q OV sets are determined according to the q strongly connected subgraphs, and the mutexes included in a strongly connected subgraph constitute an OV set.

5. The method according to any one of claims 1 to 4, characterized in that Determining the standard HB relationship based on the event log during software runtime includes: When it is determined that the target event is a target event type, updating a first local clock tree corresponding to the target event on the target thread to a second local clock tree, wherein the updating method is to merge the first local clock tree with the variable clock tree recorded at the target variable to obtain the second local clock tree, wherein the target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event; Using the events included in the event log as the target events in sequence, and repeating the above steps until the last event; A standard HB relationship is determined based on each of the second local clock trees.

6. The method according to claim 5, characterized in that The target event types include: Read operation, or acquire lock operation.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: When it is determined that the target event is a write operation, the first variable clock tree recorded at the target variable is updated to the first variable clock tree and the second variable clock tree. The updating method is to copy the local clock tree corresponding to the target event on the target thread to the target variable to obtain the second variable clock tree. The target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event. The events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: When it is determined that the target event is a lock release operation, the first variable clock tree recorded at the target variable is updated to a third variable clock tree, by merging a local clock tree corresponding to the target event on the target thread with the first variable clock tree to obtain the third variable clock tree, the target thread being the thread where the target event is located, and the target variable being used to represent an operation object of the target event; The events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event.

9. A computer device, characterized in that: include: A first determining module is configured to determine a standard event occurrence HB relationship based on an event log during software operation, wherein the event log is configured to record events occurring in chronological order, and the standard HB relationship is configured to reflect the HB relationship between the events; a second determining module, configured to determine, based on the event log, n lock holding event pairs, each lock holding event pair including a first event and a second event, wherein the first event is holding a first mutex lock, and the second event is acquiring a second mutex lock, the lock holding event pair being used to indicate that the first mutex lock has been held and the second mutex lock needs to be acquired, and n ≥ 2; a third determining module, configured to determine the hypothetical point events corresponding to the n lock holding event pairs, to obtain n hypothetical point events, each hypothetical point event being the previous event of the thread where each of the first events is located; The deadlock detection module is configured to determine a deadlock sequence based on the standard HB relationship, the n locking event pairs, and the n hypothesis point events.

10. The device according to claim 9, characterized in that The deadlock detection module is specifically used to: Reading a first lock event pair among the n lock event pairs; Determine a second lock event pair from the n lock event pairs according to a preset condition, wherein the mutex lock that needs to be acquired by the first lock event pair is the mutex lock already held by the second lock event pair; The second lock event pair is used as the new first lock event pair, and the above steps are repeated until p lock event pairs are determined, so that the mutex locks involved in the p lock event pairs form a lock order violation (OV) loop, and the mutex locks involved in the p lock event pairs form a deadlock sequence, and p ≥ 2; The preset conditions include: The second event in the second lock holding event pair has no HB relationship with the first hypothesis point event corresponding to the first lock holding event pair; The second event in the second lock holding event pair has no program order (PO) relationship with the first event in the first lock holding event pair; The second event in the first locking event pair has no HB relationship with the second hypothesis point event corresponding to the second locking event pair; The second event in the first lock holding event pair has no PO relationship with the first event in the second lock holding event pair; The second event in the first lock-holding event pair has no HB relationship with the second event in the second lock-holding event pair.

11. The device according to any one of claims 9-10, characterized in that The second determining module is specifically configured to: Determine m initial lock event pairs according to the event log, where m≥n; Determine q OV sets according to the event log, each OV set includes at least two mutexes, q≥1; According to the q OV sets, n lock event pairs are determined from the m initial lock event pairs, and the first mutex and the second mutex involved in each lock event pair are from the same OV set.

12. The device according to claim 11, characterized in that The second determining module is further configured to: Simplifying the event log to obtain each third event and a lock relationship graph associated with the third event, wherein the third event is a lock acquisition operation; Determine q strongly connected subgraphs according to the lock relationship graph; Q OV sets are determined according to the q strongly connected subgraphs, and the mutexes included in a strongly connected subgraph constitute an OV set.

13. The device according to any one of claims 9 to 12, characterized in that The first determining module is specifically configured to: When it is determined that the target event is a target event type, updating a first local clock tree corresponding to the target event on the target thread to a second local clock tree, wherein the updating method is to merge the first local clock tree with the variable clock tree recorded at the target variable to obtain the second local clock tree, wherein the target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event; Using the events included in the event log as the target events in sequence, and repeating the above steps until the last event; A standard HB relationship is determined based on each of the second local clock trees.

14. The device according to claim 13, characterized in that The target event types include: Read operation, or acquire lock operation.

15. The device according to any one of claims 9 to 14, characterized in that The first determining module is further configured to: When it is determined that the target event is a write operation, the first variable clock tree recorded at the target variable is updated to the first variable clock tree and the second variable clock tree. The updating method is to copy the local clock tree corresponding to the target event on the target thread to the target variable to obtain the second variable clock tree. The target thread is the thread where the target event is located, and the target variable is used to represent the operation object of the target event. The events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event.

16. The device according to any one of claims 9 to 15, characterized in that The first determining module is further configured to: When it is determined that the target event is a lock release operation, the first variable clock tree recorded at the target variable is updated to a third variable clock tree, by merging a local clock tree corresponding to the target event on the target thread with the first variable clock tree to obtain the third variable clock tree, the target thread being the thread where the target event is located, and the target variable being used to represent an operation object of the target event; The events included in the event log are sequentially used as the target events, and the above steps are repeated until the last event.

17. A computer device comprising a processor and a memory, wherein the processor is coupled to the memory, wherein: The memory is used to store computer-readable instructions; The processor is configured to read the computer-readable instructions so that the computer device executes the method according to any one of claims 1 to 8.

18. A computer storage medium, characterized in that Computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

19. A computer program product, characterized in that The computer program product includes computer-readable instructions, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

20. A chip comprising a processor and a data interface, characterized in that: The processor reads instructions stored in the memory through the data interface and executes the method according to any one of claims 1 to 8.

Images