JPH07120302B2 - Task debug method - Google Patents

Description

TECHNICAL FIELD The present invention relates to an operating system for multiple programming, and more particularly to a task debug system.

[Conventional technology]

The processing of the information in the information processing device is usually performed by a program. The program processes the information serially. However, in general, a program does not need to be sequentially processed because all processes are related to each other. The processing speed can be improved by dividing the program into modules for each processing and operating them in parallel.

Such an idea is called "concurrent programming", and program modules corresponding to each process are called "tasks". These tasks are managed by the operating system (hereinafter referred to as OS). The OS selects the task in consideration of the task status and allocates the CPU. The tasks operate in parallel and perform processing while synchronizing with each other and communicating data.

Now consider the following OS.

It is assumed that the task operating under the OS performs the state transition shown in FIG. Each state has the following meanings.

・ Run: CPU is allocated by OS.

-Ready ... A condition in which all conditions are met and processing can be executed.

-Wait ... Waiting for the condition to be met.

The OS manages the task by a task control block (TCB) as shown in FIG. The task control block stores information necessary for the OS to manage tasks, such as priority and task status. This task control
The blocks are linked to each other as shown in FIG. The OS has the end of this link and the task control block address of the last task.
The task control block has the task control block address before and after itself, and it is possible to follow them in order. The task control blocks at the beginning of the link have no task control blocks before them, and the last task control block of the link has no task control blocks after them, so their addresses The area contains "0".

When a task requests the OS to operate on another task (issue a system call), specify the task control block address as the value that specifies the task. The priority order is given to each task as a criterion for the OS to specify and select the task. OS is
Select one of the tasks in "ready" state and allocate the CPU. The OS allocates the CPU to the task with the highest priority among the tasks in the “ready” state.

Next, run the tasks under the control of such OS,
This will be described with reference to FIG.

For the sake of simplicity, the number of tasks is two, and they are called “task A” and “task B”, respectively. These tasks are task control block TCB-A, task
Managed by control block TCB-B.
The task control blocks are linked to each other as already explained. FIG. 5 shows this state. The priority of tasks is such that task A> task B. The processing of these tasks is performed by inputting / outputting I / O while mutually excluding each other by a semaphore. A semaphore is a mechanism for synchronizing tasks devised by Dijkstra in the Netherlands. Mainly OS
It is used for exclusive control between tasks related to the access of resources owned by. In this OS, it is used for exclusive control when accessing I / O which is a resource of the OS.

Semaphores cannot be operated directly from tasks.
To operate a semaphore, a task makes a request to the OS in the form of a system call.

First, the system call that requests the semaphore is "wai-se
m ”. This system call allows the task to acquire the semaphore. If the semaphore has been acquired by another task, the task that issued this system call will be "run" according to the state transition diagram in Figure 9.
Transition from state to "wait" state.

The system call that returns a semaphore is "sig-sem". This system call causes the task to return the acquired semaphore to the OS. At this time, if there is a task in the "wait" state where the semaphore cannot be acquired, the semaphore can be acquired at this point and the task transits to the "ready" state.

First, the two tasks are in the "ready" state. Since task A has a higher priority, the OS assigns a CPU to task A (see FIG. 10). Task A acquires a semaphore by the "wai-sem" system call for I / O input / output. Task A, which has acquired the semaphore, enters the "wait" state for a certain period of time by the "wai-tsk" system call in order to synchronize with I / O (Fig. 10).

When task A enters the "wait" state, the OS allocates CPU to task B. Task B is at the same time as Task A
Issue the "wai-sem" system call to input / output I / O. However, since the semaphore has already been acquired by task A, task B transitions to the "wait" state (Fig. 10). Since both tasks entered the "wait" state, the CPU enters the task unassigned state (Fig. 10).

When the specified time has elapsed, task A transits from the "wait" state to the "ready" state and resumes I / O processing (Fig. 10). When the I / O processing is completed, task A returns the acquired semaphore to the OS by the "sig-sem" system call. The semaphore returned is "wa
It is given to task B that has transitioned to the "it" state. At this point, task B transitions to the "ready" state (Fig. 10). However, since task A is in the "ready" state, task B cannot be assigned a CPU. When the processing in the task A progresses and the task A transits to the "wait" state due to other factors, the CPU is assigned to the task B (Fig. 10).

As described above, the two tasks perform processing while mutually excluding each other.

Next, consider debugging the above task with a debugger that is realized as a task on the same OS. The relationship between the priority of the debugger and the tasks A and B is as follows.

Debugger> Task A> Task B A breakpoint is used as a debugging method. A breakpoint is a point at which task execution is stopped. When the task runs to the breakpoint, "wa
The debugger in the "it" state is started and the task is "wait"
It is realized by transitioning to the state.

Now, it is assumed that the breakpoint is set before the semaphore acquisition operation of task A. The operations of task A and task B at this time will be described with reference to FIG.
For simplicity, the operation of the debugger is not shown in FIG.

As before, the two tasks are in the "ready" state. The debugger is in "wait" state until a command is input. Among tasks in the “ready” state, task A has a higher priority, so the OS allocates CPU to task A (first
(Fig. 1). When task A reaches the breakpoint,
The debugger is started. The debugger calls task A "wai
transition to the "t" state. Due to the transition of task A to the "wait" state, the OS allocates CPU to task B (11th
(In the figure).

Task B issues a "wai-sem" system call for I / O input / output. Before task A acquires the semaphore, "wa
Since it transits to the “it” state, task B can acquire the semaphore (see FIG. 11). Task B, which has acquired the semaphore, enters the "wait" state by the "wai-tsk" system call in order to synchronize with the I / O (Fig. 11).

At this time, it is assumed that the task A, which has been in the "wait" state in order to continue execution, is returned to the "ready" state by the debugger. Since task B is in the "wait" state, the OS allocates CPU to task A (Fig. 11).

Task A tries to acquire a semaphore by the "wai-sem" system call. However, since task B has already acquired the semaphore, it transits to the "wait" state again (Fig. 11).

[Problems to be Solved by the Invention]

As is clear from the above description of the operation, by stopping the task A (putting it in the “ready” state) for debugging, the task B executes the processing before the task A. By nature, debugging should not affect the target system. However, in the conventional method, the minimum relationship that must be observed in the multitask processing such as the task synchronization relationship and the execution order is broken. For this reason, if the stopped task continues to operate, it will be in a state in which there is no resource or the like that should be originally acquired by another task, and normal processing of the task will not be performed. If task B acquires the semaphore and then waits for activation from task A, task A waits for the semaphore to be returned, and task B holds the semaphore It will enter a state where it waits for activation from A. Such a state is called "deadlock", and two tasks enter an infinite waiting state.

[Means for Solving the Problems]

According to the task debugging method of the present invention, a means for designating a plurality of tasks from among tasks operating on an operating system for multiple programming, and the designation in a control block of the plurality of tasks designated by the designating means. Means for storing information indicating that the task has been designated, means for inspecting information in the control block of the stopped task when an arbitrary task is stopped, and the task inspected by the inspecting means When designated by the designating means, means for stopping the execution of the task is provided, and when the execution of any of the tasks designated by the designating means is stopped, other designated tasks are also included. The feature is that they are stopped at the same time.

〔Example〕

Next, a first embodiment of the present invention will be described with reference to the drawings. The conditions such as the number of tasks, the state, and the position of the breakpoint are the same as those used in the description of the conventional example.

FIG. 1 shows a first embodiment of the present invention. Figure 1 shows the third
It corresponds to the status area of the task control block shown in the figure. In FIG. 1, when the identification bit is set to "1", the task is transited to the "wait" state in the breakpoint processing of the debugger.

If "0" is set, the debugger does nothing. FIG. 6 shows the processing flow of the debugger when the task reaches the breakpoint in this embodiment. FIG. 8 shows operation of tasks according to this embodiment and a second embodiment described later.

FIG. 5 shows the links of the task control blocks of each task. For simplicity, the task control block of the debugger is not shown. The OS has the task control block address of task A at the beginning of the link and the task control block address of task B at the end of the link. In the task control block of task A, the next task control block address is assigned to task B.
Contains the task control block address of the. The previous task control block address is "0" because task A is at the beginning of the link. In the task control block of task B,
The task control block address of task A is entered as the previous task control block address. The next task control block address is because task B is at the end of the link,
It is "0".

Next, the operation of this embodiment will be described with reference to FIG. 1, FIG. 5, FIG. 6, and FIG.

Now, it is assumed that task A and task B are designated as the group to be stopped when the breakpoint is reached. The debugger sets "1" to the status identification bit in the task control block that manages task A and task B. After setting, the debugger transitions to the "wait" state. The OS assigns the CPU to task A when the debugger enters the "wait" state (Fig. 8).

When task A reaches the breakpoint, the debugger is launched. The debugger shifts the task A stopped at the breakpoint to the "wait" state. Next, since the task control block of task A is "0",
It can be seen that task A is at the beginning of the link. The next task control block address is task B
Is the task control block address (in FIG. 6). Check the identification flag in the task control block of task B (Fig. 6).
As described above, the identification flag of the task B is “1” in advance.
Is set. Therefore, the debugger is task B
To the “wait” state (FIG. 6, FIG. 8). The task control block of the next task B is referred to and the next task control block address is obtained. Since the next task control block address is "0", it can be seen that task B is at the end of the link. Therefore, the reference of the task control blocks of all the tasks is completed, and the breakpoint processing is ended (see FIG. 6).

After performing the above operations, the debugger enters the "wait" state.

Since all three tasks (debugger, task A, and task B) have entered the "wait" state, the CPU enters the state where no tasks have been assigned (Fig. 8). Here, it is assumed that the operation of continuing the execution is performed. Debugger reaches task A and is placed in "wait" state.
To "ready" state. Next, as in the previous step, the identification flag in the task control block is searched, and the task B that has been transited to the "wait" state is "re
Return to "ady" state (Fig. 8). The debugger enters the "wait" state after performing the above operations.

Of the two tasks in the “ready” state, task A has a higher priority than task B, so the OS assigns task A
Allocate CPU (Fig. 8).

Task A resumes processing as described above.

In this embodiment, the grouping can be realized without increasing the size of the table by using the area in the existing task control block.

Next, a second embodiment of the present invention will be described with reference to the drawings.

FIG. 2 shows a task control block in the second embodiment of the present invention. FIG. 7 shows the processing flow of the debugger when the task reaches the breakpoint in this embodiment.

Next, the operation of this embodiment will be described with reference to FIG. 2, FIG. 5, FIG. 6, and FIG. The conditions such as the number of tasks and the states are the same as those used in the description of the first embodiment.

Now, it is assumed that task A and task B are designated as the group to be stopped when the breakpoint is reached. The debugger sets "1" to the group ID in the task control block that manages task A and task B. After setting, the debugger transitions to the "wait" state. The OS assigns the CPU to task A when the debugger enters the "wait" state (Fig. 8).

When task A reaches the breakpoint, the debugger is launched. The debugger shifts the task A stopped at the breakpoint to the "wait" state. Task control of the task put in the "wait" state at the breakpoint
Get the group ID from the block (Fig. 7). Next, the link area (area containing the address of the next task or the previous task) is referred to, and the task control block address of task B is obtained (in FIG. 7). Get the group ID from the task control block of task B. A comparison is made with the group ID of task A obtained earlier (in FIG. 7). As described above, the group IDs of both parties are “1”. Therefore, the debugger shifts task B to the "wait" state (see FIG.
(In the figure). The debugger attempts to get the next task control block address, but the task control block is no longer linked and terminates breakpoint processing (FIG. 7).

After performing the above operations, the debugger enters the "wait" state.

Since all three tasks (debugger, task A, and task B) have entered the "wait" state, the CPU enters the state where no tasks have been assigned (Fig. 8). Here, it is assumed that the operation of continuing the execution is performed. Debugger reaches task A and is placed in "wait" state.
To "ready" state. Next, the group ID in the task control block is searched in the same manner as above, and the task B that has been transited to the "wait" state is "re
Return to "ady" state (Fig. 8). The debugger enters the "wait" state after performing the above operations.

Of the two tasks in the “ready” state, task A has a higher priority than task B, so the OS assigns task A
Allocate CPU (Fig. 8).

Task A resumes processing as described above.

In this embodiment, by setting an arbitrary value in the group ID area, it is possible to set a plurality of groups of tasks stopped at a breakpoint, and the related tasks can be finely divided near each breakpoint. It can be specified and the efficiency of debugging can be improved.

〔The invention's effect〕

As is clear from the above description, according to the present invention, when a task is stopped by a breakpoint, tasks related to the task to which a preset breakpoint is set can be stopped at the same time. This makes it possible to maintain the task synchronization relationship that was not possible with the conventional method, and when the task stopped at the breakpoint is restarted, the subsequent processing is also performed normally. .

Further, according to the present invention, unlike the method in which the entire system is stopped to maintain the synchronization relationship between tasks, it is possible to affect a task that is performing processing that is completely unrelated to the processing of the task to which the breakpoint is set. Absent.

[Brief description of drawings]

FIG. 1 is a diagram showing a first embodiment of the present invention, FIG. 2 is a diagram showing a second embodiment of the present invention, FIG. 3 is a diagram illustrating the structure of a task control block, and FIG. The figure shows a task
Diagram showing a general example of links between control blocks,
FIG. 5 is a diagram showing the link relationship when there are two tasks, FIG. 6 is a flow diagram showing the processing of the debugger when the task reaches a breakpoint in the first embodiment, and FIG. 7 is a second diagram. FIG. 8 is a flow chart showing the processing of the debugger when a task reaches a breakpoint in the embodiment, FIG. 8 is a diagram illustrating the operation of the task in the embodiment of the present invention, and FIG.
FIG. 10 is a diagram showing task state transitions on the OS, FIG. 10 is a diagram showing an operation of two tasks in a normal case, and FIG. 11 is a diagram showing an operation of two tasks in the conventional example. 0, ..., 14,15 …… Bit position.

Claims (1)

[Claims] 1. An operating system for multiple programming
Means for designating a plurality of tasks among the tasks operating on the system, and means for storing information indicating the designation by the designating means in a control block of the plurality of tasks designated by the designating means And means for inspecting information in the control block of the stopped task when any task is stopped, and executing the task if the task inspected by the inspection means is designated by the designating means Equipped with means for stopping
A task debugging method characterized in that, when the execution of any of the tasks specified by the specifying means is stopped, the other specified tasks are also stopped at the same time.