JP2004118334A - Failure restoring method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a failure restoring method for surely restoring the failure without impairing the efficiency of a system, though in a conventional failure restoring method, a failure restoring task cannot be transferred to an execution state to perform the restoring processing. <P>SOLUTION: In a first step of this failure restoring method, the task 1 occurring the failure gives the notification to increase the priority of a restoring task in accordance with a degree of failure to a kernel 4 of the system, or a maintenance monitoring task 3 detects the failure in the arbitrary task, and gives the notification to increase the priority of the restoring task higher than the priority of the task 1 in which the failure is detected, to the kernel 4 of the system, in a second step, the kernel 4 of the system receiving the notification changes the priority of the maintenance monitoring task 3 as the restoring task in accordance with the notification, and in a third step, the maintenance monitoring task 3 as the restoring task restores the failure with the changed priority, and the priority of the changed restoring task is exclusively reserved. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a failure recovery method, and more particularly to a failure recovery method capable of reliably and efficiently recovering from a failure by controlling the priority of the failure recovery task.
[0002]
[Prior art]
In general, in a real-time multitask system, an application is divided into units which can be processed independently and in parallel, and the divided programs are called tasks.
When a task is created, task identification information (task ID), attributes, activation addresses, task activation priorities, task names, and the like are specified as task generation information.
[0003]
Here, the task activation priority is a value for determining the execution order at the time of task activation, and usually uses a value in the range of 1 to a predetermined maximum task priority (for example, 255). 0 is special, and only the kernel, which is the top process acting as a core entity in a computer system, uses this priority. The kernel means a part that realizes basic functions of the OS, such as memory management and task management.
[0004]
The smaller the value of the task priority, the higher the priority, and the same priority can be designated to a plurality of tasks.
Then, the task activation priority can be changed after the task is created by using a system call.
[0005]
When an arbitrary task becomes ready for execution, the kernel issues an execution request to the kernel via a system call, and the kernel performs task scheduling processing.
Specifically, when there is no task currently being executed by the CPU, the task is set to the execution state.
[0006]
In addition, when the CPU is executing when the system call of the execution request is received, the kernel sets a ready queue provided for each priority based on the priority set for the task that requested the execution. The task is put in a called CPU allocation queue and the execution order is made to wait.
[0007]
When the task that is being executed by the CPU is completed, the kernel checks the ready queue provided for each priority, assigns the CPU by sequentially selecting tasks waiting to be executed in the queue with the highest priority, It is set to the execution state.
[0008]
In the system of the multitask configuration for performing the prioritized scheduling described above, as a failure recovery method when an abnormality or a failure occurs, a dedicated task (maintenance monitoring task 3 ') for performing a failure report and recovery processing is provided. A recovery process is performed by a failure occurrence notification from the failure occurrence task 1 'or a failure detection by monitoring.
[0009]
At this time, if the failure occurrence task 1 'or the task that performs other processing (the other task 2) has a higher priority than the maintenance monitoring task 3' that performs the failure report and recovery processing, the task cannot be preempted. In some cases, failure reporting and recovery processing could not be performed.
[0010]
A specific example will be described with reference to FIG. FIG. 3 is an explanatory diagram showing a situation when a failure occurs in a conventional real-time multitask system.
First, only the relationship between the task in which an error or a failure has occurred (failure task 1 ') and the task of performing a failure report and recovery process (maintenance monitoring task 3') will be described. If 1 '<maintenance monitoring task 3', the failure occurrence task 3 'reports a failure to the maintenance monitoring task 3' to notify the occurrence of the failure, and the maintenance monitoring task 3 'operates upon receiving the failure report. , The recovery process can be performed immediately.
[0011]
However, if the priority order is as follows: failure occurrence task 1 '> maintenance monitoring task 3', or failure occurrence task 1 '= maintenance monitoring task 3', as shown in FIG. Even if a failure report is received from the occurrence task 1 ', since the failure occurrence task 1' having a higher priority is in operation, the task is not preempted, and the maintenance monitoring task 3 'cannot move to the execution state and cannot perform recovery processing. There are cases.
[0012]
Next, only the relationship between the maintenance monitoring task 3 'and the task performing other processing (other task 2') will be described. If the relationship of the priority is other task 2 '<maintenance monitoring task 3', The fault occurrence task reports the fault to the maintenance monitoring task 3 ', and the maintenance monitoring task 3' having the highest priority operates upon receiving the fault report, and can immediately perform the recovery processing.
[0013]
However, when the priority order is other task 2 '> maintenance monitoring task 3' or other task 2 '= maintenance monitoring task 3', as shown in FIG. Even if a report is received, since the other task 2 'having a higher priority is in operation, the task may not be preempted, and the maintenance monitoring task 3' may not shift to the execution state and the recovery process may not be performed.
[0014]
As in the above specific example, when the priority of the maintenance monitoring task 3 ′ is not higher than that of the faulty task 1 ′ or the other task 2 ′, the task cannot be preempted, and appropriate fault reporting and recovery processing cannot be performed. Will be. That is, the maintenance monitoring task 3 'needs to have a higher priority than the faulty task 1' or the other task 2 '.
[0015]
As a prior art for controlling task priorities, Japanese Patent Application Laid-Open No. 5-53836, published on March 5, 1993, entitled "Automatic Determination of Task Execution Priority" (Applicant: Yaskawa Electric Corporation, Inventor: Akio Nakamura).
This conventional technique samples the operation waiting time and the activation cycle every time the system is activated by a task whose execution priority can be changed, and when the activation cycle exceeds a preset value for a certain modifiable task. If it is determined that the current execution priority is inappropriate from the average value of the sampling data, the task execution priority is automatically increased by repeating the process of raising the execution priority of the task by one rank on the personal computer maker server for each task. This is a determination method, which enables the system to automatically determine and optimize the priority of executing a task without burdening the user (see Patent Document 1).
[0016]
[Patent Document 1]
JP-A-5-53836 (pages 2-3)
[0017]
[Problems to be solved by the invention]
However, the conventional failure recovery method has a problem that when the priority of the maintenance monitoring task is lower than that of the failure occurrence task or other tasks, the failure recovery task cannot shift to the execution state and the recovery processing cannot be performed.
[0018]
Also, in a system that requires real-time processing, making the continuous monitoring task the highest priority to ensure recovery processing means lowering system throughput, which may affect normal processing. There was a problem that there is.
[0019]
The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a failure recovery method that can reliably recover from a failure without lowering the efficiency of the system.
[0020]
[Means for Solving the Problems]
The present invention for solving the problems of the above-mentioned conventional example provides a failure recovery method in which a plurality of tasks given priorities according to the importance of system operation are processed, and tasks are assigned according to the system status. A failure recovery method for a real-time multitasking system in which priority can be changed,
The failed task issues a notification to the system to raise the priority of the recovery task according to the degree of the failure, or the maintenance monitoring task detects a failure in any task and the priority of the task in which the failure was detected A first step of issuing a notification to the system to raise the priority of the recovery task to a higher level;
A second step in which the notified system changes the priority of the recovery task according to the notification;
A third step in which the recovery task performs the fault recovery with the changed priority;
The feature is that the priority of the recovery task to be changed is reserved for exclusive use, and the failure can be reliably recovered without lowering the efficiency of the system.
[0021]
BEST MODE FOR CARRYING OUT THE INVENTION
An embodiment of the present invention will be described with reference to the drawings.
According to the failure recovery method of the present invention, as a first step, a notification is issued to the system in which the failed task raises the priority of the recovery task in accordance with the degree of the failure, or the maintenance monitoring task is performed in an arbitrary task. A failure is detected, and a notification that raises the priority of the recovery task to a higher priority than the priority of the task in which the failure is detected is issued to the system. As a second step, the system that has been notified receives the priority of the recovery task. Is changed according to the notification, and as a third step, the recovery task performs a fault recovery with the changed priority, and the priority of the changed recovery task is reserved for exclusive use, so that the efficiency of the system is reduced. It is possible to recover from a failure without any trouble.
[0022]
A failure recovery method according to an embodiment of the present invention will be described with reference to FIG. FIG. 1 is an explanatory diagram showing a state of a failure recovery method according to an embodiment of the present invention. Parts having the same configuration as in FIG. 3 are described with the same reference numerals.
In a multi-task configuration system that performs scheduling with priorities, similarly to the related art, a failed task 1 in which a failure has occurred, another task 2, and a dedicated task for performing failure reporting and recovery processing (maintenance monitoring task 3) ), And the kernel 4 of the system that realizes the basic functions of the OS, such as memory management and task management, receives a system call from each task.
In FIG. 1, the kernel 4 is shown on the right side of the user task indicated by □ in order to make it easy to understand the exchange between the kernel 4 and the user task, but the priority (priority) of the user task is high or low. The kernel 4 is not conscious of the level of the priority (priority).
[0023]
The normal maintenance monitoring task 3 performs maintenance monitoring in the apparatus and does not need to be processed in real time. Therefore, it can be considered that a lower priority is set.
In the failure recovery method according to the embodiment of the present invention, for example, when a failure occurs in a certain task (failure task 1), the failure task 1 determines the degree of the failure and performs a maintenance monitoring task 3 A request (setting change request) requesting that the setting of the priority be changed to a priority corresponding to the degree of the failure is output to the kernel 4 as a system call.
[0024]
Note that the type and degree of a fault vary depending on each task, but a fault is associated with a change level in each task in advance so as to correspond to a level at which the priority of the maintenance monitoring task 3 is finally changed. When a failure occurs, a function is realized by a program that outputs a setting change request at a change level corresponding to the failure that has occurred.
[0025]
For example, when a failure occurs at the same level as a system failure, a request is made to raise the priority of the maintenance monitoring task 3 to the highest level, and control is made to give top priority to failure reporting and recovery.
In addition, when a failure that causes a reduction in function occurs, a request is made to raise the priority of the maintenance monitoring task 3 to a level that does not cause performance degradation of the remaining system, and the failure report and recovery and normal processing are performed in parallel. Control to be performed.
[0026]
Then, the kernel 4 changes the priority of the maintenance monitoring task 3 to increase according to the setting change request from the failure generating task 1, and the maintenance monitoring task 3 having the higher priority enters the execution state to report the failure, Alternatively, a failure recovery process is performed.
[0027]
The fault report referred to here covers all notifications to different devices (for example, a higher-level device, a subordinate device, and an external terminal) or writing of a fault log or the like to a memory in the same device.
In addition, the failure recovery processing may include switching to a call standby or a hot standby apparatus, switching to a mirror site, and resetting an initialization processing from a device in terms of a system.
[0028]
In addition, when the failure occurred in the failure task 1 is serious, or when the above-described function is not realized in the failure task 1, the failure task 1 sends the kernel 4 to the kernel 4 as described above. Since it is not always possible to output a notification (setting change request) requesting a priority change of the maintenance monitoring task 3, the maintenance monitoring task 3, which monitors the occurrence of a failure in the system with a low priority, usually generates When the occurrence of a failure in task 1 is detected, a notification requesting to change the setting of the priority of maintenance monitoring task 3 to a higher (higher) priority than the priority according to the priority of the failed task 1 ( (A setting change request) to the kernel 4.
[0029]
Then, in response to the setting change request from the maintenance monitoring task 3, the kernel 4 changes the priority of the maintenance monitoring task 3 to increase, and the maintenance monitoring task 3 with the higher priority enters an execution state and performs a recovery process. It has become.
[0030]
The maintenance monitoring task 3 holds task information, such as a task ID, a task priority, and a task name, relating to the running task as a process list necessary for monitoring. Is detected, the priority of the faulty task 1 is acquired from the process list, and the priority of the maintenance monitoring task 3 is changed to a higher (higher) priority than the priority according to the acquired priority. Request to do so. The contents of the process list include an example in which a system call for referring to task information of each task is periodically made for all tasks to collect information.
[0031]
Here, the priority of the task will be described using a specific example with reference to FIG. FIG. 2 is an explanatory diagram showing a specific example of the task priority used in the failure recovery method of the present invention.
Assuming that the priority of a task is, for example, from 0 to 255 as shown in FIG. 2, priority 0 is a priority that can be used only by the kernel of the system that is usually the top process, followed by a higher priority (Group 1 in FIG. 2) is the priority used by the indispensable tasks of the system.
[0032]
Then, a plurality of groups are provided for other priorities with respect to the higher priorities used in the system system, so that the groups can be used in a user task constituting a user application.
In the example of FIG. 2, three groups are provided for the priority used by the user task, and the higher priority (group 2 in FIG. 2) is set in the tasks constituting each user application. The priority is such that a task called a daemon that requires real-time processing can be used.
Note that a task called a daemon is resident in the background so that it can always respond to a request (interrupt) from the outside (a portable terminal, a higher-level device, etc.), and processes the request when it is received. The task is started and processed, and the task is set to wait for a request.
[0033]
The lower priority (group 4 in FIG. 2) is a priority at which a task that does not need to be processed in real time (described as an application in FIG. 2) among tasks constituting each user application can be used. , The middle priority (group 3 in FIG. 2) does not need to be processed in real time than the group 2 task among the tasks constituting each user application, but is processed in real time than the group 4 task. Is a priority at which a required task (described as an application in FIG. 2) can be used.
That is, the tasks (applications) of the groups 3 and 4 are tasks that process requests received by the daemons of the group 2 and tasks that are individually activated for each request.
It should be noted that the normal maintenance monitoring task 3 performs maintenance monitoring in the apparatus and does not need to be processed in real time. Therefore, it can be considered that the priority belonging to the group 3 or the group 4 is set.
[0034]
As a characteristic part of the present invention, a priority reserved exclusively for changing the priority of the maintenance monitoring task 3 when a failure occurs is secured during the provision of the plurality of priority groups as described above. , Respectively, are associated with the degree of failure.
[0035]
2, the priority 10 between the group 1 and the group 2 is used for the maintenance monitoring task 3 (recovery task) when a catastrophic failure occurs, and the priority 10 between the group 2 and the group 3 is set. The priority 20 is for the maintenance monitoring task 3 (recovery task) when a serious failure occurs, and the priority 30 between the groups 3 and 4 is for the maintenance monitoring task 3 3 (recovery task).
That is, the degree of the failure is divided into three levels, and the priority of the maintenance monitoring task 3 (recovery task) is changed to the priority 10 or 20 or 30 according to the degree of the failure that has occurred.
[0036]
Next, a specific operation of the failure recovery method of the present invention will be described with reference to FIG.
Assuming that the priorities in the system are grouped into four groups as shown in FIG. 2 and the user tasks are three groups among them, the user tasks using the priorities grouped in three stages as shown in FIG. It is assumed that there is.
[0037]
Since the maintenance monitoring task 3 performs maintenance monitoring inside the apparatus as a normal operation, the priority of the low-order group (priority 31 or higher) is set, and the maintenance monitoring task 3 operates under the task control of the kernel 4.
In addition to the maintenance monitoring task 3, a number of user tasks in which the priority of each group is set are operating in an executable state or an execution state under the task control of the kernel 4.
[0038]
Then, for example, a fault occurs in the task (failure task 1) operating in the middle priority group (priorities 21 to 29), and for example, the priority of the maintenance monitoring task 3 is determined from the degree of the fault. When a notification (setting change request) requesting to change the setting to the priority 20 for the recovery task at the time of a serious failure is output to the kernel, the kernel 4 sets the priority of the maintenance monitoring task 3 to the priority 20. When the setting is changed and there is no task with a higher priority, control is performed so that a recovery operation can be performed.
[0039]
Further, a notification is issued to request that the priority of the maintenance monitoring task 3 be changed to the priority 30 for the recovery task in the event of a catastrophic failure (setting change request) because the degree of the failure occurring in the failure generating task 1 is heavy. Is output to the kernel, the kernel 4 changes the priority of the maintenance monitoring task 3 to the priority 30 and controls so that the recovery operation can be performed with the highest priority among the user tasks.
[0040]
Further, when a serious failure occurs in the failure task 1 and the notification of the setting change request cannot be output to the kernel 4 or when the function is not provided, the maintenance monitoring task 3 Detects the occurrence of a failure in the failed task 1 during the normal monitoring, and the priority of the failed task 1 is in the middle of 21 to 29. Therefore, the priority 20 or higher priority is set. When a notification (setting change request) requesting to change the setting to the degree 30 is output to the kernel, the kernel 4 changes the priority of the maintenance monitoring task 3 to the priority 20 or 30, and can perform the recovery operation. Control.
[0041]
In the above description, the fault occurrence task 1 outputs a notification (setting change request) to the kernel 4 requesting that the priority of the maintenance monitoring task 3 be changed to a priority corresponding to the degree of the fault. As described above, the fault occurrence task 1 notifies the maintenance monitoring task 3 of the fault,
A request to increase the priority level from the maintenance monitoring task 3 may be output to the kernel 4.
[0042]
In the above description, the case where the maintenance monitoring task 3 itself performs a fault recovery has been described. However, a task for performing a fault recovery process (referred to as a recovery task) is provided separately, and the priority of the recovery task is determined according to a request. It may be changed or the recovery task may be started with the requested priority.
[0043]
In the above description, each task includes a notification (a setting change request) requesting the kernel 4 to change the priority of the maintenance monitoring task 3 to a priority corresponding to the degree of the failure when a failure occurs. Has been described so as to realize only the function of outputting a task, but a function of performing a fault report or a fault recovery process is provided in each task, and a request is made to raise the priority of the own task according to the degree of the fault. You may do it.
[0044]
The failure report referred to here is a notification to the maintenance monitoring task 3 in the same device, a notification to a different device related to the task (for example, a higher-level device, a subordinate device, an external terminal), or an application to a memory in the same device. It is intended for writing logs and the like.
The failure recovery processing is release of a memory or the like dynamically secured by the task or the application, release of a medium in use, and the like, and recovery of a range related to the task.
[0045]
According to the failure recovery method of the embodiment of the present invention, the failed task 1 in which the failure has occurred notifies the kernel 4 of the system of raising the priority of the failure recovery task 3 for performing the failure recovery according to the degree of the failure. The kernel 4 of the issued and notified system changes the priority of the failure recovery task 3 according to the notification, and the failure recovery task 3 operates at the changed priority to perform failure recovery. Occasionally, the failure recovery task 3 is started with a priority according to the degree of the failure and without depending on the operation processing of the failure occurrence task 1 or another user task, and a failure report and recovery processing can be performed. There is an effect that the restoration process can be performed efficiently.
[0046]
Further, according to the failure recovery method of the embodiment of the present invention, when a failure occurs in the failure occurrence task 1, the maintenance monitoring task 3 detects the occurrence of the failure, and the failure monitoring task 1 detects the failure. A notification that raises the priority of the recovery task to a higher priority than the priority is issued to the kernel 4 of the system, and the kernel 4 of the system that has received the notification changes the priority of the recovery task 3 according to the notification, and the recovery task 3 Operates at the changed priority to perform failure recovery. Therefore, even if the failure occurrence task 1 cannot issue a notification when an abnormality or a failure occurs, the operation of the maintenance monitoring task 3 allows the priority of the failed task to be determined. , The maintenance monitoring task 3 is started without depending on the operation processing of the failure occurrence task 1 and other user tasks, and the failure monitoring and the recovery processing can be performed, and the recovery processing can be efficiently performed. There is an effect that can be.
[0047]
Further, according to the failure recovery method according to the embodiment of the present invention, when a failure occurs, the priority of the change destination for raising the priority of the maintenance monitoring task 3 is reserved in advance for exclusive use. The priority processing time is not occupied by another task, and if the priority is changed, the priority is changed to the execution state without interruption and the failure report and recovery processing are performed. Thus, there is an effect that the restoration process can be performed reliably and efficiently.
[0048]
Further, according to the failure recovery method of the embodiment of the present invention, a recovery task dedicated to failure recovery processing is separately provided instead of the maintenance monitoring task 3, and the priority of the recovery task is changed according to a request. Alternatively, since the recovery task may be started with the requested priority, there is an effect that the failure recovery can be started more quickly.
[0049]
Further, according to the failure recovery method of the embodiment of the present invention, the maintenance monitoring task 3 usually monitors the occurrence of a failure in the system with a low priority. Recovery is performed with the priority given, the normal operation does not hinder the operation of other tasks, and in the event of an error, the recovery is performed using the full performance of the CPU, thus lowering the efficiency of the system. Without this, there is an effect that the failure can be reliably and efficiently recovered.
[0050]
Further, according to the failure recovery method according to the embodiment of the present invention, a task for performing a failure report or a failure recovery process is provided in each task, and the priority of the own task is increased according to the degree of the failure. Since a failure can be requested and a high priority can be used to recover the fault in the task, there is an effect that even a fault closed in the task can be reliably and efficiently recovered. You may do it.
[0051]
【The invention's effect】
According to the present invention, as a first step, the failed task issues a notification for raising the priority of the recovery task to the system according to the degree of the failure, or the maintenance monitoring task detects the failure in any task. Detects and issues a notification to the system that raises the priority of the recovery task to a higher priority than the priority of the task where the failure was detected. As a second step, the notified system notifies the priority of the recovery task As a third step, the recovery task performs a failure recovery with the changed priority, and the priority of the changed recovery task is a dedicated recovery method. There is an effect that the failure can be surely recovered without lowering.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a state of a failure recovery method according to an embodiment of the present invention.
FIG. 2 is an explanatory diagram showing a specific example of task priorities used in the failure recovery method of the present invention.
FIG. 3 is an explanatory diagram showing a situation when a failure occurs in a conventional real-time multitask system.
[Explanation of symbols]
1, 1 '... fault occurrence task, 2 ... other task, 3, 3' ... maintenance monitoring task,
4 ... Kernel

Claims (1)

A plurality of tasks given priority according to the importance of system operation are processed, a failure recovery method of a real-time multi-task system capable of changing the priority of the task according to the status of the system,
The failed task issues a notification to the system to raise the priority of the recovery task according to the degree of the failure, or the maintenance monitoring task detects a failure in any task, and A first step of issuing a notification to the system to raise the priority of the recovery task to a higher priority than the priority;
A second step in which the notified system changes the priority of the recovery task according to the notification;
A third step in which the recovery task performs fault recovery with the changed priority.
A failure recovery method for a real-time multitask system, wherein the priority of the recovery task to be changed is reserved exclusively.

Images