JPH0457135A - Fault processing system for inter-task communication - Google Patents

Abstract

PURPOSE:To reduce a memory capacity by using a queue with fixed length in communication, monitoring the occurrence of a fault in an opposite task, resetting a communication requirement issued when time out occurs, and clearing the communication requirement registered on the queue. CONSTITUTION:The task 120 issues the communication requirements 201, 20m to the task 110, and awaits a response 20. At this time, the communication requirement is registered on the queue 10 with fixed length, and sequence is scheduled. Meanwhile, the task 120 registers a timer value 60, an opposite task ID 70, and its own task ID 80 as a pair on a timer monitoring table 50 for the task 100 to require timer monitoring when the communication requirement is issued. Also, when overflow occurs in the queue 10, a requirement is registered on a communication requirement hang-up task ID table 30, and the task 120 finds the task IDs 70, 80 from the table 50 when the time out occurs since no communication response 20 to generate hang-up arrives, and resets the hung up communication requirement of a correspondent task(for example, 120). Then, the queue 10 is found by the ID 70, and all the same task IDs as the task ID 80 out of issuing origin task IDs 301-30m are cleared.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to recognition of a fault in a partner task in communication between a plurality of tasks in which a single-order execution is queued, and recovery from a fault in a task that issued the single-order execution.

[Conventional technology]

Conventionally, as described in Japanese Unexamined Patent Application Publication No. 1-93852, there is a method in which a communication request issuing task is notified before the queue reaches 'a: It became.

Furthermore, in Japanese Patent Application Laid-Open No. 60-29852, there was a method of enlarging the queue when the queue was full.

[Problem to be solved by the invention]

In conventional inter-task communication, it was necessary to have a large 1 minute queue area so as not to limit the number of queues required for communication. However, this method cannot take into account the case where there is not enough memory available.

An object of the present invention is to provide failure recovery when the number of queues is limited, with the aim of keeping usable memory small.

[Means to solve the problem]

In order to achieve the above purpose, a fixed-length queue is used during communication, and a timer is used to monitor the occurrence of failures in the other task.
This system is provided with means for resetting the communication requests currently being issued and means for clearing the communication requests queued at the time of time alarm 1-.

[Effect]

In information processing systems that communicate between multiple tasks,
Communication is scheduled in a fixed-length queue for queuing communication requests, and when a failure is detected in the other task, the communication request of the banked-up task is set to reset 1 because the communication request cannot be registered in the queue, and furthermore, the other task is If the communication type is invalid when it starts moving, it will be sent to I-1, so clearing the queue can recover from failures.

〔Example〕

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

Task 120 sends communication request 201.20 to task IO
Issue m and wait for response 20. At this time, the fixed length queue 10
The communication requests are iterated and the order is scheduled.

On the other hand, when 120 issues a communication request, timer monitoring table 50 is used to request timer monitoring for task 1.00.
, the timer value 60, the other task ID 70, and the own task ID
Register 80 as a group. Furthermore, when the queue 10 overflows, the request is registered in the communication request hangup task ID table 30, and the task 120 hangs up.

The communication monitoring task 100 operates according to the flow shown in FIG. If a time lag occurs because the communication response 20 is not received, the communication task IDs 70 and 80 will be changed from 50.
and checks from 80 whether the same ID as 80 is registered in 30.

If there is one, the hung communication request of the corresponding task (for example, 120) is reset.

Next, from 70, find the queue 1.0 and issue the issuer task I.
Clear all of D301-30m that are the same as 80. As a result, of the communication requests 201 to 20m, the one issued by 120 is completely cleared.

On the other hand, if 110 returns response 20 after timer 1, 120 is discarded.

The same applies to the communication between task month n and task 12Ω. Further, even if requests for tasks 120 to 11 are mixed and entered in queues 10 to 1n, this method can handle the request.

Since the cleared communication request remains in the timer monitoring table held by the communication monitoring task, timer monitoring is continued, one after another, and the time alarm 1- occurs, and the same process is repeated.

By resetting the hung communication request, the task 120 recognizes the abnormality of the other task, and may take measures to prohibit communication with the other task.

The above results (1) Asynchronous communication considering failure handling,
This can be achieved with a fixed-length queue, allowing for memory reduction.

〔Effect of the invention〕

According to the present invention, since the communication request queue used for communication between multiple tasks can be made small, memory can be reduced.

In addition, failures in communication between tasks can occur when the other task's
Since 'l'r'; is almost constant, there is no need to perform an unnecessary 1-lie in the event of a failure.

[Brief explanation of drawings]

FIG. 1 is a system configuration diagram of a failure handling method in an information processing system according to an embodiment of the present invention, and FIG.
FIG. 3 is a processing flow diagram of a QO task. 10, in-communication request registration queue 20 response, 21... registration of communication request in queue, 22 retrieval of communication request from queue, 30...
Communication request hangup task IDt record table, 50...-Timer monitoring table, 60.6k Timer monitoring value, 70.7k Task II of the other task (110-111), 80.8k Communication issuer task (120-111)
12Q) task ID, 201-20m -2n 1 2 [1m-communication request,
301-30m-3n 1-3 nm-Communication request task ID, 40-4Q... ID of the task where the communication request is hung up, 100- Communication monitoring task, 110-lln... Communication partner task, edition Diagram 2 Diagram Scoot −

Claims (1)

[Claims] 1. In communication between multiple tasks, in which there is always a response to an inquiry from a request source, there is a fixed-length queue for queuing inquiry requests, and clearing of the queue and communication when timer monitoring times out. A failure handling method for intertask communication characterized by having a function of resetting a publisher.