Deadlock detection method, system and equipment based on lock template class and medium

Abstract

The invention provides a deadlock detection method, system and equipment based on a lock template class, and a medium, and the method comprises the steps: creating a mutual exclusion lock template class, and customizing a lock type for protecting shared resources; the mutual exclusion lock template class sets a lock stack to record a lock state of a thread, and a timestamp mechanism is introduced into the mutual exclusion lock template class to detect a blocking state; constructing a lock dependency graph of the global thread by the mutual exclusion lock template class, and identifying a lock and a lock dependency relationship by adopting nodes and edges of the lock dependency graph; and presetting a check period, and identifying a deadlock cycle in the global thread by adopting a detection algorithm according to the lock stack and the lock dependency graph. According to the method, the state of the lock and the resource allocation condition of the thread are monitored in real time through the template class, the potential deadlock risk can be found in time, early warning is given out, detailed deadlock information is provided, and a developer is helped to rapidly position the deadlock problem.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a deadlock detection method, system, device and medium based on a lock template class. Background Art

[0002] Multithreaded programming is one of the important means to improve program execution efficiency and response speed, but this parallel computing mode also brings complex synchronization problems to execution efficiency. In order to solve the synchronization problem of multithreading, lock technology is needed. Among them, improper use of mutex locks can easily lead to deadlock in multitasking, that is, two or more threads are blocked due to competition for resources or communication with each other, resulting in the inability of threads to continue execution.

[0003] Existing mutex locks focus on basic locking and unlocking functions, lacking in-depth monitoring of lock status and deadlock prevention mechanisms. When deadlock occurs, developers are often required to debug manually, which is not only inefficient but also requires high concurrent programming capabilities from developers.

[0004] Therefore, there is an urgent need for a deadlock statistical detection method based on the mutex lock template class that can automatically detect the lock blocking state, record the lock holder information, and have deadlock warning and diagnosis capabilities, which is of great significance to improving software quality and shortening the development cycle. Summary of the invention

[0005] In view of the deficiencies in the prior art, the present invention proposes a deadlock detection method, system, device and medium based on a lock template class.

[0006] The first aspect of the present invention discloses a deadlock detection method based on a lock template class, comprising:

[0007] Create a mutex template class and customize the lock type to protect shared resources;

[0008] The mutex template class sets the lock stack to record the lock status of the thread, and the mutex template class introduces a timestamp mechanism to detect the blocking status;

[0009] The mutex lock template class constructs a lock dependency graph of a global thread, and uses nodes and edges of the lock dependency graph to identify locks and lock dependencies;

[0010] A check cycle is preset, and a detection algorithm is used to identify a deadlock cycle within a global thread based on the lock stack and the lock dependency graph.

[0011] In an optional embodiment, the mutex lock template class is a template parameterized setting that can be interoperable with different code languages. The mutex lock template class provides threads with the functions of obtaining and releasing locks, and configures locks for shared resources in multi-threaded tasks. The lock types include mutex locks, spin locks, fine-grained locks, and fair locks.

[0012] In an optional embodiment, the mutex lock template class sets the lock stack to record the lock state of the thread, including:

[0013] A linear table with a stack data structure is used to track each thread, where each thread maintains a lock stack;

[0014] The linear table is used to record the order in which different threads request locks and the order in which different threads obtain locks;

[0015] When each thread issues a lock request, a lock request identifier for marking the thread is generated and recorded in the linear table. When each thread releases a lock, a lock release identifier for marking the thread is generated and recorded in the linear table. The lock stack is used to describe the resource allocation of the lock in the thread.

[0016] In an optional embodiment, the mutex template class introduces a timestamp mechanism to detect the blocking state, including:

[0017] Use timestamps to record the request time for each lock in different threads, and the lock time of each shared resource after the thread releases the lock;

[0018] The time difference between the request time and the lock time is detected regularly. If the time difference exceeds the blocking threshold, the blocking detection logic will be triggered, and the blocking detection logic will reveal the deadlock condition of repeated attempts to request the lock in the thread behavior.

[0019] In an optional embodiment, the mutex lock template class constructs a lock dependency graph of a global thread, and uses nodes and edges of the lock dependency graph to identify locks and lock dependencies, including:

[0020] The locks protecting the common resources are represented as nodes in the lock dependency graph, and the lock dependency relationships between threads are represented as undirected edges in the lock dependency graph;

[0021] The requested locks held by the first thread and the second thread are represented as directed edges from the first thread to the second thread, and the directed edges are used to identify potential deadlock cycles in the lock dependency relationship in which the first thread waits for the second thread to release the lock.

[0022] In an optional embodiment, the preset inspection cycle uses a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph, including:

[0023] Setting a deadlock cycle check period according to the thread state and lock request state recorded in the lock stack and the lock dependency graph, and traversing the lock stack and the lock dependency graph to search for the deadlock cycle within the check period;

[0024] The waiting relationship of different threads for locks is determined according to the lock request sequence in the lock stack, and a search algorithm is used to detect a deadlock loop consisting of nodes, undirected edges and directed edges in the lock dependency graph.

[0025] In an optional embodiment, the adopting a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph includes:

[0026] The banker's algorithm is used to simulate the resource allocation process in the thread through the lock stack to find a safe sequence that satisfies each thread to obtain the target public resource in sequence. If the safe sequence does not exist, the prediction result indicates that the system is in a deadlock loop. When the prediction result indicates that a deadlock loop exists, a loop detection algorithm is used to traverse the lock dependency graph to search for the relationship between nodes and edges. When there is an initial node that returns to the initial node along multiple undirected edges and directed edges, the deadlock loop associated with the initial node is identified as a deadlock loop.

[0027] The abnormal lock and the abnormal lock dependency relationship are determined in the lock dependency graph according to the deadlock loop, the association information between the abnormal lock and the thread is determined according to the lock stack, and the deadlock loop is re-debugged according to the association information.

[0028] A second aspect of the present invention discloses a deadlock detection system based on a lock template class, the system comprising:

[0029] Template class creation module, used to create mutex template class and customize the lock type to protect shared resources;

[0030] The lock stack module is used by the mutex lock template class to set the lock stack to record the lock status of the thread. The mutex lock template class introduces a timestamp mechanism to detect the blocking status;

[0031] A lock dependency graph module is used for the mutex lock template class to construct a lock dependency graph for a global thread, and the nodes and edges of the lock dependency graph are used to identify locks and lock dependencies;

[0032] The statistical detection module is used to preset a detection period and adopt a detection algorithm to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph.

[0033] In an optional embodiment, the template class creation module is a template parameterization setting that can be interoperable with different code languages. The mutex lock template class provides threads with the functions of obtaining and releasing locks, and configures locks for shared resources in multi-threaded tasks. The lock types include mutex locks, spin locks, fine-grained locks, and fair locks.

[0034] In an optional embodiment, the mutex lock template class in the lock stack module sets the lock state of the lock stack record thread, including:

[0035] A linear table with a stack data structure is used to track each thread, where each thread maintains a lock stack;

[0036] The linear table is used to record the order in which different threads request locks and the order in which different threads obtain locks;

[0037] When each thread issues a lock request, a lock request identifier for marking the thread is generated and recorded in the linear table. When each thread releases a lock, a lock release identifier for marking the thread is generated and recorded in the linear table. The lock stack is used to describe the resource allocation of the lock in the thread.

[0038] In an optional embodiment, the mutex lock template class in the lock stack module introduces a timestamp mechanism to detect the blocking state, including:

[0039] Use timestamps to record the request time for each lock in different threads, and the lock time of each shared resource after the thread releases the lock;

[0040] The time difference between the request time and the lock time is detected regularly. If the time difference exceeds the blocking threshold, the blocking detection logic will be triggered, and the blocking detection logic will reveal the deadlock condition of repeated attempts to request the lock in the thread behavior.

[0041] In an optional embodiment, the mutex lock template class in the lock dependency graph module constructs a lock dependency graph of a global thread, and uses the nodes and edges of the lock dependency graph to identify locks and lock dependencies, including:

[0042] The locks protecting the common resources are represented as nodes in the lock dependency graph, and the lock dependency relationships between threads are represented as undirected edges in the lock dependency graph;

[0043] The requested locks held by the first thread and the second thread are represented as directed edges from the first thread to the second thread, and the directed edges are used to identify potential deadlock cycles in the lock dependency relationship in which the first thread waits for the second thread to release the lock.

[0044] In an optional embodiment, a check cycle is preset in the statistical detection module, and a detection algorithm is used to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph, including:

[0045] Setting a deadlock cycle check period according to the thread state and lock request state recorded in the lock stack and the lock dependency graph, and traversing the lock stack and the lock dependency graph to search for the deadlock cycle within the check period;

[0046] The waiting relationship of different threads for locks is determined according to the lock request sequence in the lock stack, and a search algorithm is used to detect a deadlock loop consisting of nodes, undirected edges and directed edges in the lock dependency graph.

[0047] In an optional embodiment, the statistical detection module uses a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph, including:

[0048] The banker's algorithm is used to simulate the resource allocation process in the thread through the lock stack to find a safe sequence that satisfies each thread to obtain the target public resource in sequence. If the safe sequence does not exist, the prediction result indicates that the system is in a deadlock loop.

[0049] When the prediction result is that there is a deadlock cycle, a cycle detection algorithm is used to traverse the lock dependency graph to search for the relationship between nodes and edges. When there is an initial node returning to the initial node along multiple undirected edges and directed edges, the deadlock loop associated with the initial node is identified as a deadlock cycle;

[0050] The abnormal lock and the abnormal lock dependency relationship are determined in the lock dependency graph according to the deadlock loop, the association information between the abnormal lock and the thread is determined according to the lock stack, and the deadlock loop is re-debugged according to the association information.

[0051] The third aspect of the present invention discloses a deadlock detection device based on a lock template class, comprising:

[0052] at least one processor, and

[0053] a memory communicatively connected to the at least one processor; wherein,

[0054] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the deadlock detection method based on the lock template class as described in any one of the first aspects of the present invention.

[0055] A fourth aspect of the present invention discloses a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the deadlock detection method based on the lock template class as described in any one of the items disclosed in the first aspect of the present invention.

[0056] Compared with the prior art, the present invention has the following advantages:

[0057] The present invention provides a deadlock detection method, system, device and medium based on a lock template class, the method comprising creating a mutex template class, customizing the lock type for protecting shared resources; the mutex template class sets a lock stack to record the lock state of a thread, and the mutex template class introduces a timestamp mechanism to detect a blocking state; the mutex template class constructs a lock dependency graph of a global thread, and uses the nodes and edges of the lock dependency graph to identify locks and lock dependencies; a check cycle is preset, and a detection algorithm is used to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph. The above-mentioned scheme adopts a template class design, so that the mutex can be applied to different types of shared resources, improving the reusability and flexibility of the code. At the same time, the template class can also be customized and expanded according to specific needs to meet the concurrency control requirements in different scenarios. Based on the template class, the lock status and resource allocation of threads are monitored in real time, which can promptly detect potential deadlock risks, issue warnings and provide detailed deadlock information to help developers quickly locate deadlock problems. At the same time, statistics on lock usage, waiting time and number of deadlocks as key indicators can help developers gain an in-depth understanding of the system's concurrent performance, discover potential concurrency problems, and optimize lock usage strategies and concurrency control mechanisms accordingly. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] 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 some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0059] Figure 1 It is a flow chart of the deadlock detection method based on the lock template class of the present invention;

[0060] Figure 2 It is a schematic diagram of a deadlock detection system based on a lock template class of the present invention. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0062] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0063] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0064] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there may be three relationships, for example, "A and / or B" can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects before and after are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0065] Example 1

[0066] See also Figure 1 The embodiment of the present invention discloses a deadlock detection method based on a lock template class, comprising:

[0067] 101. Create a mutex template class and customize the lock type to protect shared resources;

[0068] In an optional embodiment, the mutex lock template class is a template parameterized setting that can be interoperable with different code languages. The mutex lock template class provides threads with the functions of obtaining and releasing locks, and configures locks for shared resources in multi-threaded tasks. The lock types include mutex locks, spin locks, fine-grained locks, and fair locks.

[0069] Specifically, the mutex lock template class is a general class template that allows us to define a class that can be used for multiple data types. By using the template class, we can create class instances suitable for different types without rewriting code, which is convenient for reuse in programming. In addition to providing standard lock() and un lock() methods to ensure that threads can safely access shared resources, different lock types can be introduced according to business needs, such as introducing finer-grained locks, spin locks, fair locks and other strategies to reduce lock contention and improve concurrent access efficiency. It supports customization and expansion according to specific needs to meet the concurrency control requirements in different scenarios.

[0070] 102. The mutex template class sets the lock stack to record the lock status of the thread, and the mutex template class introduces a timestamp mechanism to detect the blocking status;

[0071] Specifically, a stack is a linear list that is limited to insertion or deletion only at the end of the list. For a stack, the end of the list is called the top of the stack, and the head of the list is called the bottom of the stack. An empty list without elements is called an empty stack. Because the stack is limited to insertion or deletion at the end of the list, it can be adapted to record the lock state with time attributes in this embodiment to obtain the order in which the thread makes a lock request and the thread obtains the lock state. In addition to using the linear list form of the stack, the graph data structure can also be used to replace the stack to record the lock state by linearly representing the event sequence.

[0072] In an optional embodiment, the mutex lock template class sets the lock stack to record the lock state of the thread, including:

[0073] A linear table with a stack data structure is used to track each thread, where each thread maintains a lock stack;

[0074] The linear table is used to record the order in which different threads request locks and the order in which different threads obtain locks;

[0075] When each thread issues a lock request, a lock request identifier for marking the thread is generated and recorded in the linear table. When each thread releases a lock, a lock release identifier for marking the thread is generated and recorded in the linear table. The lock stack is used to describe the resource allocation of the lock in the thread.

[0076] In an optional embodiment, the mutex template class introduces a timestamp mechanism to detect the blocking state, including:

[0077] Use timestamps to record the request time for each lock in different threads, and the lock time of each shared resource after the thread releases the lock;

[0078] The time difference between the request time and the lock time is detected regularly. If the time difference exceeds the blocking threshold, the blocking detection logic will be triggered, and the blocking detection logic will reveal the deadlock condition of repeated attempts to request the lock in the thread behavior.

[0079] Specifically, a timestamp mechanism is introduced to record the start time of each lock request. Before each lock attempt, the difference between the current time and the last request time is checked. If it exceeds the preset blocking threshold, the blocking detection logic is triggered. The blocking detection logic includes but is not limited to printing warning information, recording logs, and attempting to unlock other held locks, etc., to reduce or avoid the occurrence of deadlock.

[0080] Furthermore, the linear table of the lock stack can provide a function for recording the number of lock holders, and use an internal data structure (such as a thread ID list or a hash table) to record the thread / process information currently holding the lock and provide a query interface, allowing external access to the lock holder list for easy debugging and monitoring.

[0081] 103. The mutex lock template class constructs a lock dependency graph of a global thread, and uses nodes and edges of the lock dependency graph to identify locks and lock dependencies;

[0082] In an optional embodiment, the mutex lock template class constructs a lock dependency graph of a global thread, and uses nodes and edges of the lock dependency graph to identify locks and lock dependencies, including:

[0083] The locks protecting the common resources are represented as nodes in the lock dependency graph, and the lock dependency relationships between threads are represented as undirected edges in the lock dependency graph;

[0084] The requested locks held by the first thread and the second thread are represented as directed edges from the first thread to the second thread, and the directed edges are used to identify potential deadlock cycles in the lock dependency relationship in which the first thread waits for the second thread to release the lock.

[0085] Specifically, a global lock dependency graph is constructed, where nodes represent locks and edges represent lock dependencies between threads. When a thread A holds lock X and requests lock Y (but is held by thread B), a directed edge from A to B is added to the graph, indicating that A is waiting for B to release lock Y. This graph structure helps identify potential deadlock cycles.

[0086] 104. Preset a check cycle and use a detection algorithm to identify a deadlock cycle in the global thread according to the lock stack and the lock dependency graph.

[0087] In an optional embodiment, the preset inspection cycle uses a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph, including:

[0088] Setting a deadlock cycle check period according to the thread state and lock request state recorded in the lock stack and the lock dependency graph, and traversing the lock stack and the lock dependency graph to search for the deadlock cycle within the check period;

[0089] The waiting relationship of different threads for locks is determined according to the lock request sequence in the lock stack, and a search algorithm is used to detect a deadlock loop consisting of nodes, undirected edges and directed edges in the lock dependency graph.

[0090] Specifically, according to the actual situation of the system (such as the number of threads, lock request frequency), a required inspection cycle is set, and then the system inspection is performed. In each inspection cycle, the lock dependency graph is traversed or the lock stacks of all threads are analyzed to find out whether there is a deadlock cycle. For graph structures, algorithms such as depth-first search (DFS) or breadth-first search (BFS) can be used to detect loops in the graph; for stack structures, it is necessary to infer the potential waiting relationship by comparing the lock stacks of different threads.

[0091] In an optional embodiment, the adopting a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph includes:

[0092] The banker's algorithm is used to simulate the resource allocation process in the thread through the lock stack to find a safe sequence that satisfies each thread to obtain the target public resource in sequence. If the safe sequence does not exist, the prediction result indicates that the system is in a deadlock loop.

[0093] When the prediction result is that there is a deadlock cycle, a cycle detection algorithm is used to traverse the lock dependency graph to search for the relationship between nodes and edges. When there is an initial node returning to the initial node along multiple undirected edges and directed edges, the deadlock loop associated with the initial node is identified as a deadlock cycle;

[0094] The abnormal lock and the abnormal lock dependency relationship are determined in the lock dependency graph according to the deadlock loop, the association information between the abnormal lock and the thread is determined according to the lock stack, and the deadlock loop is re-debugged according to the association information.

[0095] Specifically, the deadlock detection method based on the lock template class provides comprehensive statistical and analytical functions, including statistics on key indicators such as lock usage, waiting time, and number of deadlocks. The above statistical data can help developers gain an in-depth understanding of the system's concurrent performance, discover potential concurrency problems, and optimize lock usage strategies and concurrency control mechanisms accordingly. At the same time, at the system application level, the deadlock detection method based on the lock template class has good integrability and ease of use. Developers only need to perform simple configuration to integrate it into existing concurrent programs without making extensive modifications to the original code.

[0096] The present invention provides a deadlock detection method, system, device and medium based on a lock template class, the method comprising creating a mutex template class, customizing the lock type for protecting shared resources; the mutex template class sets a lock stack to record the lock state of a thread, and the mutex template class introduces a timestamp mechanism to detect a blocking state; the mutex template class constructs a lock dependency graph of a global thread, and uses the nodes and edges of the lock dependency graph to identify locks and lock dependencies; a check cycle is preset, and a detection algorithm is used to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph. The above-mentioned scheme adopts a template class design, so that the mutex can be applied to different types of shared resources, improving the reusability and flexibility of the code. At the same time, the template class can also be customized and expanded according to specific needs to meet the concurrency control requirements in different scenarios. Based on the template class, the lock status and resource allocation of threads are monitored in real time, which can promptly detect potential deadlock risks, issue warnings and provide detailed deadlock information to help developers quickly locate deadlock problems. At the same time, statistics on lock usage, waiting time and number of deadlocks as key indicators can help developers gain an in-depth understanding of the system's concurrent performance, discover potential concurrency problems, and optimize lock usage strategies and concurrency control mechanisms accordingly.

[0097] Example 2

[0098] like Figure 2 As shown, the second aspect of the present invention discloses a deadlock detection system based on a lock template class, the system comprising:

[0099] Template class creation module, used to create mutex template class and customize the lock type to protect shared resources;

[0100] The lock stack module is used by the mutex lock template class to set the lock stack to record the lock status of the thread. The mutex lock template class introduces a timestamp mechanism to detect the blocking status;

[0101] A lock dependency graph module is used for the mutex lock template class to construct a lock dependency graph for a global thread, and the nodes and edges of the lock dependency graph are used to identify locks and lock dependencies;

[0102] The statistical detection module is used to preset a detection period and adopt a detection algorithm to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph.

[0103] In an optional embodiment, the template class creation module is a template parameterization setting that can be interoperable with different code languages. The mutex lock template class provides threads with the functions of obtaining and releasing locks, and configures locks for shared resources in multi-threaded tasks. The lock types include mutex locks, spin locks, fine-grained locks, and fair locks.

[0104] In an optional embodiment, the mutex lock template class in the lock stack module sets the lock state of the lock stack record thread, including:

[0105] A linear table with a stack data structure is used to track each thread, where each thread maintains a lock stack;

[0106] The linear table is used to record the order in which different threads request locks and the order in which different threads obtain locks;

[0107] When each thread issues a lock request, a lock request identifier for marking the thread is generated and recorded in the linear table. When each thread releases a lock, a lock release identifier for marking the thread is generated and recorded in the linear table. The lock stack is used to describe the resource allocation of the lock in the thread.

[0108] In an optional embodiment, the mutex lock template class in the lock stack module introduces a timestamp mechanism to detect the blocking state, including:

[0109] Use timestamps to record the request time for each lock in different threads, and the lock time of each shared resource after the thread releases the lock;

[0110] The time difference between the request time and the lock time is detected regularly. If the time difference exceeds the blocking threshold, the blocking detection logic will be triggered, and the blocking detection logic will reveal the deadlock condition of repeated attempts to request the lock in the thread behavior.

[0111] In an optional embodiment, the mutex lock template class in the lock dependency graph module constructs a lock dependency graph of a global thread, and uses the nodes and edges of the lock dependency graph to identify locks and lock dependencies, including:

[0112] The locks protecting the common resources are represented as nodes in the lock dependency graph, and the lock dependency relationships between threads are represented as undirected edges in the lock dependency graph;

[0113] The requested locks held by the first thread and the second thread are represented as directed edges from the first thread to the second thread, and the directed edges are used to identify potential deadlock cycles in the lock dependency relationship in which the first thread waits for the second thread to release the lock.

[0114] In an optional embodiment, a check cycle is preset in the statistical detection module, and a detection algorithm is used to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph, including:

[0115] Setting a deadlock cycle check period according to the thread state and lock request state recorded in the lock stack and the lock dependency graph, and traversing the lock stack and the lock dependency graph to search for the deadlock cycle within the check period;

[0116] The waiting relationship of different threads for locks is determined according to the lock request sequence in the lock stack, and a search algorithm is used to detect a deadlock loop consisting of nodes, undirected edges and directed edges in the lock dependency graph.

[0117] In an optional embodiment, the statistical detection module uses a detection algorithm to identify a deadlock loop in a global thread according to the lock stack and the lock dependency graph, including:

[0118] The banker's algorithm is used to simulate the resource allocation process in the thread through the lock stack to find a safe sequence that satisfies each thread to obtain the target public resource in sequence. If the safe sequence does not exist, the prediction result indicates that the system is in a deadlock loop.

[0119] When the prediction result is that there is a deadlock cycle, a cycle detection algorithm is used to traverse the lock dependency graph to search for the relationship between nodes and edges. When there is an initial node returning to the initial node along multiple undirected edges and directed edges, the deadlock loop associated with the initial node is identified as a deadlock cycle;

[0120] The abnormal lock and the abnormal lock dependency relationship are determined in the lock dependency graph according to the deadlock loop, the association information between the abnormal lock and the thread is determined according to the lock stack, and the deadlock loop is re-debugged according to the association information.

[0121] The second aspect of the present invention provides a deadlock detection system based on a lock template class, which can monitor the state of the lock and resource allocation of the thread in real time based on the template class, timely discover potential deadlock risks, issue warnings and provide detailed deadlock information, help developers quickly locate deadlock problems, and at the same time count the usage, waiting time and number of deadlocks of the locks as key indicators, which can help developers gain a deep understanding of the concurrent performance of the system, discover potential concurrency problems, and optimize the lock usage strategy and concurrency control mechanism accordingly. The system has good integrability and ease of use, and developers only need to configure it simply to integrate it into existing concurrent programs without making a lot of modifications to the original code.

[0122] The third aspect of the present invention discloses a deadlock detection device based on a lock template class, comprising:

[0123] at least one processor, and

[0124] a memory communicatively connected to the at least one processor; wherein,

[0125] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the deadlock detection method based on the lock template class as described in any one of the first aspects of the present invention.

[0126] The computer device may be a terminal, and the computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a deadlock detection method based on a lock template class is implemented. The display screen of the computer device may be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device may be a touch layer covered on the display screen, or a key, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

[0127] A fourth aspect of the present invention discloses a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the deadlock detection method based on the lock template class as described in any one of the items disclosed in the first aspect of the present invention.

[0128] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments of the deadlock detection method based on the lock template class. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0129] Alternatively, if the above modules of the present invention are implemented in the form of software function modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention can be essentially or partly reflected in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the methods of each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, RAM, ROM, magnetic disks or optical disks.

[0130] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A deadlock detection method based on lock template class, characterized in that: The method comprises: Create a mutex template class and customize the lock type to protect shared resources; The mutex template class sets the lock stack to record the lock status of the thread, and the mutex template class introduces a timestamp mechanism to detect the blocking status; The mutex lock template class constructs a lock dependency graph of a global thread, and uses nodes and edges of the lock dependency graph to identify locks and lock dependencies; A check cycle is preset, and a detection algorithm is used to identify a deadlock cycle within a global thread based on the lock stack and the lock dependency graph.

2. The deadlock detection method based on lock template class according to claim 1 is characterized in that: The mutex lock template class is a template parameterized setting that can be interoperable with different code languages. The mutex lock template class provides threads with the functions of obtaining and releasing locks, and configures locks for shared resources in multi-threaded tasks. The lock types include mutex locks, spin locks, fine-grained locks, and fair locks.

3. The deadlock detection method based on lock template class according to claim 1 is characterized in that: The mutex lock template class sets the lock stack to record the lock status of the thread, including: A linear table with a stack data structure is used to track each thread, where each thread maintains a lock stack; The linear table is used to record the order in which different threads request locks and the order in which different threads obtain locks; When each thread issues a lock request, a lock request identifier for marking the thread is generated and recorded in the linear table. When each thread releases a lock, a lock release identifier for marking the thread is generated and recorded in the linear table. The lock stack is used to describe the resource allocation of the lock in the thread.

4. The deadlock detection method based on lock template class according to claim 1 is characterized in that: The mutex template class introduces a timestamp mechanism to detect the blocking state, including: Use timestamps to record the request time for each lock in different threads, and the lock time of each shared resource after the thread releases the lock; The time difference between the request time and the lock time is detected regularly. If the time difference exceeds the blocking threshold, the blocking detection logic will be triggered, and the blocking detection logic will reveal the deadlock condition of repeated attempts to request the lock in the thread behavior.

5. The deadlock detection method based on lock template class according to claim 1 is characterized in that: The mutex lock template class constructs a lock dependency graph of a global thread, and uses the nodes and edges of the lock dependency graph to identify locks and lock dependencies, including: The locks protecting the common resources are represented as nodes in the lock dependency graph, and the lock dependency relationships between threads are represented as undirected edges in the lock dependency graph; The requested locks held by the first thread and the second thread are represented as directed edges from the first thread to the second thread, and the directed edges are used to identify potential deadlock cycles in the lock dependency relationship in which the first thread waits for the second thread to release the lock.

6. The deadlock detection method based on lock template class according to claim 5 is characterized in that: The preset inspection cycle uses a detection algorithm to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph, including: Setting a deadlock cycle check period according to the thread state and lock request state recorded in the lock stack and the lock dependency graph, and traversing the lock stack and the lock dependency graph to search for the deadlock cycle within the check period; The waiting relationship of different threads for locks is determined according to the lock request sequence in the lock stack, and a search algorithm is used to detect a deadlock loop consisting of nodes, undirected edges and directed edges in the lock dependency graph.

7. The deadlock detection method based on lock template class according to claim 6 is characterized in that: The adopting detection algorithm to identify the deadlock cycle in the global thread according to the lock stack and the lock dependency graph includes: The banker's algorithm is used to simulate the resource allocation process in the thread through the lock stack to find a safe sequence that satisfies each thread to obtain the target public resource in sequence. If the safe sequence does not exist, the prediction result indicates that the system is in a deadlock loop. When the prediction result is that there is a deadlock cycle, a cycle detection algorithm is used to traverse the lock dependency graph to search for the relationship between nodes and edges. When there is an initial node returning to the initial node along multiple undirected edges and directed edges, the deadlock loop associated with the initial node is identified as a deadlock cycle; The abnormal lock and the abnormal lock dependency relationship are determined in the lock dependency graph according to the deadlock loop, the association information between the abnormal lock and the thread is determined according to the lock stack, and the deadlock loop is re-debugged according to the association information.

8. A deadlock detection system based on lock template class, characterized in that: The system comprises: Template class creation module, used to create mutex template class and customize the lock type to protect shared resources; The lock stack module is used by the mutex lock template class to set the lock stack to record the lock status of the thread. The mutex lock template class introduces a timestamp mechanism to detect the blocking status; A lock dependency graph module is used for the mutex lock template class to construct a lock dependency graph for a global thread, and the nodes and edges of the lock dependency graph are used to identify locks and lock dependencies; The statistical detection module is used to preset a detection cycle and adopt a detection algorithm to identify a deadlock cycle in a global thread according to the lock stack and the lock dependency graph.

9. A deadlock detection device based on a lock template class, characterized in that: include: at least one processor, and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the deadlock detection method based on the lock template class as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the deadlock detection method based on the lock template class according to any one of claims 1 to 7.

Images