A deadlock detection method and apparatus

Abstract

This invention discloses a deadlock detection method and apparatus, comprising: acquiring a target task in a suspended queue; acquiring a target mutex lock corresponding to the target task; acquiring the holder of the target mutex lock; generating deadlock detection information when the holder exists in the suspended queue; the deadlock detection information indicating the existence of a deadlock in the system. This invention detects deadlocks in an RTOS in real time by detecting whether the holder of the target mutex lock to be acquired by the target task in the suspended queue also exists in the suspended queue. It achieves semi-loop detection, resulting in high detection efficiency and low time consumption, significantly improving the real-time performance of the deadlock detection method.

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to a deadlock detection method and apparatus. Background Technology

[0002] A mutex (also known as a mutex) is a lock protection mechanism provided by the operating system to prevent race conditions caused by concurrent access to shared resources. However, improper use of mutexes can have serious consequences, the most common being deadlock. Deadlock can cause a decrease in the utilization rate of resources in the system and may eventually lead to system crash.

[0003] AB-BA deadlock is a common type of deadlock. Specifically, at a certain moment, thread 1 holds mutex A and thread 2 holds mutex B. When thread 1 tries to acquire mutex B and thread 2 tries to acquire mutex A, the two threads wait for each other to acquire their respective locks, thus forming a deadlock.

[0004] A real-time operating system (RTOS), also known as an instantaneous operating system, manages system resources in a prioritized manner and provides a consistent foundation for application development. Compared to general operating systems, the biggest feature of an RTOS is its "real-time" nature. If a task needs to be executed, the RTOS will execute it immediately (within a short time) without a long delay. This characteristic ensures the timely execution of each task. In contrast, most existing RTOSs use strategies such as priority inheritance to effectively reduce deadlock, but they do not detect deadlock in real time. Summary of the Invention

[0005] To address the problems existing in the prior art, the present invention provides a deadlock detection method and apparatus that can detect deadlock in real time, with high detection efficiency, low time consumption, and improved RTOS operation stability and real-time performance.

[0006] The technical solution is as follows:

[0007] On one hand, the present invention provides a deadlock detection method, comprising:

[0008] Retrieve the target task from the pending queue;

[0009] Obtain the target mutex lock corresponding to the target task;

[0010] Find the holder of the target mutex lock;

[0011] When the holder exists in the suspended queue, deadlock detection information is generated; the deadlock detection information indicates that a deadlock exists in the system.

[0012] Furthermore, if the suspend queue includes multiple sleeping tasks, then obtaining the target task from the suspend queue includes:

[0013] Obtain the sleep time information and sorting position information corresponding to each of the multiple sleep tasks;

[0014] Based on multiple sleep time information, a first screening process is performed on multiple sleep tasks to obtain multiple target sleep tasks;

[0015] Based on the sorting position information, a second filtering process is performed on multiple target sleep tasks to obtain the target tasks.

[0016] Furthermore, if the sleep time information includes the sleep start time of the sleep task, then the first filtering process for multiple sleep tasks based on multiple pieces of sleep time information to obtain multiple target sleep tasks includes:

[0017] Get the current time point;

[0018] Based on the current time point and multiple sleep start times, the sleep duration corresponding to multiple sleep tasks is obtained;

[0019] Based on a preset duration and multiple sleep durations, the first filtering process is performed on multiple sleep tasks to obtain multiple target sleep tasks.

[0020] Furthermore, before retrieving the target task from the pending queue, the method further includes:

[0021] Create the suspension queue, which is used to store information about sleep tasks waiting to acquire the target mutex lock.

[0022] Preferably, before retrieving the target task from the pending queue, the method further includes:

[0023] Run the task so that the task acquires the corresponding target mutex lock;

[0024] When the task fails to acquire the target mutex lock, the task is marked as a sleeping task and added to the suspended queue.

[0025] Furthermore, when the task fails to acquire the target mutex lock, the method further includes:

[0026] The corresponding sleep start time is stored in the sleep time information of the sleep task;

[0027] The information of the corresponding target mutex is stored in the information of the sleep task.

[0028] Furthermore, the information corresponding to the suspended queue includes parameter variables, which are used to store the number of sleeping tasks in the suspended queue.

[0029] Furthermore, after marking the task as a sleeping task and adding the sleeping task to the suspension queue when the task fails to acquire the target mutex lock, the method further includes:

[0030] Update the parameter variables based on the sleep task.

[0031] Furthermore, before acquiring the target mutex lock corresponding to the target task, the method further includes:

[0032] Obtain the sorting position information of the target task in the suspended queue;

[0033] When the parameter variable and the sorting position information meet the preset conditions, the process of obtaining the target mutex lock corresponding to the target task is executed.

[0034] On the other hand, the present invention provides a deadlock detection device, comprising:

[0035] The first acquisition module is used to acquire target tasks in the pending queue;

[0036] The second acquisition module is used to acquire the target mutex lock corresponding to the target task;

[0037] The third acquisition module is used to acquire the holder of the target mutex lock;

[0038] The detection module is used to generate deadlock detection information when the holder exists in the suspended queue; the deadlock detection information indicates that a deadlock exists in the system.

[0039] Implementing this invention has the following beneficial effects:

[0040] 1. This invention is based on a suspended queue for detection. By detecting whether the holder of the target mutex lock that the target task wants to acquire also exists in the suspended queue, deadlocks in the RTOS can be detected in real time. This achieves semi-loop detection, which is highly efficient and time-saving, and can greatly improve the real-time performance of deadlock detection methods, thereby improving the stability and real-time performance of the RTOS.

[0041] 2. The detection target of this invention is the target task in the suspended queue. It is not necessary to detect all sleeping tasks in the suspended queue. Instead, the target task is obtained after the first and second screening processes, which further improves the detection efficiency and the real-time performance of the deadlock detection method. Attached Figure Description

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

[0043] Figure 1 This is a logical structure diagram of a deadlock detection method provided in an embodiment of the present invention;

[0044] Figure 2 A logical structure diagram of a target task screening method provided in an embodiment of the present invention;

[0045] Figure 3 A logical structure diagram of a method for screening target sleep tasks provided in an embodiment of the present invention;

[0046] Figure 4 A logical structure diagram of a data storage method for a suspended queue provided in an embodiment of the present invention;

[0047] Figure 5 A logical structure diagram of the acquisition conditions of a target mutex lock provided in an embodiment of the present invention;

[0048] Figure 6 This is a schematic diagram of a deadlock detection device provided in an embodiment of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments, and therefore should not be construed as limiting the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0050] It should be noted that the terms "first," "second," etc., in the specification, claims, and 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 embodiments of the invention can be implemented in orders other than those shown in the figures or descriptions below. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0051] This embodiment addresses the problem in existing technologies where RTOS does not detect deadlocks in real time by providing a deadlock detection method applicable to RTOS. This deadlock detection method can be applied to the deadlock detection device of this embodiment. When a detection command is received, the target task in the suspension queue is retrieved, and the target mutex corresponding to the target task is obtained. Then, the holder of the target mutex is retrieved. If the holder also exists in the suspension queue, deadlock detection information is generated, indicating that a deadlock exists in the real-time operating system. If the holder does not exist in the suspension queue, the tasks in the suspension queue are traversed to update the target task and continue deadlock detection. This method has high detection efficiency, low time consumption, and is beneficial for improving the real-time performance of the RTOS.

[0052] The technical solutions of the embodiments of the present invention will be described in detail below, with reference to the appendix to the specification. Figure 1 The method includes:

[0053] S101, retrieve the target task from the suspended queue.

[0054] The suspend queue includes multiple sleeping tasks. This queue stores information about sleeping tasks waiting to acquire a target mutex lock. A sleeping task is a task that is in a sleeping state. In an RTOS, each task has multiple states, including ready, running, waiting, and sleeping. When a task wants to access a shared resource, it needs to acquire the corresponding mutex lock. However, if the mutex lock is being held by another task, the task cannot acquire the mutex lock and will then enter a sleeping state.

[0055] If the target task is a single sleep task selected from multiple sleep tasks in the suspended queue, then the deadlock detection method detects only the sleep tasks in the suspended queue. This method is highly targeted and does not require detecting all tasks in the real-time operating system, which helps to save detection time, improve detection efficiency, and thus improve the real-time performance of the RTOS.

[0056] S103, acquire the target mutex lock corresponding to the target task.

[0057] In an RTOS, each task is assigned a unique task ID. This task ID allows for quick retrieval or tracking of the task's control information, thereby obtaining various information related to the task, such as the mutex lock information associated with the task.

[0058] In one possible implementation, when a task is in a sleep state, the task control information of the sleep task includes blocked object information and sleep time information. The blocked object information is used to store the mutex lock information corresponding to the sleep task. When the task cannot acquire the corresponding mutex lock, the mutex lock information is stored in the blocked object information of the sleep task, indicating that the sleep task is blocked on the mutex lock. The sleep time information is used to store at least the sleep start time of the sleep task. When the task cannot acquire the corresponding mutex lock and enters a sleep state, the sleep start time of the sleep task is stored in the sleep time information so that the blocked object information and sleep time information can be called during the deadlock detection process.

[0059] In an RTOS, a task control block structure variable is allocated to each task to manage the task. That is, a pointer to the task control block structure variable is used to identify the task. Both blocked and sleep are members of the task control block structure variable, so as to obtain information related to the task.

[0060] The target mutex lock corresponding to the target task here refers to the mutex lock that the target task failed to acquire. It means that the target task is currently waiting to acquire the target mutex lock. In a specific implementation, when acquiring the target mutex lock, the target mutex lock can be obtained directly based on the blocking object information of the target task, which is convenient, fast and efficient.

[0061] S105, obtain the holder of the target mutex lock.

[0062] In an RTOS, the control block structure of a mutex lock includes owner information and a waitlist. The owner information stores information about the task currently holding the mutex lock (i.e., the owner), while the waitlist stores information about tasks (or sleeping tasks) waiting to acquire the mutex lock. Therefore, in this step, once the target mutex lock is acquired, the owner information can be directly obtained from the control block structure of the target mutex lock, which is efficient and fast.

[0063] In one possible implementation, the waiting queue is a sorting queue, and the sleep tasks waiting to acquire the mutex lock are stored in the waiting queue in a preset order; alternatively, storing them in the waiting queue in a preset order means storing them in the waiting queue according to the sleep start time corresponding to the sleep task.

[0064] S107, when the holder exists in the suspended queue, deadlock detection information is generated; the deadlock detection information indicates that a deadlock exists in the system.

[0065] At this point, if the holder is in the pending queue, it means that the holder is also waiting to acquire a mutex lock. Regardless of whether the mutex lock corresponding to the holder is the target task, a deadlock is considered to exist in the RTOS. The deadlock detection process only detects the process from the target task to the holder of the target mutex lock, without needing to determine whether the mutex lock corresponding to the holder is the target task, forming a semi-loop detection, which further improves detection efficiency and shortens time consumption.

[0066] Taking a specific process as an example, the target task is the first task, which exists in the pending queue. The first task is waiting to acquire mutex A, while the holder of mutex A is the second task, which is waiting to acquire mutex B. Then, it is only necessary to determine whether the second task exists in the pending queue. There is no need to determine whether the holder of mutex B is the first task. That is, only the semi-loop detection of AB-BA type deadlock is implemented, without the need to perform the full loop detection of AB-BA type deadlock, which greatly reduces the time consumption.

[0067] It should be noted that steps S101 to S107 are the deadlock detection process for a single target task. When the holder is not present in the suspended queue, the process returns to step S101, retrieves another target task from the suspended queue, and repeats steps S101 to S107 to perform deadlock detection. That is, it iterates through the sleeping tasks in the suspended queue to update the target task. When the current holder is detected to be in the suspended queue during any round of detection, deadlock detection information is generated. If no holder is present in the suspended queue when iterating through the target tasks in the suspended queue, then there is no deadlock in the real-time operating system.

[0068] Specifically, prior to step S101, the method further includes:

[0069] Obtain the detection start command.

[0070] During RTOS initialization, a loop detection task is created. This loop detection task is a periodic task used to initiate the deadlock detection process in steps S101 to S107. When the loop detection task is started, the detection start instruction is obtained, and the target task in the suspension queue is obtained according to the detection start instruction to perform deadlock detection.

[0071] In one possible implementation, the loop detection task has a detection cycle of 30 to 90 seconds; in another possible implementation, the loop detection task has a detection cycle of 60 seconds, that is, the loop detection task is woken up once every 60 seconds to perform deadlock detection.

[0072] Specifically, prior to step S101, the method further includes:

[0073] Create the suspended queue.

[0074] In one possible implementation, the suspension queue is a sorted queue, in which sleep tasks are stored in the order in which they failed to acquire the target mutex lock; in an optional implementation, they are arranged according to the order in which the sleep tasks start sleeping.

[0075] Specifically, the information corresponding to the suspend queue includes a parameter variable, which is used to store the number of sleep tasks in the suspend queue. This parameter variable is created during RTOS initialization and is a global variable. When the number of sleep tasks in the RTOS changes, this parameter variable also changes accordingly. The initial value of this global variable is 0.

[0076] Specifically, the suspend queue is a dynamic queue. In an RTOS, when a task fails to acquire a mutex, it is stored as a sleeping task in the suspend queue. When a sleeping task acquires the mutex, it is awakened and removed from the suspend queue. Therefore, for a task in an RTOS, before step S101, such as... Figure 2 As shown, the method further includes:

[0077] S202, Run the task so that the task acquires the corresponding target mutex lock.

[0078] If the task successfully acquires the target mutex, the holder of the target mutex is set to the task's task identifier, indicating that the target mutex is being held by the task. Information about the task can be obtained through the task's task identifier. Furthermore, the task can run normally without sleeping or being stored in the pending queue.

[0079] S204, when the task fails to acquire the target mutex lock, the task is marked as a sleeping task and the sleeping task is added to the suspension queue.

[0080] Specifically, in this step, when the task fails to acquire the target mutex lock, the method further includes:

[0081] The corresponding sleep start time is stored in the sleep time information of the sleep task;

[0082] The information of the corresponding target mutex is stored in the information of the sleep task.

[0083] In this embodiment, the information of the time node when the task failed to acquire the sleep start time is added to the member sleep time information of the task. In this embodiment, the sleep task can be stored in the suspension queue according to the sleep start time. The information of the target mutex is stored in the member blocking object information of the sleep task to associate the sleep task with the target mutex. When the sleep task is the target task, the target mutex corresponding to the target task can be easily acquired in step S103.

[0084] In addition, for the target mutex, when the task fails to acquire it, the sleeping task is added to the waiting queue of the target mutex to associate the target mutex with the sleeping task.

[0085] Finally, the task is put into a sleep state. At this point, the task is a sleeping task, completing the process of acquiring the target mutex lock.

[0086] Specifically, in one possible implementation, after step S204, the method further includes:

[0087] S206, Update the parameter variables according to the sleep task.

[0088] That is, when the sleep task is stored in the suspension queue, the corresponding parameter variable used to record the number of sleep tasks in the suspension queue will also be updated accordingly, incremented by one based on the original value, to obtain the parameter variable that matches the current suspension queue, with good accuracy; for example, when the original value is the initial value of 0, after adding a sleep task, the value of the parameter variable is updated to 1.

[0089] Specifically, such as Figure 3 As shown, step S1, which involves retrieving the target task from the suspended queue, includes:

[0090] S301, Obtain the sleep time information and sorting position information corresponding to each of the multiple sleep tasks.

[0091] Among them, the sleep time information can be directly obtained from the task control information of the corresponding sleep task; while the sorting position information includes the sorting position of the sleep task in the suspension queue, which is obtained from the information corresponding to the suspension queue; in an optional implementation, the sorting position information can be the sorting sequence number of the sleep task in the suspension queue.

[0092] S303, based on the multiple sleep time information, perform a first screening process on the multiple sleep tasks to obtain multiple target sleep tasks.

[0093] RTOS systems have extremely high real-time requirements. Therefore, when detecting deadlock, priority is given to sleep tasks with earlier sleep start times. First, based on the sleep time information of each sleep task, a first screening process is performed in the suspension queue to obtain the target sleep task. The sleep start time of the target sleep task is earlier than that of the non-target sleep tasks.

[0094] S305, according to the sorting position information, a second filtering process is performed on multiple target sleep tasks to obtain the target tasks.

[0095] In each deadlock detection process, only a single target task can be judged and detected. Deadlock detection of the next target task can only be carried out after the detection of the target task is completed. In the target sleep task, the second screening process is carried out to select the target sleep task with the earliest sleep start time as the target task.

[0096] In an optional implementation, this step can be selected as further filtering multiple target sleep tasks based on sleep time information to obtain target tasks.

[0097] In another optional implementation, the suspended queue is already a sorted queue. Sleep tasks with earlier start times are sorted earlier, while sleep tasks with later start times are sorted later. Therefore, the target sleep task with the first sorted position can be identified as the target task based on the sorted position of each target sleep task. When performing duplicate detection in subsequent iterations of the suspended queue, the target sleep task located one sorted position after the target task (or the sorted number of the target task plus one) is taken as a new target task, and the loop detection continues. This process is repeated to complete the deadlock detection process (i.e., one detection cycle) for one suspended queue.

[0098] Specifically, in one possible implementation, such as Figure 4 As shown, step S303 includes:

[0099] S402, Get the current time point.

[0100] In an optional implementation, this step can be performed before step S101, or the current time point can be obtained after receiving the detection start command.

[0101] S404, based on the current time point and the multiple sleep start times, obtain the sleep duration corresponding to the multiple sleep tasks.

[0102] S406, based on a preset duration and multiple sleep durations, perform the first filtering process on multiple sleep tasks to obtain multiple target sleep tasks.

[0103] When the sleep duration of a sleep task is greater than or equal to the preset duration, the sleep task is considered to meet the screening criteria of the first screening process, and is included in the deadlock detection range as one of the target sleep tasks, and the S305 step continues to be executed; however, for sleep tasks with a sleep duration less than the preset duration, the sleep time is too short and will not have a significant impact on the overall stability and real-time performance of the RTOS system, so it can be temporarily ignored. In subsequent detection cycles, its sleep duration will increase with the change of the current time point, and then the judgment on whether to include it in the deadlock detection range will be re-evaluated based on the sleep duration.

[0104] In other words, within a detection cycle, the deadlock detection method of the present invention does not need to perform deadlock detection on all sleep tasks, but only on sleep tasks with longer sleep durations. Some sleep tasks with shorter sleep durations can be excluded from the deadlock detection scope, saving time and computing power, and improving real-time performance.

[0105] The preset duration can be set according to the actual situation. The preset duration can be a specific value, such as 120 seconds, or a range of values, such as 120 to 600 seconds. This invention does not make a specific limitation on this.

[0106] Specifically, such as Figure 5 As shown, before step S103, that is, before acquiring the target mutex lock corresponding to the target task, the method further includes:

[0107] S501, Obtain the sorting position information of the target task in the suspended queue.

[0108] In one possible implementation, this step is a sub-step of step S301. When obtaining the sorting position information of each sleep task in step S301, the sorting position information of the target task can be obtained directly without having to obtain it again, thus further improving detection efficiency.

[0109] S503, when the parameter variable and the sorting position information meet the preset conditions, execute the step of obtaining the target mutex lock corresponding to the target task.

[0110] In one possible implementation, if the value of the parameter variable is always greater than or equal to the sorting number, the preset condition can be selected as the difference between the parameter variable and the sorting number being greater than or equal to a preset threshold. When this preset condition is met, it means that the target task belongs to the deadlock detection range, and step S103 is executed to acquire the target mutex lock. The preset threshold can be selected as 1, that is, when the difference between the parameter variable and the sorting number of the target task is greater than or equal to 1, step S103 is executed. Correspondingly, in an optional implementation, the preset condition can be that the sorting position of the target task is not the last one in the suspended queue, and the sleep task with the shortest sleep duration is removed from the range of target sleep tasks, that is, the deadlock detection range is further narrowed and the time consumption is further reduced.

[0111] Furthermore, when the parameter variables and sorting position information do not meet the preset conditions, the target task continues to sleep for one cycle until it is awakened in the next detection cycle and performs the deadlock detection steps S101 to S107 again.

[0112] Specifically, within a detection cycle, the target task is updated as the detection progresses. Therefore, before step S103, the method further includes:

[0113] Determine whether the target task exists.

[0114] If the target task exists, execute step S103 to acquire the target mutex lock corresponding to the target task; if the target task does not exist, it means that all target sleeping tasks in the suspended queue have been detected, that is, the suspended queue has been traversed, and the sleeping task continues to remain in the sleeping state. The detection cycle ends, and no deadlock is detected in the RTOS.

[0115] Specifically, after step S103, the method further includes:

[0116] Determine whether the target mutex lock exists.

[0117] If the target mutex exists, proceed to step S105 to obtain the holder of the target mutex; if the target mutex does not exist, it means that the target task is not blocked, so the sleep task continues to remain in the sleep state, and the current detection cycle ends.

[0118] As can be seen from the above embodiments, the deadlock detection method in the embodiments of the present invention has the following beneficial effects:

[0119] 1. This invention is based on a suspended queue for detection. By detecting whether the holder of the target mutex lock that the target task wants to acquire also exists in the suspended queue, deadlocks in the RTOS can be detected in real time. This realizes semi-circular detection of AB-BA type deadlocks, which has high detection efficiency and low time consumption. It can greatly improve the real-time performance of deadlock detection methods, thereby helping to improve the operational stability and real-time performance of the RTOS.

[0120] 2. The detection target of this invention is the target task in the suspended queue. It does not need to detect all sleeping tasks in the suspended queue, but only the target task that has been sleeping for more than a preset time, which further improves the detection efficiency and the real-time performance of the deadlock detection method.

[0121] Corresponding to the deadlock detection method provided in this embodiment, this embodiment of the invention also provides a deadlock detection device. Since the deadlock detection device provided in this embodiment of the invention corresponds to the deadlock detection methods provided in the above-mentioned embodiments, the implementation methods of the aforementioned deadlock detection methods are also applicable to the deadlock detection device provided in this embodiment, and will not be described in detail in this embodiment.

[0122] The deadlock detection device provided in this embodiment of the invention can implement the deadlock detection method in the above method embodiments, as shown in the appendix to the specification. Figure 6 As shown, the device may include:

[0123] The first acquisition module 610 is used to acquire the target task in the pending queue;

[0124] The second acquisition module 620 is used to acquire the target mutex lock corresponding to the target task;

[0125] The third acquisition module 630 is used to acquire the holder of the target mutex lock;

[0126] The detection module 640 is used to generate deadlock detection information when the holder exists in the suspended queue; the deadlock detection information indicates that a deadlock exists in the system.

[0127] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0128] The deadlock detection device of this invention iterates through the target tasks in the suspension queue whose sleep duration exceeds a preset duration, acquires the corresponding target mutex lock according to the target task, and then obtains the holder of the target mutex lock. When it is determined that the holder also exists in the suspension queue, it is considered that a deadlock exists in the RTOS, and deadlock detection information is generated so that the system can allocate resources according to the deadlock detection information. This deadlock detection device can realize semi-circular detection of AB-BA type deadlock, with high detection efficiency and low time consumption, which is beneficial to improving the real-time performance of the RTOS.

[0129] This invention also provides an electronic device, including a processor and a memory. The processor (or CPU (Central Processing Unit)) is the core component of the deadlock detection device. Its main functions are to interpret memory instructions and process data fed back by various monitoring modules or acquisition modules. The processor's structure is roughly divided into an arithmetic logic unit and a register unit. The arithmetic logic unit mainly performs related logical calculations (such as shift operations, logical operations, fixed-point or floating-point arithmetic operations, and address operations), while the register unit is used to temporarily store instructions, data, and addresses.

[0130] A memory is a storage device used to store software programs and modules. A processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, including but not limited to Windows, Linux, etc., which are not limited in this invention. Furthermore, it may store application programs required for functions. For example, the memory storage space may also contain at least one instruction suitable for loading and execution by the processor; these instructions may be one or more computer programs (including program code). The data storage area may store data created based on the use of the device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0131] This invention also provides a storage medium storing at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the deadlock detection method described above. Optionally, the storage medium may be located in at least one of multiple network servers in a computer network. Furthermore, the storage medium may include, but is not limited to, random access memory (RAM), read-only memory (ROM), USB flash drive, portable hard drive, disk storage device, flash memory device, other volatile solid-state storage devices, and other storage media capable of storing program code.

[0132] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0133] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0134] The above description is merely some embodiments of the present invention and is not intended to limit the present invention. Those skilled in the art should understand that the present invention can have various changes and modifications, and any modifications, equivalent substitutions and improvements made in accordance with the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A deadlock detection method, characterized by, include: Retrieve the target task from the pending queue; The information corresponding to the suspended queue includes parameter variables, which are used to store the number of sleeping tasks in the suspended queue; Obtain the target mutex lock corresponding to the target task; Find the holder of the target mutex lock; When the holder exists in the suspended queue, deadlock detection information is generated; The deadlock detection information indicates that a deadlock exists in the system. The suspended queue includes multiple sleeping tasks, and obtaining the target task in the suspended queue includes: Obtain the sleep time information and sorting position information corresponding to each of the multiple sleep tasks; the sleep time information includes the sleep start time and acquisition failure time node corresponding to each of the multiple sleep tasks; the sorting position information is the sorting sequence number of the multiple sleep tasks in the suspension queue. Based on multiple sleep time information, a first screening process is performed on multiple sleep tasks to obtain multiple target sleep tasks; Based on the sorting position information, a second filtering process is performed on multiple target sleep tasks to obtain the target tasks; Before acquiring the target mutex lock corresponding to the target task, the method further includes: When the parameter variable and the sorting position information of the target task in the suspended queue meet the preset conditions, the step of obtaining the target mutex lock corresponding to the target task is executed.

2. The deadlock detection method according to claim 1, characterized in that, The sleep time information includes the sleep start time of the sleep task. The first filtering process, based on multiple pieces of sleep time information, to obtain multiple target sleep tasks includes: Get the current time point; Based on the current time point and multiple sleep start times, the sleep duration corresponding to multiple sleep tasks is obtained; Based on a preset duration and multiple sleep durations, the first filtering process is performed on multiple sleep tasks to obtain multiple target sleep tasks.

3. The deadlock detection method according to claim 1, characterized in that, Before retrieving the target task from the pending queue, the method further includes: Create the suspension queue, which is used to store information about sleep tasks waiting to acquire the target mutex lock.

4. The deadlock detection method according to claim 1, characterized in that, Before retrieving the target task from the pending queue, the method further includes: Run the task so that the task acquires the corresponding target mutex lock; When the task fails to acquire the target mutex lock, the task is marked as a sleeping task and added to the suspended queue.

5. The deadlock detection method according to claim 4, characterized in that, When the task fails to acquire the target mutex lock, the method further includes: The corresponding sleep start time is stored in the sleep time information of the sleep task; The information of the corresponding target mutex is stored in the information of the sleep task.

6. The deadlock detection method according to claim 1, characterized in that, After marking the task as a sleeping task and adding the sleeping task to the suspension queue when the task fails to acquire the target mutex lock, the method further includes: Update the parameter variables based on the sleep task.

7. A deadlock detection device, characterized in that, include: The first acquisition module is used to acquire target tasks in the pending queue; The information corresponding to the suspended queue includes parameter variables, which are used to store the number of sleeping tasks in the suspended queue; The second acquisition module is used to acquire the target mutex lock corresponding to the target task; The third acquisition module is used to acquire the holder of the target mutex lock; The detection module is used to generate deadlock detection information when the holder exists in the suspended queue; the deadlock detection information indicates that a deadlock exists in the system. The deadlock detection device is specifically used for: Obtain sleep time information and sorting position information corresponding to each of the multiple sleep tasks; the sleep time information includes the sleep start time and acquisition failure time node corresponding to each of the multiple sleep tasks; the sorting position information is the sorting sequence number of the multiple sleep tasks in the suspension queue; based on the multiple sleep time information, perform a first filtering process on the multiple sleep tasks to obtain multiple target sleep tasks; based on the sorting position information, perform a second filtering process on the multiple target sleep tasks to obtain the target task; Obtain the sorting position information of the target task in the suspended queue; When the parameter variable and the sorting position information meet the preset conditions, the process of obtaining the target mutex lock corresponding to the target task is executed.

Images