JP2014119964A - Computer system and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method for automatically detecting a deadlock in software operating in a multithread environment without modification of a kernel for solving the deadlock and solving the deadlock state without a failover.SOLUTION: A deadlock is solved by collecting and storing exclusive control information of a thread, detecting a deadlock from the information, evading the deadlock by adding exclusive control, and restoring to a state before the deadlock in the case of occurrence of a deadlock.

Description

  The present invention relates to a computer system and a program, and more particularly, to a computer system and a program for detecting a deadlock in a computer system that operates in a multi-thread and avoiding it before occurrence of deadlock and eliminating it after occurrence of deadlock.

  In recent years, software operating in a multi-thread environment has become widespread in various systems. In a multi-thread environment, an OS (Operating System) manages execution units in software using threads. In the OS, a CPU (Central Processing Unit) schedules time allocation for threads. The thread can operate only for a time allocated by the OS from the CPU time.

  Therefore, in a multi-thread environment including a plurality of CPUs, threads can be executed in parallel to increase the speed. However, a problem called deadlock occurs when the processes are executed in parallel.

  Here, deadlock means that when processing units such as a plurality of threads or processes share resources, processing units that are omission of resource release or occupy resources (Lock) continue to wait for resource release (Unlock), The process cannot be resumed and is stopped. Here, a process is an execution unit of a program and holds variables and states used in the program and is composed of one or more threads.

  The process in which the deadlock occurred does not terminate abnormally. For this reason, software users and developers do not notice immediately after the occurrence of an abnormality. Even if a software developer notices an abnormality, it takes time to check and analyze the behavior of the thread. Therefore, technology for preventing and solving deadlocks becomes important.

  Patent Document 1 adds a global lock, focusing on the point that deadlock occurs between threads that acquire double or more locks. In other words, a constraint for acquiring a global lock is provided for a thread that acquires a double or more lock. This limits threads that acquire double or more locks and prevents deadlocks. Furthermore, instead of acquiring global locks uniformly, performance degradation is suppressed by adding conditions.

  Further, in Patent Document 2, API function hooks are performed for lock acquisition and release, information on “locking” and “lock acquisition” is acquired for each shared resource for each thread, and deadlock is performed by the combination thereof. Computer systems and programs for detection have been proposed. Here, the API function is an interface for application and software development provided by the OS and middleware, and is provided in the form of a common library. The API function hook means to intercept the API function processing and to perform the processing uniquely defined by the user. Further, “locking” means a state in which another thread cannot access the resource because the thread is occupying the resource. On the other hand, “lock acquisition in progress” is a state in which a lock is made after waiting for a resource occupied by another thread to be released.

  Patent Document 2 combines these pieces of information. Specifically, the resource 1 is “locked” and the resource B is “lock acquired”, and the resource A is “lock acquired” and the resource B is “ If the thread 2 that is “locked” exists at the same time, it can be detected as a deadlock that keeps waiting for resources to be released from each other. After the deadlock is detected, the occurrence path is memorized and failed over to the redundant system, thereby preventing the recurrence of the deadlock at the failover destination. Here, the failover is an operation in which data is synchronized in a redundant computer during normal operation, data is transferred from the computer in which a failure has occurred to the remaining normal computers, and the processing is continued.

Japanese Patent Application Laid-Open No. 07-191944 JP 2009-271858 A

  The technique described in Patent Document 1 requires that locks be acquired continuously, and all necessary locks are known in advance at the time of acquiring multiple locks. In an actual program, since necessary locks differ depending on paths, it is difficult to acquire all necessary locks in advance, and deadlock occurs when all necessary locks cannot be acquired.

The technique described in Patent Document 2 can prevent the recurrence of deadlock. However, it is necessary to perform failover every time a deadlock occurs in another route. During failover execution, processing that must be executed cannot be executed, and the service that the user wants to provide is affected. Failover should be avoided as much as possible, because failover is not possible without a switchable computer.
Even if Patent Document 1 and Patent Document 2 are combined, there is no return means after the occurrence of deadlock, so that it cannot be solved easily.

  According to a typical embodiment of the present invention, a computer system that executes a plurality of threads, the computer system including at least one processor and a memory, and a first thread in software operating in the computer system. And a monitoring information area for executing the monitoring thread for monitoring the first thread and holding the exclusive control information of the first thread, an area and information for deadlock avoidance for the first thread, The save area for restoring the memory contents is held in the memory, the first thread and the monitoring thread store exclusive control information in the monitor information area, and the first thread stores the memory contents in the save area The monitoring thread detects a deadlock from the monitoring information area, and the monitoring thread de- When exclusive control is added to the lock avoidance area and a deadlock occurs in the first thread, the deadlock is prevented by returning the processing of the first thread to the save position and restoring the memory contents from the save area. Eliminate.

  The problem described above is a computer system that executes a plurality of processing threads and a monitoring thread in parallel, and includes a processor and a memory, and the processing threads collect and accumulate exclusive control information, and multiple exclusive control information To the monitoring thread, and when the monitoring thread accumulates the multiple exclusive control information and detects a combination that causes a deadlock between the multiple exclusive control information, the monitoring thread returns to the return location of the multiple exclusive control information of the combination. This can be achieved by a computer system that adds exclusive control.

  In addition, the computer collects and accumulates exclusive control information, a processing thread that transmits multiple exclusive control information to the monitoring thread, a combination that accumulates the multiple exclusive control information and causes a deadlock between the multiple exclusive control information. When detected, this can be achieved by a program that functions as a monitoring thread that adds exclusive control to the return location of the multiple exclusive control information of the combination.

  According to the present invention, it is possible to automatically detect a deadlock and return from a deadlock state to a normal state without performing a failover.

It is a hardware block diagram of a communication apparatus. It is a figure explaining the thread | sled structure and process content of the apparatus which performs a deadlock monitoring. It is a figure explaining a lock record and a multiple lock record. It is a flowchart of a Lock instruction. It is a flowchart of a lock instruction with a hook. It is a flowchart of an Unlock instruction. It is a flowchart of a hooked Unlock instruction. It is a figure explaining a lock record table. It is a figure explaining a multiple lock record table. It is a processing flowchart of a multiple lock record. It is a flowchart which shows the flow of a deadlock detection, avoidance, and cancellation. It is a flowchart of a deadlock detection. It is a flowchart of deadlock avoidance. It is a flowchart of deadlock cancellation. It is a figure explaining the process which restores the memory contents to the state before the occurrence of deadlock.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings using examples. The same reference numerals are assigned to substantially the same parts, and the description will not be repeated.

The first embodiment describes a computer that repeats a specific process like a communication device.
With reference to FIG. 1, a hardware communication apparatus having a minimum configuration will be described. In FIG. 1, the communication device 100 includes a processor 101, a memory 102, and an NIF (Network InterFace) 103.

  The processor 101 is an arithmetic device such as a CPU, and executes software such as an OS and application programs. The memory 102 is a main storage device, and stores a program execution binary and data used by the program when the processor 101 executes software. The NIF 103 is an interface for transmitting and receiving packets to and from a device different from the communication device 100. Since the hardware blocks are connected to each other via the buses 110-1 and 110-2, it is possible to transmit command messages and data to each other.

  In order to apply this embodiment, the processor 101 needs to support multitasking. Here, multitasking is a method in which an arithmetic unit executes a plurality of processes while switching a plurality of processes, and most general-purpose computer processors support multitasking.

  The communication device 100 may be physically implemented by one computer, or may be implemented by a virtual computer provided by at least one computer.

  With reference to FIG. 2, a software thread configuration and a hook process for recording a lock will be described. The subroutine shown in FIG. 2 will be described in detail later with reference to the following drawings. In FIG. 2, the thread includes a plurality of processing threads 200 that perform call control of the communication device and the like, and a monitoring thread 210 that determines whether or not the processing thread 200 is operating normally.

  The processing thread 200 waits for an event such as packet reception after the activation (S202). The processing thread 200 receives the packet (S203), processes the packet to be transmitted (S204), and repeats the transmission (S205) operation. Software binaries are not changed from thread activation to packet transmission.

  The processing thread 200 prepares a hook process 220 and a lock record table 700. The hook processing 220 is a set of hook functions that intercept all the Lock instructions 500 and Unlock instructions 600 that are called at the packet processing step 203, the packet processing step 204, and the packet transmission step 205. In the hook process 220, when the Lock instruction 500 is called, a subroutine Lock instruction 550 that is defined separately is called. Further, when the Unlock instruction 600 is called, a subroutine Unlock instruction 650 that is defined separately is called. The subroutine Lock instruction 550 will be described later with reference to FIG. 4, and the subroutine Unlock instruction 650 will be described later with reference to FIG. The hook process 220 temporarily stores the lock record in the lock record table 700. Of these, if it is determined that the record is a multiple lock record, the multiple lock record 450 is added to the queue 230 of the monitoring thread 210.

  When the program counter reaches the subroutine multiple lock record processing 900, the monitoring thread 210 checks whether the multiple lock record 450 is in the queue 230, and if the multiple lock record 450 is in the queue 230, the multiple lock record 450 is checked. A multiple lock record 450 is added to the record table 800. The subroutine multiple lock record processing 900 will be described in detail with reference to FIG.

  According to the procedure described above, the lock information can be recorded in the lock record table 700 without changing the step 202 for thread activation and event waiting, the step 203 for packet reception, the step 204 for packet processing, and the step 205 for packet transmission. it can.

  Further, the monitoring thread 210 determines whether or not it is a check cycle after activation, and performs a deadlock check process (S300) if it is a check cycle, and performs a multiple lock record process (S900) if it is not a check cycle. Repeat the operation. Here, the check cycle may be automatically calculated from the statistics of exclusive control other than the time and number of times specified by the developer or user. The deadlock check process will be described later with reference to FIG.

  In the present embodiment, the monitoring thread 210 repeatedly executes deadlock check processing. As a result, when deadlock is detected and detected before deadlock occurs, deadlock is avoided, and when deadlock is detected at the same time as deadlock occurs, the deadlock state is resolved and deadlock is prevented. Solve automatically. In this embodiment, the monitoring thread is dedicated to monitoring, but it is also possible to give the monitoring thread another role or to add a monitoring operation to the processing thread side. As a result, there is no need to increase the number of threads, and there is an advantage of saving the amount of memory and CPU resources.

  With reference to FIG. 3, the lock record 400 and the multiple lock record 450 used for the detection process of the deadlock check operation will be described.

  In FIG. 3A, the lock record 400 includes a nesting number 401, a lock handle 402, and a return place 403. The lock record 400 is a record of exclusive control managed individually by the processing thread 200. Here, the nest number 401 is the depth of exclusive control. The lock handle 402 is an identifier necessary for exclusive control. The return location 403 is a deadlock saving area.

  3B, the multiple lock record 450 includes an item number 451, a lock order 452, a return place 403, and an additional lock handle 453. The multiple lock record 450 is a record of an exclusive control combination pattern managed by the monitoring thread 210. Here, the item number 451 is an identifier for managing multiple lock records. The lock order 452 is the order in which the lock handle 402 is acquired. The additional lock handle 453 is a lock handle for avoiding deadlock.

  The lock record 400 is managed by the lock record table 700 shown in FIG. Multiple lock record 450 is managed by multiple lock record table 800 shown in FIG. The lock record table 700 is a table managed individually by the processing thread 200. The lock record table 700 indicates the exclusive control acquired by the processing thread 200 at that time. The lock record table 700 is acquired by hooking a lock acquisition instruction (hereinafter, Lock instruction, in this embodiment, pthread_mutex_lock) and a lock release instruction (hereinafter, Unlock instruction, in this embodiment, pthread_mutex_unlock). Here, the hook is processing that intercepts processing and causes the processor 101 to perform processing defined by the user.

  Specifically, it can be realized by an API function hook using a LD_PRELOAD environment variable of a Linux (registered trademark) OS and a shared library. In a state where the LD_PRELOAD environment variable is not specified, the pthread_mutex_lock function and the pthread_mutex_unlock function are set to libpthread. A function of a shared library called so is executed. However, if the shared library file name is specified by the LD_PRELOAD environment variable, the address resolution order from the function name to the function to be executed is changed, and the shared library specified by the LD_PRELOAD environment variable is preferentially searched. By defining the pthread_mutex_lock function and the pthread_mutex_unlock function in the specified shared library, the libthread. The functions of the shared library can be executed before executing the pthread_mutex_lock function and the pthread_mutex_unlock function of the so. In the shared library pthread_mutex_lock function and pthread_mutex_unlock function, By calling the pthread_mutex_lock function and the pthread_mutex_unlock function of the so, a hook to the Lock instruction and a hook to the Unlock instruction can be realized.

  With reference to FIG. 4, the flowchart of the Lock instruction and the flowchart of the Lock instruction with hook will be described. In addition, a flowchart of the Unlock instruction and a flowchart of the Unlock instruction with a hook will be described with reference to FIG.

  In FIG. 4A, when the Lock instruction is started, the processing thread 200 determines whether or not a lock handle can be acquired (S501). If acquisition is possible, the processing thread 200 acquires the lock handle (S504) and ends the processing. If the lock handle cannot be acquired in step 501, the process waits until the lock handle is released (S503), and acquires the lock handle (S504).

  In FIG. 4B, when the lock instruction with hook is started, the processing thread 200 performs a lock record recording addition process (S551). The record addition process for the lock record is a process for registering the lock handle to be acquired in the lock record and adding it to the lock record table 700. After the addition, the processing thread 200 determines whether the nesting number 401 of the lock record table 700 is 2 or more (S552). If the determination result is 2 or more, the processing thread 200 creates a multiple lock record 450 from all the lock records 400 registered in the lock record table 700 and enqueues it in the queue 230 of the monitoring thread 210 (S553). After completion of enqueue and when the number of nestings 401 is less than 2, the processing thread 200 executes a Lock instruction (S500) and completes the hooked Lock function.

In FIG. 5A, when the Unlock instruction is started, the processing thread 200 releases the lock handle (S601), and ends the Unlock instruction.
In FIG. 5B, when the Unlock instruction with hook 650 is started, the processing thread 200 executes the Unlock instruction (S600). The processing thread 200 performs the record deletion processing of the lock record after the processing is completed (S651), and completes the hooked Unlock command.

  The processing thread 200 reflects the acquired lock handle as the latest state in step 551 of the lock record recording process of the lock instruction with hook and step 651 of the recording deletion process of the lock record of the hook instruction with hook. be able to.

  The state transition of the lock handle table 700 will be described with reference to FIG. In FIG. 6, from the state 701 where the lock handle A is acquired by the hook 220, when the lock handle B is acquired with the lock with lock (B), the state becomes the state 702, and when the lock handle B is released with the unlock with hook (B). State 703 is entered.

  In the state 702, since the number of nests 401 is 2 or more, the processing thread 200 creates a multiple lock record 450 in the lock instruction with hook. If the lock record table 700 is in the state 702, the lock order 452 of the created multiple lock record 450 is A → B, the return location 403 is FuncAB, and the created multiple lock record 450 is enqueued in the queue 230 of the monitoring thread 210. The item number 451 and the additional lock handle 453 of the multiple lock record 450 are registered later by the monitoring thread 210. Note that since a deadlock occurs between processing threads 200 that have acquired double or more lock handles 402, a multiple lock record 450 may be created only when the number of nestings 401 is two or more.

  After the processing thread 200 enqueues the multiple lock record 450 in the queue 230, the monitoring thread 210 registers the multiple lock record 450 in the multiple lock record table 800 in the multiple lock record processing 900. The multiple lock record table 800 is a table that stores the multiple lock record 450 shown in FIG. 7 and starts from a state 801 that does not have the multiple lock record 450. FIG. 7 will be described in the flowchart.

  With reference to FIG. 8, a process of adding an unregistered multiple lock record by multiple lock record processing will be described. In FIG. 8, when the multiple lock record process is started, the monitoring thread 210 determines whether there is a multiple lock record in the queue 230 (S901). When there is a multiple lock record, the monitoring thread 210 determines whether it is not registered in the multiple lock record table 800 (S902). If not registered, the monitoring thread 210 registers it in the multiple lock record table (S903), and ends the multiple lock record process. Note that whether or not the multiple lock record is unregistered is determined by whether or not the lock order and the return location match. When the multiple lock record is not in the queue 230 or when the multiple lock record is already registered, the monitoring thread 210 ends the multiple lock record process. By this operation, in FIG. 7, from the state 801 in which the multiple lock record 450 is not held, the unregistered multiple lock record (A → B) is received, and the item number 451 is registered in the order received, thereby entering the state 802. Become.

  As shown in FIG. 2, the monitoring thread 210 performs multiple lock record processing 900 on the multiple lock record table 800 at times other than the check cycle, and performs deadlock check processing 300 shown in FIG. 9 at the check cycle.

  In FIG. 9, when the deadlock check process is started, the monitoring thread 210 executes a deadlock detection process (S310). The monitoring thread 210 determines whether a deadlock has been detected (S320). If YES, the monitoring thread 210 executes deadlock avoidance processing (S330). The monitoring thread 210 determines whether the detected deadlock has occurred (S340). If YES, the monitoring thread 210 executes deadlock elimination processing (S350) and ends. When NO in step 320 or step 340, the monitoring thread 210 ends the deadlock detection process.

  The deadlock detection process will be described with reference to FIG. In FIG. 10, when the deadlock detection process is started, the monitoring thread 210 determines whether there is a multiple lock record that has not been compared (S311). Here, the non-compared multiple lock record is a set of multiple lock records that are not subjected to comparison for deadlock detection among combinations of multiple lock records included in the multiple lock record table 800. At the start of the deadlock detection process, all multiple lock records are not compared. When there are uncompared multiple lock records, the monitoring thread 210 selects candidates X and Y from among them (S312). The monitoring thread 210 determines whether the candidates X and Y have a possibility of deadlock (S313). If there is a possibility of deadlock, the monitoring thread 210 registers it as a deadlock pattern (S314), and returns to step 311. After all the comparisons are completed (S311: NO), the monitoring thread 210 ends.

  As a simple method for determining whether or not there is a possibility of deadlock in step 313, a method is used in which a matching lock handle is extracted from the lock order 452 of the candidates X and Y, and whether or not the order is reversed is determined. Is mentioned.

  Returning to FIG. 7, if the multiple lock record table is in the state 803, only the lock handle A matches and there is no order reversal, so it is determined that no deadlock occurs. Also, if the multiple lock record table is in the state 804, all combinations of three types of multiple lock records are compared, and the lock handles A and B match in the multiple lock records of item number 1 and item number 3, and Since order reversal has occurred, it can be detected as a deadlock.

  Note that since the multiple lock record table 800 accumulates multiple lock records, it is possible to detect even a deadlock having a low occurrence probability from past multiple lock records. However, if the multiple lock records are continuously accumulated, the storage area is compressed, so old information may be deleted as necessary. In addition, since an uncompared multiple lock record 450 is newly registered in the multiple lock record table 800, a deadlock detection process may be executed after step 903 of the multiple lock record process 900.

  The deadlock avoidance process will be described with reference to FIG. In FIG. 11, the monitoring thread 210 receives a combination (at least two) of multiple lock records in which a deadlock has been detected, and confirms whether an additional lock handle 453 is registered in the multiple lock records (S331). . When the additional lock handle 453 is not registered in all the multiple lock records (NO), the monitoring thread 210 newly secures the additional lock handle 453 (referred to as GlobalAB), and sets GlobalAB in the additional lock handle 453 of the multiple lock record. Register (S332) and end the deadlock avoidance process.

  If the additional lock handle 453 has been registered in step 331 (YES), the monitoring thread 210 confirms whether the registered additional lock handle 453 is one type (S333). When the registered additional lock handle 453 is one type (referred to as GlobalXX) (YES), the monitoring thread 210 registers GlobalXX in the unregistered additional lock handle 453 (S334), and ends the deadlock avoidance process. .

When there are a plurality of additional lock handles 453 registered in Step 333 (referred to as GlobalXX and GlobalYY) (NO), the monitoring thread 210 newly secures a lock handle (referred to as GlobalXY) and adds an unregistered additional lock handle 453. Then, GlobalXX and GlobalYY of the received multiple lock record are registered or overwritten with GlobalXY (S335). Further, the monitoring thread 210 overwrites and registers the record in which GlobalXX or GlobalYY is registered in the additional lock handle 453 from the multiple lock table 800 with GlobalXY (S336). The monitoring thread 210 deletes the memory areas of GlobalXX and GlobalYY that have become unnecessary due to the overwrite registration (S337). After the registration of the additional lock handle 453 is completed, the monitoring thread 210 ends the deadlock avoidance process.
Note that there are a plurality of additional lock handles 453 when the number of nests is three or more.

  Specifically, if the multiple lock record table 800 in FIG. 7 is in the state 804, the deadlock avoidance process detects the multiple lock records of item number 1 and item number 3, and registers the additional lock handle 453 for both. Therefore, a state 805 is obtained by newly securing and registering an additional lock handle (GlobalAB).

  The additional lock handle 453 registered in the deadlock avoidance process is scoped locked at the return location registered in the multiple lock record, and is covered with exclusive control to which a portion where a deadlock may occur is added. In the state 804, the lock handles are acquired in the order of (A) → (B) and (B) → (A). However, in the state 805, (GlobalAB) → (A) → (B) ( Since the order is (GlobalAB) → (B) → (A), deadlock can be prevented by GlobalAB. Note that the scoped lock is a mechanism for automatically executing the Unlock instruction after the effective range (scope) of a function or the like after the start of the Lock instruction, and it is possible to prevent omission of resource release.

  Further, by overwriting and registering the additional lock handle 453, a deadlock pattern detected in the past (specifically, A → B → C, D → C → B) and a newly detected deadlock pattern (E → C). Since the same additional lock handle 453 is designated in (B), all deadlocks can be prevented. It is also possible to use only one type of additional lock handle 453 and use the same additional lock handle for all deadlock patterns.

  As the return location 403 of the lock record table 700 and the multiple lock record table 800, it is necessary to specify a location (address on the program) where deadlock can be prevented. The designation method includes a checkpoint method and a function hook method. The checkpoint method is a method in which the software developer explicitly specifies the return location as a checkpoint. On the other hand, the function hook method causes a deadlock because it can be hooked at the start and end of a function by specifying the "-finstrument-functions" option when building the source code of software written in C or C ++. This is a method for automatically designating the start location of a function including a Lock instruction.

  Since deadlock cannot be avoided when deadlock is detected at the same time, deadlock elimination processing is performed. In order to determine whether or not a deadlock has occurred, it is confirmed whether or not there is a response to the processing thread 200 during the check cycle, and there is no response and the lock record table 700 of the processing thread 200 indicates the possibility of deadlock. When the detected multiple lock record is included, the deadlock state is determined.

  With reference to FIG. 12, the deadlock elimination processing will be described. When the deadlock elimination process is started, the monitoring thread 210 sets a return location in the program counter (S351). The monitoring thread 210 restores the memory contents to the state before the deadlock occurred (S352). The monitoring thread 210 releases the lock handle causing the deadlock (S353), and ends the deadlock elimination process.

  The program counter indicates the address of the instruction that the processor 101 executes next on the program. Since each thread holds a program counter, the address of an instruction to be executed next by an arbitrary thread can be changed to an arbitrary address by rewriting the program counter. Therefore, the return location 403 in which the program counter is registered in the multiple lock record table 800 is designated. The processing thread 200 restarts the process from acquiring the additional lock handle (GlobalAB), and prevents the deadlock from recurring.

  Next, there is a possibility that the memory contents are already rewritten at the time of occurrence of the deadlock, and the data being updated is held in the memory. For this reason, data consistency is maintained by returning the memory contents to the state before the deadlock occurs.

  The memory restoration will be described with reference to FIG. In the memory restoration, first, a snapshot of the memory content 1300 before the occurrence of the deadlock is taken in the memory 102, and the memory content is copied (state 1301). Here, by using a named memory map at the time of snapshot, it is possible to search for necessary memory after a deadlock occurs. Thereafter, even if the value of the memory is rewritten as in the state 1302 when the occurrence of deadlock is detected, the memory content can be restored by overwriting the snapshot 1301 in the memory state 1302. Note that if the snapshot is executed within the lock instruction with a hook, the memory contents before the occurrence of the deadlock can be held.

  Returning to FIG. 12, in step 353, among the acquired lock handles of the processing thread 200, the lock handles (A) and (B) that are the cause of the deadlock, and the lock handle acquired between them are released. The processing thread 200 that has stopped waiting for Unlock can resume processing from the return location FuncAB.

As described above, deadlock can be detected, avoided, and resolved.
According to the present embodiment, the precondition that all necessary locks are known in advance at the time of acquiring the multiple lock is not necessary, and can be applied to any software for general purposes. In addition, even if a deadlock occurs, the process can be resumed without performing a failover, so that the software reliability and operating rate can be improved.

  DESCRIPTION OF SYMBOLS 100 ... Communication apparatus, 101 ... Processor, 102 ... Memory, 103 ... NIF, 110 ... Bus, 200 ... Processing thread, 210 ... Monitoring thread, 220 ... Hook, 230 ... Queue, 400 ... Lock record, 450 ... Multiple lock record, 500 ... Lock instruction, 550 ... Lock instruction with hook, 600 ... Unlock instruction, 650 ... Unlock instruction with hook, 700 ... Lock record table, 800 ... Multiple lock record table, 1301 ... Snapshot

Claims (5)

A computer system that executes a plurality of processing threads and a monitoring thread in parallel,
A processor and memory;
The processing thread collects and accumulates exclusive control information, sends multiple exclusive control information to the monitoring thread,
The monitoring thread accumulates the multiple exclusive control information, and when detecting a combination that causes a deadlock between the multiple exclusive control information, adds the exclusive control to the return location of the multiple exclusive control information of the combination. A computer system. The computer system according to claim 1,
The computer system according to claim 1, wherein the processing thread collects the exclusive control information using a hook to a lock acquisition instruction and a lock release instruction. The computer system according to claim 1,
The computer system is characterized in that the monitoring thread hooks at the start of a function including a lock acquisition instruction that causes a deadlock and at the end of a function including a lock release instruction, and specifies a return location. The computer system according to claim 1,
Take a snapshot of the memory contents before the deadlock occurs,
After the deadlock occurs, restore the memory contents from the snapshot,
Change the program counter position to the return position,
A computer system that restores from a deadlock state by releasing exclusive control that caused a deadlock. Computer
A processing thread that collects and accumulates exclusive control information and sends multiple exclusive control information to the monitoring thread,
A monitoring thread that accumulates the multiple exclusive control information and adds exclusive control to the return location of the multiple exclusive control information of the combination when a combination that causes a deadlock between the multiple exclusive control information is detected;
Program to function as.

Images