Resource managing method

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Industrial application field]

The present invention relates to computer resource management. [Technical background] First, the program executable body will be described with reference to FIG. As shown in the figure, the program executor consists of space 1, task 2, and thread 3.

【0002】

Space 1 is the only unit that can be controlled from outside the space based on a defined interface such as a system call. Each space 1 is composed of one independent address space, and inside the space 1, task 2 and thread 3 which are internal execution bodies operate to execute a program. Spaces cannot influence each other without going through an interface. Therefore, it is the most robust execution environment in terms of security.

【0003】

Task 2 provides one independent program effective environment in space 1 (for example, the execution environment of a program having a main function in C language). In space 1, there are multiple tasks 2 and it is possible to execute multiple programs. Task 2 is particularly effective when constructing an execution environment for a communication application program. The program execution environment with high task independence allows multiple application programs to be executed in one space, thus reducing space resources.

【0004】

Thread 3 is the most basic control unit that executes the instruction sequence of a program with the execution right of the CPU. Each task 2 can process a program in parallel with a plurality of threads 3 inside. The execution right of the CPU is distributed to each thread 3 in a time-division manner according to the execution priority of the thread. When a thread gets the execution right of the CPU, the instruction code of the program associated with the thread is executed. When the execution thread is switched, the execution environment before the switch is saved, and when the execution thread is re-executed, the saved execution environment is restored.

【0005】

Thread 3 is especially effective when realizing parallel processing of GS (OS server). In GS, in order to process processing requests from clients at high speed, individual threads are used to process each processing request from clients. Due to the structure of the program executor as described above, the resources and attributes originally possessed by the program executor are decomposed into spatial resource 4, task resource 5, and thread resource 6 (for these resources, It will be described later.).

【0006】

By structuring the program execution body in this way, the optimum execution environment and execution form are realized for each application of the program. Here, the spatial resource 4, the task resource 5, and the thread resource 6 will be described. Space 1 has a space resource 4 shared by all tasks 2 in the space. Such resources include a process id that uniquely identifies the space in the system, a user id that indicates the authority of the space, and a group id. and so on. These spatial resources 4 have space-specific properties in the first place, resources that cannot be assigned to lower-level executable bodies (task 2 or thread 3), are unlikely to be changed by a program, and are problematic for sharing by task 2. There are no resources etc. (Conversely, when space 1 operates with multiple tasks 2, the programs operating within each task are restricted from changing spatial resources that affect other tasks.) The following is a list of typical spatial resources 4. 1. Process id 2. Parent process id 3. Process group id 4. Section 5. Actual user id, actual group id, effective user id, effective group id, evacuation user id, evacuation group id 6. Current working directory 7. Root directory 8. File mode generation mask 9. Environment variable pointed to by the external variable environ 10. Load module library 11. Pre-open file However, for environment variables, the task can change the value of its own external variable, environ, to point to the task-specific environment variable range.

【0007】

Each task 2 has task resources such as external variables used by the program and an open environment for files, and provides a program execution environment that does not cause resource conflicts with other tasks. The following is a list of typical task resources 5. 1. Task id 2. External variable area of the program 3. File descriptor, I / O buffer 4. Dynamic acquisition area Thread 3 has only the following typical thread resources and realizes a lightweight execution control body. 1. Thread id 2. CPU resources such as PSW and general-purpose registers 3. Static local variable area of the program 4. Signal master and signal response behavior [0008]

[Conventional technology]

In the conventional resource management method, the program area and the system resource for managing the program area are considered as one, and when the program area is collected, the system resource is also the target of collection. However, with the progress of technology, the program area is increasing day by day, so the system resources for managing this are naturally increasing.

【0009】

[Problems to be Solved by the Invention]

In such a situation, in an environment where a single task operates, the end of the thread is the same as the end of the space, so there is no need to bother to recover the resources managed by the thread or task, so execute it. It does not degrade performance. However, in an environment in which multitasking operates, the thread does not end in space, so it is necessary to recover resources explicitly. Therefore, in multitasking, if the program area to be collected or the system resources for managing the program area increases, the execution performance is significantly deteriorated.

【0010】

An object of the present invention is to improve the execution performance at the time of thread termination and thread regeneration in the resource management method. Furthermore, it is an object of the present invention to improve the execution performance at the time of requesting the recovery of the dynamic program area and the time of requesting the reacquisition of the program area.

【0011】

[Means for solving problems]

In order to achieve the first object, the present invention has one or a plurality of tasks in a space, has one or a plurality of threads in the task, and uses a file management control table for each task. In the resource management method in which file management is performed and program management is performed using the program area management control table for each thread, only the program area and the system resources possessed by the thread are collected at the end of the thread.

【0012】

The system resources of the program area and its threads can be recovered by recovering the area used by the program area management control table. In order to achieve the second object, the present invention has one or more tasks in the space, one or more threads in the task, and uses a file management control table for each task. In the resource management method in which file management is performed and program management is performed using the program area management control table for each thread, only the program area is collected when a dynamic program collection request is made.

【0013】

Note that the dynamic program recovery request means that the user explicitly requests the recovery of the program area, not the recovery request triggered by the recovery of resources such as the space, task, and thread described above. The collection of the program area can be performed by collecting the area used as the program area and clearing the start address of the program area managed by the program area management control table.

【0014】

[Action]

The present invention is characterized in that the management of the program area is not only managed only by the thread which is the scope of the program area, but also by the task which is the higher execution unit. Therefore, in multitasking, only the resources managed by the thread are collected at the end of the thread, and the resources managed by the task are not collected to reduce the amount of resources to be collected and execute at the end of the thread. Improve performance. In addition, when the thread is regenerated, the execution performance at the time of thread regeneration is improved by reusing the system resources that were not collected.

【0015】

In a single task, when a dynamic program area recovery request is made, only the program area is collected and the resources managed by the thread are not collected, so that the amount of resources to be collected is reduced and the dynamic program area is collected. Improves execution performance at the time of request. Further, in order to regenerate the program area, the execution performance at the time of regenerating the program area is improved by reusing the program area that has not been collected.

【0016】

[Example]

First, the structures of various spaces to which the resource management method of the present invention is applied will be described with reference to FIGS. 4 to 6. The space is divided into three types, for example, a space for batch and conversation processing, a communication application space, and a GS space, depending on the difference in the execution environment and execution form of the program.

【0017】

Figure 4 shows the structure of the space for batch and conversation processing, which is a single-tasking environment. The space 7 for batch and conversation processing is composed of one task 2 and one thread 3 operating in the space. For an application program running in this space 7, it is not so important that the program executor is composed of space 7, task 2, and thread 3. The application program runs exclusively on all resources in space 7. The form in which one space, one task, and one thread are degenerated to form a program execution body in this way is called a process.

【0018】

Space 7 for batch and conversation processing is created each time an individual application program or utility program is executed, and is deleted when the program ends. Figure 5 shows the structure of the communication application space, which is a multitasking environment. In the communication application space 8, a plurality of tasks 2 and 2 run multiple times in one space. In each task 2, one thread 1 runs and executes the application program. The file that operates in each task 2 can be run in the program execution environment with high task independence with almost no awareness of the existence of other tasks in the space 8. 10 is a pre-open file environment.

【0019】

The communication application space 8 is created in advance before the application program starts processing, and is deleted when the application program is stopped. In these spaces 8, the files used by the application program can be opened in advance when the space is created. This allows application programs running on tasks to use files with less overhead.

【0020】

Figure 6 shows the structure of the GS space, which is a single-tasking environment. Each server space of the OS is called GS (Global Service) space. In GS space 9, there is only one task 2, and multiple threads 3 and 3 run in it. Processing requests from clients are processed at high speed by lightweight threads. In GS space 9, task 2 does not play a very important role.

【0021】

This GS space 9 is created when the system is started or when the startgs utility is executed, and is deleted when the system is stopped or when the stopgs utility is executed. Among the above-mentioned various spaces, the present invention can be used in a system that requires a multitasking environment such as a communication application space 8 or in a single tasking environment such as a space 7 for batch and conversation processing and a GS space 9. It is valid.

【0022】

Next, the relationship between the program area and the system resources in this embodiment will be described with reference to FIG. In FIG. 7, 11 is a task resource table and 12 is a file management control table. File management control Table 12 is a task resource, and a chain continues for each file. File management control Table 12 records the open environment of files such as file exclusion and information required for file reading.

【0023】

13 is the thread resource table and 14 is the program area management control table. Program area management control Table 14 is a thread resource, and a chain continues for each program. The program area environment control table 14 records the open environment of the file pointing to the file management control table 12 and the program area management such as the start address and size of the program area 15. 15 is the program area.

【0024】

Next, the processing flow at the time of requesting the collection of the program area and the time of requesting the reacquisition of the program area will be described with reference to FIGS. 1 and 2. The processing flow shown in Fig. 1 starts when a collection request for the program area is requested. When each execution body of the space, task, or thread that is the execution body of the program ends, the resources of each execution body are automatically collected. For example, when an executable body called a thread terminates, a resource recovery request is made to a component having a thread resource. The collection request at the end of the thread referred to here means this request. Here, since the component related to the present invention has a thread resource, the system receives an opportunity to recover the thread resource at the end of the thread. At this time, thread resources are collected as needed.

【0025】

Similarly, when the execution body called a task ends, the system makes a resource recovery request to the component having the task resource. This request is a collection request at the end of the task. Further, instead of the collection request triggered by the collection of resources such as the space, task, and thread described above, a dynamic program area collection request is also made in which the user explicitly requests the collection of the program area. Specifically, the supervisor prepares a function for collecting the program area for the user, and the user requests the supervisor to collect the program area by using this function. The main component is the shell, which is used for the effective use of resources because the virtual area of space-time (shell space) is finite.

【0026】

When there is a request to collect the program area, the program area is collected in step S11. Collecting the program area means collecting the area used as the program area 15 and clearing the start address of the program area 15 managed in the program area management control table 14. Next, in step S12, it is determined whether or not the collection request in the program area is a collection request at the end of the thread or task. If it is the above-mentioned dynamic program area recovery request, the process ends only by collecting the program area in step S11.

【0027】

If it is a collection request at the end of the thread or task, the process proceeds to step S13, and the resources held by the thread are collected. Retrieving the resources of a thread means retrieving the area used in Program Area Management Control Table 14. In step S14, it is determined whether or not the collection request is a collection request at the end of the task. If the collection request is a collection request at the end of the thread, the process ends only by collecting the program area in step S11 and collecting the resources held in the thread in step S13.

【0028】

If it is a collection request at the end of the task, the process proceeds to step S15, the resources possessed by the task are collected, and the process ends. The recovery of resources possessed by a task means the recovery of the area used in the file management control table 12 and the return of the open environment of the file which is the information managed by this file management control table 12. In the case of a collection request at the end of the task, the program area of step S11 is collected, the resources of the thread of step S13 are collected, and the resources of the task of step S15 are collected.

【0029】

The processing flow shown in Fig. 2 starts when a reacquisition request for the program area is made. When there is a request for reacquisition of the program area, it is determined in step S21 whether or not there is a corresponding system resource possessed by the thread, and in step S22 it is determined whether or not there is a corresponding system resource possessed by the task. If the corresponding system resource possessed by the thread and the corresponding system resource possessed by the task do not exist together, the corresponding system resource possessed by the task is acquired in step S23, the system resource possessed by the thread is acquired in step S24, and the system resource possessed by the thread is acquired in step S25. The program area is acquired.

【0030】

Here, acquisition of system resources possessed by a task means acquiring an area as a file management control table 12 and constructing an open environment for files in this file management control table 12. Acquiring system resources in a thread means acquiring an area as a program area management control table 14, pointing to the resource table used as a file open environment in this program area management control table 14, and setting the size of the program area. Say to do.

【0031】

Acquisition of the program area means acquiring the area as the program area, reading the contents of the program into this area, performing processing such as rearrangement if necessary, and managing the program area using this acquired address as the start address of the program area. It means to set in control table 14. If there is a corresponding system resource possessed by the thread and there is no corresponding system resource possessed by the task, the system resource possessed by the thread is acquired in step S24, and only the program area is acquired in step S25.

【0032】

If the thread has the corresponding system resource, only the program area is acquired in step S25. Figure 8 compares the recovery status of resources with the conventional method. As can be seen from this table, the dynamic program area recovery request collects only the program area, so the amount of resources to be recovered is reduced. Further, for the reacquisition request for the same program area, the processing is completed only by acquiring the program area.

【0033】

Further, in the collection request at the end of the thread, only the system resources possessed by the program area and the thread are collected, so that the amount of resources to be collected is reduced. In addition, for the reacquisition request at the time of thread playback, the process is completed by acquiring only the system resources possessed by the program area and the thread. Therefore, the processing amount is reduced for the same reacquisition request as in the conventional case, and the execution performance can be improved.

【0034】

The resource management method described above is effective for a dynamic program area recovery request and a program area reacquisition request for a single task. Also, regarding multitasking, it is effective when reusing the task environment. When the task is completed, all the resources possessed by the thread and the resources possessed by the task are recovered, so that the active maintenance of the application realized by the present invention in task units is not hindered.

【0035】

[Effect of the invention]

As described above, according to the present invention, in the resource management method, the execution performance at the time of thread termination and thread regeneration is improved, and further, when a dynamic program area recovery request and a program area reacquisition request are made. Even the execution performance can be improved.

[Simple explanation of drawings]

[Figure 1]

The flowchart which shows the processing flow at the time of the collection request of the program area of the Example of this invention.

[Figure 2]

The flowchart which shows the processing flow at the time of the reacquisition request of the program area of the Example of this invention.

[Fig. 3]

The figure which shows the structure of the execution body of a program.

[Fig. 4]

The figure which shows the structure of the space for batch and conversation processing.

[Fig. 5]

The figure which shows the structure of a communication application space.

[Fig. 6]

The figure which shows the structure of GS space.

[Fig. 7]

The figure which shows the relationship between a program area and a system resource.

[Fig. 8]

The figure which compares and shows the resource recovery state by an Example of this invention, and the resource recovery state by a conventional example.

[Explanation of symbols]

1 ... space 2 ... task 3 ... thread 4 ... Spatial resources 5 ... task resources 6 ... thread resources 7 ... Space for batch and conversation processing 8 ... Communication application space 9 ... GS space 10 ... pre-open file environment 11 ... Task resource table 12 ... File management control table 13 ... Thread resource table 14 ... Program area management control table 15 ... Program area