JPH0390938A - Control system for task stack data - Google Patents

Abstract

PURPOSE:To reduce the manhour for production of an application program by disusing a sorting process corresponding to the necessity/unnecessity for storage of the stack data and the fractionization of tasks. CONSTITUTION:The stack data on tasks are uniformly saved in a secondary storage 14 regardless of the attribute, etc., and then recovered at restart. In such a constitution, the using frequency can be reduced for the stack area of a main storage 12 without fractionizing the stack nor performing a sorting process according to the necessity/unnecessity for storage of the stack data. Thus it is possible to effectively evade the complication of an application program due to the fractionization of the stack and a sorting process of the stack data. Then the labor and the time can be reduced for production and the debug of the application program.

Description

DETAILED DESCRIPTION OF THE INVENTION (Field of Industrial Application) The present invention relates to a task stack data management method applied to online real-time systems and the like.

(Prior art) Traditionally, this type of online real-time system has a dynamic system that handles multiple tasks that are processed in parallel.
A stack area for storing data is provided on the main memory. This stack area tends to have an excessive storage capacity when a large number of tasks exist at the same time and the lifetime of the tasks is long. Therefore, in order to avoid this, the following method is adopted.

First, by subdividing the tasks themselves, the amount of stack data handled by each task can be reduced. Next, the stack data of each task is classified according to whether it is necessary to take over before or after the task is interrupted, and only the stack data that needs to be taken over at the time of task interruption is saved for the duration of the task interruption, and the stack data that does not need to be taken over is By discarding the data when a task is interrupted, the amount of stack data during task interruption can be reduced.

(Problem to be Solved by the Invention) In the conventional method described above, a new problem arises in that when individual tasks are subdivided to reduce the amount of stack data, communication between tasks increases and the number of man-hours required to create an application program increases. A problem arises.

Furthermore, the process of classifying task stack data according to whether or not it is necessary to save it during a task suspension period is performed at the expense of the application program as part of the processing of the application program. As a result, there are problems in that the application program becomes complicated, the number of man-hours required to create it increases, making it difficult to create it, and the number of bugs in the program increases.

(Means for Solving the Problems) First, according to the present invention, the number of man-hours for creating an application program can be reduced by abolishing the classification process according to the necessity of saving stack data and the subdivision of tasks.

In order to avoid an increase in the amount of memory in the stack area due to the abolition of classification processing and subdivision, the stack data is not made to reside in the stack area on main memory during a task suspension period, and is transferred from this stack area to secondary memory. A save/recover method is adopted in which data is saved in a save area on the device and recovered from this save area to a stack area in the main memory when the task is restarted.

However, in this case, the main C
When PU saves and covers stack data,
The processing speed of the original task is considerably reduced. Therefore, according to the present invention, a dedicated CPU is provided which is dedicated to saving and covering stack data.

Furthermore, under a single memory bus, competition between the main CPU and the CPU dedicated to save/recovery for the right to use the memory bus causes one CPU to enter a waiting state, and an improvement in processing performance cannot be expected. It disappears. According to the present invention, the main memory for the stack is a dual-port memory bus equipped with two memory buses that can be accessed independently from both directions.
A memory is installed, and access rights from one port are assigned to the main CPU, and access rights from the other port are assigned to a CPU dedicated to save/recovery.

As a result, the CPU dedicated to save/recovery can independently process the save/recovery of stack data in dual-port memory without affecting the main CPU's processing, maintaining the main CPU's processing speed. be done.

Hereinafter, the operation of the present invention will be explained in detail together with examples.

(Embodiment) FIG. 1 is a block diagram showing the configuration of an online real-time system to which a task stack data management method according to an embodiment of the present invention is applied.

10 is the main CPU that executes the task, 11 is the task/
A dual-port main memory (dual-port memory) in which stack data is stored, 12 a single-port main memory (memory) in which programs and data are stored, 13 a save/recover dedicated CPU, 14 a The secondary storage device 15.16 is a memory bus.

Dual port memory 11 has memory buses 15 and 16
It has two access ports that can be read from and written to through either of them, and task stack data to be saved/recovered is stored in these ports.

FIG. 2 shows the correspondence between the stack area on the dual-port memory 11 and the save area on the secondary storage device 14. An m-plane stack area is formed on the dual-port memory 11 that allows simultaneous processing of reading and writing during task execution and saving/recovering stack data, and all suspended tasks are stored on the secondary storage device 14. An n-plane save area is formed in which stack data of .

Generally, there are a larger number of save areas on the secondary storage device 14 than the number of stack areas on the dual-port memory 11.
Secured above.

FIG. 3 is a flow diagram showing the flow of task execution.

Task execution acceptance queue 50 and task execution waiting queue 5
1 is a queue for controlling the execution of tasks, and includes a stack data recovery request queue 52, a stack data recovery completion notification queue 53, a stack data save request queue 54, and a stack data save completion notification queue 5.
5 is the main CPU10 and the save/recovery CPU
3 is a hardware queue used for communication regarding save/recover processing.

The following describes how the task stack data used by each task is managed when the task is created, interrupted, restarted, or destroyed. For all tasks, task stack data is saved when the task is suspended, and task stack data is recovered when the task is resumed.The details are as follows.

First, when a task generation request occurs, the task is registered in the task execution acceptance queue 50, and then the task is taken out from the task execution acceptance queue 50.
An appropriate free stack area (in this example, stack area 31) on memory 1 is searched for and supplemented. A stack area that is being saved is treated as a stack area that is in use. Next, it is determined whether the task stack data needs to be recovered. When the task is generated, it is determined that recovery is required because there is no stack data to be recovered, and only the task is registered in the task execution queue 51.
The system waits for its execution.

Thereafter, when it is the task's turn to execute, the task is taken out from the task execution queue 51, execution begins using the stack area 31 that is being captured, and the task enters the execution state. When a request to interrupt a task is made during execution, a stack data save request is registered in the stack data save request queue 54 together with save control information for saving the task stack data. When a stack data save request is registered in the stack data save request queue 54, the save/recovery CPU 1
3, based on the save control information added to this save request, the stack data in the stack area 31 on the dual port memory 11 is captured and secured in the corresponding save area ( In this example, the data is transferred to the save area 41). This transfer information does not include the entire stack area, but only the used task/stack data.

Note that the size of one save area surface corresponding to a task on the secondary storage device 14 is variable, and a save area corresponding to the size of the task stack data transferred when the task is interrupted is secured for each task by the capture process. The save area can be used effectively. In addition, save/recovery CP
Even if U13 is saving stack data, main C
If there is another task requesting execution, PU10 starts executing this task and does not enter an idle state.

When the save/recovery dedicated CPU 13 finishes the stack data transfer process, it registers a save completion notification in the stack data/save completion notification queue 55. main cpu
When to receives the stack data save completion notification via the stack data save completion notification queue 55, it shifts the task that issued the stack data save request to the suspended state, and also transfers the stack area 31 on the dual port memory 11 to the suspended state. to open. In this state, the stack data exists only in the save area 41 on the secondary storage device 14.

Thereafter, when a request to resume the suspended task occurs, it is re-registered in the task execution acceptance queue 50.

Next, the task is taken out from the task execution acceptance queue 50, and after an appropriate free stack area (in this example, the free stack area 33) is secured by capture, it is determined whether the task/stack data needs to be recovered. Ru. When the suspended task is restarted, it is determined that stack data recovery is necessary, and a stack data recovery request is registered in the corresponding request queue 52 along with control information. Main CPU
0 means that after this, until stack data recovery is completed,
Perform other tasks. On the other hand, save/recovery CP
When the recovery request is registered in the stack data recovery request queue 52, U13 saves the task stack data to the save area 41 on the secondary storage device 14 based on the control information.
Transfer to the designated stack area 33 is started.

When the save/recovery CPU 13 finishes transferring the task/stack data, the save/recovery CPU 13 saves the save area 4 that was being used.
1 and registers a stack data recovery completion notification in the stack data recovery completion notification queue 53. When the main CPU 10 is notified of the completion of recovery via the stack data recovery completion notification queue 53, the task is re-registered in the task execution waiting queue 51 and enters a task execution waiting state.

Subsequently, when this task's turn to execute comes, it is taken out from the task execution queue 51 and its execution is started using the stack data recovered in the stack area 33. After this, if there is no execution interruption request from the task, the execution ends, the stack area 33 is released, the task disappears, and all task processing ends.

As explained above, stack data is saved when execution of a task is interrupted, and stack data is recovered when execution of a task is resumed. When focusing on a single task, it seems that it takes time to secure and recover the stack data, delaying the execution of the task, but this time is extremely short and does not pose a practical problem. In addition, in a situation where many tasks coexist, other tasks can be executed while stack data related to a certain task is being saved/recovered, so as a result, the burden of saving and recovering stack data is placed on the main CPU10. However, the processing capacity does not decrease.

The present invention has been exemplified above as applied to an online real-time system. However, the task stack data management method according to the present invention can also be applied to a badge processing system where a plurality of tasks are processed in parallel.

(Effects of the Invention) As explained in detail above, the task stack data management method according to the present invention uniformly saves the stack data in the secondary storage device when a task is interrupted, regardless of its attributes, and recovers it when restarting. Because of this configuration, it is possible to significantly reduce the usage of the stack area on the main memory without subdividing tasks or performing classification processing based on whether or not storage of stack data is necessary.

Therefore, the complexity of the application program caused by stack subdivision and stack data classification processing is effectively avoided, and the effort and time required to create and debug it are significantly reduced.

[Brief explanation of drawings]

FIG. 1 shows an online real-time system that applies the task stack data management method according to an embodiment of the present invention.
FIG. 2 is a block diagram showing the configuration of the system. FIG. 2 is a conceptual diagram for explaining the correspondence between the stack area on the dual port memory 1 in FIG. 1 and the save area on the secondary storage device 14. FIG. It is a flow diagram showing the flow of task execution.

Claims (1)

[Scope of Claims] A main CPU that executes a plurality of tasks in parallel; and a dual CPU in which task stack data used by each of the tasks is stored in a stack area by the main CPU through one port. A port-type main memory device, and when a task is interrupted, the task stack data in the main memory device is saved to a secondary storage device through the other port, and when the task is restarted, the task stack data is saved from the secondary storage device through the other port. A task/stack data management method characterized by comprising a CPU dedicated to save/recovery for recovery.