A deadlock detection method and device, electronic equipment and storage medium

Abstract

The application discloses a deadlock detection method and device, electronic equipment and a storage medium. The method comprises the following steps: before a first thread currently running applies for a lock resource, determining a first lock resource that the first thread is about to apply for; for each thread currently running on the electronic equipment, reading thread resource information from a thread stack corresponding to the thread; wherein the thread resource information is resource information that is pressed into the thread stack when the thread acquires a thread resource or waits for a thread resource within a historical time; when a lock loop is formed between the first lock resource and the thread resource information, it is determined that if the first thread applies for the first lock resource, thread deadlock will occur. According to the scheme, whether a lock resource based on a thread will produce deadlock when a lock operation is performed on the thread can be detected in advance before the thread applies for the lock resource, so that the thread deadlock condition can be effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a deadlock detection method, apparatus, electronic device, and storage medium. Background Technology

[0002] Most programs in current application environments support multithreading, which can help improve task completion efficiency. However, deadlocks often occur during multithreaded execution. A deadlock occurs when two or more threads are blocked while waiting for each other. Deadlocks can lead to Out-of-Performance (OOPS) errors, causing system crashes. Since system crashes prevent log collection, it's difficult to pinpoint the deadlock location.

[0003] The commonly used approach is to determine the lock resources causing the deadlock based on the time of its occurrence and forcibly release them. However, this method has significant drawbacks: firstly, when a deadlock occurs, the CPU has already incurred Out-of-PS (OOPS) errors, and many commands and programs cannot run normally, so the recovery measures may not be effective; secondly, forcibly releasing the locks may cause incalculable damage to some protected resources. Furthermore, existing technologies that use directed graphs cannot solve deadlock problems between CPUs. Summary of the Invention

[0004] This invention provides a deadlock detection method, apparatus, electronic device, and storage medium, which can detect in advance whether deadlock will occur if a thread performs a locking operation based on a lock resource before the thread requests a lock resource.

[0005] According to one aspect of the present invention, a deadlock detection method is provided, applied to an electronic device, the method comprising:

[0006] Before the first thread currently running requests a lock resource, determine the first lock resource that the first thread is about to request;

[0007] For each thread currently running on the electronic device, thread resource information is read from the thread stack corresponding to the thread; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or while waiting for thread resources in a historical time period;

[0008] When a locking loop is formed between the first lock resource and the thread resource information, it is determined that if the first thread requests to acquire the first lock resource, a thread deadlock will occur.

[0009] According to another aspect of the present invention, a deadlock detection device is provided, applied to an electronic device, the device comprising:

[0010] The first lock resource determination module is used to determine the first lock resource that the first thread is about to request before the currently running first thread requests the lock resource;

[0011] The thread resource information reading module is used to read thread resource information from the thread stack corresponding to each thread currently running on the electronic device; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or waiting for thread resources in a historical time period;

[0012] The deadlock detection module is used to determine that if the first thread requests to acquire the first lock resource, a thread deadlock will occur when a locking loop is formed between the first lock resource and the thread resource information.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the deadlock detection method according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the deadlock detection method according to any embodiment of the present invention.

[0018] The deadlock detection scheme of this invention is applied to an electronic device. The method includes: determining that a first thread is about to request a lock resource before the currently running first thread requests a lock resource; reading thread resource information from the thread stack corresponding to each thread currently running on the electronic device; wherein the thread resource information is resource information pushed onto the thread stack by the thread after acquiring thread resources or while waiting for thread resources in a historical time; when a locking loop is formed between the first lock resource and the thread resource information, determining that a thread deadlock will occur if the first thread requests to acquire the first lock resource. Through the technical solution provided by this invention, before a thread requests a lock resource, it is possible to detect in advance whether a deadlock will occur if a thread is locked based on a lock resource, based on the thread resource information in the thread stack corresponding to each thread running on the electronic device, thereby helping to effectively avoid thread deadlock.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart of a deadlock detection method provided in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram illustrating a thread acquiring a lock resource according to an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram illustrating a thread acquiring a lock resource according to an embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram illustrating a process for a thread to acquire thread resources across CPUs, provided by an embodiment of the present invention.

[0025] Figure 5 for Figure 4 A diagram illustrating thread resource information in the stack of each thread during inter-CPU thread calls.

[0026] Figure 6 This is a schematic diagram of a deadlock detection device provided in an embodiment of the present invention;

[0027] Figure 7 A schematic diagram of the structure of an electronic device for implementing the deadlock detection method of this invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Figure 1 This is a flowchart illustrating a deadlock detection method provided in an embodiment of the present invention. This embodiment is applicable to deadlock detection situations. The method can be executed by a deadlock detection device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0031] S110. Before the currently running first thread requests the lock resource, determine the first lock resource that the first thread is about to request.

[0032] In this embodiment of the invention, after the electronic device enters the startup state, multiple threads running in the electronic device can be monitored. The electronic device can be a single-CPU device or a multi-CPU device. Before detecting that the first running thread is requesting a lock resource, the lock resource that the first thread is about to request is determined; for ease of description, the lock resource that the first thread is about to request is referred to as the first lock resource.

[0033] S120. For each thread currently running on the electronic device, read thread resource information from the thread stack corresponding to the thread; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or waiting for thread resources in a historical time.

[0034] In this embodiment of the invention, after the electronic device enters the startup state, it adds identification information to all lock resources. If a thread in the electronic device requests a lock resource, and the lock resource requested by the thread is not occupied by other threads, the thread can successfully acquire the lock resource and push the identification information corresponding to the acquired lock resource onto the thread's corresponding stack. If the lock resource requested by the thread is occupied by another thread, and the other thread is not currently waiting to acquire a lock resource, the thread waits to acquire the lock resource and pushes the identification information of the lock resource it is waiting to acquire onto the thread's corresponding stack. Here, a stack is a data structure in memory that grows from the bottom to the top. Optionally, when the electronic device is a multi-CPU device, in addition to threads within the same CPU acquiring or waiting for lock resources, there are also cases where threads call each other across CPUs via interfaces. When a thread calls across CPUs via an interface, the identifier of the interface called by the thread, the identifier of the thread being called across CPUs, and the identifier of the CPU where the thread being called across CPUs resides can be pushed onto the thread's corresponding stack. In this embodiment of the invention, lock resources and interface resources are referred to as thread resources. Since each thread can occupy multiple thread resources, and each thread resource can only be occupied by one thread at a time, the above method can push the thread resource information corresponding to the thread's acquisition of thread resources or waiting for thread resources into the thread stack corresponding to the thread in the historical time.

[0035] In this embodiment of the invention, all threads currently running on the electronic device are determined, and for each thread currently running on the electronic device, thread resource information is read from the thread stack corresponding to the thread. The thread resource information in the thread stack is used to reflect the thread resources acquired or waited for by the thread during its historical execution.

[0036] S130. When a locking loop is formed between the first lock resource and the thread resource information, it is determined that if the first thread requests to acquire the first lock resource, a thread deadlock will occur.

[0037] In this embodiment of the invention, it is determined whether a locking loop will be formed between the thread resource information and the first lock resource based on the thread resource information corresponding to each thread currently running on the electronic device. If so, it means that the first lock resource currently requested by the first thread is currently occupied by other threads, and the thread resource currently occupied by the first thread is the resource that other threads are currently waiting to acquire. At this time, it can be determined that if the first thread requests to acquire the first lock resource, a thread deadlock will occur.

[0038] Optionally, forming a locking loop between the first lock resource and the thread resource information includes: determining, based on the thread resource information, the second lock resource currently occupied by the first thread; if, based on the thread resource information, it is determined that the first lock resource is currently occupied by another thread, the second lock resource is currently a lock resource that another thread is waiting to acquire, and the lock resources that each target thread involved in the first lock resource and the second lock resource is currently waiting to acquire are lock resources mutually occupied by the respective target threads, then it is determined that a locking loop is formed between the first lock resource and the thread resource information.

[0039] For example, Figure 2 This is a schematic diagram illustrating a thread acquiring a lock resource according to an embodiment of the present invention. Figure 2As shown, the currently running threads in the electronic device include thread 1 and thread 2. The green area in the thread stack represents the lock resources that the thread has already acquired, that is, the lock resources currently occupied by the thread, and the red area represents the lock resources that the thread has requested to acquire. Assuming that the locking order of thread 1 and thread 2 in the electronic device is as follows: thread 1 + lock resource 1, thread 2 + lock resource 2, thread 1 + lock resource 2, thread 2 + lock resource 1, using the deadlock detection method provided in this embodiment of the invention, before each thread requests to acquire a lock resource, it first determines whether other threads are currently occupying the lock resource that the thread is requesting to acquire, and whether there will be mutual exclusion of lock resources between threads. For example, when thread 1 acquires lock resource 2, it iterates through the thread resource information in thread stack 1 corresponding to thread 1 and thread resource information in thread stack 2 corresponding to thread 2. It finds that thread 2 is currently holding lock resource 2, and thread 2 has not requested to acquire other lock resources. That is, thread 2 is not currently waiting for other lock resources. After thread 2 releases lock resource 2, thread 1 can acquire lock resource 2. In other words, there is no locking loop between lock resource 2 and the thread resource information corresponding to thread 1 and thread resource information corresponding to thread 2. This shows that if thread 1 requests to acquire lock resource 2, it will not cause thread deadlock. Therefore, thread 1 can wait to acquire lock resource 2. For example, when thread 2 requests lock resource 1, iterating through the thread resource information in thread stack 1 corresponding to thread 1 and thread stack 2 corresponding to thread 2 reveals that thread 1 currently occupies lock resource 1. Then, iterating through the thread resource information in thread stack 1 corresponding to thread 1 reveals that thread 1 is currently waiting to acquire lock resource 2. Further iterating through the thread resource information in the thread stacks of all threads (i.e., iterating through the thread resource information in thread stack 1 corresponding to thread 1 and thread stack 2 corresponding to thread 2) reveals that thread 2 is currently occupying lock resource 2. At this point, a locking loop is created between lock resource 1 and the thread resource information corresponding to thread 1 and thread 2. That is, the lock resource 1 that thread 2 is requesting to acquire is exactly the lock resource currently occupied by thread 1, and the lock resource 2 that thread 1 is waiting to acquire is exactly the lock resource currently occupied by thread 2. This demonstrates that if thread 2 requests to acquire lock resource 1, it will lead to a deadlock. Therefore, thread 2 should be prohibited from requesting to acquire lock resource 1.

[0040] For example, Figure 3 This is a schematic diagram illustrating a thread acquiring a lock resource according to an embodiment of the present invention. Figure 3As shown, the currently running threads in the electronic device include thread 1, thread 2, and thread 3. The green area in the thread stack represents the lock resources that the thread has already acquired, that is, the lock resources currently occupied by the thread, while the red area represents the lock resources that the thread has requested to acquire. Assume that the locking order of threads 1, 2, and 3 in the electronic device is as follows: thread 1 + lock resource 1, thread 2 + lock resource 2, thread 3 + lock resource 3, thread 1 + lock resource 2, thread 2 + lock resource 3, thread 3 + lock resource 1. According to... Figure 3 It can be seen that no two threads (Thread 1, Thread 2, and Thread 3) will cause a deadlock because there is no mutual exclusion of lock resources between any two threads. However, according to the above locking order, a deadlock will occur among the three threads. For example, when Thread 1 acquires lock resource 2, it iterates through the thread resource information in the thread stacks of all threads and finds that Thread 2 currently occupies lock resource 2, and Thread 2 has not yet requested to acquire other lock resources, that is, Thread 2 is not currently waiting for other lock resources. At this time, it can be determined that there is no locking cycle between lock resource 2 and the thread resource information of each thread. This shows that if Thread 1 requests to acquire lock resource 2, it will not cause a thread deadlock. Therefore, Thread 1 can wait to acquire lock resource 2. For example, when thread 2 acquires lock resource 3, it iterates through the thread resource information in the thread stacks of all threads. It can be found that lock resource 3 is currently being occupied by thread 3, and thread 3 has not yet requested to acquire other lock resources. That is, thread 3 is not currently waiting for other lock resources. At this time, it can be determined that there will be no locking loop between lock resource 3 and the thread resource information of each thread. This shows that if thread 2 requests to acquire lock resource 3, it will not cause thread deadlock. Therefore, thread 2 can wait to acquire lock resource 3.

[0041] For example, when thread 3 requests lock resource 1, iterating through the thread resource information in the thread stacks of all threads reveals that thread 1 currently occupies lock resource 1, is currently waiting to acquire lock resource 2, thread 2 currently occupies lock resource 2, and is currently waiting to acquire lock resource 3. Lock resource 3 is the lock resource currently occupied by thread 3. At this point, a locking loop is created between lock resource 1 and the thread resource information of all threads, indicating that if thread 3 requests to acquire lock resource 1, it will lead to a thread deadlock. Therefore, thread 3 can be prohibited from requesting to acquire lock resource 1.

[0042] Optionally, forming a locking loop between the first lock resource and the thread resource information includes: determining the first CPU where the first thread is located, and determining the second thread currently occupying the first lock resource based on the thread resource information; if, based on the thread resource information, it is determined that the first thread's request for the first lock resource is a call request initiated by a first target thread in the second CPU, and the target thread resource that the second thread is currently waiting to acquire is currently occupied by the first target thread, then it is determined that a locking loop is formed between the first lock resource and the thread resource information. Optionally, the target thread resource is an interface resource. The advantage of this setting is that it can effectively detect deadlocks caused by cross-CPU thread calls.

[0043] Optionally, before reading thread resource information from the thread stack corresponding to the thread, the method further includes: if any third thread in the source CPU calls the second target thread in the destination CPU through the target interface, the thread resource information pushed onto the thread stack corresponding to the third thread includes the identification information of the target interface, the identification information of the destination CPU, and the identification information of the second target thread.

[0044] In this embodiment of the invention, during the operation of an electronic device, there may be situations where threads within the electronic device call threads within other electronic devices; when the electronic device is a multi-CPU device, there may be situations where threads across multiple CPUs within the electronic device call each other, which can be referred to as cross-CPU thread calls. For example, Figure 4 This is a schematic diagram illustrating a process for a thread to acquire thread resources across CPUs, as provided in an embodiment of the present invention. Figure 4As shown, the process of this invention is as follows: when a cross-CPU message is detected in thread 1, the cross-CPU interface is pushed onto the stack. Before thread 1 in CPU1 requests to acquire lock resource 1, it finds that lock resource 1 is not occupied. Therefore, thread 1 in CPU1 can successfully acquire lock resource 1, that is, thread 1 in CPU1 occupies lock resource 1, and pushes the identification information of lock resource 1 onto the stack corresponding to thread 1. Then, before thread 1 in CPU1 requests to acquire lock resource 2, it finds that lock resource 2 is not occupied. Therefore, thread 1 in CPU1 can successfully acquire lock resource 2, and pushes the identification information of lock resource 2 onto the stack corresponding to thread 1. Then, thread 1 in CPU1 calls thread 2 in CPU2 through the SetEncode interface. At this time, CPU1 is the source CPU, CPU2 is the destination CPU, and the SetEncode interface is the target interface. The identification information of the SetEncode interface, the identification information of CPU2, and the identification information of thread 2 in CPU2 are pushed onto the stack corresponding to thread 1. After receiving the call request sent by Thread 1 of CPU1 through the SetEncode interface, Thread 2 in CPU2 pushes the identification information of the SetEncode interface, the identification information of CPU1, and the identification information of Thread 1 in CPU1 onto the stack corresponding to Thread 2 in CPU2. Then, before Thread 2 in CPU2 requests to acquire lock resource 3, it finds that lock resource 3 is not occupied. Therefore, Thread 2 in CPU2 can successfully acquire lock resource 3 and pushes the identification information of lock resource 3 onto the stack corresponding to Thread 2 in CPU2. Then, before Thread 2 in CPU2 requests to acquire lock resource 4, it finds that lock resource 4 is not occupied. Therefore, Thread 2 in CPU2 can successfully acquire lock resource 4 and pushes the identification information of lock resource 4 onto the stack corresponding to Thread 2 in CPU2. Then, Thread 2 in CPU2 calls Thread 2 in CPU1 through the GetParam interface. At this time, CPU2 is the source CPU, CPU1 is the destination CPU, and the GetParam interface is the target interface. The identification information of the GetParam interface, the identification information of CPU1, and the identification information of Thread 2 in CPU1 are pushed onto the stack corresponding to Thread 2 in CPU2.After receiving the call request sent by Thread 2 of CPU2 through the GetParam interface, Thread 2 in CPU1 pushes the identification information of the GetParam interface, the identification information of CPU2, and the identification information of Thread 2 in CPU2 onto the stack corresponding to Thread 2 in CPU1. Then, before Thread 2 in CPU1 requests to acquire lock resource 1, it finds through the thread resource information in the thread stacks of all threads that lock resource 1 is currently occupied by Thread 1 in CPU1. The thread resource required by Thread 1 is the SetEncode interface, which is currently occupied by Thread 2 of CPU2. Since the request for lock resource 1 by Thread 2 in CPU1 is exactly the call request initiated by Thread 2 in CPU2, it can be determined that a locking loop is formed between lock resource 1 and the thread resource information corresponding to all threads in each CPU. Therefore, if Thread 2 in CPU1 requests to acquire lock resource 1, a thread deadlock will occur.

[0045] Optionally, after determining that a thread deadlock would occur if the current thread were to perform a locking operation based on the target lock resource, the method further includes: responding to a failure of the first thread's request for the first lock resource, causing the first thread to release the currently occupied thread resource, and controlling the first thread to request and acquire the first lock resource after a preset time. The advantage of this setting is that when a deadlock is detected in advance if a locking operation based on the lock resource would occur, the electronic device can be seamlessly restored, improving the user experience.

[0046] For example, with Figure 3 Taking thread 3's request to acquire lock resource 1 as an example, if it is detected that thread 3's request to acquire lock resource 1 would lead to a deadlock, the operation can be returned indicating that thread 3's request to acquire lock resource 1 has failed. This allows thread 3 to release lock resource 3, enabling thread 2 to successfully acquire lock resource 3 and execute its corresponding business operation. Afterward, thread 2 releases both lock resource 3 and lock resource 2. Then, thread 1 successfully acquires lock resource 2 and executes its corresponding business operation, releasing both lock resource 2 and lock resource 1. After thread 1 releases lock resource 1, thread 3 is then controlled to request to acquire lock resource 1, at which point thread 3 can successfully acquire lock resource 1. This avoids system crashes and does not affect normal business operations. For example, if the business task corresponding to thread 3's request to acquire lock resource 1 is to acquire a video stream, then if it is detected that thread 3's request to acquire lock resource 1 would lead to a deadlock, the video stream acquisition failure can be returned, and the video stream acquisition task can be reissued after a preset time period. For example, if the business task corresponding to thread 3 requesting to acquire lock resource 1 is adjusting the TV wall window, then if it is detected that thread 3's request to acquire lock resource 1 will cause a thread deadlock, the TV wall window adjustment can be returned as failed, and the TV wall window adjustment task can be reissued after a preset time period.

[0047] This invention discloses a deadlock detection method applied to an electronic device. The method includes: determining that a first thread is about to request a lock resource before the currently running first thread requests it; reading thread resource information from the thread stack corresponding to each thread running on the electronic device; wherein the thread resource information is resource information pushed onto the thread stack by the thread after acquiring or waiting for thread resources in a historical time period; when a locking loop is formed between the first lock resource and the thread resource information, determining that a thread deadlock will occur if the first thread requests to acquire the first lock resource. Through the technical solution provided by this invention, before a thread requests a lock resource, it is possible to detect in advance whether a deadlock will occur if a thread is locked based on a lock resource, based on the thread resource information in the thread stack corresponding to each thread running on the electronic device, thereby helping to effectively avoid thread deadlock.

[0048] In some embodiments, the thread resource information in the thread stack corresponding to each thread currently running on the electronic device is displayed on the thread resource display interface. For example, the thread resource information corresponding to each thread running on the electronic device is displayed in a pre-created thread resource display interface. Figure 5 for Figure 4 This diagram illustrates the thread resource information in the stack of each thread during inter-CPU thread calls. The advantage of this setup is that it allows users to visually observe the locking behavior between threads.

[0049] Figure 6 This is a schematic diagram of a deadlock detection device provided in an embodiment of the present invention. Figure 6 As shown, the device includes:

[0050] The first lock resource determination module 610 is used to determine the first lock resource that the first thread is about to request before the currently running first thread requests the lock resource;

[0051] The thread resource information reading module 620 is used to read thread resource information from the thread stack corresponding to each thread currently running on the electronic device; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or waiting for thread resources in a historical time period;

[0052] The deadlock detection module 630 is used to determine that if the first thread requests to acquire the first lock resource, a thread deadlock will occur when a locking loop is formed between the first lock resource and the thread resource information.

[0053] Optionally, the deadlock detection module is used for:

[0054] The second lock resource currently occupied by the first thread is determined based on the thread resource information;

[0055] If, based on the thread resource information, it is determined that the first lock resource is currently occupied by another thread, the second lock resource is currently a lock resource that another thread is waiting to acquire, and the lock resources that each target thread involved in the first lock resource and the second lock resource is currently waiting to acquire are lock resources that are mutually occupied by each target thread, then it is determined that a locking loop is formed between the first lock resource and the thread resource information.

[0056] Optionally, the deadlock detection module is used for:

[0057] Determine the first CPU where the first thread is located, and determine the second thread currently occupying the first lock resource based on the thread resource information;

[0058] If, based on the thread resource information, it is determined that the first thread's request for the first lock resource is a call request initiated by the first target thread in the second CPU, and the target thread resource that the second thread is currently waiting to acquire is currently occupied by the first target thread, then it is determined that a locking loop is formed between the first lock resource and the thread resource information.

[0059] Optionally, the target thread resource is an interface resource.

[0060] Optional, also includes:

[0061] The thread resource information pushing module is used to push the thread resource information onto the thread stack corresponding to the third thread before reading the thread resource information from the thread stack corresponding to the thread. If any third thread in the source CPU calls the second target thread in the destination CPU through the target interface, the thread resource information pushed onto the thread stack corresponding to the third thread includes the identification information of the target interface, the identification information of the destination CPU, and the identification information of the second target thread.

[0062] Optional, also includes:

[0063] The failure operation response module is used to respond to the failure operation of the first thread in requesting the first lock resource after determining that a thread deadlock will occur if the current thread is locked based on the target lock resource, so that the first thread releases the currently occupied thread resource, and controls the first thread to request to acquire the first lock resource after a preset time.

[0064] Optional, also includes:

[0065] The thread resource information display module is used to display the thread resource information in the thread stack corresponding to each thread currently running on the electronic device on the thread resource display interface.

[0066] The deadlock detection device provided in this embodiment of the invention can execute the deadlock detection method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0067] Figure 7 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0068] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0069] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0070] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as deadlock detection methods.

[0071] In some embodiments, the deadlock detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the deadlock detection method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the deadlock detection method by any other suitable means (e.g., by means of firmware).

[0072] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0073] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0074] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0075] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0076] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0077] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0078] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0079] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A deadlock detection method, characterized in that, Applied to electronic devices, the method includes: Before the first thread currently running requests a lock resource, determine the first lock resource that the first thread is about to request; For each thread currently running on the electronic device, thread resource information is read from the thread stack corresponding to the thread; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or while waiting for thread resources in a historical time period; When a locking loop is formed between the first lock resource and the thread resource information, it is determined that if the first thread requests to acquire the first lock resource, a thread deadlock will occur.

2. The method according to claim 1, characterized in that, A locking loop is formed between the first lock resource and the thread resource information, including: The second lock resource currently occupied by the first thread is determined based on the thread resource information; If, based on the thread resource information, it is determined that the first lock resource is currently occupied by another thread, the second lock resource is currently a lock resource that another thread is waiting to acquire, and the lock resources that each target thread involved in the first lock resource and the second lock resource is currently waiting to acquire are lock resources that are mutually occupied by each target thread, then it is determined that a locking loop is formed between the first lock resource and the thread resource information.

3. The method according to claim 1, characterized in that, A locking loop is formed between the first lock resource and the thread resource information, including: Determine the first CPU where the first thread is located, and determine the second thread currently occupying the first lock resource based on the thread resource information; If, based on the thread resource information, it is determined that the first thread's request for the first lock resource is a call request initiated by the first target thread in the second CPU, and the target thread resource that the second thread is currently waiting to acquire is currently occupied by the first target thread, then it is determined that a locking loop is formed between the first lock resource and the thread resource information.

4. The method according to claim 3, characterized in that, The target thread resource is an interface resource.

5. The method according to claim 1, characterized in that, Before reading thread resource information from the thread stack corresponding to the thread, the process also includes: If any third thread in the source CPU calls the second target thread in the destination CPU through the target interface, the thread resource information pushed onto the thread stack corresponding to the third thread includes the identification information of the target interface, the identification information of the destination CPU, and the identification information of the second target thread.

6. The method according to any one of claims 1-5, characterized in that, After determining that a thread deadlock would occur if a locking operation were performed on the current thread based on the target lock resource, the method further includes: In response to the failure of the first thread to request the first lock resource, the first thread releases the currently occupied thread resources, and after a preset time, the first thread is controlled to request to acquire the first lock resource.

7. The method according to any one of claims 1-5, characterized in that, Also includes: The thread resource display interface shows the thread resource information in the thread stack corresponding to each thread currently running on the electronic device.

8. A deadlock detection device, characterized in that, Applied to electronic devices, the device includes: The first lock resource determination module is used to determine the first lock resource that the first thread is about to request before the currently running first thread requests the lock resource; The thread resource information reading module is used to read thread resource information from the thread stack corresponding to each thread currently running on the electronic device; wherein, the thread resource information is the resource information pushed into the thread stack by the thread after acquiring thread resources or waiting for thread resources in a historical time period; The deadlock detection module is used to determine that if the first thread requests to acquire the first lock resource, a thread deadlock will occur when a locking loop is formed between the first lock resource and the thread resource information.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the deadlock detection method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the deadlock detection method according to any one of claims 1-7.

Images