JP2007072958A - Method and device for detecting deray of event synchronization - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To detect an execution restart delay of a standby thread when a plurality of programs run in cooperation with an event. <P>SOLUTION: When a standby request is received from a thread in relation to a monitoring event, an OS records information indicating standby in a memory. When notification is received in relation to the event, the OS records a notification time in the memory. When execution of the standby sled is restarted, the OS erases corresponding standby record and the appropriate notification time. While the standby record and the appropriate notification record remain, and when a current time passes over a predetermined allowed time or more than the remaining notification time, the OS determines as an execution restart delay of the corresponding thread. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for monitoring the operation of a program executed on a computer, and more particularly to a technique for detecting an operation delay when a program is linked by an event.

  In a computer system that requires a high level of response performance and a computer system in which the time until the completion of processing is strictly defined, it is important that the processing execution of each program is accommodated within a predetermined time. In the construction of such a system, it is important to design the processing time so as to be within a certain time, or to monitor an event in which the processing does not end even if a predetermined time is exceeded.

  In a system constructed using an OS generally referred to as a real-time OS, the processing time of all the processes executed by the computer can be calculated, whereby the operation time of the program executed by the user can be designed in advance. As a result, it is possible to keep processing executed in the system within a certain period of time.

  On the other hand, in a general-purpose OS, the processing time of a program cannot be obtained in advance. This is because processing that cannot be controlled by the user is executed in the OS. In such an OS, it is important to monitor whether or not the program is executing as expected. For this reason, Patent Document 1 realizes a method for managing and displaying the state of a process executing a specific program.

  In addition, a general-purpose OS may incorporate a function that prevents the linkage operation of a plurality of processes from being delayed. For example, Patent Document 2 discloses a method of detecting an abnormality in a program using an exclusive control function used for process linkage operation. In Non-Patent Document 1, since a process with high priority is executed in process scheduling, the priority of the process is temporarily set as a mechanism for running a process that can run but cannot be given a CPU. The method of making it high is disclosed.

  In addition, there is also a general method called a watch dog timer which notifies that a program is normally executed at a constant cycle and monitors the situation.

US Patent 5,636,376 (June 1997) System and method for selectively and contemporaneously monitoring processes in a multiprocessing server JP 2001-5694 A D. Solomon et al., “Windows® Internal 4th Edition,” (Priority Boost for CPU Starvation, pp354-355), Microsoft Press, 2005

  In the conventional technology for general-purpose OS, there is a problem that the linked operation between programs due to a certain event cannot be monitored. In particular, there is a problem that a process waiting for an event notification cannot detect a situation in which it cannot run due to another high priority process in the system despite the event notification. The same applies to threads when a process is executed in units of threads.

  In the operation monitoring of individual programs according to the prior art, there is a problem that it is difficult to determine what causes each program to execute normally. For example, in monitoring by the watchdog timer, the watchdog timer is accessed within a certain period of time in order to notify that the program is operating normally, but this operation does not necessarily indicate that the program is running normally. Because it does not reflect, there is a case that the operation of the program may not be monitored, which is a problem.

  An object of the present invention is to detect an operation delay when a plurality of programs are linked by an event.

  The present invention specifies an event to be monitored in order to monitor a program linkage operation by an event, records a standby for an event notification specified as a monitoring target, records a notification operation, and The technique is characterized by recording a restart of execution and detecting the existence of a thread that does not resume running despite being notified of an event by checking the record.

  According to the present invention, in a system using a general-purpose OS, it is possible to monitor whether or not the cooperation of a program due to a specific event is operating without delay. As a result, it is possible to reliably and quickly detect a case where an unauthorized process occupies the CPU in the system or an event in which a predetermined thread cannot resume execution within a predetermined time due to overload.

  If the present invention is applied to a cluster system composed of a plurality of computers, a delay due to event cooperation can be detected as an abnormality, and a cluster configuration change can be started on that occasion.

  Further, when the present invention is applied to a notification of completion of an asynchronous I / O operation, it is possible to detect a program whose execution cannot be resumed even though the I / O operation is completed.

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

  Example 1 will be described below. FIG. 5 is a diagram illustrating a configuration example of the computer 500 according to the first embodiment. The configuration shown here is an example, and does not limit the configuration of a computer that can implement the present invention.

  The computer 500 includes a CPU 501, a main storage device 502, an external storage device 503, a communication control unit 504, an input / output device, and a control unit that connects them. The CPU 501 executes a program loaded in the main storage device (memory) 502. Hereinafter, it will be described that the CPU executes the program simply that the program executes. In addition, the OS schedules program execution in units of threads.

  The external storage device 503 stores files necessary for execution of the computer 500, such as an OS, a program, a registration program 120 for registering a monitoring target event, and a setting file 520. The main storage device 502 in FIG. 5 shows a state in which the OS, the program 121, and the program 122 are loaded.

  In the OS, event monitoring management data 100 for event linkage monitoring and an event processing unit 511 exist. The OS provides an event object (hereinafter sometimes abbreviated as an event) for cooperation between various processes. A thread can perform a standby operation on an event assigned in the OS. A thread that waits for an event suspends execution and waits until another process performs a notification operation on the event. When another process performs a notification operation for the event, the OS instructs the scheduler to resume execution of the thread waiting for that event.

  In the first embodiment, it is assumed that the program 121 and the program 122 are synchronized by an event. The external storage device 503 holds a setting file 520 related to event monitoring, and the registration program 120 registers a monitoring target event in the OS according to the contents of the setting file 520.

  FIG. 1 is a diagram illustrating a relationship between a data structure and a processing module according to the first embodiment. First, the data structure will be described.

  The OS executed by the computer 500 holds the event monitoring management data 100. The event monitoring management data 100 includes a monitoring event table 101 and a notification list 102. The notification list 102 comprises at least one notification block 103-105. The monitoring event table 101 holds information on events registered as monitoring targets by the registration program 120.

  The monitoring event table 101 holds, for each target event object, the event object address, the allowable time from when the event is notified until the standby thread resumes running, and the standby thread restart status for each event notification operation. The head address of the list 102 is held.

  The notification list 102 records the execution resumption status of a thread waiting when a notification operation is executed for an event. The notification list 102 includes at least one notification block. One notification block is generated by the initialization process, and one notification block is generated and added to the notification list 102 each time each event notification is performed. The notification block holds the number of waiting threads that have not resumed execution after waiting for an event, the notification time when the event notification was accepted, and the address of the next notification block that holds an older event notification record.

  A notification block 103 at the top of the notification list 102 indicates a waiting state of a thread related to the event at that time. The same applies to the notification block 105. A block 104 after the top of the notification list 102 indicates the status of a thread that has been waiting for the event but should resume execution by the event notification. In the example of FIG. 1, the notification list 102 includes notification blocks 103 and 104. Notification block 104 indicates that there are two threads that have been previously notified of the event but have not resumed execution. The notification block 103 indicates that there are three threads waiting for an event at the present time.

  Next, an event operation processing procedure according to the first embodiment will be described. The event processing unit 511 includes an event registration processing unit 111, an event standby processing unit 112, an event notification processing unit 113, and an event monitoring processing unit 114.

  The event registration processing unit 111 registers and deletes event objects in the monitoring event table 101. The registration process receives the name of the event object and the allowable time until the standby thread resumes execution, assigns the specified event object to the thread as necessary, and assigns an entry for the event to the monitoring event table 101 Record the event object's address and allowable time in the entry. Then, the notification list 102 is initialized. In the initialization process, the notification block 103 is assigned as the head of the notification list 102, and the address is recorded in the notification list head address of the entry in the monitoring event table 101.

  The registration process includes registration of an operation when an event linkage delay is detected. In this processing, an identifier indicating the specified abnormal operation is recorded in the abnormal processing mode 110.

  The registration program 120 is executed when the system is started up, and registers an identifier indicating a monitoring target event and an event linkage abnormality process according to the contents of the setting file 520. An example of the setting file 520 is shown in FIG. The setting file 520 specifies an event name and an allowable delay time for event cooperation for each event to be monitored. The setting file 502 also specifies an operation identifier (“panic” in this example) when an event linkage abnormality is detected.

  The event standby processing unit 112 and the event notification processing unit 113 are event linkage processing used by the user program. In the present embodiment, the OS provides a basic event linkage function, and processing for event linkage monitoring is added to it. These processing units record the event cooperation operation with reference to the monitoring event table 101. The processing procedure of each processing unit will be described later.

  The event monitoring processing unit 114 refers to the monitoring event table 101 to check whether there is a thread that has performed an event notification operation but has not resumed execution even after an allowable time has elapsed. The event monitoring processing unit 114 sets a monitoring period at the time of OS initialization processing so that the OS itself is executed in a timer interrupt process accepted by the OS at a constant period. For example, the OS registers the event monitoring processing unit 114 to be executed every second. This period may be settable from the outside. The processing procedure of the event monitoring processing unit 114 will be described later.

  When the event monitoring processing unit 114 finds a thread that is delayed in restarting, the process set in the abnormal time processing mode 110 is executed. As this processing, for example, abnormal termination of the OS, notification of an abnormality to another computer via the communication control unit 504, recording of the occurrence of an abnormality in the main storage device 502, and the like are possible. The processing possible here is not limited to this description.

  The OS provides an OS interface 115 that can be used by a user program. The interface 115 includes an interface for registering event waiting and notification processing and monitoring settings. The registration program 120, the program 121, and the program 122 execute OS event waiting, notification, and registration processing via the interface 115.

  Next, an OS event processing procedure will be described. Here, it is assumed that the program 121 waits for an event notification for a certain event and the program 122 notifies the event.

  FIG. 2 is an event standby process procedure according to the first embodiment. When the program 121 calls the OS event standby process, the event standby processing unit 112 executes the process from step 201. First, the event standby processing unit 112 refers to the monitoring event table 101 and determines whether or not the target event is a monitoring target (step 201). If it is not the monitoring target, the thread that requested the event standby is set in the event standby state (step 211). In this process, the identifier of the thread is registered in the target event object, the thread state is set to the event waiting state, and the thread scheduling process is executed. This is a process equivalent to a general OS event waiting process. When the notification operation for the event is executed, the thread resumes execution and returns to the processing of the program 121.

  If the target event is a monitoring target, the event standby processing unit 112 prohibits an operation on the event (step 202). This is realized by acquiring the lock of the event. Next, 1 is added to the number of waiting threads of the first notification block in the notification list 102 of the event to register that there is a waiting thread (step 203).

  Thereafter, the address of the notification block in which the thread wait is recorded is recorded in the memory area of the thread (step 204), and the thread is set in the event wait state (step 205). The address of the notification block may be recorded in a memory area that stores the stack of the thread being executed. As long as the processing of steps 203 and 204 is processing for recording information indicating standby in association with the thread, other methods may be used. The process of step 205 is the same process as step 211. In the present embodiment, it is assumed that the execution of the thread that requested event waiting is in a waiting state between step 205 and step 206.

  The processes after Step 206 are processes when another process executes the event notification process for the event and the waiting thread resumes execution.

  As will be described in detail in the event notification processing, when the program 122 executes notification processing for an event, a new notification block is inserted at the top of the notification list 102. In the following description, it is assumed that the notification block in which the address is recorded in step 204 is the notification block 104 in FIG.

  When the thread resumes execution, the event waiting processing unit 112 first prohibits the operation for the event (step 206), and calculates 1 from the number of waiting threads of the notification block 104 whose address is recorded in the memory area of the thread. Decrease (step 207). When the number of waiting threads becomes 0 (step 208 yes), it means that all waiting threads related to the notification block have resumed execution. In this case, the event standby processing unit 112 deletes the notification block 104 from the notification list 102 (step 209). The processing in steps 208 and 209 may be processing that erases the standby recording of the corresponding thread recorded in steps 203 and 204.

  Finally, the prohibition of operation for the event is canceled (step 210), and the processing returns to the program 121.

  Next, an event notification processing procedure will be described. FIG. 3 is a procedure of event notification processing according to the first embodiment. When the program 122 calls the event notification process, the event notification processing unit 113 executes the process from step 301.

  First, the event notification processing unit 113 refers to the monitoring event table 101 and determines whether or not the target event is a monitoring target (step 301). If it is not a monitoring target, the event notification processing unit 113 executes a normal event notification operation. That is, the state of the thread waiting in the event is set to run, the identifier of the waiting thread is deleted from the event object, the scheduling request is registered (step 308), and the process ends. The event notification processing unit 113 checks the scheduling request in the process of returning to the program 122, executes the scheduling process of the thread, and the waiting thread resumes running.

  If the event is a monitoring target, the event notification processing unit 113 first prohibits an operation on the target event (step 302). Then, with reference to the number of waiting threads of the first notification block in the notification list 102, it is determined whether or not the thread is waiting (step 303). If not, the process proceeds to step 307, and the event notification process is completed.

  If there is a waiting thread, the event notification processing unit 113 records the current time in the notification time of the first notification block in the notification list 102 (step 304). Next, the event notification processing unit 113 inserts a newly allocated notification block at the top of the notification list 102 in preparation for the subsequent event notification processing (step 305). 0 is set in the “number of waiting threads” of the first notification block. When step 209 is executed, the first notification block in the notification list 102 is an empty block for recording the next event standby and notification. The notification list 102 in FIG. 1 shows the data structure after the notification block 103 is inserted. The notification block in which the notification time is recorded in step 304 is the notification block 104.

  Subsequently, the event notification processing unit 113 requests scheduling so that the waiting thread can run (step 306), cancels the event operation prohibition (step 307), and returns to the processing of the program 122.

  As a result of the above processing, the notification list 102 is a list including a notification block 103 that records the next event notification operation and a notification block 104 that records the thread standby status for the past notification operation. If a thread waiting for an event is normally scheduled and resumes execution, the processing from step 206 deletes the notification block 104 in which the standby status is recorded from the notification list 102. However, if the waiting thread does not resume running, the notification block 104 remains in the list.

  FIG. 4 shows a processing procedure of the event monitoring processing unit 114. In this procedure, the monitoring event table 101 and the notification list 102 are inspected, and a thread whose execution restart is delayed is detected. Hereinafter, this processing procedure will be described.

  The process shown in FIG. 4 is executed for all events registered in the monitoring event table 101. In step 401, the event monitoring processing unit 114 selects a processing target event. When all the events in the monitoring event table 101 have been processed, the processing ends.

  Next, the event monitoring processing unit 114 acquires the event notification list 102 to be processed (step 402), and processes each event notification block included in the list. In step 403, it is determined whether or not all notification blocks in the list have been processed, and if there are remaining notification blocks, one of them is selected. When all the notification blocks have been processed, the process returns to step 401 and is repeated.

  The event monitoring processing unit 114 executes the following processing for the selected notification block. First, when the notification block is at the head of the notification list, the process returns to step 403 to select the next notification block. This is because the top of the notification list is an empty block for recording the next event notification.

  When the notification block is notified of an event and the number of waiting threads is not 0, the event monitoring processing unit 114 adds the allowable time described in the monitoring event table 101 to the notification time described in the notification block. It is checked whether or not it has passed (step 405). If it has not passed, that is, if the number of waiting threads is 0, or if the set allowable time has not passed since the event notification, the process returns to step 403 to select the next notification block.

  If the allowable time has elapsed since the event notification, the OS executes the process specified in the abnormal time processing mode 110 (step 406). When this process is completed and the process returns, the process returns to step 401 to check another event.

  As an alternative method of the first embodiment, for example, each time a standby request is received from a thread, the thread identifier is recorded in a time series in the table, and each time an event notification is received, the notification time is recorded in the time series in the thread identifier. A method of recording, recording the notification time in association with the thread identifier recorded in time series every time there is an event notification, and deleting the notification time corresponding to the thread identifier from the recording each time execution of each thread is resumed But you can. The event monitoring processor 114 determines whether or not a predetermined allowable time has passed beyond the notification time when the current time remains.

  By the event notification, the standby process, and the event monitoring process described above, it is possible to detect a delay in the linkage operation of the program executed through the event linkage operation.

  In the first embodiment, since the event monitoring process from step 401 is executed in the timer interrupt process, even if a high priority process illegally occupies the CPU in the computer 500, the event linkage delay is detected quickly. it can. In addition, since an abnormality process can be executed when an abnormality is detected, it is possible to quickly cope with an event linkage abnormality.

  The first embodiment is particularly effective when configuring a system using a general-purpose OS. That is, in the general-purpose OS, a process that cannot be controlled by the user travels, so that the possibility of event linkage delay is unavoidable. According to the present invention, this delay can be detected, and processing for responding to the delay can be performed.

  In the first embodiment, the data structure of the monitoring event table 101 and the notification list 102 is provided separately from the event object of the OS, but these may be integrated into the event object. For example, an equivalent process can be realized by including data such as a flag indicating whether to be monitored, a delay allowable time, and a notification list address in the event object.

  In the first embodiment, the event monitoring processing unit 114 is executed in the timer interrupt processing, but may be executed by a normal program. In this case, the event monitoring management data 100 needs to be set so that it can be referred to from the program. Further, the priority of the program may be increased, or the execution of the program may be monitored by a watchdog timer.

  Next, Example 2 will be described. In the first embodiment, a general-purpose OS interface is used, and the event processing unit 511 separates operations for monitored events and other events. However, another OS interface may be provided for event monitoring. In the second embodiment, a method is described in which the OS interface 115 related to the monitoring target event is provided separately from the general-purpose event operation interface.

  Here, a configuration in which a new event operation interface is introduced by a device driver is shown. FIG. 7 is a diagram illustrating a configuration of the second embodiment.

  In the second embodiment, the standby process related to the event for which the cooperation delay monitoring is performed is the process from step 202 in FIG. 2, and the notification process is the process from step 302 in FIG. These processing units are mounted in the device driver. However, the processing in step 211 and step 308 is an OS standard event processing, and can be called from the device driver.

  The programs 121 and 122 execute event standby and notification processing according to instructions to the newly introduced device driver. Usually, the OS interface 115 includes an interface for issuing an instruction to the device driver, and the program can execute an event operation using the interface.

  As described above, according to the second embodiment, it is possible to realize an event cooperation process capable of detecting a cooperation delay by using an existing general-purpose OS event cooperation method.

  Next, Example 3 will be described. The third embodiment is characterized by a computer system having a cluster configuration to which the first or second embodiment is applied.

  A cluster-structured computer system is composed of two computers, a primary system and a secondary system. The computer that is the main system performs the actual processing, and the computer that is the secondary system waits for a failure in the main system. When the slave system detects the occurrence of a fault in the master system, it switches to execute as the master system. This is called system switching. According to the cluster configuration, it is possible to continue the processing of the entire system even if a failure occurs in the computer.

  One of the problems in a cluster-structured computer system is to quickly detect a main system failure. The present invention can be used as one of the failure detection methods. Below, it demonstrates using drawing.

  FIG. 8 shows a configuration example of a computer system having a cluster configuration according to the third embodiment and a cluster control procedure. Two computers of the computer 800 and the computer 810 are connected via the communication control units 802 and 812 to form a cluster. The cluster control unit 811 periodically communicates with the cluster control unit 801 via the communication control unit, and always detects whether or not the computer 800 is operating normally. The OS executed on each computer holds the event processing unit 511 and the event monitoring management data 100 of this embodiment. The program executed on each computer executes a linkage operation by event waiting and notification processing in the first and second embodiments. Although not shown in the figure, the registration program 120 registers the specified event in the OS as a monitoring target, and sets the operation at the time of cooperation delay detection as the abnormal termination of the OS.

  For example, the processing flow will be described assuming that the computer 800 is executing as a main system. 850 is a diagram showing the processing flow.

  The programs 803 and 804 on the computer 800 execute processing in cooperation with each other (step 851). Coordinated events may be arbitrary. Here, it is assumed that there is a delay in cooperation due to an event for some reason (step 852). The event monitoring processing unit 114 detects a delay in event cooperation by the processing from step 401 and abnormally terminates the OS (step 853). Here, the meaning of the abnormal termination of the OS is that the computer 800 has terminated abnormally as a system.

  The cluster control unit 811 of the standby computer 810 detects that communication from the computer 800 has been interrupted, determines that the computer 800 that has been the main system has stopped (step 854), and sets the computer 810 as the main system. The program is set to be executed (step 855), and the corresponding program is executed by event cooperation (step 856).

  As described above, detection of event linkage delay and cluster system switching control according to the present invention can be linked. As a result, the type of abnormality that causes cluster system switching can be added, and an abnormality such as event linkage delay can be quickly reflected in a change in system configuration.

  In the above description of the third embodiment, the OS is abnormally terminated when the cooperation delay is detected. Instead, an abnormality may be notified to the partner system via the communication control unit. In this case, it is possible to quickly detect an abnormality.

  The fourth embodiment shows a control procedure for detecting a return delay from an input / output (I / O) operation that starts execution of a program. The fourth embodiment is configured by using the first or second embodiment.

  There are OSs that can execute I / O operations that are expected to take time, such as network reception and disk reading, asynchronously with program execution. Some OSs can notify the program of completion of an asynchronously executed I / O operation by a notification operation for an event assigned by the program.

  By applying the present invention to such an OS, it is possible to detect a failure that delays the resumption of a program that is waiting for I / O completion despite completion of the I / O operation. FIG. 9 shows the processing procedure of the program and OS of the fourth embodiment.

  First, the program assigns an event for notifying the OS of completion of I / O processing (step 901) and registers it as a monitoring target (step 902). Then, the program designates this event as a notification event when I / O is completed, and requests the OS to execute an I / O operation asynchronously (step 903).

  In response to the I / O operation request, the OS starts the instructed I / O operation (step 904). Since the OS is instructed to execute the I / O operation asynchronously, the OS starts the I / O operation and returns control to the program. The program waits at the event assigned to complete the I / O operation (step 905). This event standby process is the event standby process of the first or second embodiment.

  When the I / O operation being executed asynchronously is completed, the OS executes a notification operation for the event designated at the start of the I / O operation and notifies the program of the completion of the I / O (step 906). This event notification process is the event notification process of the first or second embodiment.

  Thereafter, the execution of the program waiting for the event is resumed by the scheduler of the OS (step 907), and the program continues processing.

  When the I / O is completed and the OS executes the event notification operation, but the execution of the program is not resumed, the event monitoring processing unit 114 can detect a delay and execute an abnormal process.

  As described above, according to the present invention, it is possible to detect a program that is delayed in restarting execution for some reason even though the I / O operation is completed and the vehicle can run.

It is a figure which shows the data structure of Example 1, and the structure of a processing module. It is a figure which shows the event standby process procedure of Example 1. FIG. It is a figure which shows the event notification process procedure of Example 1. FIG. It is a figure which shows the procedure which detects the thread | sled which execution resumption of Example 1 is overdue. 3 is a diagram illustrating a configuration of a computer according to Embodiment 1. FIG. It is a figure which shows the example of the content of a setting file. 6 is a diagram illustrating a configuration of Example 2. FIG. FIG. 10 is a diagram illustrating a configuration and a control procedure of a computer system having a cluster configuration according to a third embodiment. FIG. 10 is a diagram illustrating a processing procedure of Example 4.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 ... Monitor event table, 102 ... Notification list, 103 thru | or 105 ... Notification block, 111 ... Event registration process part, 112 ... Event standby process part, 113 ... Event notification process part, 114 ... Event monitor process part, 115 ... OS interface 120, registration program, 121, 122 ... program

Claims (10)

In a computer in which at least one thread executing a program synchronizes with another program processing by an event, a delay detection method for detecting an execution restart delay of the thread,
When receiving a wait request from the thread in relation to the event, recording information indicating that the event is waiting in association with the thread;
Recording a notification time in the memory for each notification when the notification is received from the processing of the other program regarding the event;
When the waiting thread is resumed, the corresponding waiting record and the corresponding notification time are erased.
Determining whether or not the standby record and the corresponding notification record remain, and whether or not a predetermined allowable time has passed from the notification time when the current time remains,
An event-synchronized delay detection method, wherein, when the current time exceeds the allowable time, it is determined that the execution delay of the corresponding thread is delayed.   2. The event synchronization delay detection method according to claim 1, wherein the step of determining whether or not the current time has exceeded the allowable time is executed in a timer interrupt process of an operating system.   Each step of the delay detection method is realized by executing an operating system (OS), and the interface of the waiting request from the thread and the interface of the notification from the processing of the other program are interfaces of a general-purpose OS. 2. The event synchronization delay detection method according to claim 1, wherein the interface is a dedicated interface different from the face.   In a cluster-structured computer system having a first computer that operates as a main system and a second computer that operates as a standby system, when the first computer detects the delay and detects the execution restart delay 2. The event synchronization delay according to claim 1, wherein an abnormal state of the first computer is asserted, and the second computer detects the abnormal state and switches from a standby operation to a main operation. Detection method.   The event is an event for notifying completion of the input / output operation, the thread issues a request for waiting for the completion of the input / output operation, and the processing of the other program is completion of the input / output operation. The event synchronization delay detection method according to claim 1, wherein: A computer comprising a CPU and a memory, wherein at least one thread executing a program synchronizes with another program process and an event, and detects a delay in restarting the execution of the thread, the computer comprising:
Means for recording in the memory information indicating that a wait is made in association with the thread when a wait request is received from the thread with respect to the event;
Means for recording a notification time in the memory for each notification when the notification is received from the processing of the other program regarding the event;
Means for erasing the corresponding waiting record and the corresponding notification time when the waiting thread is resumed;
Means for determining whether or not the standby record and the corresponding notification record remain, and whether or not a predetermined allowable time has passed beyond the notification time when the current time remains;
When the current time has passed the allowable time or more, it is determined that the execution delay of the corresponding thread is delayed.   7. The computer according to claim 6, wherein the means for determining whether or not the current time has exceeded the allowable time is executed in a timer interrupt process of an operating system.   Each means of the computer is realized by executing an operating system (OS), and an interface of a waiting request from the thread and an interface of notification from the processing of the other program are an interface of a general-purpose OS. 7. The computer according to claim 6, wherein each is a different dedicated interface.   A first computer that operates as a main system and a second computer that operates as a standby system constitute a cluster-structured computer system. The computer performs the delay detection as the first computer and resumes execution. 7. An abnormal state of the first computer is asserted when a delay is detected, and the second computer detects the abnormal state and switches from standby system operation to main system operation. Calculator. The event is an event for notifying completion of the input / output operation, the thread issues a request for waiting for the completion of the input / output operation, and the processing of the other program is completion of the input / output operation. 7. The computer according to claim 6, wherein the computer is notified.

Images