JP7757657B2 - Deadlock analysis support device, deadlock analysis support method, and deadlock analysis support program - Google Patents

Description

The present invention relates to a deadlock analysis support device, a deadlock analysis support method, and a deadlock analysis support program.

Large-scale computer systems run a large number of threads (also called tasks or processes) that share a large number of information processing resources. When using a certain information processing resource, each thread typically acquires a lock on that resource, thereby providing exclusive control over access to that resource by other threads. In such computer systems, deadlocks can occur, where multiple threads each have acquired locks on different information processing resources and are waiting for the other threads to release their locks, causing processing to halt. Therefore, there is a need for technology that can quickly and accurately detect the occurrence of such deadlocks.

In relation to this technology, Patent Document 1 discloses a device for determining the state of access contention for a shared resource. This device detects characteristic quantities obtained in relation to the acquisition of access rights to a shared resource, and determines the state of access contention for the shared resource based on these characteristic quantities.

Patent document 2 also discloses a device that performs a deadlock check after an appropriate delay time has elapsed. This device measures the lock time during which a resource is locked by a task, and determines the delay time based on the measured lock time. This device then performs a deadlock check when the time that the task has been in a waiting state exceeds the support time.

Patent document 3 also discloses a system that uses an event-driven method to detect the occurrence of deadlocks in a node. This system registers the resource lock acquisition status of individual threads in a lock status table, and detects the occurrence of a deadlock based on the lock acquisition request from the thread and the lock acquisition status registered in the lock status table.

Patent document 4 also discloses a real-time OS (Operating System) that detects deadlock states without affecting application programs. This OS has a management table for detecting deadlock states caused by multiple tasks sharing a shared resource. This OS records in the management table information about tasks that have transitioned to a state waiting to acquire a shared resource, as well as information about tasks currently acquiring the shared resource that are causing the task to enter a waiting state.

WO 2009/123343 Japanese Patent Application Laid-Open No. 2018-101343 JP 2009-271858 A Japanese Patent Application Laid-Open No. 2004-341878

Countermeasures against deadlocks include, for example, monitoring for deadlock occurrences. If a state that suggests a deadlock has occurred is detected, the deadlock is resolved by releasing the lock on the information processing resource or canceling the lock wait state. System logs are typically collected to analyze the cause of the deadlock. In this case, if there are few log collection points, it becomes difficult to identify suspected deadlock-related areas. Furthermore, if there are many log collection points, the volume of collected logs becomes enormous, especially in large-scale systems. This increases the impact on system operation due to the long log collection time, and also increases the burden on users due to analyzing the vast amount of logs. Therefore, the challenge is to efficiently provide information that accurately supports users in analyzing the cause of deadlocks. The technologies described in Patent Documents 1 to 4 above cannot be said to be sufficient to solve this problem.

The primary objective of the present invention is to provide a deadlock analysis support device that efficiently provides information that accurately supports users in analyzing the causes of deadlocks.

A deadlock analysis support device according to one aspect of the present invention comprises: management means for managing lock state information representing the lock state of a locked resource used by each unit information process executed on an information processing device; detection means for detecting whether the lock state represented by the lock state information satisfies predetermined detection criteria indicating the possibility of a deadlock occurring; and output means for outputting the lock state information when the lock state satisfies the predetermined detection criteria.

In another aspect of achieving the above object, a deadlock analysis support method according to one aspect of the present invention manages, by an information processing device, lock state information representing the lock state of a locked resource used by each unit information processing executed on the information processing device, detects whether the lock state represented by the lock state information satisfies predetermined detection criteria indicating the possibility of a deadlock occurring, and outputs the lock state information if the lock state satisfies the predetermined detection criteria.

In addition, in a further aspect of achieving the above object, a deadlock analysis support program according to one aspect of the present invention causes an information processing device to execute, for each unit information processing executed on the information processing device, a management process for managing lock state information representing the lock state of a locked resource used by the unit information processing; a detection process for detecting whether the lock state represented by the lock state information satisfies predetermined detection criteria indicating the possibility of a deadlock occurring; and an output process for outputting the lock state information when the lock state satisfies the predetermined detection criteria.

Furthermore, the present invention can also be realized by a computer-readable, non-volatile recording medium on which such a deadlock analysis support program (computer program) is stored.

The present invention provides a deadlock analysis support device that efficiently provides information that accurately supports users in analyzing the causes of deadlocks.

1 is a block diagram showing a configuration of a deadlock analysis support device 10 according to a first embodiment of the present invention. FIG. 2 is a diagram illustrating data of a lock status table 111 according to the first embodiment of the present invention. 1 is a flowchart showing an operation of the deadlock analysis support device 10 according to the first embodiment of the present invention when an AP thread 100 secures a lock on a lock target resource 103. 4 is a flowchart showing an operation of the deadlock analysis support device 10 according to the first embodiment of the present invention when an AP thread 100 releases a lock on a lock target resource 103. FIG. 3 is a diagram illustrating data in a lock status reference table 112 according to the first embodiment of the present invention. 1 is a flowchart (1/2) showing the operation of the deadlock analysis support device 10 according to the first embodiment of the present invention to detect the possibility of a deadlock occurring and output data of the lock status table 111. 10 is a flowchart (2/2) showing the operation of the deadlock analysis support device 10 according to the first embodiment of the present invention to detect the possibility of a deadlock occurring and output data of the lock status table 111. 1 is a flowchart showing an operation of the deadlock analysis support device 10 according to the first embodiment of the present invention, analyzing the occurrence status of a deadlock from data in the lock state table 111. FIG. 10 is a block diagram showing a configuration of a deadlock analysis support device 30 according to a second embodiment of the present invention. FIG. 9 is a block diagram showing a configuration of an information processing device 900 capable of realizing a deadlock analysis support device according to each embodiment of the present invention.

Embodiments of the present invention will be described in detail below with reference to the drawings.

First Embodiment
1 is a block diagram showing the configuration of a deadlock analysis support device 10 according to a first embodiment of the present invention. The deadlock analysis support device 10 is included in an information processing device 900, which will be described later with reference to FIG. 9, for example, and is a device that provides analytical support for deadlocks that occur in the information processing device 900. Alternatively, the deadlock analysis support device 10 may provide analytical support for deadlocks that occur in an information processing device other than the deadlock analysis support device 10 itself.

An information processing device including the deadlock analysis support device 10 executes AP (Application) threads 100-1 to 100-3, etc. The number of AP threads executed by the information processing device is arbitrary. In this embodiment, hereafter, AP threads 100-1 to 100-3, etc., may be collectively referred to as an AP thread 100, or at least one of them. An AP thread 100 is an information processing unit generated when the information processing device executes an application program, and is also referred to as a task or process.

AP thread 100 uses locked resources 103-1 to 103-3, which are information processing resources included in the information processing device. The information processing device may include any number of locked resources. In this embodiment, hereafter, locked resources 103-1 to 103-3, etc., may be collectively referred to as locked resources 103, or at least one of them may be referred to as locked resources 103. Locked resources 103 are devices with specific information processing functions that require exclusive control regarding access from multiple AP threads 100.

When AP thread 100-1 uses lock target resource 103-1, for example, it acquires a lock on lock target resource 103-1 via lock acquisition unit 101. If lock target resource 103-1 is already locked by AP thread 100-2, for example, AP thread 100-1's lock on lock target resource 103-1 is held in a wait state until AP thread 100-2 releases the lock. After acquiring the lock on lock target resource 103-1, AP thread 100-1 begins using lock target resource 103-1. After finishing using lock target resource 103-1, AP thread 100-1 releases the lock on lock target resource 103-1 via lock release unit 102. The lock acquisition unit 101 and lock release unit 102 are executed by calling, for example, an API (Application Programming Interface). The API is, for example, a system call such as mutex, or a lock acquisition function provided by a software product.

A terminal device 20 is communicatively connected to the deadlock analysis support device 10. The terminal device 20 is, for example, an information processing device such as a personal computer. The terminal device 20 accepts user input operations related to information to be input to the deadlock analysis support device 10, and displays information output from the deadlock analysis support device 10 on a display screen (not shown) provided with the terminal device 20.

The deadlock analysis support device 10 includes a management unit 11, a detection unit 12, an output unit 13, and an analysis unit 14. The management unit 11, the detection unit 12, the output unit 13, and the analysis unit 14 are examples of a management means, a detection means, an output means, and an analysis means, respectively.

In this embodiment, we will first explain the operation of the deadlock analysis support device 10, which manages the lock status of the AP thread 100 on the lock target resource 103. Next, we will explain the operation of the deadlock analysis support device 10, which detects the possibility of a deadlock occurring, outputs information indicating the lock status of the AP thread 100 on the lock target resource 103, and further analyzes the deadlock occurrence situation.

<Operation of managing the lock state of the AP thread 100 for the lock target resource 103>
The management unit 11 manages, for each AP thread 100 , information indicating the lock state of the lock target resource 103 used by the AP thread 100 by updating the lock state table 111 .

Figure 2 is a diagram illustrating data in the lock status table 111 according to this embodiment. As illustrated in Figure 2, the lock status table 111 indicates, for each of the lock target resources 103, the identifier of the AP thread 100 that secured the lock and the time the lock was secured. According to the lock status table 111 illustrated in Figure 2, the lock target resource 103-1 is locked by AP thread 100-1, and the time the lock was secured is time A. The lock target resource 103-2 is locked by AP thread 100-2, and the time the lock was secured is time B. The lock target resource 103-3 is locked by AP thread 100-2, and the time the lock was secured is time C.

Furthermore, the lock status table 111 represents the "state," "lock request time," "lock acquisition time," "lock release time," "number of lock requests," "accumulated acquisition wait time," "accumulated lock acquisition time," and "label" for each combination of lock target resource 103 and AP thread 100. Of these items, the lock status table 111 must include the "state," "lock request time," "lock acquisition time," and "lock release time" that are necessary to detect the possibility of a deadlock occurring. The lock status table 111 may also include the "number of lock requests," "accumulated acquisition wait time," "accumulated lock acquisition time," and "label" that are necessary for analyzing performance issues, etc., as needed. Note that the specifications of the lock status table 111 are not limited to those illustrated in FIG. 2, and the lock status table 111 may include items other than those illustrated in FIG. 2.

The "state" in the lock state table 111 indicates one of "lock secured," "waiting for lock to be secured," and "no lock requested" for the AP thread 100 and the lock target resource 103. The lock state table 111 illustrated in FIG. 2 indicates, for example, that for AP thread 100-1, a lock has been secured for lock target resource 103-1, a lock is waiting to be secured (requesting) for lock target resource 103-2, and no lock has been requested for lock target resource 103-3. The lock state table 111 illustrated in FIG. 2 indicates, for example, that for AP thread 100-2, a lock is waiting to be secured for lock target resource 103-1, a lock has been secured for lock target resource 103-2, and a lock has been secured for lock target resource 103-3.

The "lock request time" in the lock status table 111 indicates the time at which the AP thread 100 requested a lock on the lock target resource 103. According to the lock status table 111 illustrated in FIG. 2, for example, the time at which the AP thread 100-1 requested a lock on the lock target resource 103-1 was time D (however, time D is assumed to be a time earlier than time A), and the time at which the AP thread 100-1 requested a lock on the lock target resource 103-2 was time G.

The "lock release time" in the lock status table 111 represents the time when the AP thread 100 released the lock on the locked resource 103. In the example shown in Figure 2, since the AP thread 100-1 is currently locking the locked resource 103-1, no value is set in the lock status table 111 for the time when the AP thread 100-1 released the lock on the locked resource 103-1.

The "Lock Request Count" in the lock status table 111 represents the cumulative number of times that the AP thread 100 has requested a lock on the lock target resource 103. According to the lock status table 111 illustrated in FIG. 2, for example, the number of times that the AP thread 100-1 has requested a lock on the lock target resource 103-1 is one.

The "accumulated wait time for locking" in the lock status table 111 represents the accumulated time from when the AP thread 100 requests a lock on the lock target resource 103 until the lock is secured. According to the lock status table 111 illustrated in FIG. 2, for example, the accumulated time until the AP thread 100-1 secures a lock on the lock target resource 103-1 is time E.

The "Lock Acquisition Accumulative Time" in the lock status table 111 represents the accumulated time that the AP thread 100 has acquired a lock on the lock target resource 103. According to the lock status table 111 illustrated in FIG. 2, for example, the accumulated time that the AP thread 100-1 has acquired a lock on the lock target resource 103-1 is time F.

The "label" in the lock state table 111 is information that indicates the location in the application program that created the AP thread 100 where a lock was requested for the lock target resource 103 (where the API was called), and is information that the user optionally assigns to the application program so that the operation of the application program can be analyzed. According to the lock state table 111 illustrated in Figure 2, for example, the location in the application program where AP thread 100-1 called to lock the lock target resource 103-1 is the location represented as "label X."

Next, with reference to the flowcharts in Figures 3 and 4, the operation (processing) of the deadlock analysis support device 10 according to this embodiment to manage the lock state of the AP thread 100 on the lock target resource 103 will be described in detail.

Figure 3 is a flowchart showing the operation of the deadlock analysis support device 10 to manage the lock state when the AP thread 100 secures a lock on the lock target resource 103.

The lock acquisition unit 101 calls and executes the API for a lock request by AP thread 100-i (i is any natural number) for lock target resource 103-j (j is any natural number) (step S101). The management unit 11 updates the status of the entry for AP thread 100-i's lock target resource 103-j in the lock status table 111 to "Waiting for lock to be secured," updates the lock request time to the current time, and increments the number of lock requests by one (step S102).

If the lock target resource 103-j is locked by an AP thread 100 other than AP thread 100-i (Yes in step S103), processing returns to step S103. If the lock target resource 103-j is not locked by an AP thread 100 other than AP thread 100-i (No in step S103), the lock acquisition unit 101 executes an API for AP thread 100-i to secure a lock on the lock target resource 103-j (step S104).

In the entry for the locked resource 103-j of AP thread 100-i in the lock status table 111, the management unit 11 updates the status to "lock secured," updates the lock acquisition time to the current time, and updates the cumulative wait time to the sum of the difference between the lock acquisition time and the lock request time. The management unit 11 also updates the entry for the locked resource 103-j in the lock status table 111 to "locked by AP thread 100-i," and updates the lock acquisition time to the current time (step S105), and the entire process ends.

Figure 4 is a flowchart showing the operation of the deadlock analysis support device 10 to manage the lock state when the AP thread 100 releases the lock on the locked resource 103.

The lock release unit 102 calls and executes the API for AP thread 100-i to release the lock on resource 103-j (step S201). The management unit 11 updates the status in the lock status table 111 for the lock target resource 103-j of AP thread 100-i to "no lock request," updates the lock release time to the current time, and updates the cumulative lock acquisition time to the value obtained by adding the difference between the lock release time and the lock acquisition time. The management unit 11 also updates the entry for resource 103-j in the lock status table 111 to "no lock request" (step S202), and the entire process ends.

<Operations for detecting the possibility of a deadlock occurring, outputting information indicating the lock status of the AP thread 100 on the lock target resource 103, and analyzing the occurrence of a deadlock>
Next, the operation of the deadlock analysis support device 10 to detect the possibility of a deadlock occurring, output information indicating the lock state of the AP thread 100 on the lock target resource 103, and analyze the state of deadlock occurrence will be described.

The management unit 11 manages the lock state reference table 112 that the deadlock analysis support device 10 references when detecting the possibility of a deadlock occurring.

Figure 5 is a diagram illustrating data in the lock state reference table 112 according to this embodiment. As illustrated in Figure 5, the lock state reference table 112 indicates the time at which any AP thread 100 secured a lock for each of the locked resources 103 indicated in the lock state table 111 the last time the deadlock analysis support device 10 determined the possibility of a deadlock occurring. However, the deadlock analysis support device 10 performs the operation of determining the possibility of a deadlock occurring, for example, at predetermined time intervals. Alternatively, the deadlock analysis support device 10 may perform the operation of determining the possibility of a deadlock occurring when, for example, it receives information from the terminal device 20 input by the user instructing it to determine the possibility of a deadlock occurring. The lock state reference table 112 illustrated in Figure 5 indicates that the lock secured times at the time of the previous reference, as described above, for the locked resources 103-1 to 103-3 are time P, time Q, and time R, respectively.

When the deadlock analysis support device 10 determines the possibility of a deadlock occurring, the management unit 11 checks whether the lock acquisition time differs between the lock status table 111 and the lock status reference table 112 for each of the locked resources 103. If the lock acquisition time differs between the lock status table 111 and the lock status reference table 112, the management unit 11 updates the lock acquisition time in the lock status reference table 112 to the lock acquisition time in the lock status table 111.

In this case, the lock acquisition time for the locked resource 103 has been updated (i.e., a new lock has been acquired) since the deadlock analysis support device 10 last determined the possibility of a deadlock occurring, so it is considered unlikely that a deadlock has occurred. Therefore, in this case, the deadlock analysis support device 10 does not perform the operation of detecting the possibility of a deadlock using the detection unit 12 described below, but waits until the next time it detects the possibility of a deadlock occurring (stops the operation of detecting the possibility of a deadlock occurring). If the lock acquisition time matches between the lock state table 111 and the lock state reference table 112 for each locked resource 103, the deadlock analysis support device 10 performs the operation of detecting the possibility of a deadlock using the detection unit 12 described below.

The detection unit 12 checks whether the lock state of the locked resource 103 represented by the lock state table 111 satisfies the detection criteria 120, which indicate the possibility of a deadlock occurring. However, the detection unit 12 assumes that the detection criteria 120 have been provided in advance, for example, by the user.

The detection criterion 120 indicates that a deadlock may have occurred, for example, when the lock status table 111 indicates that a lock is waiting to be secured for at least one AP thread 100 and a lock target resource 103, and the difference between the current time and the lock request time is greater than or equal to a threshold value.

When the detection unit 12 detects that a deadlock may have occurred between at least one AP thread 100 and a locked resource 103, it outputs the data in the lock status table 111 and the identifier of the locked resource 103 to the output unit 13 as a detection result of the possibility of a deadlock having occurred.

The output unit 13 outputs the detection result of the possibility of deadlock occurrence input from the detection unit 12 to the analysis unit 14. The output unit 13 also transmits the detection result to the terminal device 20. The terminal device 20 displays the detection result received from the detection unit 12 on a display screen provided therein. The output unit 13 may output a file representing the detection result.

After the detection unit 12 detects that a deadlock may have occurred for a certain locked resource 103, the deadlock analysis support device 10 waits before detecting the possibility of a deadlock occurring for that locked resource 103 until the lock acquisition time at the previous reference in the lock state reference table 112 and the lock acquisition time in the lock state table 111 no longer match. In other words, the deadlock analysis support device 10 waits before detecting the possibility of a deadlock occurring for that locked resource 103 until one of the AP threads 100 acquires a new lock for that locked resource 103.

When a new lock is acquired by one of the AP threads 100 for the locked resource 103, the deadlock analysis support device 10 causes the management unit 11 to update the lock acquisition time from the previous reference in the lock state reference table 112 to the lock acquisition time in the lock state table 111 updated by the new lock. The deadlock analysis support device 10 then resumes operation to detect the possibility of a deadlock occurring for the locked resource 103.

The analysis unit 14 analyzes the lock status of the locked resource 103 being analyzed by comparing the data in the lock status table 111 output from the output unit 13 and the identifier of the locked resource 103 with the analysis criteria 140. The analysis unit 14 transmits the analysis results to the terminal device 20 via the output unit 13. The terminal device 20 displays the analysis results received from the output unit 13 on its display screen.

The analysis unit 14 checks the data in the lock status table 111 to see if at least one AP thread 100 has requested a new lock on a locked resource 103 before releasing a lock on that locked resource 103 for which it has already secured a lock. The analysis unit 14 performs the above-mentioned check, for example, from the chronological relationship between the lock request time, lock acquisition time, and lock release time shown in the lock status table 111. If the lock status table 111 shows the above-mentioned situation, the analysis unit 14 outputs, via the output unit 13, an analysis result indicating that a multiple lock has occurred on the locked resource 103 by the AP thread 100.

The analysis unit 14 checks the data in the lock status table 111 to see if AP thread 100-j (first unit information process), which has secured a lock on lock target resource 103-i (first lock target resource), is waiting to secure a lock on lock target resource 103-k (second lock target resource). The analysis unit 14 also checks whether AP thread 100-l (second unit information process), which has secured a lock on lock target resource 103-k, is waiting to secure a lock on lock target resource 103-i. If the lock status table 111 indicates the above-mentioned situation, the analysis unit 14 outputs, via the output unit 13, an analysis result indicating that a deadlock has occurred between AP threads 100-j and 100-l and lock target resources 103-i and 103-k. Note that i, j, k, and l are all natural numbers. The output unit 13 may output a file representing the analysis result.

Next, with reference to Figures 6A and 6B and the flowchart in Figure 7, we will explain in detail the operation (processing) of the deadlock analysis support device 10 according to this embodiment, which detects the possibility of a deadlock occurring, outputs information indicating the lock status of the AP thread 100 on the lock target resource 103, and analyzes the deadlock occurrence status.

Figures 6A and 6B are flowcharts showing the operation of the deadlock analysis support device 10 to detect the possibility of a deadlock occurring and output data from the lock status table 111.

If the timing for the deadlock analysis support device 10 to detect the possibility of a deadlock occurring has not yet arrived (No in step S301), processing returns to step S301. That is, the deadlock analysis support device 10 waits until the timing for detecting the possibility of a deadlock occurring arrives. If the timing for the deadlock analysis support device 10 to detect the possibility of a deadlock occurring arrives (Yes in step S301), the detection unit 12 compares the lock acquisition time of the previous reference to the lock status reference table 112 with the lock acquisition time in the lock status table 111 for the locked resource 103 (step S302).

If the lock acquisition times do not match (No in step S303), the management unit 11 updates the lock acquisition time from the previous reference in the lock status reference table 112 to the lock acquisition time in the lock status table 111 (step S304), and processing returns to step S301. If the lock acquisition times match (Yes in step S303), the detection unit 12 checks the lock status table 111 to see if there is an AP thread 100 in the "waiting for lock acquisition" state for the locked resource 103 (step S305).

If there is no AP thread 100-i in the "waiting for lock to be secured" state (No in step S306), processing returns to step S301. If there is an AP thread 100-i in the "waiting for lock to be secured" state (Yes in step S306), the detection unit 12 checks in the lock status table 111 whether the difference between the lock request time and the current time for the lock target resource 103 and the AP thread 100-i is greater than or equal to a threshold (step S307).

If the difference is not greater than or equal to the threshold (No in step S308), processing returns to step S301. If the difference is greater than or equal to the threshold (Yes in step S308), the detection unit 12 outputs the data in the lock status table 111 and the identifier of the locked resource 103 being analyzed as the detection result to the analysis unit 14 and terminal device 20 via the output unit 13 (step S309).

The management unit 11 compares the lock acquisition time of the previous reference in the lock status reference table 112 with the lock acquisition time in the lock status table 111 for the relevant lock target resource 103 (step S310). If the lock acquisition times match (Yes in step S311), processing returns to step S310. If the lock acquisition times do not match (No in step S311), the management unit 11 updates the lock acquisition time of the previous reference in the lock status reference table 112 to the lock acquisition time in the lock status table 111 (step S312), and processing returns to step S301.

Figure 7 is a flowchart showing the operation of the deadlock analysis support device 10 to analyze the occurrence of a deadlock from the data in the lock status table 111.

The analysis unit 14 checks whether at least one AP thread 100 has requested a new lock on the lock target resource 103-i that was the subject of analysis in the detection result by the detection unit 12 before releasing the lock on the lock target resource 103-i for which it had already secured a lock (step S401). If the situation in step S401 applies (Yes in step S402), the analysis unit 14 outputs an analysis result indicating that a multiple lock on the lock target resource 103-i by the AP thread 100 has occurred to the terminal device 20 via the output unit 13 (step S403), and the entire process ends.

If the situation in step S401 does not apply (No in step S402), the analysis unit 14 checks whether AP thread 100-j, which has secured a lock on lock target resource 103-i, is waiting to secure a lock on another lock target resource 103-k, and whether AP thread 100-l, which has secured a lock on lock target resource 103-k, is waiting to secure a lock on lock target resource 103-i (step S404).

If the situation in step S404 does not apply (No in step S405), the entire process ends. If the situation in step S404 applies (Yes in step S405), the analysis unit 14 outputs an analysis result indicating that a deadlock has occurred between AP threads 100-j and 100-l and lock target resources 103-i and 103-k to the terminal device 20 via the output unit 13 (step S406), and the entire process ends.

The deadlock analysis support device 10 according to this embodiment can efficiently provide information that accurately supports the user in analyzing the causes of deadlocks. This is because the deadlock analysis support device 10 manages a lock status table 111 that indicates the lock status of the lock target resources 103 used by the AP thread 100, and outputs data from the lock status table 111 when the lock status table 111 satisfies detection criteria 120 that indicate the possibility of a deadlock occurring.

The following provides a detailed explanation of the effects achieved by the deadlock analysis support device 10 according to this embodiment.

System logs are typically collected to analyze the causes of deadlocks. In this case, if there are few log collection points, it becomes difficult to identify suspected deadlock-related areas. Furthermore, if there are many log collection points, the amount of logs collected becomes enormous, especially in large-scale systems. This not only increases the impact on system operation due to the long log collection time, but also places a heavy burden on users due to the need to analyze the vast amount of logs. Therefore, the challenge is to efficiently provide information that accurately supports users in analyzing the causes of deadlocks.

In response to these issues, the deadlock analysis support device 10 according to this embodiment includes a management unit 11, a detection unit 12, and an output unit 13, and operates as described above with reference to Figures 1 to 7, for example. That is, the management unit 11 manages a lock state table 111 that indicates the lock state of the lock target resource 103 used by each AP thread 100 executed in the information processing device. The detection unit 12 detects whether the lock state indicated by the lock state table 111 satisfies predetermined detection criteria 120, which indicate the possibility of a deadlock occurring. Then, the output unit 13 outputs the information indicated by the lock state table 111 when the lock state satisfies the detection criteria 120.

In other words, when the deadlock analysis support device 10 detects the possibility of a deadlock occurring, it outputs the information represented by the lock status table 111, rather than a commonly collected log that also includes information unrelated to the occurrence of a deadlock. The lock status table 111, as shown in the example of FIG. 2, represents only information related to the occurrence of a deadlock, allowing the user to accurately and efficiently analyze the causes of the deadlock based on the information represented by the lock status table 111. Therefore, the deadlock analysis support device 10 can efficiently provide information that accurately supports the user in analyzing the causes of the deadlock.

The deadlock analysis support device 10 according to this embodiment also includes an analysis unit 14 that analyzes the lock state by comparing the information represented by the lock state table 111 output when the possibility of a deadlock is detected with predetermined analysis criteria 140, and outputs the analysis results. This allows the user to analyze the cause of the deadlock based on the analysis results from the analysis unit 14. Therefore, the deadlock analysis support device 10 can more accurately support the user in analyzing the cause of the deadlock.

Furthermore, the output unit 13 according to this embodiment may be configured to output the information represented by the lock state table 111 when the user inputs information requesting the output of the information represented by the lock state table 111, even if the lock state represented by the lock state table 111 does not satisfy the detection criteria 120. This allows the deadlock analysis support device 10 to accurately support the user in analyzing the detailed operations of the AP thread 100 generated by the execution of an application program to secure or release a lock on the lock target resource 103.

In addition, the lock status table 111 according to this embodiment includes items such as "number of lock requests," "accumulated wait time for locking," "accumulated lock acquisition time," and "label." This allows the deadlock analysis support device 10 to not only analyze deadlocks, but also assist users in analyzing performance problems caused by locks.

The configuration of the deadlock analysis support device 10 according to this embodiment may also be implemented in a system as a wrap function for an existing locking method. In this case, the deadlock analysis support device 10 can support the analysis of deadlocks that occur between different lock types and locked resources.

Second Embodiment
FIG. 8 is a block diagram showing the configuration of a deadlock analysis support device 30 according to the second embodiment of the present invention.

The deadlock analysis support device 30 includes a management unit 31, a detection unit 32, and an output unit 33. The management unit 31, the detection unit 32, and the output unit 33 are examples of a management means, a detection means, and an output means, respectively.

The management unit 31 manages lock state information 311 that indicates the lock state of the lock target resource 402 used by each unit information process 401 executed in the information processing device 40. The unit information process 401 is a unit of information processing, such as the AP thread 100 according to the first embodiment. The lock target resource 402 is an information processing resource, such as the lock target resource 103 according to the first embodiment. The lock state information 311 is information such as that represented by the lock state table 111 according to the first embodiment. The management unit 31 operates in the same manner as the management unit 11 according to the first embodiment, for example.

The detection unit 32 detects whether the lock state represented by the lock state information 311 satisfies a predetermined detection criterion 320, which indicates the possibility of a deadlock occurring. The detection criterion 320 is, for example, the same as the detection criterion 120 according to the first embodiment. The detection unit 32 operates in the same manner as the detection unit 12 according to the first embodiment, for example.

If the lock state satisfies the detection criteria 320, the output unit 33 outputs lock state information 311. The output unit 33 operates in the same manner as the output unit 13 according to the first embodiment, for example.

The deadlock analysis support device 30 according to this embodiment can efficiently provide information that accurately supports the user in analyzing the causes of deadlocks. This is because the deadlock analysis support device 30 manages lock state information 311 that indicates the lock state of the locked resources 402 used by the unit information process 401, and outputs the lock state information 311 when the lock state information 311 satisfies the detection criteria 320 that indicate the possibility of a deadlock occurring.

<Hardware configuration example>
In each of the above-described embodiments, each unit in the deadlock analysis support device shown in Figures 1 and 8 can be realized by dedicated HW (Hardware) (electronic circuitry). In Figures 1 and 8, at least the following components can be considered as functional (processing) units (software modules) of a software program that includes instructions executed by a processor.
Management units 11 and 31,
detection units 12 and 32,
Output units 13 and 33,
- Analysis section 14.

However, the division of each component shown in these drawings is for the sake of convenience, and various configurations are possible when implementing the system. An example of the hardware environment in this case will be explained with reference to Figure 9.

Figure 9 is a diagram illustrating an exemplary configuration of an information processing device 900 (computer) capable of realizing the deadlock analysis support device according to each embodiment of the present invention. That is, Figure 9 shows the configuration of a computer (information processing device) capable of realizing the deadlock analysis support device shown in Figures 1 and 8, and represents a hardware environment capable of realizing each function in the above-described embodiments.

The information processing device 900 shown in FIG. 9 includes the following components.
・CPU (Central_Processing_Unit) 901,
・ROM (Read_Only_Memory) 902,
・RAM (Random_Access_Memory) 903,
Hard disk (storage device) 904,
communication interface 905,
Bus 906 (communication line),
A reader/writer 908 capable of reading and writing data stored on a recording medium 907 such as a CD-ROM (Compact Disc Read Only Memory),
Input/output interface 909 including a monitor, speaker, keyboard, etc.

In other words, the information processing device 900 having the above components is a general computer in which these components are connected via a bus 906. The information processing device 900 may have multiple CPUs 901, or may have a CPU 901 configured with multiple cores.

The above-described embodiment may also supply a computer program capable of realizing the following functions to the information processing device 900 shown in FIG. 9. For example, the functions are the above-described configurations in the block diagrams (FIGS. 1 and 8) or flowcharts (FIGS. 3, 4, 6A to 7) referred to in the description of the embodiment. The functions of the server or information processing device according to the above-described embodiment are then achieved by reading, interpreting, and executing the computer program into the CPU 901 of the hardware. The computer program supplied to the device may be stored in readable and writable volatile memory (RAM 903) or a non-volatile storage device such as ROM 902 or hard disk 904.

Furthermore, in the above case, the method for supplying the computer program to the hardware can employ currently common procedures. Examples of such procedures include installing the program into the device via a recording medium 907 such as a CD-ROM, or downloading it from an external source via a communications line such as the Internet. In such cases, the computer program supplied to the information processing device according to this embodiment can be considered to be composed of the code that constitutes the program, or the recording medium 907 on which that code is stored.

The present invention has been described above using the above-described embodiment as an exemplary example. However, the present invention is not limited to the above-described embodiment. In other words, the present invention can be applied in various aspects that are understandable to those skilled in the art within the scope of the present invention.

REFERENCE SIGNS LIST 10 Deadlock analysis support device 100 AP thread 101 Lock acquisition unit 102 Lock release unit 103 Lock target resource 11 Management unit 111 Lock state table 112 Lock state reference table 12 Detection unit 120 Detection criteria 13 Output unit 14 Analysis unit 140 Analysis criteria 20 Terminal device 30 Deadlock analysis support device 31 Management unit 311 Lock state information 32 Detection unit 320 Detection criteria 33 Output unit 40 Information processing device 401 Unit information processing 402 Lock target resource 900 Information processing device 901 CPU
902 ROM
903 RAM
904 Hard disk (storage device)
905 Communication interface 906 Bus 907 Recording medium 908 Reader/writer 909 Input/output interface

Claims (8)

a management means for managing lock state information representing a lock state for a lock target resource used by each unit information process executed in the information processing device;
a detection means for detecting whether the lock state represented by the lock state information satisfies a predetermined detection criterion indicating the possibility of a deadlock occurring;
an output means for outputting the lock state information when the lock state satisfies the predetermined detection criterion;
analysis means for analyzing the lock state by comparing the lock state information output from the output means with a predetermined analysis standard and outputting the analysis result;
Equipped with
The lock state information is
The lock information includes information indicating whether the lock has been secured, is waiting to be secured, or has not been requested, the time at which the lock was requested, the time at which the lock was secured, and the time at which the lock was released,
The information may include at least one of the cumulative number of times the lock was requested, the cumulative time required from requesting the lock to securing the lock for one or more locks that were previously performed, the cumulative time required from securing the lock to releasing the lock for one or more locks that were previously performed, and information indicating a part of the program that generated the unit information processing that instructed the lock.
Deadlock analysis support device. the output means outputs the lock state information when information requesting output of the lock state information is input, even if the lock state does not satisfy the predetermined detection criterion.
The deadlock analysis support device according to claim 1 . The predetermined detection criterion is that a deadlock may have occurred when the lock status information indicates that the lock is waiting to be secured for at least one of the unit information processes and the lock target resource, and the difference between the current time and the time when the lock was requested is equal to or greater than a threshold value.
3. The deadlock analysis support device according to claim 1 . The predetermined analysis criterion is that, when the lock state information indicates that at least one of the unit information processes has requested a new lock on the lock target resource before releasing the lock on the lock target resource for which the lock has already been secured, this indicates that a multiple lock has occurred on the lock target resource by the unit information process.
The deadlock analysis support device according to any one of claims 1 to 3 . The predetermined analysis criterion indicates that a deadlock has occurred between the first and second unit information processes and the first and second lock target resources when the lock state information indicates that a first unit information process that has secured the lock on the first lock target resource is waiting to secure the lock on the second lock target resource, and that a second unit information process that has secured the lock on the second lock target resource is waiting to secure the lock on the first lock target resource.
The deadlock analysis support device according to any one of claims 1 to 4 . the management means manages lock state reference information indicating the time at which the lock indicated by the lock state information was secured the last time the detection means referred to the lock state information, and
the detection means detects that the lock state satisfies the predetermined detection criterion when the times at which the lock was secured match between the lock state information and the lock state reference information, and after detecting that the lock state satisfies the predetermined detection criterion, stops detecting that the lock state satisfies the predetermined detection criterion until the times at which the lock was secured no longer match between the lock state information and the lock state reference information.
The deadlock analysis support device according to any one of claims 1 to 5 . By the information processing device,
managing lock state information representing a lock state for a lock target resource used by each unit information process executed in the information processing device;
detecting that the state of the lock represented by the lock state information satisfies a predetermined detection criterion indicating the possibility of a deadlock occurring;
If the lock state satisfies the predetermined detection criterion, output the lock state information;
Analyzing the lock status by comparing the output lock status information with a predetermined analysis standard and outputting the analysis result;
The lock state information is
The lock information includes information indicating whether the lock has been secured, is waiting to be secured, or has not been requested, the time at which the lock was requested, the time at which the lock was secured, and the time at which the lock was released,
The information may include at least one of the cumulative number of times the lock was requested, the cumulative time required from requesting the lock to securing the lock for one or more locks that were previously performed, the cumulative time required from securing the lock to releasing the lock for one or more locks that were previously performed, and information indicating a part of the program that generated the unit information processing that instructed the lock.
A method for supporting deadlock analysis. a management process for managing lock state information representing a lock state for a lock target resource used by each unit information process executed in the information processing device;
a detection process for detecting whether the lock state represented by the lock state information satisfies a predetermined detection criterion indicating the possibility of a deadlock occurring;
an output process for outputting the lock state information when the lock state satisfies the predetermined detection criterion;
an analysis process for analyzing the lock status by comparing the output lock status information with predetermined analysis criteria and outputting the analysis result;
causing the information processing device to execute the above ;
The lock state information is
The lock information includes information indicating whether the lock has been secured, is waiting to be secured, or has not been requested, the time at which the lock was requested, the time at which the lock was secured, and the time at which the lock was released,
The information may include at least one of the cumulative number of times the lock was requested, the cumulative time required from requesting the lock to securing the lock for one or more locks that were previously performed, the cumulative time required from securing the lock to releasing the lock for one or more locks that were previously performed, and information indicating a part of the program that generated the unit information processing that instructed the lock.
A deadlock analysis support program.