JPH0512039A - Trouble detecting mechanism - Google Patents

Abstract

PURPOSE:To prevent tasks from continuing to queue a message and to quickly release the queuing state of the task at the time of the occurrence of trouble by monitoring whether message conversion between tasks is executed within a certain time or not. CONSTITUTION:A timer value C and event information ID are stored in a user area Y, and a queue area Q is provided with a tiger counter 5 and an event flag 6. A response monitor part 1 of an operating system OS is provided with a monitor table 10 which is set at the time of request of trouble monitor from each task. In this case, the trouble occurrence monitor time is dependent upon the timer value C. Each item of the monitor table 10 consists of a queue area address Qa and event information ID reported from each task. The queue area Q is referred to monitor the presence/absence of response for the certain time in response to requests from tasks A and B; and if response is not obtained, the occurrence of trouble is reported to request source tasks A and B to prevent them from continuing to queue a response.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure detection mechanism for detecting a failure that occurs when a plurality of tasks exchange messages with each other and proceed with processing.

[0002]

2. Description of the Related Art OSI (Open Systems Interconnectio)
In the protocol of n), the communication protocol is divided into seven layers. Predetermined protocol processing will be performed for each layer, but in order to perform protocol processing quickly and smoothly, prepare a task for each protocol processing,
Tasks exchange messages with each other to complete protocol processing. An operating system is provided to control and manage a plurality of tasks, and each task will exchange messages via this operating system.

FIG. 2 shows an explanatory diagram of conventional protocol processing. The figure shows a case of waiting for a response (reception of message) after performing notification (transmission of message). In the figure, first, task A sends a message M1 to task B via the operating system OS (step S1). The task A waits for the reception of the message M2 and shifts to the waiting state (step S
2).

On the other hand, in the task B, when the message M1 is received (step S11), a predetermined process (protocol process) is executed based on the message M1 to execute the message M2.
Is generated (step S12). After that, the message M2 is transmitted (step S13), and a waiting state for waiting for a new message from the task A is entered (step S14). When the task A receives the message M2 (step S3), predetermined processing is executed based on the message M2, and the process proceeds to step S1 again.

Now, a case where a failure occurs in message exchange between task A and task B will be described. Figure 3
FIG. 7 is an explanatory diagram relating to a conventional failure. First, as described earlier with reference to FIG. 2, it is assumed that the task A transmits the message M1 (step S1) and enters the waiting state (step S2). Then task B receives message M1
Is received (step S11), and the processing based on the message M1 is started (step S2). here,
Step S12 due to a bug in the program of task B
Processing, that is, the operation of task B is stopped (step S15).

[0006]

As described above, when the processing is smoothly performed by exchanging messages with each other, task A also stops, and task A waiting for a response from task B also stops. There was a problem that it would be in a state (deadlock state). Further, since the operating system does not monitor the states of the tasks A and B and only performs the operations according to the requests from the individual tasks, it cannot grasp that the operations of both the tasks A and B have stopped. There was also a problem. The present invention has been made in view of the above points, and an object of the present invention is to provide a failure detection mechanism capable of detecting occurrence of a failure and preventing the operation from being stopped.

[0007]

A failure detection mechanism according to the present invention includes a plurality of tasks each performing a preset process and an operating system for controlling the operation of each task. Is provided with a queue area having a flag indicating that a notification requiring a response from another task has been executed and a counter indicating the waiting time for the response, and the operating system, when receiving the notification, A response monitoring unit for monitoring the presence or absence of the response within the waiting time indicated by the counter is provided.

[0008]

The operating system OS of this mechanism is
Based on the fault monitoring requests from the tasks A and B, the queue area Q is referred to and the presence or absence of a response is monitored for a certain period of time. When the response is not executed, the task A and B that have requested the fault monitoring are notified of the occurrence of the fault, and the situation of waiting for the response is avoided.

[0009]

DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 shows a conceptual diagram of a fault detecting mechanism according to the present invention. In the figure, a task A, a task B, and an operating system OS are shown. For each task,
Event management table Ta1, which is set in the storage device
, Tb1, Tb2, ... Are provided. Each event management table is provided with a user area Y in which a user (event) who activates a task stores unique information and a queue area Q which the operating system OS accesses.

In the user area Y, the timer value C and the event information ID are stored. A timer counter 5 and an event flag 6 are provided in the queue area Q. The timer value C is a time during which the operating system OS monitors whether a failure related to a task has occurred, and an arbitrary value can be set for each event management table. The event information ID is information for identifying the event management table. The timer counter 5 is used by the operating system OS to count the value of the timer value C. The event flag 6 specifies the event management table in which the operating system OS is monitoring the occurrence of a failure.

A response monitor 1 is provided in the operating system OS. The response monitoring unit 1 is provided with a monitoring table 10 set when a failure monitoring request is received from each task. The monitoring table 10 is 1
One item is composed of a queue area address Qa notified from each task and an event information ID. The queue area address Qa is an address for specifying the queue area Q in the event management table. The event information ID is
It corresponds to the event information of the event management table related to the task for which the monitoring request is made.

The operation of the fault detection mechanism having the above configuration will be described with reference to FIG. Note that here, the user related to the event management table Ta1 of task A is task B
It is assumed that the user related to the event management table Tb1 is notified and the response is waited for. FIG. 4 is a flowchart relating to the monitoring request. When performing the step S2 of FIG. 2 on the task A side, the task A sends a queue request address (for example, command WAIT D) to the operating system OS together with a queue area address for specifying the queue area Q, Timer value C, and event information I
Notify D (step S21).

Operating system O notified
In S, items (queue area address Qa, event information ID) are set in the monitoring table 10 (step S2
2) The timer value C is set in the timer counter 5 of the queue area Q (step S23), and the event flag 6
Is set (step S24). After that, the operating system OS shifts to the failure monitoring operation.

FIG. 5 is a flowchart relating to the monitoring operation. The operating system OS interrupts the response monitoring unit 1 at regular intervals and gives a fault monitoring instruction. The response monitoring unit 1 that has received this instruction uses the monitoring table 1
The item of 0 is recognized (step S31). And
The queue area Q is recognized from the queue area address Qa (step S32), and the timer counter 5 is decremented (step S33).

Further, the response monitoring section 1 judges whether the value of the timer counter 5 is "0" (step S3).
4) If the result is NO, it is determined whether or not there is an item to be monitored in the monitoring table 10 (step S35). If the result of step S35 is YES, that is, if a plurality of items have been set in the monitoring table 10, the process returns to step S31. If the result is NO, the process is terminated and a new interrupt is waited for.

When the result of step S34 is YES, that is, when the counting of the timer value C is completed, the response monitoring unit 1 notifies the operating system OS that the task A has failed (step S36). The process ends. When the operating system OS receives the notification from the response monitoring unit 1, it notifies the task A that a failure has occurred, and the task A resets the event flag 6 in the event management table in which the failure has occurred. ..

Next, the case where task B responds normally will be described. FIG. 6 is a flowchart of the response. When the task B receives the message and completes the predetermined processing, the task B issues the message to which the processing is completed, that is, the partner ID, to the operating system OS (step S41). The operating system OS activates the response monitoring unit 1 to search the monitoring table 10 and determine whether or not the event information ID corresponding to the partner ID is registered (step S42).

If the result of step S42 is YES, the corresponding item in the monitoring table 10 is deleted (step S4).
3) The event flag 6 of the queue area Q set in this item is reset (step S44), and the timer counter 5 is reset (step S45).
Then, the operating system OS transfers the message received from the task B to the task A (step S
46), the process ends. If the result of step S42 is NO, it is determined that there is no task in the waiting state, and the process proceeds to step S46.

As described above, the response monitoring unit 1 of the operating system OS monitors whether or not a response is made within the time designated by the timer value C, and the task waiting state is maintained. To prevent.

[0020]

As described above, in the operating system, the exchange of messages between tasks is monitored within a certain period of time to prevent the occurrence of tasks that keep waiting for messages. be able to. Further, when the occurrence of a failure is detected, the waiting state of the task can be released quickly, and the task can start a new process.

[Brief description of drawings]

FIG. 1 is a conceptual diagram of a failure detection mechanism according to the present invention.

FIG. 2 is an explanatory diagram of conventional protocol processing.

FIG. 3 is an explanatory diagram related to a conventional failure.

FIG. 4 is a flowchart relating to a monitoring request.

FIG. 5 is a flowchart relating to a monitoring operation.

FIG. 6 is a flowchart relating to a response.

[Explanation of symbols]

 1 Response monitoring unit 5 Timer counter 6 Event flag 10 Monitoring table

Claims (1)

Claim: What is claimed is: 1. A plurality of tasks, each of which performs preset processing, and an operating system, which controls the operation of each task. A queue area having a flag indicating that a notification requiring a response has been executed and a counter indicating a waiting time for the response is provided, and when the operating system receives the notification, the waiting area indicated by the counter is displayed. A failure detection mechanism comprising a response monitoring unit for monitoring the presence or absence of the response within a time period.