KR101300806B1 - Apparatus and method for handling abnormal processing in multi process system - Google Patents

Abstract

The present invention relates to a malfunction processing of a multi-process system, comprising: a storage unit storing idle time monitoring process information, threshold information of the idle time, and rebooting exception process list information; A determination unit that determines that a malfunction has occurred when the idle state of the target process continues above the threshold value; and, when the malfunction occurs, the process that has been performed for the longest time in the reboot exception process list is included in the reboot exception process list. Including multi-processing processing to terminate the long-running process, by detecting the malfunction through the idle time of the process in the multi-process system, and restores the system to the normal state by stopping only the abnormal process, real-time of the operation time and state of the processes System recovery without confirmation and reboot is possible.

Multi Process, Abnormal Precess, Process Starvation

Description

Apparatus and method for handling malfunctions in multi-process systems {APPARATUS AND METHOD FOR HANDLING ABNORMAL PROCESSING IN MULTI PROCESS SYSTEM}

1 is a block diagram illustrating a multi-process system apparatus according to the present invention; and

2 is a diagram illustrating a malfunction detection and processing procedure in a multi-process system according to an exemplary embodiment of the present invention.

The present invention relates to a multi-process system, and more particularly, to an apparatus and method for detecting and processing a malfunction of processor scheduling in a multi-process system.

In a multi-process environment, software is divided into functional units or task units and called a process, and each process operates independently. Here, each process has a priority set in the operating system and is cyclically processed according to the priority. That is, each of the processes occupies a central processing unit (CPU) according to a result scheduled by priority and performs a corresponding function.

At this time, if a specific processor monopolizes the central processing unit, the system may be in an abnormal state and may not perform a normal role. For example, a failure state in which an external device cannot be connected to a remote terminal or a debug terminal can be maintained. Therefore, an alternative for detecting the malfunction in a multi-process system and restoring the system to a normal state should be presented.

Accordingly, an object of the present invention is to provide an apparatus and method for recovering a system to a normal state by detecting a phenomenon in which a specific process monopolizes the system in a multi-process system.

Another object of the present invention is to provide an apparatus and method for detecting a malfunction state of a system by monitoring an idle time of a process in a multi-process system.

It is still another object of the present invention to provide an apparatus and method for restoring a system to a normal state by stopping only an abnormal process without a system reboot when a malfunction occurs in a multi-process system.

According to a first aspect of the present invention for achieving the above object, the multi-process system device, the idle time monitoring process information, the threshold information of the idle time, the rebooting (Rebooting) exception A storage unit which stores process list information, a determining unit which determines that a malfunction occurs when the idle state of the target process continues above the threshold value, and when the malfunction occurs, the process that has been performed the longest for a unit time is rebooted. If included in the exception process list, characterized in that it comprises a processing unit for processing to terminate the longest process.

According to a second aspect of the present invention for achieving the above object, the malfunction processing method in a multi-process system, the process of setting the idle time monitoring target process information, the threshold information of the idle time, reboot exception process list information, If the idle state of the target process continues above the threshold, checking whether the longest running process is included in the reboot exception process list for a unit time, and terminating the longest running process; It is characterized by.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. In the following description, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

Hereinafter, the present invention describes a technique for detecting and processing an error situation in which a specific process is not processed when processing a plurality of processes in a multi-process system.

First, the present invention briefly describes a malfunctioning situation and a processing method.

The malfunction situation considered in the present invention means a situation in which a low priority process cannot be performed because a high priority process monopolizes the system. In other words, regardless of the priority, each process must be performed within a certain time period in order for the system to perform its normal role. If a specific process cannot be performed, the system is considered to be in a failure state.

Therefore, when the idle time of the process having the low priority lasts more than a predetermined reference time, the present invention determines that the system is in a malfunction state, and restores the system to the normal state by stopping the process that occupies the system for the longest time. At this time, stopping the process does not guarantee that the system will recover to its normal state at all times. Therefore, it is necessary to distinguish the processes in which the system is restored to its normal state by stopping the process, and in some cases, stop all the processes and reboot the system.

Hereinafter, a configuration and an operation procedure of a multi-process system for performing malfunction detection and processing in the above-described manner will be described in detail with reference to the accompanying drawings.

1 shows a block diagram of a multi-process system apparatus according to the present invention.

As illustrated in FIG. 1, the multi-process system apparatus includes a control unit 101, a process scheduler 103, a storage unit 105, a malfunction determination unit 107, and a malfunction processing unit 109.

The controller 101 performs a function of processing each process, and controls the process scheduler 103, the storage 105, the malfunction determining unit 107, and the malfunction processing unit 109. The process scheduler 103 determines the priority of a plurality of processes to determine a process processing order and a processing time of the controller 101.

The storage unit 105 stores data temporarily generated during the process processing, data necessary for the process processing, and the like. In particular, the storage unit 105 stores initialization setting information for detecting a malfunction in accordance with the present invention. In other words, the storage unit 105 receives and stores a target process for monitoring idle time, a threshold value of the idle time, a reboot exception process list, and the like. Here, the reboot exception process means a process capable of normal recovery of the system by stopping only the corresponding process without rebooting when a malfunction occurs. In addition, the configuration information is information input from the system operator. That is, the setting information is determined and input from the outside according to the operating policy of the system.

The malfunction determining unit 107 determines whether a malfunction occurs according to the setting information stored in the storage unit 105. That is, the malfunction determining unit 107 checks whether the idle time of the monitored process lasts more than a threshold value. When the malfunction determining unit 107 determines that a malfunction occurs, the malfunction processing unit 109 checks the process that has been performed the longest for a unit time, and checks whether the longest process is included in the reboot exception process list. . If the longest-running process is included in the list, the malfunction processing unit 109 controls to stop only the corresponding process. If not, the malfunction processing unit 109 controls to reboot the system.

In the above-described configuration, the controller 101 may perform functions of the process scheduler 103, the malfunction determining unit 107, and the malfunction processing unit 109. In the present invention, it is configured as a separate block to describe each function separately. Therefore, in actual implementation, all of them may be configured to be processed by the controller 101 or only some of them may be configured.

2 illustrates a malfunction detection and processing procedure in a multi-process system according to an exemplary embodiment of the present invention.

Referring to FIG. 2, the controller 101 performs initialization for detecting malfunction in step 201. In other words, the target process for monitoring the idle time, the threshold value of the idle time, a reboot exception process list, and the like are received and stored. Here, the reboot exception process means a process capable of normal recovery of the system by stopping only the corresponding process without rebooting when a malfunction occurs.

After performing the initialization setting, the control unit 101 proceeds to step 203 to check whether the malfunction monitoring process, that is, the idle state of the monitoring target process continues above the threshold value.

If the idle state continues above the threshold, the controller 101 proceeds to step 205 and stores performance information of current processes. In this case, storing the performance information of the current processes is an operation for later cause analysis.

In operation 207, the controller 101 checks the process that has been performed the longest for a unit time. In other words, because the high priority process occupies the system, the low priority process cannot be processed, so the process that occupies the system for the longest time is identified.

After checking the longest process, the controller 101 checks whether the process identified in step 207 is included in the reboot exception process list.

If the longest running process is included in the reboot exception process list, the controller 101 proceeds to step 209 to stop the longest running process, thereby restoring the system to a normal state.

On the other hand, if the longest process is not included in the reboot exception process list, the controller 101 proceeds to step 211 and reboots the system.

As described above, malfunction detection and processing can be performed in a multi-process system. Here, the present invention is a function at the software level, and is implemented in micro code when implemented in practice. Accordingly, the present invention provides an example of microcode for performing the malfunction detection and processing. Examples of the micro expressed in Pseudo Code format are shown in Tables 1, 2, 3, and 4 below. Here, the expression of occupying the central precessing unit (hereinafter referred to as 'CPU') shown in Tables 3 and 4 below has the same meaning as the expression of occupying the system described with reference to FIGS. 1 and 2. to be. In addition, the CPU is one example of the control unit 101.

Function of function

code
Explanation


Variable declaration


struct process_time {   ULONG RUNNING_TIME; Time the process was performed   ULONG START_TIME; Process start time   ULONG ENDTIME; Process end time   ULONG LATEST_TIME; Save time of execution time } PROCESS_RUN_TIME [MAX_PID];

Table 1 shows an example of microcode that declares a structure for storing a variable. The components of the structure shown in Table 1 above are minimal, and in some cases, may include additional components.

Function of function

code
Explanation

Supervised
Process input
Get_LOW_PRI_PROCESS () {   if (user_input ())     LOW_PRI_PROCESS = user_input ();   else     LOW_PRI_PROCESS = IDLE_Process; }

Idle time
Enter threshold
Get_LOW_PRI_STARV_TIME () {   if (user_input ())     LOW_PRI_STARV_TIME = user_input (); Save input time   else     LOW_PRI_STARV_TICK = DEFAULT_TIME; }
Reboot exception
Process input Get_LowPri_Reboot_Except_List () {   LowPri_Reboot_Except_List = user_input (); }

Set
reset
Initialize_Low_Pri_Starvation () {   Get_LOW_PRI_PROCESS ();   Get_LOW_PRI_STARV_TIME ();   Get_LowPri_Reboot_Except_List (); }

Table 2 shows an example of microcode for initializing settings. In other words, Table 2 shows microcode for receiving and storing an idle time monitoring process, a threshold value of the idle time, a reboot exception process list, and the like. In the example illustrated in FIG. 2, step 201 corresponds to step 201.

Function
function

code
Explanation




CPU
Transfer of Rights





context_switch (task_t * prev, task_t * next) {   getCurrentTime (&timestamp); Read current time   store_prev_process_run_time_and_time (timestamp); Save execution time and shutdown time of processes that pass CPU usage rights   store_next_process_start_time (timestamp); Save start time of processes that are granted CPU usage   switch_to (prev, next, prev); Transfer of CPU Usage Rights }






Malfunction
Detect timer_interrupt_handler () {   getCurrentTime (&timestamp); Read current time   store_current_process_run_time_and_time (timestamp); Save run time and end time of currently running process   if (timestamp-PROCESS_RUN_TIME [LOW_PRI_PROCESS] .LATEST_TIME)> LOW_PRI_STARV_TIME) Determination of malfunction by comparing idle time   {     LOW_PRI_STARVATION_DETECTION ();   } }

Table 3 shows an example of the micro code for detecting the process switching and malfunction. 2 corresponds to step 203 in the embodiment shown in FIG. 2.

Function
function

code
Explanation










Malfunction

restore




LOW_PRI_STARVATION_DETECTION () {   save_process_running_history (); It is used for post cause analysis and saves execution time and status information of stored processes.   MAX_LOAD_PROCESS_ID = get_max_cpu_possess_process (); Determine which processes occupy the most CPUs per unit time   for (i = 0; i <LowPri_Reboot_Except_List_Cnt; i ++) Check existence of reboot exception list   {     if (MAX_LOAD_PROCESS == LowPri_Reboot_Except_List [i]) {     found = 1;     break;     }   }   if (found) {     kill_MAX_LOAD_PROCESS (); Abort that process   }   else {     reboot (); Perform a reboot   } }

Table 4 shows microcodes for recovering a system from a malfunction to a normal state when a malfunction is detected. 2 corresponds to steps 205 to 213 in the embodiment shown in FIG.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments, but is capable of various modifications within the scope of the invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, by detecting a malfunction through the idle time of the process in a multi-process system, and recovering the system to the normal state by stopping only the abnormal process, it is possible to check the operating time and status of the processes in real time and recover the system without rebooting.

Claims (8)

In a multi-process system device, A storage unit for storing idle time monitoring process information, threshold information of the idle time, and rebooting exception process list information; A determination unit that determines that a malfunction occurs when the idle state of the target process continues above the threshold value; When the malfunction occurs, if the longest running process for the unit time is included in the reboot exception process list, the longest running process is terminated, and the longest running process for the unit time is the reboot exception process. If not included in the list, the device comprising a processing unit for processing to reboot the entire system. delete The method of claim 1, Wherein, And when the malfunction occurs, storing performance information of all processes at the present time. In the method of handling malfunction in a multi-process system, Setting idle time monitoring process information, threshold time information of idle time, and rebooting exception process list information; If the idle state of the target process continues above the threshold, checking whether the longest running process for a unit time is included in the reboot exception process list; If the longest running process for the unit time is included in the reboot exception process list, terminating the longest running process; If the longest running process for the unit time is not included in the reboot exception process list, rebooting the entire system. delete 5. The method of claim 4, If the idle state of the target process continues above the threshold, further comprising storing performance information of all processes at the present time. The method of claim 1, The reboot exception process list is a list of processes capable of normal recovery of the system by stopping only the corresponding process without rebooting when a malfunction occurs. 5. The method of claim 4, The reboot exception process list is a list of processes capable of normal recovery of the system by stopping only the corresponding process without rebooting when a malfunction occurs.

Images