JPH08212064A - Switching system and method for shared subroutine - Google Patents

Abstract

PURPOSE: To effectively switch the shared subroutines without stopping the operation of an entire system. CONSTITUTION: A shared subroutine switching system includes a subroutine switch processing instruction recorder means 5 which instructs how to deal with the task that is using a subroutine when a subroutine switching command is carried out. Then the system decides the using state of the subroutine to be switched and carries out the switch processing when the subroutine is not used by any task and also the means 5 has no designation. In other cases, the task is compulsively finished by an instruction or the switch processing is delayed until the task is finished and the switch processing becomes possible.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a shared subroutine replacing system and shared subroutine for replacing a shared subroutine in a system in which a plurality of tasks share a plurality of shared subroutines without stopping the entire system. Regarding the replacement method.

[0002]

2. Description of the Related Art Conventional operating systems such as UNIX (UNIX: operating system licensed by Unix System Laboratories) can be shared and used by all tasks in the system. Subroutine (called shared library in Unix) is prepared. The shared subroutine is not included in the task object file but is a separate file.
Therefore, the amount of use of the hard disk storing the object files can be reduced as compared with the case where the subroutines are linked to the object files of all the tasks in advance. Further, since the shared subroutine on the memory is shared by a plurality of tasks, the memory usage amount can be saved.

For common subroutines, refer to the document "Managing Programs and Libraries
AIX Version 3 For Risk System / 6000 Processor: IBM Journal of Research and Development, Vol. 34, Vol. 1
Issue January 1990 M. A. By Auslander "(M
anaging programs and libraries in AIX Version 3 fo
r RISC System / 6000 processors: IBM Journal of Rese
arch and Development Vol.34, no1. January 1990: M.
A. Auslander), “Shared Library in SunOS: Euzenix Proceedings”
Robert A. Summer 1987. Zinger et al. "(Shared L
ibraries in SunOS: USENIX proceding Summer 1987: R
obert A. Gingell et al.).

It may be necessary to replace this shared subroutine online. For example, when updating the version of the subroutine during system operation,
This is a case of debugging a shared subroutine. Therefore, in the conventional operating system, a command and a system for performing the replacement process of the common subroutine as shown in, for example, JP-A-4-39739 are prepared.

In Japanese Patent Laid-Open No. 4-39739, the subroutine exchange management means has a call discrimination means for discriminating which subroutine is which task, and the subroutine is currently used by the task running by the call discrimination means. It is determined whether it has been done. Alternatively, instead of the call discriminating means, a subroutine mapping information recording unit for managing which subroutine is currently mapped in the memory is provided, and the usage status of the subroutine is checked from this. Then, when all the subroutines included in the shared subroutine are not used, the replacement process is performed, and when there is a subroutine used by the task, wait until the task using the subroutine finishes, or execute the task. Replace the shared subroutine after forcibly ending it. When a task tries to call a subroutine in the middle of replacement, task management cancels the call and forcibly terminates the task, or postpones the call. As a result, the shared subroutines can be replaced without stopping all the tasks of the system and without causing inconsistency in the execution results of the tasks.

[0006]

In the conventional subroutine replacement process as described in Japanese Patent Laid-Open No. 4-39739, the process for the task executing the subroutine is either task forced termination or task termination waiting. Since it is fixed, there is a problem that the replacement of subroutines brings a large overhead to the system.

The first example is subroutine replacement processing in a system in which tasks of different natures or processing forms coexist. Generally, the nature of the tasks that make up the system can be divided into two types depending on the processing form. One is a task of the nature that it does not end itself by repeating an infinite loop and continuing some processing like a daemon process in Unix. Call it "task". The “daemon type task” often receives a processing request from another task or an input / output device of a computer and performs the processing. Further, if there is no processing request from another task or the input / output device of the computer, the task remains in the execution state and is in the sleep state until the next request arrives. The other is a task that has the property of ending itself when processing is completed, and such a task is called a "normal task" below.

In a system in which two types of tasks, "daemon type task" and "normal task" are mixed,
The conventional replacement process has the following problems. That is, when the process of the subroutine replacement processing unit is fixed to the forced termination of the task when the shared subroutine is replaced, when the subroutine called by the "normal task" is replaced, the "normal task" does not have to call the subroutine thereafter. , Kill the task. This invalidates the processing result of the "normal task" that has been executed until then, and the processing must be re-executed from the beginning, resulting in a decrease in processing efficiency.

On the contrary, if the processing of the subroutine replacement processing unit is fixed to the task completion waiting time when the shared subroutine is replaced, the "daemon type task" is executed.
The "daemon-type task" continues to wait for the end of the task when it replaces the subroutine called by the "daemon-type task". Therefore, this waiting time is wasted.

The second example is subroutine replacement processing in a system in which "tasks having exclusive control instructions" and "tasks not having exclusive control instructions" coexist. The "task having an exclusive control instruction" is a task that uses the exclusive control instruction to exclusively access shared data, a shared database, and the like. The exclusive control instruction includes a lock for monopolizing shared data and an unlock instruction for releasing shared data. The “task having no exclusive control instruction” is a task that does not use an exclusive control instruction.

In a system in which these two types of tasks coexist, the conventional replacement processing has the following problems. When the processing of the subroutine replacement processing unit is fixed to the forced termination of the task when the shared subroutine is replaced, the shared data is locked by the task when the subroutine called by the "task having the exclusive control instruction" is replaced. Even in this case, since this task is forcibly terminated, there is no task that unlocks the shared data occupied by the task. Therefore, all the tasks that try to use the shared data thereafter fall into a state where the shared data cannot be used.

On the contrary, when the processing of the subroutine replacement processing unit is fixed at the end of the processing of the task at the time of the replacement of the shared subroutine, when the subroutine called by the "task having no exclusive control instruction" is replaced, Although a task that does not have an exclusive control instruction cannot enter a deadlock state, it continues to wait for the end of the task. Therefore, this waiting time is useless.

As described above, in the known shared subroutine replacement system, since the nature of the task to be investigated is not taken into consideration, a large overhead occurs in the system depending on the combination of the processing for the task and the task type. There was a problem.

An object of the present invention is to provide a system for exchanging shared subroutines which is efficient and reduces the above overhead when exchanging shared subroutines.

[0015]

In order to achieve the above-mentioned object, a shared subroutine replacing system of the present invention comprises a task for executing a user program and a shared subroutine which is a program that can be shared among tasks. ,
A subroutine storage unit for storing the shared subroutine,
In a computer system having a subroutine replacement means for replacing subroutines stored in the subroutine storage part and a task management means for performing task execution start processing and task execution end processing, the subroutine replacement means executes a subroutine replacement command. Sometimes when a subroutine is in use by a task,
It has a subroutine replacement processing instruction recording means for designating the handling of the task based on the nature of the task, and the task management means judges whether the replacement processing is being executed for the subroutine to be called by the task, and the replacement processing is in progress. If so, the processing of the task is interrupted or forcibly terminated, and the subroutine replacement means determines the usage status of the subroutine to be replaced, the subroutine is not used for the task, and is designated as the subroutine replacement processing recording means. If there is not, the replacement process is performed, and in other cases, the task is forcibly terminated according to the instruction, or the subroutine replacement process is postponed until the task ends and the replacement process becomes possible.

[0016]

According to the present invention, when the shared subroutine replacement processing is performed, it is confirmed whether or not the task currently being executed is using the shared subroutine, and if so, the task is designated based on the nature of each task. According to the instruction of the executed subroutine replacement processing instruction recording unit, whether to wait for the end of the task or to forcibly terminate the task is selected.

According to the above, when the subroutine replacement is performed in a system in which tasks having different properties such as "normal task" and "daemon type task" are mixed,
When the "normal task" is being executed, the replacement of subroutines is postponed until the task is completed. Therefore, the processing results up to the middle of the “normal task” are not discarded unnecessarily. If the "daemon-type task" is being executed, the task is immediately terminated and the subroutine is replaced. Therefore, the situation of wastefully waiting for the end of the "daemon-type task" for the subroutine replacement processing does not occur, and an efficient shared subroutine replacement system can be realized.

[0018]

[Embodiment] One embodiment of the present invention is a "normal task".
And an example of a subroutine replacement system in a system in which "daemon type tasks" are mixed. In this system, when changing subroutines, "normal task"
If is being executed, the replacement of subroutines is postponed until the end of the task. If the "daemon type task" is being executed, the task is immediately terminated and the subroutines are replaced.

First, FIG. 1 shows the configuration of a shared subroutine replacing system of the present invention. Tasks 1 and 2 perform a program described by the user or a program defined by the system, and call and execute shared subroutines 31 to 33 when necessary. Each task has task identification information so that it can be uniquely distinguished. The task identification information includes a task number and the like. In addition, in FIG. 1, a "broken line" arrow indicates a movement of data, and a "solid line" arrow indicates a movement of control information.

The shared subroutine is a program which is shared between tasks and can be freely executed. The shared subroutine includes a single-entry subroutine having only a single subroutine inside and a multi-entry subroutine having a plurality of subroutines. In this embodiment,
Although all shared subroutines are described as being single-entry subroutines, it is clear that the present invention is also applicable in the case of multi-entry subroutines.
Each of the subroutines 31 to 33 has a subroutine identifier so that it can be uniquely identified like the task identification information.
The subroutine number is a subroutine number. In this embodiment, the shared subroutine is "lo
It is loaded by the "ad" command and unloaded by the "deload" command. Loading is copying a file of a shared subroutine on an external storage device such as a disk onto a memory. Further, unloading means erasing the loaded shared subroutine from the memory. Also,
It is assumed that the task start process is realized by the command “queue” and the end process is realized by the command “abort”.

The command interpreter 6 interprets a command input by the user 13 with the mouse 125 or the keyboard 126. The command interpreter 6 uses the "load" command, "d"
When the "eload" command is received, the interpreted command and argument are passed to the subroutine exchanging means 15. Also,
When you receive the "queue" command or the "abort" command,
Pass the command and arguments to the task management means 14. Note that "lo
The "ad" command specifies the file name and subroutine identifier of the shared subroutine, and the "deload" command specifies the subroutine identifier as an argument.

The sub-routine exchanging means 15 for exchanging the common sub-routine comprises the sub-routine exchanging unit 4,
It has a subroutine replacement processing instruction recording unit 5, a subroutine use recording unit 9, and a subroutine replacement recording unit 11. Upon receiving the command and the subroutine identifier from the command interpreter 11, the sub-routine exchanging means 15 causes the sub-routine exchanging unit 4 to execute “load” and “deloa”.
d) command.

The task managing means 14 for managing the running state of the task has a task managing section 10 for carrying out task start processing and task end processing, and is called from the command interpreter 6 and the subroutine replacing section 4. "Queue", "ab
In the task management means 14 receiving the "ort" command, the task management unit 10 performs the start processing of the task having the specified task number based on the task number of the task specified as an argument to start the execution or the task to end the execution. Perform termination processing.

The subroutine storage unit 3 is a subroutine file storage unit existing in an external storage device such as a disk.
It represents the area on memory for loading the shared subroutine file stored in 8.

FIG. 3 shows an example of the configuration when one embodiment of the present invention is realized on the computer 12. Task 1, 2
Then, the shared subroutine replacement unit 4 is read from the disk 123 to the memory 122. Thereafter, areas for the task state recording unit 7, the subroutine replacement recording unit 11, the subroutine replacement processing instruction recording unit 7, and the subroutine storage unit 3 are secured in the memory 122. Then, the processor 121 executes these tasks and the subroutine replacement unit. FIG.
Shows that all the subroutines 31 to 33, tasks 1 and 2 and the shared subroutine replacing section 4 exist on a continuous memory, but these can also exist on a discontinuous memory. In addition, it is not necessary that all of them exist in the memory at the same time, and they may all exist in the memory as needed. Further, the computer of this embodiment is provided with the display 124, the mouse 125, the keyboard 126, and the printer 127 as input / output devices, but the input / output devices are not limited to these, and it is not necessary to have all of them.

FIG. 4 shows the configuration of the subroutine replacement recording unit 11. Subroutine replacement recording unit 11,
Corresponding to each of the subroutines 31 to 33, it has areas 111 to 113 indicating whether or not execution of the subroutine is permitted. In each of the areas 111 to 113, "1" is recorded when the use of the corresponding subroutine is permitted, and "0" is recorded when the use is not permitted. Therefore, "1" is stored if the shared subroutine is loaded, and "0" is stored if the shared subroutine is unloaded.

As shown in FIG. 5, the subroutine use recording section 9 has columns 92 to 94 of an area for recording all shared subroutines linked to each task 1 and 2, and a column for recording a subroutine identifier corresponding to the shared subroutine. Has 91. In the present embodiment, the subroutine use recording unit 9 is realized by a bit string, and the value of each of the columns that record the subroutine linked by the task is "1" when the subroutine is in use, and the value when the subroutine is not in use. Is recorded as "0". It is assumed that the contents of the subroutine use recording unit 9 are all initialized in advance. For example, when compiling a task or linking a shared subroutine, the user can specify the subroutine identifier and task number of the shared subroutine used by the task, and this can also be initialized by recording this in a file in the subroutine use recording section. Is.

FIG. 6 shows the structure of the subroutine replacement processing instruction recording unit 5. When each of the tasks 1 and 2 is in the running state, when the subroutine to which the tasks are linked is "deloaded",
An instruction to forcibly terminate the task or stop "deload" until the end of the subroutine is recorded for each task. In the former case, "KILL" is recorded, and in the latter case, "WAIT" is recorded in the corresponding area of each task.

FIG. 7 shows the structure of the task status recording unit 7. The task state recording unit 7 has areas 71 to 73 indicating whether the task is a running state or a stopped state for each of the tasks 1 and 2. In each area, "1" is recorded when the corresponding task is in the running state, and "0" is recorded when the corresponding task is in the stopped state.

The processing procedure from execution of the task to execution of the shared subroutine to stop of the task processing will be described below. Then, a processing procedure of command processing for loading and unloading a subroutine will be described.

A. Task Processing Procedure In FIG. 1, a procedure in which a user command “queue” or “queue” is called from another management unit of the system, task 1 starts execution, and then the task ends is described. . Here, as shown in FIGS. 4 to 7, it is assumed that task 1 links subroutines 31 and 32.

In order for the task 1 to operate normally, the subroutines 31 and 32 used by the task 1 must be loaded in the subroutine storage unit 3 in advance. Here, the user operating the system is the command interpreter.
It is assumed that the subroutines 31 and 32 have already been loaded by issuing "load" of the subroutines 31 and 32 to 6.

Immediately after the start of task execution, control of the process is first transferred to the task management unit 10, and the task management unit 10 executes the command "queue". A flowchart of this "queue" command is shown in FIG.

(1) The type of task is determined, and the area of the corresponding task of the subroutine replacement processing instruction recording means 5 is
Records the process when the subroutine called by the task is "deloaded". In the case of "daemon type task",
If you do not kill the task, you can not replace it,
Record "KILL". In the case of a "normal task", "WAIT" is recorded because it is sufficient to stop "deload" until the end (801).

(2) One subroutine number used by the task is read from the subroutine use recording unit 9 (802).

(3) The subroutine replacement recording unit 11 checks whether or not the area corresponding to the subroutine number is 1 (use permitted) (803). If the value is 0 (use not permitted), the task cannot continue execution, so error processing is performed and the task ends. If 1 (use permitted), the process (4) is executed.

(4) After repeating the processes of (1), (2), and (3) for all the subroutine identifiers recorded in the subroutine use recording section 9, (80)
4) Set the area of the relevant task in the task status recording section to 1 (running status).

(5) The substance of the task is generated (805).

An example of a task type determination method in the process (1) will be described below. The "daemon type task" includes an instruction for reading a processing request from another task. On Unix, processing requests are read using functions such as signals, sockets, and shared memory. When there is no processing request, the "daemon type task" is in the dormant state. In the present embodiment, it is assumed that the request read and the operation to enter the sleep state when there is no request are performed by the system call "qwait". Usually, in "daemon type task", this "qwait" is surrounded by an infinite loop. So when compiling the source program of the task, if "qwait" surrounded by a loop is detected,
The task is decided to be a "daemon type task". Then, an area indicating the task type is generated in the header of the object file of the task determined to be the "daemon type task" and recorded as "daemon type task".

On the other hand, when "qwait" enclosed by the loop cannot be detected, the task is determined to be a "normal task" and is recorded in the header of the object code as "normal task". And in (1), by referring to the area that represents the task type in the header of the object file,
Whether the task is a "daemon type task" or "normal task"
Is determined.

When the processing of the task management unit 10 is completed, the processing moves to the created task. Then, when the processing of the task ends, the task itself calls "abort" to end the task management unit. A flowchart of the "abort" command is shown in FIG.

(1) The stopped state is recorded in the task area of the task state storage section (901).

(2) The substance of the task is deleted (902).

In this embodiment, the first loading of the shared subroutine into the memory is performed by the command input from the command interpreter 6. However, a method of issuing a command to load the subroutine registered in the subroutine use recording unit 9 for all the tasks at the time of starting the computer is also conceivable. For example, in Unix, there is a method of executing a load command when the computer is started up by using the rc command. The rc command is described in detail in "Unix 4.3 BSD Design and Implementation (SJ Leffler et al., published by Maruzen Co., Ltd.)".

B. Load / Unload Command Processing Procedure In FIG. 1, the present embodiment will be described by taking as an example the case where a load / unload command of a shared subroutine is input.

First, when the user inputs the commands "load" and "deload" to the keyboard 125 or other input device, the command interpreter 6 sends the command and its argument to the subroutine exchanging means 15, and the control is executed to the subroutine exchanging means. Move to 15. Subroutine replacement means
In 15 the sent command is transferred to the subroutine changing section 4
To process. FIG. 10 is a flowchart showing the operation of the “deload” of the subroutine replacement unit 4.

(1) First, the subroutine replacement recording section
The area of the relevant subroutine number of 11 is set to 0 (unusable) (1001).

(2) From the line of the subroutine number in the subroutine use recording unit 9, for a task, whether or not the task executes the subroutine is searched (1002). When executing, move to (3). If not, move to (5).

(3) The task status recording unit 7 is searched to see if the task is in the running status (1003). If it is in the execution state, move to (4). If not, move to (5).

(4) The processing for the task being executed is checked from the area of the task in the subroutine replacement instruction processing recording section 5 (1004). If the area of the relevant task is "KILL", the task management means 14 forcibly terminates the task, and if it is "WAIT", it waits until the relevant task is terminated. Then move to (5).

(5) The above processes (2), (3) and (4) are repeated for all task numbers (1005).

(6) The memory area allocated to the relevant subroutine is released (1006).

In this way, the old shared subroutine is deleted from the memory.

Next, FIG. 11 shows a flow chart of the "load" operation of the subroutine changing section.

(1) An unused memory area designated by the subroutine identifier in the subroutine storage unit 3 is allocated to the subroutine (1101). After that, the subroutine file specified by the argument is read from the subroutine file storage unit 8 and loaded into the allocated memory area (1102).

(2) The subroutine number area of the subroutine replacement recording section 7 is set to "1" (usable) (1103).

In this way, the new shared subroutine is replaced.

In the above-described embodiment of the present invention, even when the "load" and "deload" commands cannot be executed, the common subroutine replacement process can be continued. However, in a system where it is more important not to hinder the execution of tasks than the loading and unloading of shared subroutines, subroutine replacement processing is performed for tasks that prioritize such processing when executing the "queue" command. “ABORT” is recorded in the corresponding area of the instruction recording unit 5. When the "deload" command is executed, the subroutine replacement processing instruction recording unit 5
If the task has "ABORT" written in, "deload"
Command processing will be terminated. As a result, it is possible to perform highly reliable shared subroutine replacement processing even in a system in which there is a task for which processing must be prioritized.

Further, in the above-described embodiment of the present invention, the operation instruction at the time of sub-routine replacement processing for each task is automatically given based on the object file. On the other hand, it is also possible to give a processing instruction to the task at the time of the subroutine replacement processing from the user as needed when the shared subroutine replacement processing occurs. The configuration of this embodiment is shown in FIG.
Shown in

This shared subroutine replacement system has a message display section 16 instead of the subroutine replacement processing recording section 5. Then, when a task that uses the subroutine to be replaced is found during execution of the "deload" command, the message display unit 16 displays "kill the task", "wait for the task to finish", or "command An option such as “End” is displayed on the screen and the user is prompted to select a process. Then, the processing of the "deload" command is continued according to the user's selection. In the operation described above, in the processing of step 1004 of FIG. 10, the message display unit shows the user the processing options for the task, and forcibly terminates the task according to the user's selection, or waits for the termination of the task. Alternatively, it can be realized by changing to select whether to terminate the command.

As a result, it is possible to prevent an inadvertent termination of a task or a delay in subroutine replacement processing, and to perform efficient shared subroutine replacement processing.

Furthermore, in one embodiment of the present invention,
The shared subroutine has been described as being a single entry subroutine. However, shared libraries such as Unix are generally multi-entry subroutines, and this case is described below.

In the case of a shared library, a subroutine number is assigned not as a subroutine but as a subroutine identifier for each library. Then, the subroutine use recording unit 9 records which subroutine each task uses, in each library, not in each subroutine. Also, the replacement designation unit of the "load" and "deload" commands is not the subroutine unit but the library unit. By doing so, it is possible to realize a system that efficiently replaces the multi-entry shared subroutine library online.

[0064]

According to the present invention, when the shared subroutine replacement processing is performed, it is confirmed whether or not the task currently being executed is using the shared subroutine, and if so, the task is designated for each task. According to the instruction of the subroutine replacement processing instruction recording unit, it is selected whether to wait for the end of the task or to forcibly end the task.

As described above, when the "normal task" is being executed in a system in which the "normal task" and the "daemon type task" are mixed, the subroutine replacement is postponed until the end of the task. Therefore, the processing results up to the middle of the “normal task” are not discarded unnecessarily. If the "daemon-type task" is being executed, the task is immediately terminated and the subroutine is replaced. For this reason, the situation of wastefully waiting for the end of the "daemon-type task" does not occur due to the subroutine replacement processing.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a subroutine replacement system of the present invention.

FIG. 2 is a configuration diagram of another subroutine replacement system of the present invention.

FIG. 3 is an example of a configuration diagram in which a subroutine replacement system of the present invention is realized on a computer.

FIG. 4 is a configuration diagram of a subroutine replacement recording unit.

FIG. 5 is a configuration diagram of a subroutine use storage unit.

FIG. 6 is a configuration diagram of a subroutine replacement processing instruction storage unit.

FIG. 7 is a configuration diagram of a task state storage unit.

FIG. 8 is a flowchart showing the operation of the embodiment according to the present invention.

FIG. 9 is a flowchart showing the operation of the embodiment according to the present invention.

FIG. 10 is a flowchart showing the operation of the embodiment according to the present invention.

FIG. 11 is a flowchart showing the operation of the embodiment according to the present invention.

[Explanation of symbols]

1, 2 ... Task, 3 ... Subroutine storage section, 4 ... Subroutine replacement section, 5 ... Subroutine replacement processing instruction recording section, 6 ... Command interpreter, 7 ... Task state recording section, 8 ... Subroutine file storage section, 9 ... Subroutine use Recording unit, 10 ... Task management unit, 11 ... Subroutine replacement recording unit, 12 ... Calculator, 14 ... Task management unit, 15 Subroutine replacement unit, 16 ... Message display unit, 31-33 ... Subroutine, 125 ... Mouse, 126 ... Keyboard .

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Masahiko Saito 7-1-1 Omika-cho, Hitachi City, Ibaraki Hitachi Ltd. Hitachi Research Laboratory (72) Inventor Tomoaki Nakamura 5-2 Omika-cho, Hitachi City, Ibaraki Prefecture No. 1 Stock company Hitachi Ltd. Omika factory

Claims (4)

[Claims] Claim: What is claimed is: 1. One or more tasks, a shared subroutine that can be shared and executed between tasks, a subroutine storage section for storing the shared subroutine, and a subroutine exchange for exchanging the shared subroutine stored in the subroutine storage section. In a shared subroutine replacement system having means and task management means for performing execution start processing and execution end processing of a task, the subroutine replacement means uses the subroutine to be replaced by the task when the subroutine is replaced. In the case of being in the middle, it has a subroutine replacement processing instruction recording means for designating the processing for the task that uses the subroutine, and the task management means judges whether the replacement processing of the subroutine used by the task is being executed, and the replacement processing If it's inside The processing for the task that uses the task is interrupted or forcibly terminated, the subroutine replacement means determines the usage status of the shared subroutine to be replaced, and the shared subroutine is not used for the task, and the subroutine replacement is performed. A shared subroutine replacement system, wherein the replacement processing is performed when no designation is made in the processing recording means, and in other cases, processing is performed according to the instruction recorded in the subroutine replacement processing instruction recording means. 2. A method for replacing a shared subroutine in a computer system, comprising: one or more tasks; a shared subroutine that can be shared by the tasks and executed; and a subroutine storage section for storing the shared subroutine. When substituting, the determination process that determines whether or not the sub-routine to be exchanged is in use by a task, and if the sub-routine is in use by a task by this determination process, the sub-routine is used A method for replacing a shared subroutine, characterized by having a process of determining an operation for the task depending on the nature of the task. 3. The shared subroutine replacing method according to claim 2, wherein the nature of the task using the subroutine is determined based on whether or not the task itself stops after the completion of the processing, and the task after the completion of the processing. A method for exchanging shared subroutines, characterized in that in the case of stopping itself, in the process of determining an operation for the task, the exchanging of subroutines is suspended until the task is stopped. 4. The shared subroutine replacement method according to claim 3, wherein the nature of the task is determined based on the task program at the time of compiling the task.