JP2009271858A - Computing system and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To shorten a time from fault generation to fault detection and to expand a detectable fault range by detecting the occurrence of a deadlock in a node in an event-driven way. <P>SOLUTION: A cluster system includes a node 10 for executing a plurality of threads sharing resources. The node 10 includes an API hook part 131, a lock state table 133 and a deadlock detection part 134. The API hook part 131 hooks a lock acquisition request for requesting acquisition of a lock for occupying the resources from each of the plurality of threads. In the lock state table 133, an acquisition state of the lock by the plurality of threads is registered on the basis of the lock acquisition request hooked by the API hook part 131. The deadlock detection part 134 detects the occurrence of a deadlock on the basis of the lock acquisition request hooked by the API hook part 131 and the acquisition state of the lock registered in the lock state table 133. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a computer system and a program for detecting a deadlock that occurs in a computer.

  In recent years, for example, a computer system called a high availability cluster system (hereinafter referred to as an HA cluster system) composed of a plurality of nodes (computers) and at least one storage device (shared disk) has been known. Yes. The plurality of nodes constituting the HA cluster system include, for example, an active node and a standby node.

  In the HA cluster system, for example, when a failure occurs in the active node, the standby node takes over the application, shared disk, IP (Internet Protocol) address, etc. that were operating on the active node. The failure can be recovered and the operation in the cluster system can be continued. Hereinafter, a set of takeover units (for example, an application, a shared disk, an IP address, etc.) to be taken over from the active node to the standby node necessary for continuing the functions provided by the HA cluster system are referred to as a service.

  For example, failures that occur in the active node can be roughly classified into two (first failure and second failure). The first failure is a server failure that occurs when the node itself stops, for example, shutdown. The second failure is an application failure that occurs when, for example, an application running on a node malfunctions.

  Each node constituting the above-described HA cluster system is provided with middleware (HA cluster daemon) for managing the HA cluster system. In this HA cluster daemon, since a service is automatically taken over to the standby node when a failure occurs, a mechanism for detecting a failure that occurs in the active node, for example, is required. Hereinafter, the second failure among the first failure and the second failure will be described.

  As a technique for detecting the second failure (application failure) described above, for example, an external command (state monitoring command) for monitoring the state of an application to be monitored (hereinafter referred to as a monitoring target application) is prepared, and an HA cluster is prepared. There is a technique (hereinafter referred to as Prior Art 1) for detecting a failure that has occurred in a monitoring target application by periodically executing the state monitoring command in a daemon. According to this prior art 1, if the return value of the state monitoring command indicates an abnormality, it is detected that a failure has occurred in the monitoring target application. Note that the monitoring target application includes, for example, at least one process, and the process includes one or more threads.

  Incidentally, a deadlock is a typical example of the application failure described above. For example, when one thread of the plurality of threads is executed using the shared resource of the plurality of threads (monitored applications) described above, the thread is the shared resource from another thread different from the thread. Acquire a lock to exclusively control the use (access) of In this case, other threads cannot use the shared resource while the lock is acquired. Further, when the execution of the thread is terminated, the lock acquired by the thread is released. As a result, other threads can use the shared resource.

  In such a case, deadlock means that multiple threads acquire their respective locks and wait for the shared resources that are locked to each other to be held while the locks are acquired. It means that the process stops.

  There is no known technique for directly detecting this application failure deadlock (application deadlock) and failing over the above service.

  As a technique related to the detection of the above-described application deadlock, a technique (hereinafter referred to as Prior Art 2) that can easily and accurately detect a deadlock state without affecting an application program is disclosed (for example, described below). , See Patent Document 1). According to this prior art 2, a deadlock is detected by managing a lock acquisition state in an OS (Operating System).

  In addition, a technology for detecting the possibility of deadlock based on access information to a common resource acquired during a test in which each process constituting a combination of processes that may cause a deadlock is performed separately (hereinafter, the preceding (Referred to as Patent 3). According to the prior art 3, the access order to the shared resources of all processes of the application is recorded in advance, and the possibility of deadlock is detected by matching the records.

As a technique related to deadlock in the cluster system, a technique (hereinafter referred to as Prior Art 4) that shortens the overhead time for information transfer in the cluster system and shortens the time until deadlock detection is disclosed (hereinafter referred to as Prior Art 4). For example, see Patent Document 3). This prior art 4 is a method for detecting a deadlock in a shared resource between nodes in a cluster system. According to the prior art 4, when one lock management node is prepared and access to the shared resource is not permitted, occurrence of a deadlock is detected by requesting a check from the management node.
JP 2004-341878 A JP 2001-229043 A JP 2000-172659 A

  In the above-described prior art 1, a specific failure of an application is detected by, for example, periodic execution of an external state monitoring command.

  For this reason, in the prior art 1, there is no means for directly detecting a deadlock that is a typical failure of an application from the outside. In addition, since the internal implementation of the monitoring target application is often unknown, it is difficult to monitor all the necessary functional failures by executing an external command. Therefore, in the prior art 1, for example, even if an application failure occurs in which a specific function cannot be processed by a deadlock, the deadlock may not be detected.

  In the prior art 1, it may take time until the state can be detected by the state monitoring command even when a deadlock occurs. Further, even if the state can be detected by the state monitoring command, there is a time lag until the next periodic monitoring execution, and it takes a corresponding amount of time. For this reason, in the prior art 1, even if a failure called deadlock occurs, the deadlock cannot be detected immediately.

  Therefore, in the prior art 1, there are effects such as a decrease in availability due to an increase in the average repair time and a limitation of a detectable failure range.

  The above-described prior art 2 requires a special OS and is not suitable for the operation of any application managed by the cluster system. Even if a deadlock is detected, it is not possible to take measures such as failover.

  In the above prior art 3, since the access order to the shared resources of all processes of the application is recorded in advance as described above, the deadlock is not dynamically detected. Therefore, Prior Art 3 is not suitable for detecting a failure in a cluster system.

  In the above-described prior art 4, since one lock management node is prepared as described above and the occurrence of deadlock is detected by requesting the management node to check, deadlock of an application running on the node is detected. It cannot be applied to the means for detecting.

  Therefore, an object of the present invention is to provide a computer system and a program capable of detecting the occurrence of a deadlock in a node in an event-driven manner, reducing the time from the occurrence of a failure to the failure detection, and expanding the detectable failure range. There is to do.

  According to one aspect of the present invention, a computer is provided that executes a plurality of threads that share a resource, and the computer requests acquisition of a lock for occupying the resource from each of the plurality of threads. An acquisition unit for acquiring a lock acquisition request, a lock state table in which acquisition states of locks by the plurality of threads are registered based on the acquired lock acquisition request, the acquired lock acquisition request, and the lock There is provided a computer system including detection means for detecting the occurrence of a deadlock based on a lock acquisition state registered in a state table.

  According to the present invention, by detecting the occurrence of a deadlock in a node, it is possible to reduce the time from failure occurrence to failure detection and to expand the detectable failure range.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[First Embodiment]
FIG. 1 is a block diagram showing a functional configuration of a cluster system (computer system) according to the first embodiment of the present invention.

  As shown in FIG. 1, the cluster system according to the present embodiment includes a plurality of nodes (computers) 10 and a shared disk 30. The plurality of nodes 10 include an active node and a plurality of standby nodes.

  The plurality of nodes 10 are connected to be communicable with each other via, for example, a communication path.

  The plurality of nodes 10 and the shared disk 30 are connected by, for example, an FC (Fibre Channel) cable.

  In the cluster system described above, when a failure occurs in, for example, a node (hereinafter referred to as an active node) 10 that operates as an active node among a plurality of nodes 10 constituting the cluster system, the active node 10 This is a high availability cluster system (HA cluster system) that is handed over to a node (hereinafter, simply referred to as a standby node) 10 that operates as a standby node. That is, when a failure occurs in the active node 10, for example, an application operating on the active node 10, the shared disk 30, the IP (Internet Protocol) address of the active node 10, etc. (Notation) is taken over to the standby node 10 (failover). Thereby, in the cluster system, even if a failure occurs in the active node 10, the operation can be continued in the standby node 10.

  FIG. 2 is a block diagram mainly showing a functional configuration of each of the plurality of nodes 10 shown in FIG. 1 (hereinafter simply referred to as node 10).

  On the node 10, an application 11, an OS (Operating System) 12, a jacket library 13, and a HA (High Availability) cluster daemon 14 operate.

  The application 11 is an application to be monitored by the jacket library 13 (hereinafter referred to as the monitoring target application 11). The monitoring target application 11 includes, for example, at least one process. Here, it is assumed that the monitoring target application 11 is composed of one process. Moreover, the process which comprises the monitoring object application 11 is comprised from one or more threads. Here, the process constituting the monitoring target application 11 will be described as comprising a plurality of threads.

  That is, for example, in the node (active node) 10 that operates as the active node, a plurality of threads constituting the monitoring target application 11 (processes constituting the monitored application 11) are executed.

  The plurality of threads constituting the monitoring target application 11 share resources (resources) that the node 10 has, for example.

  When a plurality of threads are executed in the node 10, each of the plurality of threads outputs a lock acquisition request for requesting acquisition of a lock for occupying resources of the node 10 to the OS 12. Thus, when a lock is acquired, exclusive control can be performed on the resource from which the lock is acquired.

  Each of the plurality of threads outputs a lock release request for releasing the occupation of the resource for which the lock is acquired by the thread to the OS 12. Thus, when the lock is released, threads other than the thread that has acquired the lock can use (use) the resource for which the lock has been acquired.

  The OS 12 manages each of a plurality of threads constituting the monitoring target application 11. In this case, the OS 12 manages the thread being executed by using a thread ID for identifying each of the plurality of threads.

  The OS 12 includes a lock acquisition unit 121 and a lock release unit 122. The lock acquisition unit 121 executes processing for acquiring a lock in response to a lock acquisition request from each of a plurality of threads. When a lock to be acquired in response to a lock acquisition request from each of a plurality of threads has already been acquired by another thread, the lock acquisition unit 121 determines that the lock is released by the other thread. Execute lock acquisition processing after waiting.

  The lock release unit 122 executes a process of releasing the lock in response to a lock release request from each of the plurality of threads.

  The jacket library 13 manages the lock acquisition status of each of the plurality of threads by hooking (acquiring) a lock acquisition request and a lock release request to the OS 12 from each of the plurality of threads constituting the monitoring target application 11. It has the function to do. The jacket library 13 has a function of detecting the occurrence of a deadlock based on a hooked lock acquisition request and a lock acquisition state by each of a plurality of threads.

  As shown in FIG. 2, the jacket library 13 includes an API (Application Program Interface) hook unit 131, a lock state management unit 132, a lock state table 133, a deadlock detection unit 134, and a deadlock notification unit 135.

  In the present embodiment, the API hook unit 131, the lock state management unit 132, the deadlock detection unit 134, and the deadlock notification unit 135 include a memory (not shown) provided in the node 10 by a computer (not shown) of the node 10 for example. ) Is executed by executing the program stored in (1). This program can be stored in advance in a computer-readable storage medium and distributed. In addition, this program may be downloaded to a computer via a network.

  Further, in the present embodiment, the lock state table 133 is in a memory provided in the node 10, for example, and the area is secured in the memory space given to the monitoring target application 11 (a process constituting the monitoring target application 11). Yes.

  In other words, the jacket library 13 shown in FIG. 2 includes a module called an API hook unit 131, a lock state management unit 132, a deadlock detection unit 134, and a deadlock notification unit 135, and data called a lock state table 133.

  The API hook unit 131 hooks a lock acquisition request and a lock release request to the OS 12 of a plurality of threads constituting the monitoring target application 11. The lock acquisition request and the lock release request include the address of the lock that is acquired or released in response to the request. The lock address is an address on the memory managed by the OS 12.

  When the lock acquisition request is hooked, the API hook unit 131 indicates that lock acquisition is executed according to the lock address included in the lock acquisition request and the lock acquisition request (hereinafter referred to as “lock acquisition request”). Notify execution ”) to the lock state management unit 132.

  Further, when a lock acquisition request is hooked, the API hook unit 131 executes a lock acquisition unit (lock acquisition API) 121 included in the OS 12 in response to the lock acquisition request. Thereby, the lock acquisition part 121 performs a lock acquisition process according to a lock acquisition request.

  When the lock release request is hooked, the API hook unit 131 executes lock release according to the lock address included in the lock release request and the lock release request (hereinafter referred to as “lock release request”). Notify execution ”) to the lock state management unit 132.

  Further, when a lock release request is hooked, the API hook unit 131 executes a lock release unit (lock release API) 122 included in the OS 12 in response to the lock release request. As a result, the lock release unit 122 executes a lock release process in response to the lock release request.

  The API hook unit 131 responds to a lock acquisition request from the OS 12 (the lock acquisition unit 121 and the lock release unit 122 included therein) (hereinafter referred to as a lock acquisition response) and a response to the lock release request (hereinafter referred to as a lock release response). Hook). The lock acquisition response and the lock release response include the address of the acquired or released lock. Further, the API hook unit 131 returns a lock acquisition response and a lock release response to the monitoring target application 11 (a thread constituting the monitoring target application 11).

  When the lock acquisition response is hooked, the API hook unit 131 locks the lock address included in the lock acquisition response and the fact that the lock acquisition response is returned (hereinafter referred to as “lock acquisition response”). Notify the management unit 132. Similarly, when the lock release response is hooked, the API hook unit 131 returns the address of the lock included in the lock release response and the lock release response (hereinafter referred to as “lock release response”). Is notified to the lock state management unit 132.

  The API hook unit 131 requests the lock state management unit 132 to update the lock state table 133 by notifying the lock state management unit 132 as described above.

  Also, the API hook unit 131 causes the deadlock detection unit 134 to generate a deadlock when executing the lock acquisition unit 121 (lock acquisition API) in response to a lock acquisition request from a thread constituting the monitoring target application 11. Request detection processing. At this time, the API hook unit 131 outputs the lock address to the deadlock detection unit 134.

  Upon receiving the notification from the API hook unit 131, the lock state management unit 132 monitors the thread ID for identifying the thread that is the request source of the lock acquisition request or the lock release request hooked by the API hook unit 131. An inquiry is made to the OS 12 that manages the threads constituting the target application 11. Thereby, the lock state management unit 132 acquires the thread ID.

  The lock state management unit 132 updates the lock state table 133 based on the notification from the API hook unit 131 and the acquired thread ID. In the lock state table 133, lock acquisition states by a plurality of threads constituting the monitoring target application 11 are registered. The lock state table 133 is updated by changing the combination state (lock acquisition state) of the lock address notified from the API hook unit 131 and the thread ID acquired by the lock state management unit 132 from the API hook unit 131. This is performed by changing to a state corresponding to the content of the notification (for example, “execution of lock acquisition”).

  The lock state management unit 132 expands the lock state table 133 when the thread ID or lock address to be updated is not in the lock state table 133 (not registered).

  Based on the request from the API hook unit 131, the deadlock detection unit 134 checks whether or not a deadlock occurs when a lock is acquired in response to a lock acquisition request hooked by the API hook unit 131. . Thereby, the deadlock detector 134 detects the occurrence of a deadlock.

  At this time, the deadlock detection unit 134 acquires the thread ID by inquiring of the OS 12 about the thread ID for identifying the thread that is the request source of the lock acquisition request. The deadlock detection unit 134 detects the occurrence of a deadlock based on the acquired thread ID, the lock address output by the API hook unit 131, and the lock acquisition state registered in the lock state table 133. When the occurrence of a deadlock is detected, the deadlock detection unit 134 outputs a notification request for the occurrence of the deadlock to the deadlock notification unit 135.

  Details of the deadlock occurrence detection process by the deadlock detector 134 will be described later.

  The deadlock notification unit 135 notifies the HA cluster daemon 14 of the occurrence of a deadlock based on the notification request output by the deadlock detection unit 134.

  The HA cluster daemon 14 has a function of executing management and operation of the cluster system. For example, when a failure occurs in the monitoring target application 11 in the node 10 that operates as the active node, the HA cluster daemon 14 operates the service of the node 10 as a standby node that is different from the node 10. Execute the failover process.

  When the deadlock notification unit 135 included in the jacket library 13 notifies the HA cluster daemon 14 that a deadlock has occurred, the HA cluster daemon 14 takes measures such as service failover as a failure (deadlock) has occurred in the monitored application 11. Do.

  Note that the HA cluster daemon 14 may be configured to restart the monitored application 11 as a countermeasure when a failure occurs in the monitored application 11.

  FIG. 3 shows an example of the data structure of the lock state table 133 shown in FIG. As shown in FIG. 3, in the lock state table 133, the lock acquisition state is registered in association with the lock address and the thread ID. Here, the lock address is represented as L (L1, L2, L3,...), And the thread ID is represented as T (T1, T2, T3,...).

  Here, the lock acquisition status includes “locking”, “lock requesting”, and “no lock”. In the example shown in FIG. 3, “locked” is represented by “◯”, “lock requested” is represented by “Δ”, and “no lock” is represented by “blank (none)”.

  In the example illustrated in FIG. 3, the lock acquisition state “◯” is registered in the lock state table 133 in association with the lock address “L1” and the thread ID “T1”. This indicates that the thread identified by the thread ID “T1” is “locking” the lock whose lock address is “L1”.

  In the lock state table 133, the lock acquisition state “◯” is registered in association with the lock address “L2” and the thread ID “T3”. This indicates that the thread identified by the thread ID “T3” is “locking” the lock whose lock address is “L2”.

  In the lock state table 133, the lock acquisition state “Δ” is registered in association with the lock address “L3” and the thread ID “T1”. This indicates that the thread identified by the thread ID “T1” is “locking requested” for the lock whose lock address is “L1”.

  The lock state table 133 indicates that the items other than those described above are not “locking” and “lock requesting”, that is, “no lock”.

  Next, update of the lock state table 133 by the lock state management unit 132 will be described with reference to FIG.

  The lock state management unit 132 updates the lock state table 133 based on the notification from the API hook unit 131 and the acquired thread ID (thread ID for identifying the thread that is the request source). As described above, the notification (contents) from the API hook unit 131 includes “execution of lock acquisition”, “response to acquire lock”, “execution of lock release”, and “response to release lock”.

  Here, as shown in FIG. 4, when the content of the notification from the API hook unit 131 is “execution of lock acquisition”, the lock state management unit 132 sets the lock acquisition state in the lock state table 133 to “ Update to “Lock Requesting”. For example, the lock address notified from the API hook unit 131 is “L1”, the thread ID acquired by the lock state management unit 132 is “T3”, and the content of the notification from the API hook unit 131 is “execute lock acquisition”. ”Is assumed. In this case, the lock state management unit 132 updates the lock acquisition state in the lock state table 133 associated with the lock address “L1” and the thread ID “T3” to “lock requested”.

  As illustrated in FIG. 4, when the content of the notification from the API hook unit 131 is “lock acquisition response”, the lock state management unit 132 sets the lock acquisition state in the lock state table 133 to “locking”. Update to

  As shown in FIG. 4, when the content of the notification from the API hook unit 131 is “execution of lock release”, the lock acquisition state in the lock state table 133 has not been changed, so the lock state management unit 132. Does not update the lock state table 133.

  As shown in FIG. 4, when the content of the notification from the API hook unit 131 is “lock release response”, the lock state management unit 132 sets the lock acquisition state in the lock state table 133 to “lock”. Update to None.

  Next, with reference to the flowchart of FIG. 5, the processing procedure of the deadlock occurrence detection process by the deadlock detection unit 134 described above will be described.

  The deadlock occurrence detection process is executed when the deadlock detection unit 134 receives a request from the API hook unit 131 (a request to confirm the occurrence of a deadlock). At this time, the deadlock detection unit 134 receives the lock address from the API hook unit 131. Moreover, the deadlock detection unit 134 acquires the thread ID by inquiring of the OS 12. The thread ID acquired here is an ID for identifying the thread that is the request source of the lock acquisition request (the lock acquisition request hooked by the API hook unit 131) including the address of the lock received from the API hook unit 131. It is. Hereinafter, the address of the lock received by the deadlock detection unit 134 from the API hook unit 131 will be described as L, and the thread ID acquired by the deadlock detection unit 134 will be described as T.

  First, the deadlock detection unit 134 clears the stack as an initialization process (step S1). This stack holds, for example, data in a last-in first-out structure, and is implemented by a combination of hardware and software functions. For example, an area of the stack is secured in a memory provided in the node 10.

  Next, the deadlock detector 134 adds T to the stack (step S2). Here, T is a thread ID acquired by the deadlock detection unit 134.

  The deadlock detection unit 134 determines whether or not the L lock received from the API hook unit 131 has been acquired by a thread other than the thread identified by T (hereinafter simply referred to as another thread) (step S3). ). At this time, the deadlock detection unit 134 performs a determination process with reference to the lock state table 133. The deadlock detection unit 134 determines whether or not there is a thread that is “locking” the L lock in the lock state table 133.

  When it is determined that the lock of L has been acquired (YES in step S3), the deadlock detection unit 134 identifies T and a thread for identifying another thread that is “locking” the lock of L ID (that is, a thread ID for identifying a thread that has acquired T = L lock) (step S4). Thereby, in the processing after step S4, the processing is executed with the thread ID for identifying the other threads described above as T.

  Next, the deadlock detection unit 134 determines whether or not T (thread ID for identifying the other thread described above) exists in the stack (step S5).

  If it is determined that the thread does not exist in the stack (NO in step S5), the deadlock detector 134 refers to the lock state table 133 and determines whether there is a lock whose thread identified by T is “lock requested”. It is determined whether or not (step S6).

  If it is determined that there is a lock that is “lock requested” (YES in step S6), the deadlock detector 134 sets L to the lock address (that is, the thread identified by L = T is “locked”). The address of the lock being “requesting”) (step S7). Thereby, in the processing after step S7, the processing is executed with the address of the lock whose thread identified by T described above is “lock requested” being L.

  When the process of step S7 described above is executed, the process returns to step S2 and is repeated.

  On the other hand, if it is determined in step S3 that the lock of L has not been acquired, even if the thread identified by the thread ID acquired by the deadlock detection unit 134 acquires the lock, no deadlock occurs. As a result, the deadlock detector 134 ends the process without detecting the occurrence of a deadlock.

  If it is determined in step S6 that there is no lock that is “lock requested”, the deadlock detector 134 ends the process without detecting the occurrence of a deadlock.

  On the other hand, when it is determined in step S5 that T exists in the stack, the deadlock detector 134 detects the occurrence of deadlock (step S8). In this way, in the lock acquisition state registered in the lock state table 133, the deadlock detection unit 134 detects the occurrence of a deadlock when a lock or lock request (lock) loop occurs. To do.

  Here, with reference to FIG. 6, the detection process of the occurrence of deadlock in the detection unit 134 will be specifically described. FIG. 6 shows an example of the lock state table 133 representing the lock acquisition state when a deadlock occurs.

  Here, it is assumed that the address of the lock received by the deadlock detection unit 134 from the API hook unit 131 is L3, and the thread ID acquired when the deadlock detection unit 134 inquires of the OS 12 is T1. That is, it is assumed that the thread identified by T1 is trying to acquire the lock of L3.

  In the example shown in FIG. 6, “lock requested (Δ)” is registered in the lock state table 133 in association with T1 and L3 described above.

  In this case, the deadlock detection unit 134 adds T1 that is the acquired thread ID to the stack.

  Next, the deadlock detection unit 134 determines whether or not the lock of L3 received from the API hook unit 131 has been acquired by a thread other than the thread identified by T1 (that is, “locking”). Is determined with reference to the lock state table 133. In the example of the lock state table 133 shown in FIG. 6, the lock of L3 received from the API hook unit 131 is acquired by the thread identified by T2. Therefore, the deadlock detection unit 134 determines that the lock of L3 has been acquired by another thread (the thread identified by T2).

  The deadlock detector 134 determines whether or not T2 exists in the stack. At this stage, since only T1 exists in the stack, the deadlock detector 134 determines that T2 does not exist in the stack.

  The deadlock detection unit 134 refers to the lock state table 133 to determine whether there is a lock in which the thread identified by T2 is “lock requested”. In the example of the lock state table 133 illustrated in FIG. 6, the thread identified by T2 is “lock requested” for the lock of L4. Therefore, the deadlock detection unit 134 determines that there is a lock (L4 lock) in which the thread identified by T2 is “lock requested”.

  In this case, the deadlock detection unit 134 adds T2 to the stack. When T2 is added to the stack, the deadlock detection unit 134 refers to the lock state table 133 to determine whether or not the lock of L4 has been acquired by a thread other than the thread identified by T2 (another thread). Judgment. In the example of the lock state table 133 shown in FIG. 6, the lock of L4 is acquired by the thread identified by T4. Therefore, the deadlock detection unit 134 determines that the lock of L4 has been acquired by another thread (the thread identified by T4).

  The deadlock detection unit 134 determines whether T4 exists in the stack. Since T1 and T2 exist in the stack at this stage, the deadlock detector 134 determines that T4 does not exist in the stack.

  The deadlock detection unit 134 refers to the lock state table 133 to determine whether there is a lock whose thread identified by T4 is “lock requested”. In the example of the lock state table 133 illustrated in FIG. 6, the thread identified by T4 is “lock requested” for the lock of L1. Therefore, the deadlock detection unit 134 determines that there is a lock (L1 lock) in which the thread identified by T4 is “lock requested”.

  In this case, the deadlock detection unit 134 adds T4 to the stack. When T4 is added to the stack, the deadlock detector 134 refers to the lock state table 133 to determine whether or not the lock of L1 has been acquired by a thread other than the thread identified by T4 (another thread). Judgment. In the example of the lock state table 133 shown in FIG. 6, the lock of L1 is acquired by the thread identified by T1. Therefore, the deadlock detection unit 134 determines that the lock of L1 has been acquired by another thread (the thread identified by T1).

  The deadlock detection unit 134 determines whether T1 exists in the stack. In this case, since T1, T2, and T4 exist in the stack, the deadlock detector 134 determines that T1 exists in the stack.

  When it is determined that T1 exists in the stack as described above, a loop during locking and lock request occurs between a plurality of threads (here, T1, T2, and T4) as shown in FIG. Each of the plurality of threads cannot execute the release of the lock acquired by the thread when “lock is being requested” for any lock. That is, for example, T1 (thread identified by) waits for T2 lock release, T2 waits for T4 lock release, and T4 waits for T1 lock release, so multiple threads occupy each other. A deadlock occurs due to waiting for the release of the resource being released.

  Therefore, the deadlock detector 134 detects the occurrence of a deadlock when a loop that is locked and a lock is requested as described above.

  When the deadlock detection unit 134 detects the occurrence of a deadlock, the deadlock detection unit 134 outputs a notification request for notifying the HA cluster daemon 14 of the occurrence of the deadlock to the deadlock notification unit 135. The deadlock notification unit 135 notifies the HA cluster daemon 14 of the occurrence of deadlock based on the notification request from the deadlock detection unit 134. In the HA cluster daemon 14, processing such as failover is executed in response to the notification from the deadlock notification unit 135.

  Next, the flow of processing when a lock is acquired by a thread constituting the monitoring target application 11 will be described with reference to FIG.

  First, the thread constituting the monitoring target application 11 outputs a lock acquisition request for occupying resources to the OS 12. This thread is, for example, a thread that is executed in the node 10 operating as an active node. The lock acquisition request output from the thread includes the address of the lock acquired in response to the lock acquisition request.

  The API hook unit 131 of the jacket library 13 hooks a lock acquisition request from a thread constituting the monitoring target application 11. When the lock acquisition request is hooked, the API hook unit 131 executes the lock state management unit 132 (step S11). At this time, the API hook unit 131 informs the lock state management unit 132 that the lock acquisition included in the hooked lock acquisition request and that lock acquisition is executed according to the lock acquisition request (execution of lock acquisition). Notice.

  When the lock state management unit 132 is executed by the API hook unit 131, the lock state management unit 132 identifies the thread that is the request source of the lock acquisition request hooked by the API hook unit 131 (that is, the thread that is being executed). The OS 12 is inquired about the thread ID to be used. Thereby, the lock state management unit 132 acquires the thread ID of the thread that is the request source of the lock acquisition request (step S12).

  The lock state management unit 132 updates the lock acquisition state associated with the lock ID notified from the API hook unit 131 and the thread ID acquired by making an inquiry to the OS 12 in the lock state table 133. At this time, since the content of the notification from the API hook unit 131 is “execution of lock acquisition”, the lock state management unit 132 updates the lock acquisition state to “lock requesting” (step S13).

  Next, the API hook unit 131 executes the deadlock detection unit 134 (step S14). At this time, the API hook unit 131 outputs the address of the lock included in the hooked lock acquisition request to the deadlock detection unit 134.

  When the deadlock detection unit 134 is executed by the API hook unit 131, the deadlock detection unit 134 acquires the thread ID of the thread that is the request source of the lock acquisition request hooked by the API hook unit 131, and the above-described diagram. The deadlock occurrence detection process shown in FIG. 5 is executed (step S15).

  If the occurrence of a deadlock is not detected by the deadlock detection unit 134 (NO in step S15), the API hook unit 131 executes the lock acquisition API (lock acquisition unit 121) of the OS 12 (step S16). At this time, the API hook unit 131 outputs a lock address to the OS 12.

  The lock acquisition unit 121 of the OS 12 executes a lock acquisition process according to the lock address output by the API hook unit 131 (step S17). At this time, for example, if the lock has already been acquired by another thread, the lock acquisition unit 121 executes the lock acquisition process after waiting for the lock to be released. When the lock acquisition process is executed, the lock acquisition unit 121 outputs a lock acquisition response (return value) to the monitoring target application 11. This lock acquisition response includes the address of the lock for which acquisition processing has been completed.

  The API hook unit 131 of the jacket library 13 hooks the lock acquisition response output by the lock acquisition unit 121 of the OS 12. When the API hook unit 131 hooks the lock acquisition response, the API hook unit 131 executes the lock state management unit 132 (step S18). At this time, the API hook unit 131 notifies the lock state management unit 132 of the address of the lock included in the hooked lock acquisition response and that the lock acquisition response has been returned (lock acquisition response).

  When the lock state management unit 132 is executed by the API hook unit 131, the lock state management unit 132 identifies the thread that is the request source of the lock acquisition request that is the source of the lock acquisition response hooked by the API hook unit 131. The OS 12 is inquired about the thread ID for this purpose. Thereby, the lock state management unit 132 acquires the thread ID (step S19).

  The lock state management unit 132 updates the lock acquisition state associated in the lock state table 133 with the lock ID notified from the API hook unit 131 and the thread ID acquired by making an inquiry to the OS 12. At this time, since the content of the notification from the API hook unit 131 is “lock acquisition response”, the lock state management unit 132 updates the lock acquisition state to “locking” (step S20).

  After the processing as described above is executed, when the lock acquisition response is returned to the monitoring target application 11 by the API hook unit 131, the processing is terminated.

  On the other hand, when the occurrence of deadlock is detected by the deadlock detection unit 134 in step S15, the deadlock detection unit 134 executes the deadlock notification unit 135 (step S21).

  When the deadlock notifying unit 135 is executed by the deadlock detecting unit 134, the deadlock notifying unit 135 notifies the HA cluster daemon 14 of the occurrence of the deadlock (step S22).

  When the deadlock notification unit 135 notifies the occurrence of a deadlock, the HA cluster daemon 14 takes measures such as service failover, assuming that a failure has occurred in the monitored application 11 (step S23).

  Note that when the processing in step S23 described above is executed, the operation of the monitoring target application 11 and the like is stopped by the HA cluster daemon 14.

  Next, the flow of processing when a lock is released by a thread constituting the monitoring target application 11 will be described with reference to FIG.

  First, the thread constituting the monitoring target application 11 outputs a lock release request for releasing the occupation of the resource for which the thread has acquired the lock to the OS 12. This lock release request includes the address of the lock released in response to the lock release request.

  The API hook unit 131 of the jacket library 13 hooks a lock release request from a thread constituting the monitoring target application 11. When the API hook unit 131 hooks the lock release request, the API hook unit 131 executes the lock state management unit 132 (step S31). At this time, the API hook unit 131 informs the lock state management unit 132 that the lock address contained in the hooked lock release request and that the lock release is executed according to the lock release request (execution of lock release). Notice.

  Here, as described above, when the content of the notification from the API hook unit 131 is “execution of lock release”, the lock acquisition state is not changed, and the lock state table 133 is not updated.

  Accordingly, the API hook unit 131 executes the lock release API (lock release unit 122) of the OS 12 (step S32). At this time, the API hook unit 131 outputs a lock address to the OS 12.

  The lock release unit 121 of the OS 12 executes a lock release process according to the lock address output by the API hook unit 131 (step S33). When the lock release processing is executed, the lock release unit 122 outputs a lock release response (return value) to the monitoring target application 11. This lock release response includes the address of the lock for which the release process has been completed.

  The API hook unit 131 of the jacket library 13 hooks the lock release response output by the lock release unit 122 of the OS 12. When hooking the lock release response, the API hook unit 131 executes the lock state management unit 132 (step S34). At this time, the API hook unit 131 notifies the lock state management unit 132 of the address of the lock included in the hooked lock release response and the fact that the lock release response is returned (lock release response).

  When the lock state management unit 132 is executed by the API hook unit 131, the lock state management unit 132 identifies the thread that is the request source of the lock release request that is the source of the lock release response hooked by the API hook unit 131. The OS 12 is inquired about the thread ID for this purpose. Thereby, the lock state management unit 132 acquires a thread ID for identifying the thread that is the request source of the lock release request that is the source of the lock release response (step S35).

  The lock state management unit 132 updates the lock acquisition state associated in the lock state table 133 with the lock ID notified from the API hook unit 131 and the thread ID acquired by making an inquiry to the OS 12. At this time, since the content of the notification from the API hook unit 131 is “lock release response”, the lock state management unit 132 updates the lock acquisition state to “no lock” (step S36).

  After the processing as described above is executed, when the lock release response is returned to the monitoring target application 11 by the API hook unit 131, the processing is terminated.

  As described above, in the present embodiment, the lock acquisition request and the lock release request from the plurality of threads constituting the monitoring target application 11 and the lock acquisition response and the lock release response from the OS 12 are hooked, By managing the lock acquisition state in the lock state table 133, for example, when a lock acquisition request is issued from a thread, it is possible to detect the occurrence of a deadlock.

  As a result, in the present embodiment, for example, by periodically executing an external command for monitoring the state of the monitoring target application 11, it is used in combination with periodic monitoring that detects a failure occurring in the monitoring target application 11. Thus, the detectable fault range can be expanded. Therefore, it is possible to reduce the possibility that the service is continued in a state where a failure has occurred in the monitoring target application 11, and it is possible to improve the reliability of the service.

  In the present embodiment, since a failure can be detected at the timing (event driven) when a deadlock occurs, even if the failure can be detected only by the regular monitoring described above, the failure occurred in the monitored application. It is possible to shorten the time until the failure is detected. As a result, the service stop time can be shortened, so that the availability of the service can be improved.

[Second Embodiment]
Next, a second embodiment of the present invention will be described with reference to FIG. FIG. 9 is a block diagram mainly showing a functional configuration of the node 100 provided in the cluster system according to the present embodiment. The same parts as those in FIG. 2 described above are denoted by the same reference numerals, and detailed description thereof is omitted. Here, parts different from FIG. 2 will be mainly described. Similarly, the following embodiments will not be described repeatedly.

  As shown in FIG. 9, the monitoring target application, the OS 120, the jacket library 130a, and the jacket library 130b operate on the node 100 provided in the cluster system according to the present embodiment.

  In the first embodiment described above, the monitoring target application has been described as being configured by one process. However, in the present embodiment, it is assumed that the monitoring target application is configured by a plurality of processes. . That is, in this embodiment, a plurality of processes including the processes 110a and 110b of the monitoring target application are executed on the node 100. Hereinafter, the process 110a of the monitoring target application is simply referred to as a process 110a. Similarly, the process 110b of the monitoring target application is simply expressed as a process 110b.

  Hereinafter, the processes 110a and 110b among the plurality of processes constituting the monitoring target application will be described. The processes other than the processes 110a and 110b are the same as the processes 110a and 110b.

  Note that the processes 110a and 110b constituting the monitoring target application are constituted by a plurality of threads.

  The OS 120 manages the process 110a, the process 110b, and each of a plurality of threads constituting the processes 110a and 110b. In this case, the OS 120 manages the thread being executed by using the process ID for identifying the processes 110a and 110b and the thread ID for identifying each of the plurality of threads constituting the processes 110a and 110b.

  The OS 120 includes a lock state table 123. The lock state table 123 is reserved in a memory space (not shown) provided in the node 100, for example, in a shared memory space among a plurality of processes assigned to the OS 120.

  In the lock state table 123, lock acquisition states by a plurality of threads constituting the processes 110a and 110b are registered.

  The jacket library 130a manages a lock acquisition state by each of the plurality of threads by hooking (acquiring) a lock acquisition request and a lock release request to the OS 120 from each of the plurality of threads constituting the process 110a. The jacket library 130a detects the occurrence of a deadlock based on a hooked lock acquisition request and a lock acquisition state by each of a plurality of threads. When the occurrence of deadlock is detected, the jacket library 130a notifies the HA cluster daemon 14 to that effect.

  Note that the jacket library corresponds to each process. That is, for example, the jacket library 130a corresponds to the process 110a, and the jacket library 130b corresponds to the process 110b. In this case, the jacket library 130a executes processing corresponding to the lock acquisition request from the process 110a, and the jacket library 130b executes processing according to the lock acquisition request from the process 110b.

  Hereinafter, the configuration and the like of the jacket library 130a will be mainly described, but the jacket library 130b is the same as the jacket library 130a.

  The jacket library 130a includes a lock state management unit 136 and a deadlock detection unit 137.

  In the present embodiment, the lock state management unit 136 and the deadlock detection unit 137 are realized by a computer (not shown) of the node 100 executing a program stored in a memory provided in the node 100, for example. And This program can be stored in advance in a computer-readable storage medium and distributed. In addition, this program may be downloaded to a computer via a network.

  The lock state management unit 136 sets a process ID for identifying a process 110a (consisting of a plurality of threads) including a thread that is a request source of a lock acquisition request or a lock release request hooked by the API hook unit 131. Inquires the OS 120. Thereby, the lock state management unit 136 acquires the process ID.

  In addition, when the notification from the API hook unit 131 is received, the lock state management unit 136 inquires of the OS 120 about a thread ID for identifying the thread that is the request source of the lock acquisition request or the lock release request. Thereby, the lock state management unit 136 acquires the thread ID.

  The lock state management unit 136 updates the lock state table 123 based on the notification from the API hook unit 131 and the acquired process ID and thread ID. That is, in this embodiment, unlike the first embodiment described above, the lock acquisition state is managed (registered) for a three-dimensional combination of a process ID, a thread ID, and a lock address.

  In the lock state table 123, as described above, the lock acquisition state by a plurality of threads constituting the processes 110a and 110b is registered, but the lock state management unit 136 of the jacket library 130a constitutes the process 110a. The lock acquisition status by a plurality of threads is registered (updated) in the lock status table 123. That is, the lock acquisition state by a plurality of threads constituting the process 110b is registered by a lock state management unit (not shown) of the jacket library 130b.

  When the process ID, thread ID, or lock address to be updated is not registered in the lock state table 123, the lock state management unit 136 extends the lock state table 123.

  The deadlock detection unit 137 confirms whether or not a deadlock occurs due to acquisition of a lock based on a request from the API hook unit 131. As a result, the deadlock detector 137 detects the occurrence of a deadlock.

  At this time, the deadlock detection unit 137 inquires of the OS 120 for a process ID for identifying the process 110a configured by the thread that is the request source of the lock acquisition request hooked by the API hook unit 131. Thereby, the deadlock detector 137 acquires the process ID of the process 110a. In addition, the deadlock detection unit 137 acquires the thread ID by inquiring the OS 120 about the thread ID for identifying the thread that is the request source of the lock acquisition request hooked by the API hook unit 131.

  The deadlock detection unit 137 generates a deadlock based on the acquired process ID, thread ID, and the lock address output by the API hook unit 131 and the lock acquisition state registered in the lock state table 123. Is detected. When occurrence of a deadlock is detected, the deadlock detection unit 137 outputs a notification request for occurrence of the deadlock to the deadlock notification unit 135.

  The configuration of the jacket library 130b is the same as that of the jacket library 130a as described above, and is omitted in FIG. A detailed description of the configuration of the jacket library 130b is omitted.

  Next, the flow of processing when a lock is acquired by a thread constituting the process 110a will be described with reference to FIG.

  First, the thread constituting the process 110a outputs a lock acquisition request for occupying resources to the OS 120. This lock acquisition request includes the address of the lock acquired in response to the lock acquisition request.

  Next, the process of step S41 corresponding to the process of step S11 shown in FIG. 7 is executed.

  The lock state management unit 136 inquires of the OS 120 about a process ID for identifying the process 110 a configured by a thread that is a request source of the lock acquisition request hooked by the API hook unit 131. Thereby, the lock state management unit 136 acquires the process ID of the process 110a (step S42).

  When the process of step S42 is executed, the process of step S43 corresponding to the process of step S12 shown in FIG. 7 described above is executed.

  The lock state management unit 136 updates the lock acquisition state associated with the address of the lock notified from the API hook unit 131, the process ID acquired in step S42, and the thread ID acquired in step S43. At this time, since the content of the notification from the API hook unit 131 is “execution of lock acquisition”, the lock state management unit 132 updates the lock acquisition state in the lock state table 123 to “lock requesting” (step S1). S44).

  Next, the deadlock detection unit 137 executes deadlock occurrence detection processing (step S46). At this time, the deadlock detection unit 137 obtains the process ID by inquiring the process ID for identifying the process 110a including the thread that is the request source of the lock acquisition request hooked by the API hook unit 131. To do. In addition, the deadlock detection unit 137 acquires the thread ID by inquiring the OS 120 about the thread ID for identifying the thread that is the request source of the lock acquisition request hooked by the API hook unit 131. The deadlock detection unit 137 detects the occurrence of a deadlock based on the acquired process ID, thread ID, lock address output by the API hook unit 131, and the lock acquisition state registered in the lock state table 123. To do. In the lock state table 123, lock acquisition states by threads constituting a plurality of processes including the processes 110a and 110b are registered.

  The deadlock generation detection process by the deadlock detection unit 137 is the same as the process shown in FIG. 5 described above, for example, when the set of process ID and thread ID is T and the lock address is L. Detailed description thereof is omitted.

  When the deadlock detection unit 137 does not detect the occurrence of a deadlock (NO in step S46), the processes in steps S47 to S49 corresponding to the processes in steps S16 to S18 shown in FIG. 7 described above are executed.

  Next, the lock state management unit 136 sets a process ID for identifying the process 110a including the thread that is the request source of the lock acquisition request that is the source of the lock acquisition response hooked by the API hook unit 131, to the OS 120. Inquire. Thereby, the lock state management unit 136 acquires the process ID of the process 110a (step S50).

  When the process of step S50 is executed, the process of step S51 corresponding to the process of step S19 of FIG. 7 described above is executed.

  The lock state management unit 136 updates the lock acquisition state associated in the lock state table 123 with the lock address, the acquired process ID, and the thread ID notified from the API hook unit 131. At this time, the lock state management unit 136 updates the lock acquisition state in the lock state table 123 to “locking” because the content of the notification from the API hook unit 131 is “response to acquire lock” (step S20). ).

  On the other hand, when occurrence of a deadlock is detected by the deadlock detection unit 137 in step S46, the processes of steps S53 to S55 corresponding to the processes of steps S21 to S23 shown in FIG. 7 described above are executed.

  Note that when the lock is acquired by the thread constituting the process 110b, the same processing as the processing shown in FIG. 10 described above is executed in the jacket library 130b, and thus detailed description thereof is omitted.

  Next, with reference to FIG. 11, the flow of processing when a lock is released by a thread constituting the process 110a will be described.

  First, the thread constituting the process 110a outputs a lock release request for releasing the occupation of the resource for which the thread has acquired the lock to the OS 120. This lock release request includes the address of the lock released in response to the lock release request.

  Next, the process of step S61-step S64 equivalent to the process of step S31-step S34 shown in FIG. 8 mentioned above is performed.

  The lock state management unit 136 inquires of the OS 120 about a process ID for identifying the process 110a configured by the thread that is the request source of the lock release request that is the source of the lock release response hooked by the API hook unit 131. Thereby, the lock state management unit 136 acquires the process ID of the process 110a (step S65).

  When the process of step S65 is executed, the process of step S66 corresponding to the process of step S35 shown in FIG. 8 described above is executed.

  Next, the lock state management unit 136 associates the lock address notified from the API hook unit 131, the process ID acquired in step S65, and the thread ID acquired in step S66 in the lock state table 123. Update the lock acquisition status. At this time, the lock state management unit 136 updates the lock acquisition state in the lock state table 123 to “no lock” because the content of the notification from the API hook unit 131 is “lock release response” (step S67). ).

  Note that when the lock is released by the thread constituting the process 110b, the same processing as the processing shown in FIG. 11 described above is executed in the jacket library 130b, and therefore detailed description thereof is omitted.

  As described above, in the present embodiment, lock acquisition requests and lock release requests from a plurality of threads that configure a plurality of processes (process 110a and process 110b) that constitute a monitoring target application, lock acquisition responses from the OS 120, and By hooking the lock release response and managing the lock acquisition states of the plurality of threads in the lock state table 123, for example, when a lock acquisition request is issued from a thread, it is possible to detect the occurrence of a deadlock. . That is, in the present embodiment, unlike the first embodiment described above, for example, a deadlock between a plurality of processes constituting the monitoring target application can be detected in an event driven manner. As a result, the present embodiment can be applied to, for example, a multi-process application.

[Third Embodiment]
Next, a third embodiment of the present invention will be described with reference to FIG. FIG. 12 is a block diagram showing a functional configuration of the node 200 provided in the cluster system according to the present embodiment.

  On the node 200, the OS 210 and the jacket library 220 operate. The OS 210 includes a lock creation unit 211 and a thread creation unit 212.

  For example, in response to a thread creation request from the monitoring target application 11, the thread creation unit 211 creates a thread that configures the monitoring target application 11. This thread creation request is made by designating an address of a function that starts a thread (hereinafter referred to as a function address). The thread creation request is appropriately output when the monitoring target application 11 is activated, for example. When a thread is created in response to a thread creation request, the thread creation unit 211 returns a thread ID for identifying the thread to the monitoring target application 11 as a response to the thread creation request.

  The lock creation unit 212 newly creates a lock for occupying resources, for example, in response to lock creation requests from a plurality of threads constituting the monitoring target application 11. The lock creation request is output from the thread as necessary after the thread creation unit 211 creates the thread, for example. When a lock is created in response to the lock creation request, the lock creation unit 212 returns the address of the lock to the monitoring target application 11 as a response to the lock creation request.

  As illustrated in FIG. 12, the jacket library 220 includes an API hook unit 221, a lock / thread association unit 222, a thread correspondence table 223, a lock correspondence table 224, a deadlock detection unit 225, a deadlock information creation unit 226, a deadlock An information reading unit 227 and a suspend determination unit 228 are included.

  In the present embodiment, the API hook unit 221, the lock / thread association unit 222, the deadlock detection unit 225, the deadlock information creation unit 226, the deadlock information read unit 227, and the suspend determination unit 228 are included in the computer (see FIG. (Not shown) is realized by executing a program stored in a memory (not shown) provided in the node 200, for example. This program can be stored in advance in a computer-readable storage medium and distributed. In addition, this program may be downloaded to a computer via a network.

  Further, in the present embodiment, the thread correspondence table 223 and the lock correspondence table 224 are, for example, in a memory provided in the node 200, and the areas of the memory correspondence table 223 and the lock correspondence table 224 are in the memory space given to the monitoring target application 11 It is secured.

  The API hook unit 221 hooks a thread creation request and a lock creation request to the OS 210 from the monitoring target application 11. The API hook unit 221 outputs the hooked thread creation request and lock creation request to the OS 210.

  The API hook unit 221 hooks a response to the thread creation request after the thread is created in response to the thread creation request. The hooked response includes a thread ID for identifying the thread created in response to the thread creation request. The API hook unit 221 requests the lock / thread association unit 222 to update the thread correspondence table 223 by outputting the thread ID included in the hooked response to the lock / thread association unit 222.

  The API hook unit 221 hooks a response to the lock creation request after the lock is created in response to the lock creation request. This hooked response includes the address of the lock created in response to the lock creation request. The API hook unit 221 requests the lock / thread association unit 222 to update the lock correspondence table 224 by outputting the lock address included in the hooked response to the lock / thread association unit 222. .

  When the lock acquisition request is hooked, the API hook unit 221 outputs a lock address included in the lock acquisition request to the suspend determination unit 228, thereby performing a lock acquisition process executed in response to the lock acquisition request. Requests a determination of whether to suspend.

  The lock / thread association unit 222 updates the thread association table 223 in response to a request from the API hook unit 221. Further, the lock / thread association unit 222 updates the lock correspondence table 224 in response to a request from the API hook unit 221.

  The thread correspondence table 223 holds information on a combination of a thread ID for identifying a thread created by the thread creation unit 211 of the OS 210 and a function address when starting the thread. This function address is specified in the above thread creation request.

  The lock correspondence table 224 includes information on the combination of the address of the lock created by the lock creation unit 212 of the OS 210 and the thread ID for identifying the thread that created the lock (the thread that has requested the lock creation request). Retained.

  When the occurrence of a deadlock is detected, the deadlock detection unit 225 requests the deadlock information creation unit 226 to create deadlock status information indicating the deadlock.

  The deadlock information creation unit 226 creates deadlock status information indicating a deadlock detected by the deadlock detection unit 225 in response to a request from the deadlock detection unit 225. At this time, the deadlock information creation unit 226 performs creation processing with reference to the thread correspondence table 223, the lock correspondence table 224, and the lock state table 133. The deadlock information creation unit 226 stores the created deadlock status information in the shared disk 30.

  The deadlock information reading unit 227 reads deadlock status information stored in the shared disk 30 in response to a request from the suspend determination unit 228. The deadlock information reading unit 227 outputs the deadlock status information read from the shared disk 30 to the suspend determination unit 228.

  When receiving the request from the API hook unit 221, the suspend determination unit 228 determines whether or not to suspend the lock acquisition process executed in response to the lock acquisition request hooked by the API hook unit 221. At this time, the suspend determination unit 228 executes determination processing with reference to the thread correspondence table 223, the lock correspondence table 224, and the lock state table 133. Also, the suspend determination unit 228 executes determination processing based on the deadlock status information output by the deadlock information reading unit 227. Details of the processing of the suspend determination unit 228 will be described later.

  FIG. 13 shows an example of the data structure of the thread correspondence table 223 shown in FIG. As shown in FIG. 13, in the thread correspondence table 223, a function address when starting a thread (function address at the time of starting the thread) and a thread ID for identifying the thread are held in association with each other.

  That is, the thread correspondence table 223 holds the function address specified in the thread creation request and the thread ID of the thread created in response to the thread creation request in association with each other.

  For example, when there are a plurality of threads started from the same function address, the thread ID of the thread is stored in the thread correspondence table 223 in the order of creation of the thread.

  As described above, the thread correspondence table 223 is updated by the lock / thread association unit 222 when a thread creation request is output from the monitoring target application 11 and a thread is created according to the thread creation request.

  In the example shown in FIG. 13, the thread correspondence table 223 holds the thread ID “T1 → T2” in association with the function address “F1” at the start of the thread. According to this, it is indicated that the thread IDs for identifying the thread whose function address is “F1” at the start of the thread are “T1” and “T2”. Further, it is shown that the threads are created in the order of the thread identified by T1 and the thread identified by T2.

  The thread correspondence table 223 holds a thread ID “T3 → T4 → T5” in association with the function address “F2” at the start of the thread. This indicates that the thread IDs for identifying the thread whose function address at the start of the thread is “F2” are “T3”, “T4”, and “T5”. Further, it is shown that the threads are created in the order of the thread identified by T3, the thread identified by T4, and the thread identified by T5.

  The thread correspondence table 223 indicates that, for example, when the monitoring target application 11 is restarted or when failover is executed and the monitoring target application 11 is started to take over the processing of the active node, the thread correspondence table 223 Used to correlate with startup. Therefore, if the creation order of threads started at the same function address is different, the thread association fails, but in general applications, the same function thread creation order is often the same. . In particular, in the HA cluster system, since the service is continued, in most cases, it is set to perform the same operation after the takeover as before the takeover, and therefore the thread creation order is the same. Therefore, in the present embodiment, it is assumed that the creation order of threads started at the same function address is the same.

  FIG. 14 shows an example of the data structure of the lock correspondence table 224 shown in FIG. As shown in FIG. 14, the lock correspondence table 224 includes a thread ID for identifying a thread constituting the monitoring target application 11 and a lock created by the lock creation unit 212 in response to a lock creation request from the thread. Addresses are stored in association with each other.

  For example, if there are a plurality of lock addresses created by the lock creation unit 212 in response to a lock creation request from the same thread, the lock addresses are held in the lock correspondence table 224 in the order of creation.

  As described above, the lock correspondence table 224 is output by the lock / thread association unit 222 when a lock creation request is output from a thread constituting the monitoring target application 11 and a lock is created according to the lock creation request. Updated.

  In the example illustrated in FIG. 14, the lock correspondence table 224 holds the lock address “L1 → L2” in association with the thread ID “T1”. According to this, it is indicated that the locks whose lock addresses are “L1” and “L2” were created in response to a lock creation request from the thread identified by the thread ID “T1”. Further, it is indicated that the locks are created in the order of the lock having the lock address “L1” and the lock having the lock address “L2”.

  Further, the lock correspondence table 224 holds a lock address “L3 → L4 → L5” in association with the thread ID “T2”. According to this, it is indicated that the locks whose lock addresses are “L3”, “L4”, and “L5” were created in response to a lock creation request from the thread identified by the thread ID “T2”. . Further, it is shown that the locks are created in the order of a lock whose lock address is “L3”, a lock whose lock address is “L4”, and a lock whose lock address is “L5”.

  Similar to the thread correspondence table 223 described above, the lock correspondence table 224 also assumes that the lock creation order in the same thread is the same.

  FIG. 15 shows an example of the data structure of deadlock status information stored in the shared disk 30. The deadlock status information includes a thread, a lock that stops other threads (a lock that is being locked), and a lock that is being requested for acquisition. Further, in the deadlock status information, the thread included in the deadlock status information, the lock that stops other threads, and the lock that is in the acquisition request are not shown in FIG. And the function address and thread and lock creation order as shown in FIG. Here, description will be made with reference to FIGS. 13 and 14 as appropriate.

  Here, it is assumed that the deadlock status information shown in FIG. 15 indicates a deadlock (deadlock in FIG. 6) like the lock acquisition state shown in FIG.

  As shown in FIG. 15, the deadlock status information indicating the deadlock of FIG. 6 includes “first of F1” as a thread and “first of the first thread of F1” as a lock that stops other threads. As a lock in the acquisition request, “first of the second thread of F1” is associated and included.

  The “first of F1” is a thread identified by the thread ID associated with the function address “F1” in the thread correspondence table 223, and represents the first created thread. That is, the example of the thread correspondence table 223 shown in FIG. 14 represents a thread identified by T1.

  “First of the first thread of F1” is a lock associated with “the first thread of F1 (here, the thread identified by T1)” in the lock correspondence table 224 shown in FIG. Represents the first created lock (here, the lock whose lock address is “L1”).

  Similarly, “the first of the second threads of F1” is associated with “the second thread of F1 (here, the thread identified by T2)” in the lock correspondence table 224 illustrated in FIG. This is a lock and represents the first created lock (here, a lock whose lock address is “L3”).

  The same applies to threads other than those described above in FIG. 15, locks that stop other threads, and locks that are in acquisition requests.

  In the deadlock status information, by using the way of expressing deadlock as described above, for example, even when different thread IDs are given among a plurality of nodes 200 even though they are the same thread, etc. By using the order in which threads are created, it is possible to associate threads between different nodes. The same applies to the lock (address).

  Next, with reference to FIG. 16, the flow of the above-described process for creating a new thread (thread creation process) will be described. For example, when the monitored application 11 is restarted in the node 200 or when failover is performed, the thread creation process is executed when the monitored application 11 is operated as the active node. It is executed when activated.

  First, for example, when the monitoring target application 11 is activated, the monitoring target application 11 outputs a thread creation request to the OS 210 in order to request thread creation. This thread creation request is made by designating a function address when the monitoring target application 11 starts a thread.

  The API hook unit 221 of the jacket library 220 hooks a thread creation request from the monitoring target application 11. When the thread creation request is hooked, the API hook unit 221 executes the thread creation API (thread creation unit 211) of the OS 210 (step S71). At this time, the API hook unit 221 outputs a thread creation request to the thread creation unit 211.

  The thread creation unit 211 of the OS 210 executes a thread creation process in response to the thread creation request output by the API hook unit 221 (step S72). At this time, the thread creation unit 211 creates a thread based on the function address specified in the thread creation request.

  When the thread creation process is executed, the thread creation unit 211 outputs a thread ID for identifying the created thread to the monitoring target application 11 as a response to the thread creation request.

  The API hook unit 221 of the jacket library 220 hooks the thread ID (response to the thread creation request) from the OS 210 (the thread creation unit 211). When the thread ID is hooked, the API hook unit 221 executes the lock / thread association unit 222 (step S73). At this time, the API hook unit 221 outputs the hooked thread ID to the lock / thread association unit 222.

  When the lock / thread association unit 222 is executed by the API hook unit 211, the lock / thread association unit 222 updates the thread association table 223 (step S74). The lock / thread association unit 222 registers the function address specified in the thread creation request and the thread ID output by the API hook unit 221 in association with each other in the thread association table 223.

  After the above process is executed, the process is terminated when the API hook unit 221 returns a thread ID as a response to the thread creation request to the monitoring target application 11.

  Next, with reference to FIG. 17, the flow of the above-described process for creating a new lock (lock creation process) will be described. This lock creation process is executed, for example, after a thread is created in the thread creation process described above.

  First, for example, when a thread is created as shown in FIG. 16 described above, the thread outputs a lock creation request to request creation of a new lock as necessary.

  The API hook unit 221 of the jacket library 220 hooks a lock creation request from the monitoring target application 11. When the lock creation request is hooked, the API hook unit 221 executes the lock creation API (lock creation unit 212) of the OS 210 (step S81). At this time, the API hook unit 221 outputs a lock creation request to the lock creation unit 212.

  The lock creation unit 212 of the OS 210 executes lock creation processing in response to the lock creation request output by the API hook unit 221 (step S82).

  When the lock creation process is executed, the lock creation unit 212 outputs the address of the created lock to the monitoring target application 11 as a response to the lock creation request.

  The API hook unit 221 hooks a lock address (response to a lock creation request) from the OS 210 (lock creation unit 212). When the lock address is hooked, the API hook unit 221 executes the lock / thread association unit 222 (step S83). At this time, the API hook unit 221 outputs the address of the hooked lock to the lock / thread association unit 222.

  When the lock / thread association unit 222 is executed by the API hook unit 211, the lock / thread association unit 222 inquires of the OS 210 about a thread ID for identifying a thread that is a request source of the lock creation request. As a result, the lock / thread association unit 222 acquires the thread ID of the thread that is the request source of the lock creation request (step S84).

  Next, the lock / thread association unit 222 updates the lock correspondence table 224 (step S85). The lock / thread association unit 222 registers the lock address output by the API hook unit 221 and the acquired thread ID in the lock correspondence table 224 in association with each other.

  After the processing described above is executed, the processing is ended when the lock address is returned to the monitoring target application 11 as a response to the lock creation request by the API hook unit 221.

  Next, with reference to FIG. 18, the flow of processing when a lock is acquired by a thread constituting the monitoring target application 11 will be described.

  First, the thread configuring the monitoring target application 11 outputs a lock acquisition request for occupying resources to the OS 210. This lock acquisition request includes the address of the lock acquired in response to the lock acquisition request.

  The API hook unit 221 of the jacket library 220 hooks a lock acquisition request from a thread constituting the monitoring target application 11. When the lock acquisition request is hooked, the API hook unit 221 executes the suspend determination unit 228 (step S91). At this time, the API hook unit 221 outputs the lock address included in the hooked lock acquisition request to the suspend determination unit 228.

  When the suspend determination unit 228 is executed by the API hook unit 221, the suspend determination unit 228 inquires the OS 210 about a thread ID for identifying the thread that is the request source of the lock acquisition request hooked by the API hook unit 221. Accordingly, the suspend determination unit 228 acquires the thread ID of the thread that is the request source of the lock acquisition request (step S92).

  The suspend determination unit 228 executes the lock executed in response to the lock acquisition request based on the lock address output by the API hook unit 221, the acquired thread ID, and the deadlock status information stored in the shared disk 30. A process of determining whether to suspend the acquisition process (hereinafter referred to as a suspend determination process) is executed (step S93). At this time, the suspend determination unit 228 executes the suspend determination process with reference to the thread correspondence table 223, the lock correspondence table 224, and the lock state table 133. Details of the suspend determination process will be described later.

  Next, steps S94 to S103 corresponding to steps S11 to S20 shown in FIG. 7 described above are executed, and the process is terminated.

  On the other hand, if it is determined in step S98 that the deadlock has been detected by the deadlock detection unit 225, the deadlock detection unit 225 executes the deadlock information creation unit 226 (step S104). The deadlock detection unit 225 requests the deadlock information creation unit 226 to create deadlock status information.

  At this time, since the occurrence of a deadlock is detected by the deadlock detector 225, the lock acquisition state registered in the lock state table 133 represents a deadlock. Therefore, the deadlock information creation unit 226 creates deadlock status information indicating a deadlock based on the lock acquisition state registered in the lock state table 133. At this time, the deadlock information creation unit 226 refers to the thread correspondence table 223 and the lock correspondence table 224, and uses the function address and the thread and lock creation order as shown in FIG. create.

  The deadlock information creation unit 226 stores the created deadlock status information in the shared disk 30.

  Next, the process of step S106-step S108 equivalent to the process of step S21-step S23 shown in FIG. 7 mentioned above is performed, and a process is complete | finished.

  Next, the processing procedure of the suspend determination process by the suspend determination unit 228 will be described with reference to the flowchart of FIG.

  The suspend determination process by the suspend determination unit 228 is executed when the suspend determination unit 228 receives a request from the API hook unit 221 as described above. The API hook unit 221 outputs a request to the suspend determination unit 228 when a lock acquisition request from the monitoring target application 11 is hooked. At this time, the suspend determination unit 228 acquires the lock address included in the lock acquisition request from the API hook unit 221.

  The suspend determination unit 228 determines whether or not deadlock status information has been read from the shared disk 30 by the deadlock information reading unit 227 (read already) (step S111).

  When it is determined that the deadlock status information has not been read (NO in step S111), the suspend determination unit 228 executes the deadlock information reading unit 227 (step S112). The suspend determination unit 228 requests the deadlock information reading unit 227 to read deadlock status information. The deadlock information reading unit 227 reads deadlock status information stored in the shared disk 30 in response to a request from the suspend determination unit 228.

  The suspend determination unit 228 acquires the deadlock status information read by the deadlock information reading unit 227 (step S113).

  Next, the suspend determination unit 228 determines whether or not to suspend the lock acquisition process according to the lock acquisition request hooked by the API hook unit 221 (step S114).

  The suspend determination unit 228 determines that the lock acquisition process should be suspended, assuming that a deadlock may occur in the future, for example, when predetermined first and second conditions are satisfied. At this time, the suspend determination unit 228 executes determination processing based on the acquired lock address, thread ID, and deadlock status information. The suspend determination unit 228 executes determination processing with reference to the thread correspondence table 223, the lock correspondence table 224, and the lock state table 133. In addition, although it demonstrates as what has two conditions (1st and 2nd conditions) here, the said conditions are not restricted to two. That is, the number of conditions may be two or more. Hereinafter, an example of the first and second conditions will be described.

  In the determination process by the suspend determination unit 228, the thread identified by the acquired thread ID is a thread included in the deadlock status information, that is, the thread is executed at the time of deadlock indicated by the deadlock status information. It is assumed that it is in the middle. In addition, other threads in which the lock acquired in response to the lock acquisition request hooked by the API hook unit 221 (the lock acquisition state based on the combination of the acquired thread ID and the lock address) is included in the deadlock status information. It is assumed that it is a lock that is stopped (will stop).

  The first condition described above is that the acquired deadlock status information is a lock (deadlock status) that stops the “lock during acquisition request” associated with the thread identified by the acquired thread ID. The “lock that stops other threads”) included in the information is acquired by the “thread” associated with the lock.

  The second condition described above corresponds to “lock during acquisition request” included in the deadlock status information that is stopped by the lock acquired in response to the lock acquisition request hooked by the API hook unit 221. The attached thread acquires the “lock that stops other threads” included in the deadlock status information in association with the thread.

  When the first and second conditions are satisfied, the suspend determination unit 228 determines that there is a possibility of falling into the same situation as the deadlock indicated by the acquired deadlock situation information. Therefore, in this case, it is determined that the lock acquisition process corresponding to the lock acquisition request hooked by the API hook unit 221 should be suspended.

  Here, with reference to FIG. 20, the process of step S114 shown in FIG. 19 will be specifically described. FIG. 20 is a diagram illustrating an example of a relationship between a lock acquired in response to a lock acquisition request hooked by the API hook unit 221 in the lock state table 133 and an already acquired lock.

  The deadlock status information acquired by the suspend determination unit 228 will be described as indicating the deadlock of FIG. In FIG. 20 and FIG. 6 described above, it is assumed that the thread IDs “T1” to “T4” and the lock addresses “L1” to “L4” correspond to each other.

  The address of the lock acquired in response to the lock acquisition request hooked by the API hook unit 221 (the address of the lock acquired by the suspend determination processing unit 228) is “L3”, and the request source of the lock acquisition request It is assumed that the thread ID (thread ID acquired by the suspend determination processing unit 228) for identifying the thread is “T2”. That is, it is assumed that the lock acquisition state in the shaded area in FIG. 20 is “locking”. Hereinafter, the lock (hatched portion in FIG. 20) acquired in response to the lock acquisition request hooked by the API hook unit 221 is referred to as a target lock.

  First, in the example illustrated in FIG. 20, the thread identified by the thread ID “T2” acquired by the suspend determination unit 228 (hereinafter simply referred to as “T2”) is indicated by deadlock status information (hereinafter referred to as “T2”). , Simply described as deadlock). In addition, the target lock is a lock that stops other threads (here, “T1”) when deadlock occurs. Therefore, the target lock satisfies the above-described assumption.

  Here, as shown in FIG. 20 and FIG. 6 described above, there is a lock that stops a lock that is being requested for acquisition at “T2” at the time of deadlock (here, a lock whose lock address is “L4”). , “T4”. Therefore, the target lock satisfies the first condition described above.

  Further, as shown in FIG. 20 and FIG. 6 described above, a thread (here, “a lock whose lock address is“ L3 ”) that is to be stopped by the target lock” (here “ T1 ") has acquired a lock (here, a lock whose lock address is" L1 ") that stops another thread (here," T4 ") at the time of deadlock. Therefore, the target lock satisfies the second condition described above.

  Therefore, when the target lock is acquired, the lock of “L3” is released before the lock whose lock address is “L1” (hereinafter referred to as “L1” lock) is “T2”. Tried to acquire the lock of “L4” before releasing the lock of “L3”, and acquired the lock of “L1” before releasing the lock of “L4” to “T4” (the lock acquisition request was output ), There is a possibility of falling into the same situation as the deadlock shown in FIG.

  Since the first and second conditions described above are examples, the suspend determination process is executed under conditions other than the first and second conditions as conditions for suspending the lock acquisition process. It doesn't matter.

  Referring back to FIG. 19 again, if it is determined that the suspension should be suspended (YES in step S114), the lock acquisition process in response to the lock acquisition request hooked by the API hook unit 221 is performed for a predetermined time (a fixed time). ) Suspended (step S115).

  Next, after suspending for a predetermined time in step S115, it is determined whether or not the process of step S115 has been executed n times (step S116). This n is a predetermined value.

  If it is determined that the process of step S115 has been executed n times (YES in step S116), the process ends. That is, the lock acquisition process corresponding to the lock acquisition request hooked by the API hook unit 221 is executed. On the other hand, when it determines with the process of step S115 not being performed n times (NO of step S116), it returns to step S114 and a process is repeated.

  If it is determined in step S111 that deadlock status information has been read, the process of step S114 is executed.

  If it is determined in step S114 that it should not be suspended, the process ends without being suspended. That is, the lock acquisition process corresponding to the lock acquisition request hooked by the API hook unit 221 is executed.

  Here, although it has been described that the suspend process is terminated when the process (suspend process) in step S115 is executed n times, the lock acquisition process is not executed until it is determined in step S114 that the suspend process should not be performed. In other words, the configuration may be such that the suspend process is continued.

  When a plurality of deadlock status information is stored in the shared disk 30, the above-described processing shown in FIG. 19 is executed for all the plurality of deadlock status information.

  As described above, in this embodiment, for example, when occurrence of a deadlock is detected in the node 200, deadlock status information indicating the deadlock is stored in the shared disk 400. In the present embodiment, when a lock acquisition request is hooked by the API hook unit 221 of the node 200, whether or not there is a possibility of falling into a deadlock when a lock acquisition process according to the lock acquisition request is executed. By determining based on the deadlock status information, the lock acquisition process can be suspended. Thereby, in the present embodiment, it is possible to reduce the probability that a deadlock having the same condition as a deadlock that has occurred in any of the plurality of nodes 200 occurs. Thus, in the present embodiment, it is possible to improve the availability of the cluster system by reducing the probability that an application failure will occur.

  In the present embodiment, when it is determined that there is a possibility of deadlock, the lock acquisition process is suspended only for a predetermined time, thereby minimizing the influence on the operation of the monitored application 11. It is possible.

  Note that the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Further, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine the component covering different embodiment suitably.

1 is a block diagram showing a functional configuration of a cluster system according to a first embodiment of the present invention. The block diagram which mainly shows the function structure of the node 10 shown in FIG. The figure which shows an example of the data structure of the lock state table 133 shown in FIG. The figure for demonstrating the update of the lock state table 133 by the lock state management part 132. FIG. The flowchart which shows the process sequence of the detection process of the occurrence of the deadlock of the deadlock detection part 134. The figure which shows an example of the lock state table 133 showing the acquisition state of a lock | rock when a deadlock occurs. The figure for demonstrating the flow of a process when a lock | rock is acquired by the thread | sled which comprises the monitoring object application. The figure for demonstrating the flow of a process when a lock is released by the thread | sled which comprises the monitoring object application. The block diagram which mainly shows a function structure of the node 100 with which the cluster system which concerns on the 2nd Embodiment of this invention is equipped. The figure for demonstrating the flow of a process when a lock is acquired by the thread | sled which comprises the process 110a. The figure for demonstrating the flow of a process when a lock is released by the thread | sled which comprises the process 110a. The block diagram which mainly shows the function structure of the node 200 of the cluster system which concerns on the 3rd Embodiment of this invention. The figure which shows an example of the data structure of the thread | sled corresponding table 223 shown in FIG. The figure which shows an example of the data structure of the lock corresponding | compatible table 224 shown in FIG. The figure which shows an example of the data structure of the deadlock status information stored in the shared disk 30. The figure for demonstrating the flow of a thread creation process. The figure for demonstrating the flow of a lock creation process. The figure for demonstrating the flow of a process when a lock | rock is acquired by the thread | sled which comprises the monitoring object application. The flowchart which shows the process sequence of the suspend determination process by the suspend determination part 228. The figure showing an example of the relationship between the lock acquired according to the lock acquisition request hooked by the API hook part 221 in the lock state table 133, and the already acquired lock.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10,100,200 ... Node (computer), 11 ... Monitored application, 12, 210 ... OS, 13, 130a, 130b, 220 ... Jacket library, 14 ... HA cluster daemon (failover means), 30 ... Shared disk (storage) Means), 121 ... Lock acquisition part, 122 ... Lock release part, 131, 221 ... API hook part (acquisition means), 132, 136 ... Lock state management part (lock management means), 123, 133 ... Lock state table, 134 , 137, 225 ... deadlock detection unit, 135 ... deadlock notification unit, 211 ... thread creation unit, 212 ... lock creation unit, 222 ... lock / thread association unit, 223 ... thread correspondence table, 224 ... lock correspondence table, 226 ... Deadlock information creation unit, 227 ... Deadlock Click information reading unit, 228 ... suspend determination unit.

Claims (7)

A computer that executes a plurality of threads that share resources;
The calculator is
An acquisition means for acquiring a lock acquisition request for requesting acquisition of a lock for occupying the resource from each of the plurality of threads;
Based on the acquired lock acquisition request, a lock state table in which acquisition states of locks by the plurality of threads are registered;
A computer system comprising: a detecting unit that detects occurrence of a deadlock based on the acquired lock acquisition request and a lock acquisition state registered in the lock state table.   The computer system according to claim 1, further comprising a failover unit that takes over the processing of the computer to a computer different from the computer when the detection unit detects the occurrence of a deadlock. Further comprising storage means accessed by the computer;
The calculator is
When the occurrence of the deadlock is detected, the deadlock status information indicating the deadlock represented by the lock acquisition status registered in the lock status table is created, and the created deadlock status information is Creating means for storing in the storage means;
A read unit that reads deadlock status information stored in the storage unit when a lock acquisition request is acquired from each of the plurality of threads by the acquisition unit;
The lock registered in the lock state table indicates whether there is a possibility of falling into a deadlock indicated by the read deadlock status information when a lock is acquired in response to the acquired lock acquisition request. Determining means for determining based on the acquisition state of
The computer system according to claim 2, further comprising: a suspend unit that suspends lock acquisition processing according to the acquired lock acquisition request when it is determined that there is a possibility of falling into the deadlock.   4. The computer system according to claim 3, wherein the suspend unit suspends for a predetermined time. When a lock is acquired in response to the acquired lock acquisition request, the lock acquisition state is registered in the lock state table as the acquisition state of the lock, and a lock acquired in response to the lock acquisition request is registered. Lock management means for registering in the lock state table that the lock is being acquired as the lock acquisition state when acquired by a thread other than the thread that is the request source of the lock acquisition request;
The detecting means refers to the lock state table to detect the occurrence of the deadlock when a loop that is registered in the lock state table and a lock request is generated between the plurality of threads. The computer system according to claim 1. A program that executes a plurality of threads that share resources and is executed by a computer having a lock state table,
In the calculator,
Obtaining a lock acquisition request for requesting acquisition of a lock for occupying the resource from each of the plurality of threads;
Registering the lock acquisition state by the plurality of threads in the lock state table based on the acquired lock acquisition request;
Detecting the occurrence of a deadlock based on the acquired lock acquisition request and the lock acquisition status registered in the lock status table. In the calculator,
When the occurrence of the deadlock is detected, taking over the processing of the computer to a computer different from the system computer;
When the occurrence of the deadlock is detected, the deadlock status information indicating the deadlock represented by the lock acquisition status registered in the lock status table is created, and the created deadlock status information is Storing in storage means accessed by the computer;
When a lock acquisition request from each of the plurality of threads is acquired, reading deadlock status information stored in the storage unit;
The lock registered in the lock state table indicates whether there is a possibility of falling into a deadlock indicated by the read deadlock status information when a lock is acquired in response to the acquired lock acquisition request. Determining based on the acquisition state of
The program according to claim 6, further executing a step of suspending lock acquisition processing according to the acquired lock acquisition request when it is determined that there is a possibility of falling into the deadlock.

Images