JPS6160137A - Inter-task synchronizing control system - Google Patents

Abstract

PURPOSE:To attain the easy and assured synchronization between tasks with a data processor by allocating a proper identification number ID having the unitary property to a task control block TCB for each generation of a task. CONSTITUTION:A master scheduler 11 extracts numbers one by one out of the unique number trains (#1, #2...) every time a task is produced and allocates these numbers to the TCB ID to connect them to the TCB cues 3, 4, etc. Therefore all tasks existing inside and outside spaces I and II have unique IDs. When a task 17 asks a task 18 for file transfer, the task 17 exchanges the TCB ID and the space information of its own task and registers the TCB ID and the space information (including an exit and an ECB address of the information light obtained in the end of its own task) of both its own task side and a task of the remote side to monitor tables 20 and 21. When the task of the remote side is over, the POST is given to an ECB or an exit routine is schedules.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a synchronization control method for notifying completion of an event between tasks that require synchronization in a data processing device.

[Conventional technology]

Generally, in a data processing device, program execution is
Controlled on a task-by-task basis. Task is ATTACH
Created by macro, TCB (Task Cont
rol Block).

If there are multiple tasks that are related to each other, and a certain synchronization relationship is set between the tasks, such as when task α performs processing that uses the execution results of task β, then Synchronous control is required.

For example, when task α in the execution state needs to wait for the completion of a certain event, it issues a WAIT macro instruction and moves to the waiting state, while task β, on the other hand, issues a PO when a certain event is completed.
Event completion notification is performed using a 3T macro instruction.

In order to notify the task side of waiting for the completion of such an event and the completion of the event, ECB (Eνent Control) is used.
1Block) is provided with a WAIT bit and a completion bit, and the supervisor monitors these displays and performs synchronization control.

There are various other methods for notifying event completion, such as specifying ECB using the A↑TAC11 macro when creating a task, and using the F, NENTS macro.

Next, as a more complicated example, a conventional method of synchronization control, particularly when issuing a file transfer request between different locations across spaces (regions), will be explained in detail with reference to FIG. In the figure, 1 is the space 1, 2 is the space ■, 3 is the common space, 4 is the request destination task (abbreviated as request destination), 5 is the request source task (abbreviated as request source), and 61.7.8 is The save areas A, B, C and 9 are activities, respectively.

■ to ■ indicate processing procedures.

(2) Save the space information of the request destination (the task that actually performs file transfer processing) to the save area A of the common space via the SVC macro. Spatial information consists of:

・Space ID ・TCB address ・Address of the ECB to be PO3Ted at the request destination ・Area for receiving and receiving the information of the request source ■The request source takes out the space information of the request destination from the save area via the SVC macro.

■The requester requests file transfer via the SVC macro. The SVC routine saves the file transfer information and the space information of the request source to the save area B of the common space. Spatial information consists of:

・Space ID ・TC'B address ・Address of the ECB to be PO3Ted at the request destination ・A field for receiving and receiving information about the request destination ■The request source uses the XMPO3T macro to notify information from the request destination to the φR destination. I do.

■Once the file transfer is complete, the requester will receive completion information (O
K, NG, etc.) are notified via the SVC macro.

■The SVC routine saves the completion information to the save area C in the common space.
After evacuating to the request source space, an activity with a high execution priority is scheduled in the request source space (based on the information in the evacuation area B).

■The activity checks the validity of the requested task (
TCB Atlus, “and peek into the task area, etc.) and notify the completion information in the evacuation area C of the common space (MO
VB).

[Problem that the invention seeks to solve]

As in the above example, when an event completion notification is to be sent from a requestee located in a separate location to a requestee, the task of the requestee must exist. If the requesting task ends for some reason and disappears, a processing error or wasteful processing will occur.

However, it is not known whether the requesting task exists or not until the activity is scheduled in the requesting space.
Furthermore, even if the schedule is successful and the validity of the TCB address is checked, there is a problem in that this alone does not provide reliable proof of existence.

Furthermore, if you schedule an activity when the requesting task has already finished and no space exists, the scheduler will be terminated abnormally, so event completion notifications will not be sent until the requesting task is restarted. Abnormal termination processing such as waiting is required.

As described above, conventionally, there has been no effective means for the side sending the event completion notification to confirm the existence of the task on the other side.

[Means for solving problems]

In order to solve the above-mentioned problems, the present invention provides a unique I' that has uniqueness every time a task is created.
By assigning a D' (identification number) to its TCB, it is possible to reliably recognize a task, and i-specific information including the task's TC'B' ID is exchanged between tasks that maintain synchronization, and each task The identification information of the task on the receiving side and the identification information of the own task are respectively registered in the system area, so that they are used when the task on the other side ends.

The configuration of the present invention based on this includes means for assigning a unique I'D to each task at the time of task creation in a data processing device, and means for assigning a unique I'D to each task while the created task exists. Each time each task in a synchronous relationship registers its own task and the other task's unique If) and spatial information in the common space, the other task's ID is provided. The feature is that the termination is monitored using a unique ID.

[Action of the invention]

Figure 1 shows the unique task ID or TCB [
FIG. 2 is a conceptual diagram of a synchronous control method of the present invention using D.

In FIG. 1, 11 is a mask scheduler, 12 is a unique number string (for example, serial number), 13 and 14 are scheduled space I, TCB queue of ■, 15 and 16 are space I and space ■, 17 and 18, respectively. are the tasks of TCB j'D#1 and TCB [D#
2 tasks.

19 is a common space such as C3A (virtual space intercommunication area), and 20 and 21 are tasks 17 and 18, respectively.
represents the task monitoring table.

The mask scheduler 11 receives task #4 when the task is created.
), take out the numbers one by one in order, and select TCB I
After assigning it to D, connect it to TCB queue 3.4 etc. As a result, all existing tasks will have a unique ID, regardless of whether they are inside or outside the space.

For example, assume that task 17 requests task 18 to perform file transfer processing. At this time, tasks 17 and 18 exchange their TCB IDs and spatial information with each other,
The Te13 jD and space information (including the ECB address of the exit or notification destination when the self task ends (EOT)) of the self task and the other task are registered in the respective task monitoring tables 20.21.

As a result, when the other task ends (F, OT), it is PO3Ted to the ECB or an exit routine is scheduled.

Furthermore, by informing the system of the TCB ID of the task on the other side, it is possible to have the system notify the status of the task, that is, the presence or absence of the task.

〔Example〕

The details of the present invention will be explained below based on examples.

FIG. 3 is an explanatory diagram of one embodiment of the present invention. In the figure, 1 to 9 are the same as in Figure 2, 1 is space I, 2 is space ), 6.7.9 is the evacuation area A, B, C19 is the activity, 3
1 and 32 represent task monitoring tables provided according to the present invention.

4.5 If the two tasks of the requester and the requestor are in a synchronous relationship, each side monitors the other side's task, and the other side's task is completed (
EOT), the task monitoring table 31.3 is used to schedule a predetermined exit process.
Create 2.

The information to be registered in the task monitoring table is as shown in Figure 4: - TCB and ID of the monitored task - Space ID of the monitored task - TCB ID of the monitoring source task - Space ID of the monitoring source task - The output of the monitoring source task is the ECB address (destination to be notified when the monitoring target ends).

Furthermore, multiple task monitoring tables can be registered for one task. Additionally, the task monitoring table facilitates scheduling by managing queues in a common space (,S,,QA, etc.).

Figure 5↓, various tables and keys in this embodiment,
It is a related diagram of the knee. In the figure, 51 is a CVT (Com
Communication Vector Table)
,, 5'2 is the key to the monitoring table, 53
are address space control blocks AS and CI3 (Address 5pace Co) provided for each virtual space.
Reference numeral 54 indicates an operation management table for managing the running tasks under each ASCB by Te13 and ID, 55 indicates a TCB queue for space (2), and 56 indicates a TCB queue for space (2).

FIG. 6 shows the format of the operation management table 54 shown in FIG. The operation management table 54 includes a TCB ID for each task under the ASCB and a one-word area that can be used for each task. The one-word area that can be used in a task is an area that can be freely used as a parameter area in a task, and is used to remember the common space area acquired in order to pass information between different schools. It is also connected to ASCB53 for each space, and S
It is placed in a common space such as Q A (System Queue Area). Every time a task is created or deleted, the operation management table for that space is updated.

By using this table, it is possible to know the status of tasks in another space from the tasks in one space.

Next, the operation of the embodiment shown in FIG. 3 will be explained according to the steps ① to ②.

■TCB I[) of request destination (task actually processed)
and spatial information to the common space save area A via the SVC macro.
evacuate to. Space information is: - Space ID - TCB address] 1 - Address of the ECB for PO3T at the requester - This is an area for receiving information about the requester.

■The requester retrieves the requestee's TCB ID and spatial information from the evacuation area A using the SVC exit.

■Requester's TCB ID and spatial information and your own TC
B ID and space information are registered in the task monitoring table 32 via the SVC macro. The request destination's spatial information is the monitoring target, and the own spatial information is the monitoring source.

■The requester requests file transfer via the SVC macro. The SVC routine saves the file transfer information, the TCB ID of the requester, and the space information to the save area B of the common space.

Space information is an area for receiving and receiving the following information: - Space ID - TCB address - Address of the ECB to be PO3Ted at the request destination - Information on the request source.

■Send XMPO3T (information notification from the requester) to the requester.

■Requester's TCB ID and spatial information and your own TC
B' Register the ID and space information in the task monitoring table 31 via the SVC macro. The requester's spatial information is the monitoring target, and your own spatial information is the monitoring source.

■When the file transfer is completed, the completion information (OK, NG, etc.) is notified via SVC.

■The SVC routine saves the completion information to the save area C in the common space.
and schedule the activity in the requesting space (based on the information in evacuation area B).

■The activity notifies the requester of the completion information in the save area C of the common space (MOV B).

Here, when a monitored task is completed, its notification processing is given priority over any other processing within the space. Note that the task monitoring table deletion request is made by the requester when all requests are completed. □・The requester will complete the notification of completion information for all requests from the requester.

〔Effect of the invention〕

When the monitoring source task ends (EOT state), the exit is scheduled with the highest priority in the space, so depending on the schedule status, the exit will be completed if the completion information is notified to the request source. Cancel information notification (cancel activity schedule) ■If the requester's request is being processed (file transfer in progress),
Notification of completion information is suspended or not notified.

This makes it possible to reliably and easily synchronize tasks, so there is no need to be aware of the other party's status when passing completion information as in the past, and processing efficiency can be improved.

[Brief explanation of the drawing]

FIG. 1 is a conceptual diagram of the method of the present invention, FIG. 2 is an explanatory diagram of the conventional method, FIG. 3 is an explanatory diagram of an embodiment of the method of the present invention, FIG. 4 is an explanatory diagram of the task monitoring table, and FIG. 6 is a diagram showing the relationship between tables and queues, and FIG. 6 is an explanatory diagram of the operation management table. In the figure, 11 is a mask scheduler, 12 is a unique number string, 13.14 is a TCB queue, 15.16 is a task with TCB ID #1 and #2, 19 is a common space, and 20.21 is a task monitoring table. represent.

Claims (1)

[Claims] The data processing device includes means for assigning a unique ID to each task at the time of task creation, and means for managing the task using the unique ID for each space while the created task exists, A task characterized in that each task in a synchronous relationship registers the unique ID and spatial information of its own task and the other task in a common space, thereby monitoring the completion of the other task using the unique ID. Synchronous control method between