JP2000105708A - Task managing method and multitask os - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a task managing method and multitask OS which can perform task management with a good memory efficiency and can perform programming easily and shorten the processing time. SOLUTION: The task managing method which allows tasks to share a last-in first-out common stack, allows a task put in a standby state from a halt state to enter an execution state in two ways, and puts the task in the execution state back into the halt state according to an end indication puts a task which is in the standby state and should not be executed in a halt waiting state wherein the task enters the halt state after a task of higher priority enters a halt state or is completed, and then puts the task in the halt waiting state in the halt state according to the principle when a task which is currently executed enters the halt state or is completed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multitasking OS capable of simultaneously executing a plurality of tasks, and more particularly to a multitasking OS capable of performing task management with high memory efficiency and easy programming (program creation such as program design / coding / test / debug). The present invention relates to a task management method and a multi-task OS capable of reducing processing time.

[0002]

2. Description of the Related Art A job, which is a single job executed by a user on a computer, is generally composed of a plurality of work units called job steps.
A unit to be executed from the viewpoint of atingSystem) is particularly called a task. That is, a task is a basic unit to which the right to use the CPU is given, and is an entity that executes a program. An OS capable of executing a plurality of the tasks at the same time is called a multitask OS. The multitask OS includes a control program for realizing functions that are the basis of the OS, such as a task management function, a job management function, and a file management function. It is roughly divided into a processing program that supports programming by a user, such as a processor service program. Hereinafter, task management performed by the control program of the multitask OS will be described. [Task Management] The multi-task OS aims at smoothly managing the execution of a plurality of tasks, and such task management requires a stack area for storing a program flow in a main storage device. Become. This stack area is an area required for each task, and the area size is usually equal to or larger than the maximum size required by the task using the stack area. However, in reality, all tasks cannot use the maximum size stack area at the same time due to various restrictions. Therefore, allocating a different stack area for each task is difficult from the viewpoint of memory (main storage) utilization efficiency. It is not preferable.

In order to solve such a problem, a method of allocating the same stack area to a task that is apparent from the design of a program that does not operate at the same time has been conventionally performed. According to this method, since the same stack area is shared by a plurality of tasks, the above-mentioned problem of memory efficiency can be considerably improved. However, even with this method, a stack area is required for tasks that may operate simultaneously, and it cannot be said that this method is a method for completely solving the above problem. Therefore, in recent years, a task management method has been proposed in which all tasks can share the same stack area by limiting the state of the task. Hereinafter, this task management method will be described.

First, in the task management method, as shown in FIG. 11, tasks are managed in three states: an execution state, a standby state, and a sleep state. The execution state is a state in which a CPU is allocated and a program of the task is executing an instruction. The standby state is a state in which a program to be executed has a stack area allocated and waits for CPU allocation. The pause state is a state in which the program waits for the result of performing some processing, such as when waiting for the allocation of resources (such as input / output devices). Is not assigned.

[0005] The task management is performed by a task management program included in the control program, and information necessary for the task management is provided for each task in a task control block (hereinafter, referred to as a task control block) in a main storage device as shown in FIG.
It is called "TCB". ) Is stored. That is, the task management program performs task management based on information (hereinafter, referred to as “task information”) stored in fields such as “task name”, “state”, “interruption address”, and “priority” of the TCB.

[0006] The "task name" field stores a task ID corresponding to the task, and the "status" field stores the current state of the task, that is, whether it is in an execution state, a standby state, or a sleep state.

The "interrupt address" field stores an interrupt address, that is, an address on the stack area to be executed next, and the task management program is stored in the "interrupt address" field. The task is switched by copying the interruption address to the stack pointer of the CPU. For example,
When it becomes necessary to shift the task in the execution state to the standby state based on various factors such as an interrupt and switch another task to the execution state, the task management program sets the interruption address of the execution state task before the switching. The task information including the task information is temporarily stored in the TCB of the task, and when resuming the execution of the task, the task information is read from the TCB and the execution is resumed (at this time, the interrupt address is set to the stack pointer of the CPU). To copy).

In this way, the execution of the task can be resumed in the state before the switching (the CPU resumes the execution from the address held in the stack area specified by the stack pointer).

[0009] By the way, selecting a task to which a CPU is to be assigned (to be in an execution state) from a plurality of tasks in an execution state or a standby state is called task scheduling. In order to enable the task selection operation in this task scheduling, the task is provided with information indicating the priority of the selection operation, that is, the execution priority, and this information is stored in the “priority” field of the TCB. (The information indicating the priority is added by the user at the time of coding.) That is, the task management program can perform the task scheduling by referring to the “priority” field of the TCB. When the task in the execution state completes the process (completes the task), the task management program releases the stack area allocated to the task, erases the task information of the task from the TCB, and then performs task scheduling. .

[0010] In this way, the preemption (interruption) of the running task can be prohibited except when a task with a higher priority is woken up, so that all tasks use the same stack area. The task can be shared and memory-efficient task management becomes possible.

[0011]

The task state transition (the arrow in the state transition diagram of FIG. 11) in the task management is performed by issuing a system call from a task being executed or based on an operator's instruction. Done by The system call is a system call that is opened so that a user can use various services provided by the OS. For example, in a Windows OS, “CreateFile (),
Since ReadFile (), CloseHandle () ", and the like are open, the user can use the file input / output service provided by the OS by creating a program using these system calls. If the call is used, O
Since the service corresponding to the system call is provided by S, the user does not need to create a complicated program.

Here, in the above-described conventional multitask OS that manages tasks by sharing the same stack area, a system call for shifting a task in a standby state to a sleep state cannot be realized (forced suspension cannot be performed). There is a restriction. Such a limitation occurs because the stack adopts a “last-in first-out method (see FIG. 13)” in which the data stored last is retrieved first. That is to say, referring to FIG. 14, when the task B is in the standby state, and the task C having a higher priority than the task B is in the execution state, and the task B is taken out of the stack area (transition to the sleep state), This is because the currently executing task C is destroyed.

For this reason, in the conventional multitask OS in which the same stack is shared by a plurality of tasks, the structure of the program becomes complicated when it is desired to shift the task in the standby state to the sleep state, as described later. There is a problem that much time is required for designing and testing.

Further, the inability to realize the above-mentioned system call poses a problem in that the processing time in task management is reduced. That is, according to the conventional multitask OS, a plurality of processing steps are required in place of the above system call, and as a result, the processing time becomes long. This problem becomes a particularly serious obstacle in a situation where a severe request is required in terms of processing time, for example, when the application of the multitask OS is control of an optical disk device.

Hereinafter, the above problem will be described in more detail with reference to FIG. Here, the tasks T ₁ and T in the standby state
₂ and when there is a task T ₃ of the execution states for internal processing when shifting the execution from the task T ₃ to the task T ₁ will be described. The task priority is T ₃ · T ₂ · T
Higher in order of ₁ .

[0016] If, assuming that it can realize a system call to shift the task in a wait state to a rest state (task force deactivation system call), as shown in FIG. 15 (I), task T ₃ of running task issuing a system call to terminate the current task after issuing the system call to T _2, the process in two steps that are completed (task T ₁ is to shift to the execution state from the waiting state).

However, as described with reference to FIG. 14, prior to the task T ₃ currently being executed, the task T ₂ located below the stack is put into a sleep state (removed from the stack). it means to destroy the task T _3, the task force deactivation system call would not be realized. Therefore, in such a conventional multitask OS, as shown in FIG. 15 (II), the task T ₃ in the execution state issues a termination request to the task T _{2 in the} standby state, and then terminates its own task. Issue a system call (end instruction for the invoking task)
As a result, the task T ₂ changed from the standby state to the execution state
Issues a system call for terminating the invoking task. Furthermore, in order to enable such an operation, it is monitored whether there is a termination request from another task in each task, and if there is a termination request from another task, the own task is terminated. Issue a system call to do so.

As described above, the conventional multitask O
According to S, it is not possible to realize a system call for shifting a task in a standby state to a suspended state, so that the structure of a program is complicated and many processing steps are required. As a result, programming becomes difficult and processing takes time. There was a problem.

The present invention has been proposed on the basis of the above-mentioned conventional circumstances, and a task management method and a multitasking method capable of performing task management with a high memory efficiency, enabling easy programming and reducing processing time. It is intended to provide an OS.

[0020]

The present invention employs the following means to achieve the above object. That is, according to the present invention, as shown in FIG. 2, a plurality of tasks share a common stack of the last-in-first-out method, and a task that has transitioned from a sleep state to a standby state bidirectionally transitions to and from an execution state. It is assumed that a task management method is possible, in which a task in an execution state is returned to a suspended state based on a termination instruction.

In the above-described task management method, a task that is in a standby state and must not be executed is set to a standby state when a task having a higher priority than the task enters a sleep state or when the task is completed, the task is suspended. After shifting on the stack to the sleep-waiting state, the currently executing task goes to sleep or when the task is completed, the task in the sleep-waiting state is removed from the stack based on the above principle. It is going to be in hibernation.
In this way, the task in the standby state can be forcibly suspended.

The task in the sleep waiting state is
When a task activation system call is issued for the task, a transition is made to a re-waiting wait state in which the waiting state and the transition condition are equivalent. In this way, the task in the sleep waiting state can be restored.

Further, the task which is in the sleep state and is to be executed is set to a standby state in which a task having a higher priority than the task enters a sleep state or shifts to an execution state when the task is completed. After the transition, the task in the waiting state is transitioned to the execution state based on the above principle when the task currently being executed is put into a sleep state or when the task is completed. In this way, the task in the sleep state can be shifted to the execution state via the waiting state.

The task in the waiting state is shifted to the waiting state by issuing a forced task suspension system call to the task in the waiting state. Is shifted to the re-waiting wait state when a task activation system call is issued for the task in the waiting state. Is performed when a task forced suspension system call is issued for the task in the waiting state. On the other hand, a task in the idle state is shifted to the standby state when a task activation system call is issued to the task in the idle state, and the task in the standby state is shifted to the idle state. This is done by issuing a task forced suspension system call to the task in the waiting state.

The task forcible suspension system call and the task activation system call are issued by a task or a handler in an execution state.

[0026]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a schematic functional block diagram of a main part of a multitask OS 10 according to the present embodiment. The task switching unit 11 and the execution task determination unit 12 included in the task management program and the task state storage unit 13a included in the TCB are included. The task priority storage means 13b is shown. Hereinafter, regarding the configuration of the multitask OS 10 according to the present embodiment,
Only different points from S will be described. [Task state transition] As shown in FIG. 2, task management in this embodiment is performed by adding a pause wait state, a re-wait wait state, and a wait wait state to three states of an execution state, a standby state, and a pause state. Tasks are managed in six states. Hereinafter, a pause wait state, a re-wait wait state, and a wait wait state will be described. Note that, among the above six states, the other four states except the sleep state and the standby wait state are all the states of the tasks in which the area to which the task is allocated exists on the stack.

The pause waiting state is a state in which a task in a standby state is taken by an end instruction such as a task forced suspension system call from a task in an executing state, and a task in a pause waiting state has a higher priority than the task. When all tasks are in the sleep state or when the tasks are completed, the state shifts to the sleep state.

The re-waiting waiting state is a state in which a task in a waiting state is taken by an activation instruction such as a task activation system call from a task in an executing state, and a task in a re-waiting state is a task in a waiting state. alike,
When all the tasks having higher priority than the task enter the sleep state or when the task is completed, the task is shifted to the execution state, and when the task forcible sleep system call is issued to the task, the task shifts to the sleep waiting state.

The above-mentioned waiting state is a state in which a task in a dormant state is taken by the above-mentioned task start system call. When the task is completed, the state transitions to the execution state, and when the task forced suspension system call is issued for the task, the state transitions to the suspension state.

That is, in the task management according to the present embodiment, a task that is in a standby state and must not be executed is shifted to a sleep standby state on the stack, and then the standby state and the transition condition are changed as necessary. Form a path for transition to an equivalent re-waiting or hibernation state. In addition, after a task that is in a dormant state and is to be executed is shifted to a waiting state on the stack, a path is formed as necessary to shift to an executing state or to return to a dormant state.

Note that such transition processing is performed by the task switching means 11 or the execution task determination means 12 as described later. [Outline of Processing at Issuance of System Call] An outline of processing executed when a task forcible suspension system call and a task activation system call are issued by a task in an execution state will be described below with reference to FIG.

When a task forcible suspension system call is issued by a task in the execution state, "task forcible suspension processing" for forcibly suspending a task targeted by the system call is performed as shown in FIG. Subsequently, after performing an “execution task determination process” for determining a task to be brought into an execution state after the above process (hereinafter, referred to as “execution task”),
The process of shifting the execution task to the execution state, that is, “task switching process” for switching tasks is performed.

When a task activation system call is issued by a task in the execution state, a "task activation process" for activating the task targeted by the system call is performed as shown in FIG. After performing the “execution task determination process”, the “task switching process” is performed.

Hereinafter, these processes will be described in more detail with reference to FIGS. [Task forcible suspension processing] When a task forcible suspension system call is issued by a task in the execution state, first, the execution task determination unit 12 refers to the task state storage unit 13a to determine the state of the task to be forcibly suspended. It is determined whether or not the task is in a running state. If the task is determined to be in an executing state, the task to be forcibly suspended is changed to a suspended state (step 1 in FIG. 4 → step 6, FIG. 7 (a)).

On the other hand, if it is determined that the task is not in the execution state, the execution task determining means 12 further determines whether the state of the task to be forcibly suspended is in the standby state (step 1 in FIG. 4).
→ Step 2).

Here, when the execution task determining means 12 determines that the task is in the standby state, the task to be forcibly suspended is changed to the suspension wait state on the stack (FIG. 4, step 2 → step 5 → step 7 → Step 8, FIG. 7 (b)
).

On the other hand, if it is determined that the task is not in the standby state, the execution task determining means 12 further determines whether or not the state of the task to be forcibly suspended is in the standby state (FIG. 4, step 2 → step 3).

If the execution task determining means 12 determines that the task is in the waiting state, it changes the task to be forcibly suspended to the suspended state (FIG. 4, step 3 → step 6, FIG. 7 (c)). .

On the other hand, when it is determined that the task is not in the standby waiting state, the execution task determining means 12 further determines whether the state of the task to be forcibly suspended is in the re-waiting standby state (FIG. 4, step 3 → step 4). .

If the execution task determining means 12 determines that the task is to be in the waiting for re-waiting state, the task to be forcibly suspended is changed to the waiting for waiting state on the stack (FIG. 4, step 4 → step 5, FIG. 4). 7 (d)).

If it is determined that the task is not in the re-waiting wait state, that is, if the state of the task to be forcibly suspended is in the suspended state or the suspended waiting state, the system call is terminated as it is (step 4 in FIG. 4).

As a result, the task to be forcibly suspended shifts to the suspended state when the task is in the execution state or the waiting state, and enters the suspended state on the stack when the task is in the waiting state or the re-waiting state. The state shifts to a pause state or a pause wait state, and the state is maintained. That is, by the task forcible suspension processing, the task to be forcibly suspended enters any of a suspended state and a suspended waiting state regardless of the state. [Task Start Processing] When a task start system call is issued by a task in the execution state, first, the execution task determination means 12 refers to the task state storage means 13a to set the state of the task to be started to the sleep state. Then, if it is determined that the task is in the sleep state, the task to be started is stored in the stack as a standby state (step 11 in FIG. 5 → step 13, FIG. 8 (a)).

On the other hand, if it is determined that the task is not in the inactive state, the execution task determining means 12 further determines whether or not the state of the task to be activated is in the inactive state (step 1 in FIG. 5).
1 → Step 12).

If the execution task determination means 12 determines that the task is to be in the waiting state, the task to be started is changed to the waiting state for re-waiting on the stack (FIG. 5, step 12 → step 14, FIG. 8). (b)).

When it is determined that the task is not in the sleep waiting state, that is, when the state of the task to be activated is any of the execution state, the standby state, the re-waiting standby state, and the standby waiting state, the system call is terminated as it is. (FIG. 5, step 12).

As a result, the task to be started is stored in the stack as a waiting state when the task is in a sleep state, and is shifted to a re-waiting state on the stack when the task is in a sleep state.・ Wait state ・ Re-wait state ・
If the state is any of the waiting states, the state is maintained. That is, by the task activation process, the task to be activated becomes any of the execution state, the standby state, the re-waiting standby state, and the standby waiting state in any state. [Executed Task Determination Processing] The execution task determination means 12 that has completed the task forcible termination processing or the task activation processing subsequently determines the “execution task” and obtains information indicating the “execution task” (this information is It is not particularly limited as long as the “execution task” can be specified, and the task switching unit 11 is notified.

Here, the execution task determining means 12 designates the task having the highest priority among the tasks in the execution state, the standby state, the re-waiting standby state, and the standby waiting state as an “executing task”.
As to decide.

Therefore, the task to be forcibly suspended is not determined as an “execution task”, and the task to be activated can be determined as an “execution task”. [Task Switching Process] The task switching unit 11 having received the above notification from the execution task determination unit 12 first determines whether or not the state of the execution task is the execution state by referring to the task state storage unit 13a. If it is determined that the task is in the execution state, the execution state of the execution task is maintained (step 21 → step 25 in FIG. 6).

On the other hand, if it is determined that the state is not the execution state, the task switching means 11 further determines whether the state of the execution task is the standby state (FIG. 6, step 21 → step 2).
2).

If the task switching means 11 determines that the task is in the standby state, the task switching means 11 reads the task information from the TCB 13 and executes the execution task from the interruption address included in the task information. It is to be noted that the execution state before the interruption can be resumed by executing from the interruption address as described in the above-mentioned conventional example (step 22 → step 26 → step 25 in FIG. 6).

On the other hand, if it is determined that the state is not the standby state, the task switching means 11 further determines whether or not the state of the execution task is the standby state (FIG. 6, step 22 → step 23).

Here, when the task switching means 11 determines that the task is in the standby waiting state, the task switching means 11 executes the execution task from the initial execution address. This initial execution address is an address on the stack area for initial execution of the execution task, and is information stored in the TCB 13 (FIG. 6).
Step 23 → Step 27 → Step 25).

On the other hand, if it is determined that the state is not the waiting state, the task switching means 11 further determines whether or not the state of the execution task is the waiting state again (step 23 in FIG. 6).
→ Step 24).

If the task switching means 11 determines that the task is in the re-waiting wait state, the task switching means 11 sets a stack pointer at the top of the stack area used by the execution task (described later), and sets the initial execution address. (Step 24 → step 28 → step 25 in FIG. 6).

As described above, according to the present invention, it is possible to forcibly suspend a task in a standby state (change to a suspended state via a suspended state). [Operation Example] Next, referring to FIG. 9, an example of the operation of the present invention will be described together with the state of the stack and the TCB. Here, four tasks T ₁ , T ₂ , T _3, and T ₄ are described, and the priorities of the tasks are T ₄ , T ₃ , T ₂ , and T _4.
And higher in the order of T _1.

First, the task T in the execution state shown in FIG.
When ₁ issues a task activation system call to the task T ₂ of the pause state, task T ₁ as shown in FIG. 9 (2)
There task T ₂ is in a standby state becomes the execution state. That is, the execution task determination unit 12, and executes the task with the highest task T ₂ of the priority of the tasks T ₁ · T ₂ after the task T ₂ in the rest state to the standby waiting state, the task switching unit 11, The task T _{1 in the} execution state is set to the waiting state, and the execution task, that is, the task T in the waiting state is set.
_{Put 2} in the running state.

[0057] Similarly, when the task T ₄ by the task T ₃ after the task T ₃ is activated by a task T ₂ is started, the task T ₁ · T ₂ · T ₃ as shown in FIG. 9 (3) task T ₄ is in a standby state becomes the execution state.

Here, the task T in the execution state_FourBut tas
K T_ThreeIssues a task forced suspension system call to
Then, the execution task determining means 12 outputs the task in the standby state.
K T _ThreeTask T after suspending₁・ T_Two・ T_Four
Task T with the highest priority_FourIs the execution task,
The task switching means 11 outputs the task T_FourShape
Stay state.

[0059] Similarly, task T ₂ the task T ₄ was in the standby state and to issue a task force deactivation system call to the task T ₂ also becomes dormant wait state. As a result,
As shown in FIG. 9 (4), the task T _2.
T ₃ is that the transition to the rest waiting state on the stack.

Thereafter, when the task T _{4 in the} execution state issues a system call (end instruction for the own task) for ending the own task and shifts to the sleep state (FIG. 9 (5))
), Execution task determination unit 12 shifts the task T ₃ in the rest waiting because higher priority task than the task T ₃ has shifted to all dormant in this state to a rest state (Fig. 9 (6)) further task T ₂ in the rest waiting because of higher priority than the task T ₂ task is migrated to all dormant also goes into hibernation in this state, then,
To migrate tasks T ₁ in the standby state to the execution state (FIG. 9
(7)). In this way, the task in the waiting state (here, the task T ₃ · T ₂ ) becomes the sleeping state when all of the tasks (here, the task T ₄ ) having a higher priority than the task enter the sleeping state, or when the task is completed, the sleeping state is reached. The transition to is as described above.

The above is an example of the operation in the present invention, but the processing required to achieve the same object in the prior art will be described below. Regarding the process illustrated in FIG. 9 (1) to (3) is set to be not described here because it is the same as in the case of the present invention, hereinafter, the task from the task T ₄ in the state in FIG. 9 (3) processing required to transition the execution T ₁ (in the case of the present invention are as described above. that is required a three-step process shown in FIG. 10 (I).) will be described.

First, the task T _{4 in the} execution state issues end requests to the tasks T ₃ and T _{2 in} the standby state sequentially, and then issues a system call for terminating the own task (FIG. 10 (II)). ~). This next higher priority task T ₃ of the task T ₄ is an execution state from the waiting state.

Here, since the task T ₃ has received the termination request from the task T ₄ , it issues a system call for terminating its own task (FIG. 10 (II)). This next higher priority task T ₂ of the task T ₃ is the execution state from the waiting state.

Similarly, task T ₂ issues a system call for terminating its own task because it has received a termination request from task T ₃ (FIG. 10 (II)). This next higher priority tasks T ₁ of the task T ₂ is an execution state from the waiting state.

As described above, the processing achieved in five steps according to the conventional technique can be achieved in three steps according to the present invention. [Reason for adding sleep wait state / re-standby wait state / standby wait state] The reason why a sleep wait state / re-standby wait state / standby wait state is newly added as a task state will be described below.

The reason for adding the pause wait state is as described above with reference to FIG. 14, and therefore the description thereof will be omitted here. First, the reason for adding the re-standby wait state will be described. As described above, the reason for adding the re-waiting wait state is to restore the task that has been in the suspended waiting state (transition to the execution state), but considering only such a reason, the re-waiting state is considered. It seems that a path from the sleep waiting state to the waiting state may be formed without adding the waiting state. However, if the task that has been put into the waiting state is executed under the same condition as the task that is in the waiting state, a problem occurs. In other words, if the task is in the standby state, it is necessary to continue the previous processing and execute it from the interrupt address. Must be executed from the initial execution address. Therefore, in the present invention,
A new task state called the re-waiting wait state, in which the waiting state and the transition condition are equivalent and the execution conditions are different, has been added. In addition,
In the task switching process, when the execution task is in the re-waiting standby state (step 28 in FIG. 6), the stack pointer is set to discard the progress of the processing so far. The reason why the stack pointer is not set in the wait state (steps 26 and 27 in FIG. 6) is to continue the processing up to now.

Next, the reason for adding the waiting state will be described. The reason for adding the wait state is to shift the task that is in the dormant state to the running state.Considering such a reason alone, the state changes from the dormant state to the standby state without adding the wait state. It would be good to form the route of. However, for example, if a task that transitions from the sleep state to the execution state through the above path is forcibly suspended at the time when the task is in the standby state, the task has the highest priority among the tasks existing on the stack. It shifts from the standby state to the sleep state via the sleep wait state (in this case, it is preferable to immediately shift from the standby state to the sleep state without going through the sleep wait state). Therefore, in the present invention, a new task state called a waiting state, which can be shifted to the execution state or returned to the halt state as needed, is added.

The reason that the task in the sleep waiting state and the task in the sleep state have different paths for transition to the execution state (the task does not transition to the execution state through the same state) is that the task once in the suspension wait state Is executed under the same condition as the task in the dormant state, a problem occurs. That is, when the task is in the sleep state, it is necessary to continue the previous processing and execute it from the initial execution address, whereas when the task is in the sleep wait state, as described above, It is necessary to discard the progress and execute from the initial execution address. Therefore, in the present invention, a task in a sleep waiting state shifts to an execution state through a re-waiting wait state, and a task in a sleep state changes to an execution state through a standby waiting state.

In the above-described embodiment, tasks are managed in six states: an execution state, a standby state, a sleep state, a sleep wait state, a re-standby wait state, and a standby wait state. It is not limited to this. For example, when the purpose is only to forcibly suspend a task in a standby state, it is needless to say that the above-described object can be achieved in four states of an execution state, a standby state, a pause state, and a pause wait state.

In the above description, the processing in the case where the task forced suspension system call or the task activation system call is issued by the task in the execution state has been described, but the present invention is not limited to this. That is, a system call as described above is common to a task in that a handler such as an interrupt handler (a handler is an entity that executes a program, but a stack or TCB
Differs from tasks in that it does not have The present invention can be similarly applied to the case in which the present invention is issued.

Further, in the above-described embodiment, each process has been described according to the flowchart. However, the present invention is not limited to the embodiments shown in the flowcharts of FIGS.
For example, a configuration in which the determination process of step 24 in FIG. 6 is omitted may be adopted. Because the execution task is in any of the execution state, the standby state, the re-waiting standby state, and the standby waiting state, the execution task determined to be “NO” in step 23 in FIG. 4 necessarily enters the standby waiting state. .

[0072]

As described above, the multitasking O of the present invention
According to S, the task in the standby state can be forcibly suspended. This eliminates the need for the user to create a program having a complicated structure, thereby facilitating programming. Further, the number of processing steps is smaller than that of a conventional multitask OS, so that the processing time in task management can be reduced. This is particularly effective in a situation where a severe request is required in terms of processing time, for example, when the use of the multitask OS is control of an optical disk device.

Further, in the multitask OS of the present invention, a task that has been forcibly suspended can be put into an execution state, and programming with a high degree of freedom is possible.

[Brief description of the drawings]

FIG. 1 is a schematic functional block diagram of a main part of a multitask OS of the present invention.

FIG. 2 is a state transition diagram of a task in the multitask OS of the present invention.

FIG. 3 is a flowchart showing an outline of processing when a task forced suspension system call / task activation system call is issued in the present invention.

FIG. 4 is a flowchart of task forcible suspension processing of the present invention.

FIG. 5 is a flowchart of a task activation process according to the present invention.

FIG. 6 is a flowchart of a task switching process according to the present invention.

FIG. 7 is an explanatory diagram of a task forcible suspension process of the present invention.

FIG. 8 is an explanatory diagram of a task activation process according to the present invention.

FIG. 9 is an explanatory diagram of an operation example of the present invention.

10 is an explanatory view when performing a transition from the task T ₄ to task T _1.

FIG. 11 is a state transition diagram of a task in a conventional multitask OS.

FIG. 12 is an explanatory diagram of a main storage device in conventional task management.

FIG. 13 is an explanatory diagram of a last-in first-out method.

FIG. 14 is a state diagram of a stack area.

15 is an explanatory view when performing a transition from the task T ₃ to task T _1.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 10 Multitask OS 11 Task switching means 12 Execution task determination means 13 Task control block (TCB) 13a Task status storage means 13b Task priority storage means

Claims (20)

[Claims] 1. A plurality of tasks share a common stack of a last-in first-out system, and a task that has transitioned from a sleep state to a standby state can be bidirectionally transitioned to and from an execution state. A task management method for returning a task that is in a running state to a sleep state by returning a task that is in a standby state and must not be executed to a task that has a higher priority than the task or is completed. After shifting to the sleep state, the currently executing task enters the sleep state or when the task is completed, the task in the sleep state is set to the sleep state based on the above principle. A task management method characterized by shifting. 2. The task management method according to claim 1, wherein the transition to the sleep waiting state is performed when a termination instruction is issued to the task in the waiting state. 3. The task according to claim 1, wherein the task in the waiting state is shifted to a re-waiting state in which a transition state and a transition condition are equivalent when a start instruction is issued to the task. The described task management method. 4. The task management method according to claim 3, wherein the task in the waiting-for-re-waiting state is shifted to a waiting-for-pause state when a termination instruction is given to the task. 5. The task management method according to claim 3, wherein the task in the waiting state for re-waiting is shifted to an execution state when a task having a higher priority than the task enters a sleep state or when the task is completed. . 6. A plurality of tasks share a common stack of a last-in first-out system, and a task that has transitioned from a sleep state to a standby state can be bidirectionally transitioned to and from an execution state. A task management method for returning a task in an execution state to a sleep state, wherein the task in the sleep state to be executed is changed to a task with a higher priority than the task or the task is completed. After shifting to the standby state, the currently executing task goes into the sleep state or when the task is completed, the task in the standby state is shifted to the execution state based on the above principle. A task management method characterized by causing a task to be executed. 7. The task management method according to claim 6, wherein the task in the waiting state is shifted to a sleep state when a termination instruction is given to the task. 8. The task management method according to claim 6, wherein the transition to the standby state is performed when a start instruction is issued to the task in the sleep state. 9. The task management method according to claim 2, wherein the end instruction is a task forcible suspension system call issued by a task in an execution state. 10. The task management method according to claim 2, wherein the end instruction is a task forcible suspension system call issued by a handler. 11. The task management method according to claim 3, wherein the activation instruction is a task activation system call issued by a task in an execution state. 12. The task management method according to claim 3, wherein the activation instruction is a task activation system call issued by a handler. 13. A stack area for sharing a plurality of tasks in a last-in first-out manner, a task state storage means for storing any one of an execution state, a standby state, and a sleep state as a task state, and a task priority. Task priority storage means for storing the degree, execution task determination means for determining the execution task based on the state of the task stored in the task state storage means and the priority stored in the task priority storage means, A multitask OS including a task switching unit that switches the execution task determined by the execution task determination unit to the execution state, wherein the sleep state is stored as a task state in addition to the execution state, the standby state, and the sleep state. Task state storage means, and waiting for the state of tasks that are in the waiting state and should not be executed After transitioning to the sleep state, the task with the highest priority is determined as the execution task from the tasks in the sleep state or the state other than the sleep wait state, and the task in the sleep wait state is assigned a higher priority than the task. A multitasking OS, comprising: the above-mentioned execution task determining means for causing a task to enter a suspended state or to transition to a suspended state when the task is completed. 14. The multitask OS according to claim 13, wherein the transition to the sleep waiting state is performed when a termination instruction is issued to the task in the waiting state. 15. The task state storage means stores, in addition to an execution state, a standby state, a sleep state, and a sleep wait state, a re-standby wait state in which a standby state and a transition condition are equivalent as a task state. 14. The multitask OS according to claim 13, wherein the determination unit determines the execution task after shifting a state of the task to be executed, which is a task in the suspension waiting state, to the standby state. 16. The multitask OS according to claim 15, wherein the transition to the re-waiting wait state is performed when a start instruction is issued to the task in the pause waiting state. 17. The multitask OS according to claim 14, wherein the termination instruction is a task forcible suspension system call issued by a task in an execution state. 18. The system according to claim 1, wherein the termination instruction is a task forced suspension system call issued by a handler.
4. The multitask OS according to 4. 19. The multitask OS according to claim 16, wherein the activation instruction is a task activation system call issued by a task in an execution state. 20. The multitask OS according to claim 16, wherein the activation instruction is a task activation system call issued by a handler.