JPH07120301B2 - Task debugging method - Google Patents

Description

The present invention relates to an operating system for multiple programming, and more particularly to a task debugging method.

[Conventional technology]

Processing of the information in the information processing apparatus is usually performed by a program. The program processes the information serially. However, in general, programs do 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 the program module corresponding to each process is called "task". These tasks are managed by an operating system (hereinafter abbreviated as OS). The OS selects the task in consideration of the task status and allocates the CPU.
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 ... SPU is assigned by the OS.

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

wait ... A condition in which the condition is met.

The OS uses the task control block (task
Control Block (hereinafter abbreviated as TCB)). TCB
The OS stores information such as priority order and task status necessary for the OS to manage tasks. When a task requests the OS to operate on another task (issue a system call), specify the TCB address as the value that specifies the task. The priority order is given to each task as a standard for the OS to 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, the operation of the task for managing the OS 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. 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 used for exclusive control between tasks related to resource access of OS. 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 a semaphore is "wai-se
m ’. This system call allows the task to acquire the semaphore. If the semaphore is acquired by another task, the task that issued this system call "run" according to the state transition diagram in Fig. 6.
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, swa
If there is a task in the "it" state, the semaphore can be acquired at this point, and the task transits to the "ready" state.

First, two tasks A and B are in "ready" state. Since task A has a higher priority, OS assigns CPU to task A
Is assigned (in FIG. 7). 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. 7). When task A enters the "wait" state, the OS sends CPU to task B
Assign The task B issues the "wai-sem" system call to input / output the I / O similarly to the task A. However, since the semaphore has already been acquired by task A, task B transitions to the "wait" state (Fig. 7). Since both tasks A and B have entered the "wait" state, the CPU enters the state where no tasks have been assigned (Fig. 7).

When the designated time has elapsed, the task A transits from the "wait" state to the "ready" state and restarts the I / O processing (Fig. 7). 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. 7). However, since task A is in “ready” state, task B cannot be assigned a CPU. When the processing in task A progresses and task A transitions to the "wait" state due to other factors, the CPU of task B is assigned (Fig. 7).

As described above, the two tasks A and B perform processing while excluding each other.

Next, consider debugging the above tasks A and B with a debugger implemented as a task on the same OS. The method of debugging is that when a task reaches a point specified in advance, the debugger in the "wait" state is activated (transition to the "ready" state) and the task is stopped (transition to the "wait" state). Take the way. Such points are called "breakpoints".

Now set a breakpoint on task A before getting the semaphore. The operation of the task at that time will be described with reference to FIG. For simplicity, the operation of the debugger is omitted in FIG. Debugger and task A, task B
The relationship of the priority of is as follows.

Debugger> Task A> Task B As before, the two tasks A and B are in the “ready” state.
The debugger is in a "wait" state until a command is entered. Of the tasks in the “ready” state, task A has a higher priority, so the OS allocates a CPU to task A (see FIG. 8). When task A reaches the breakpoint, the debugger is launched. The debugger shifts task A to the "wait" state. Due to the transition of task A to the "wait" state, the OS allocates CPU to task B (Fig. 8). That is, the debugger enters the wait state after changing the task A to the wait state. Task B is I / O
Issue "wai-sem" system call for input / output.
Since the task A transits to the “wait” state before acquiring the semaphore, the task B can acquire the semaphore (see FIG. 8). Task B that acquired the semaphore is I / O
It enters the "wait" state by the "wai-tsk" system call to synchronize with (Fig. 8). At this time, task A, which has transitioned to the "wait" state to continue execution,
It is assumed that the debugger has returned to the "ready" state. Since task B is in the "wait" state, the OS sends task A a CPU
Is assigned (in FIG. 8). That is, the debugger enters the wait state after transitioning the task A to the ready state. 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. 8).

[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 “wait” state) for debugging, the task B executes the processing before the task A. Debugging should not affect the target system by nature. 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, a state in which there is no resource or the like that should be originally acquired by another task may occur, and normal processing of the task may not be performed. Further, if the configuration is such that after the task B acquires the semaphore and is started by the task A, the task A waits for the semaphore to be returned,
Task B enters a state of waiting for activation from task A while holding the semaphore. Such a state is called "deadlock", and two tasks enter an infinite waiting state.

[Means for Solving the Problems]

The task debugging method of the present invention specifies a plurality of tasks from among tasks operating on an operating system, and registers the specified plurality of tasks in advance.
When any task registered for debugging is stopped, all other registered tasks are stopped at the same time.

[Action]

Therefore, it becomes possible to maintain the task synchronization relationship, and when the task stopped at the breakpoint is restarted, the subsequent processing is also performed normally.

〔Example〕

Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a first embodiment of the task debugging method of the present invention, and is a flowchart of the processing of the debugger when task A reaches a breakpoint, and FIG. 2 is a group registration table 21 and TCB22 in the first embodiment. , 23, 23
The figure is a time chart showing the operations of tasks A and B.

The conditions such as the number of tasks, the state, and the position of the break point are the same as those used in the description of the conventional example. Now, it is assumed that task A and task B are designated as the task group to be stopped when the breakpoint is reached.

In FIG. 2, 22.23 is the TCBs of tasks A and B, areas 26 and 28 store the addresses of the TCBs linked next to TCBs 22 and 23, and areas 27 and 29 respectively.
The address of the TCB linked immediately before TCB22, 23 is stored, and the TCB address of the task (task A, B in this case) specified in the debugger is registered in the group registration table 21. It

Next, the operation of this embodiment will be described.

First, the debugger shows in Table 21 that Task A and Task B
Link the TCB. The link is done as follows.

First, the TCB address of task B is stored in the storage area 26, and the TCB address of task A is stored in the storage area 29. “0” is stored in the storage areas 27 and 28. Next, TC of task A
The B address is stored in the storage area 24, and the TCB address of task B is stored in the storage area 25. As described above, the TCB links of the specified tasks A and B are formed, and the debugger transits to the "wait" state.

The OS assigns a CPU to task A when the debugger enters the "wait" state (see FIG. 5). When task A reaches the breakpoint, the debugger is launched. The debugger obtains the address of the group registration table 21 (step 11) and the TCB address of the head of the link from the storage area 24 of the group registration table 21 (step 12). This address belongs to task A. First, the debugger shifts task A to the "wait" state (steps 13,1).
Four). Next, the storage area 26 is examined to obtain the address of the next TCB linked, and it is checked whether it is not 0 (steps 15 and 16). In this case, since the TCB address of task B is stored in the storage area 26 and is not 0, the debugger shifts task B to the "wait" state (step 14, FIG. 5). Next, the storage area 28 of the TCB 23 is checked to obtain the address of the next linked TCB, and 0
Check if it is not (steps 15 and 16). In this case, since "0" is stored in the storage area 28,
The debugger has followed the link to the end and the debugger enters the "wait" state (step 17).

Since all three tasks (debugger, task A, task B) have entered the "wait" state, the CPU enters the state where no tasks have been allocated (Fig. 5).

Here, it is assumed that the operation of continuing the execution is performed. The debugger returns to the "ready" state the task A that has reached the breakpoint and has been transitioned to the "wait" state, and the task B that has been transitioned to the "wait" state by the group designation (Fig. 5). After performing the above operation, the debugger
t'state is entered. Of the two tasks A and B in the “ready” state, the priority of task A is higher than that of task B, so the OS allocates CPU to task A (see FIG. 5).

Task A resumes processing as described above.

FIG. 3 is a second embodiment of the task debugging method of the present invention, and is a flowchart of the processing of the debugger when task A reaches a breakpoint, and FIG. 4 is the breakpoint table 41, TCB in the first embodiment. Registration table 42
FIG.

The conditions of 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. Task A,
FIG. 5 is used to explain the operation of B.

In FIG. 4, the number of registered tasks is stored in the area 45 of the TCB registration table 42, the TCB address is stored in the areas 46 and 47, the breakpoint address is stored in the area 43 of the breakpoint storage table 41, and the area 44 is stored. The address of the TCB registration table 42 is stored in.

Next, the operation of this embodiment will be described.

When the breakpoint is set, the debugger stores the breakpoint address in the storage area 43 of the breakpoint storage table 41. When the task group to be stopped when the breakpoint is reached is specified, the debugger sets the number of tasks (= 2) to be registered in the storage area 45 of the TCB registration table 42 to task A and task B in storage areas 46 and 47, respectively. Stores the TCB address of. Then, the address of the TCB registration table 42 is stored in the storage area 44 of the gray point storage table 41. After this processing, the debugger transits to the "wait" state.

The OS assigns a CPU to task A when the debugger enters the "wait" state (see FIG. 5). When task A reaches the breakpoint, the debugger is launched. The debugger obtains the address of the TCB registration table 42 from the storage area 44 (step 31) and the number of registered tasks (= 2) from the storage area 45 (step 32). Next, the TCB address of the task A is obtained from the area 46 of the TCB registration table 42 (step 34), and the task A is transited to the "wait" state (step 35, FIG. 5). Next, the number of registrations is decremented by 1 (step 36), and the TCB registration table 42 area 4
The TCB address of the task B is obtained from 7 (step 34), and the task B is transited to the "wait" state (step 35, fifth).
(In the figure). Next, when the number of registrations is decremented by 1 (step 36), the number of registrations becomes 0, so the debugger "waits".
Enter the state (steps 33 and 37).

Since all three tasks (debugger, task A, task B) have entered the "wait" state, the CPU enters the state where no tasks have been allocated (Fig. 5).

Here, it is assumed that the operation of continuing the execution is performed. The debugger returns to the "ready" state the task A that has reached the breakpoint and has been transitioned to the "wait" state, and the task B that has been transitioned to the "wait" state by the group designation (Fig. 5). After performing the above operation, the debugger
t'state is entered. Of the two tasks A and B in the “ready” state, the priority of task A is higher than that of task B, so the OS allocates CPU to task A (see FIG. 5).

Task A resumes processing as described above.

〔The invention's effect〕

As described above, according to the present invention, when a certain task is stopped by a breakpoint, the tasks related to the task to which a predetermined breakpoint is set are stopped at the same time, which is impossible with the conventional method. It becomes possible to maintain the task synchronous relationship, and when the task stopped at the breakpoint is restarted, the subsequent processing is also performed normally, and the entire system is stopped to maintain the task synchronous relationship. Unlike the method
It does not affect the task that is performing the processing that has nothing to do with the processing of the task that set the breakpoint,
Furthermore, if you enable multiple groups of specified tasks, if multiple breakpoints are set, you can specify the related tasks in the vicinity of each breakpoint in detail, which has the effect of improving debugging efficiency. .

[Brief description of drawings]

FIG. 1 is a first embodiment of the task debugging method of the present invention, and is a flowchart of the processing of the debugger when task A reaches a breakpoint, and FIG. 2 is a group registration table 21 and TCB22 in the first embodiment. , 23,3
The figure is a second embodiment of the task debugging method of the present invention, and is a flowchart of the processing of the debugger when task A reaches a breakpoint, and FIG. 4 is the breakpoint storage table 41 and TCB registration in the first embodiment. FIG. 5 shows the table 42, and FIG. 5 shows tasks A and B in the first and second embodiments.
6 shows the operation of the operating system, FIG. 6 shows the state transitions of tasks on the operating system, and FIG.
FIG. 8 is a diagram showing the operation of a task, and FIG. 8 is a diagram showing the operation of two tasks when the conventional debugging method is used. 11 to 17, 31 to 37 …… Step, 21 …… Group registration table, 22,23 …… TCB, 24-29 …… Area, 41 …… Breakpoint storage table, 42 …… TCB registration table, 43
~ 47 …… Area.

Claims (1)

[Claims] 1. A method of debugging a task in an operating system for multiple programming, wherein a plurality of tasks are designated from among the tasks operating on the operating system, and the designated plurality of tasks are registered and debugged. A task debugging method characterized in that when any task registered for is stopped, all other registered tasks are stopped at the same time.