JPH06161872A - Inter-task exclusive control method - Google Patents

Abstract

PURPOSE:To reduce overhead corresponding to the acquisition and release of lock to resources shared among plural tasks performing parallel processing by specifying the control of the task which can not acquire the lock to the shared resources. CONSTITUTION:When a task A can not successfully acquire the lock, the acquisition of lock is repeatedly tried until the lapse of fixed time. When the lock can not be acquired even after the lapse of fixed time, the processing is transited not to the Waiting state of a conventional system but to a Ready state and when there is the other task previously to the Ready state, a task control part dispatches the available right of a processor to any one of those tasks based on the order of arrival turning to the Ready state. When the use right of the processor is dispatched from the other task, the task A is turned to a Running state again and repeats the sequence from the beginning again. In the case of releasing the lock, any operation is not performed to the other task.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exclusive control method for a plurality of tasks performing parallel processing, and more particularly to an exclusive control method with a small overhead involved in lock acquisition and release processing for a resource shared between tasks.

[0002]

2. Description of the Related Art A multiprocessor having an architecture called a tightly coupled type or a shared memory type is often used as a means for increasing the calculation processing capability of an electronic computer. In these multiprocessors, it is necessary to perform exclusive control on the shared resource stored in the memory so that a plurality of tasks performing parallel processing do not access simultaneously.

FIG. 3 shows a basic configuration of a shared memory type multiprocessor having an exclusive control function between tasks. In FIG. 3, the task control unit 302
A right to use a vacant processor is assigned (dispatched) to a task in the ready (Ready) state, and the task is set to the running (Running) state. In addition, the task control unit 302 forcibly picks up the right to use a processor for a task that has passed a certain time after entering the Running state, returns the task to the Ready state, and grants the right to use the processor to another task in the Ready state. Dispatch. The task control unit 302 also dispatches the usage right of the processor to another task in the Ready state even when the task in the Running state enters the waiting state due to waiting for acquisition of a lock or the like. When multiple tasks are in the Ready state, the task control unit displays the tasks in priority order or Read
A task for dispatching the processor usage right is selected in an order such as a first-come-first-served basis in the y state.

A task running on each processor calls the procedure of the exclusive control unit 301 on the shared memory before starting access to the shared resource so that other tasks do not simultaneously access the same shared resource. Get a lock on. Further, after the access to the shared resource is completed, the procedure of the exclusive control unit 301 is called again to release the lock so that another task can access the same shared resource.

FIG. 4 shows the state transition of task A, which was unable to acquire a new lock for the same resource because task B acquired the lock for the shared resource first. is there. Task A is Ru until then
Although the vehicle was running in the "nning" state 401, the state was changed to the "waiting" state 402 because the lock could not be acquired. After that, when the task B releases the lock on the shared resource, a wakeup signal is sent from the task B to the task A, and the task A transits from the Waiting state 402 to the Ready state 403. Next, when the processor usage right is dispatched to the task A, the task A returns to the Running state 401 again, acquires the lock for this resource, and continues the processing.

FIG. 5 is a flow chart showing a series of procedures from acquisition to release of a lock for a shared resource of one task when the conventional exclusive control method described above is used. First, the task of accessing the shared resource is performed by Test & S provided by the hardware.
An attempt is made to acquire a lock by using an atomic and indivisible command such as et (step 110). If the acquisition of the lock is not successful, the information of the own task is registered in the queue of the shared resource (step 120), and the state transition is made in the order shown in FIG. 4 (steps 130, 140, 150). Then, after acquiring the lock, the shared resource is accessed (steps 160 and 107). When the lock is released after the access is completed (step 180), a wakeup signal is transmitted to one of the tasks registered in the queue of this resource (steps 190, 200).

[0007]

As described above, in the conventional inter-task exclusive control method, the running state →
Waiting state → Ready state → Running
State transition is performed three times such as a state. Generally, there is a problem that a large amount of calculation is required for a task to make a state transition of a task, and a large overhead occurs when a situation where a lock for a shared resource cannot be acquired frequently occurs.

Further, for the task in the Waiting state, it is necessary to perform queue management depending on the cause thereof, that is, which shared resource is requested to acquire the lock, and this management is also an overhead. Furthermore, the task that releases the lock needs to request the lock acquisition for the resource, find the task in the Waiting state, and send a wake-up signal to one of them, and this processing also requires overhead. There was a problem of becoming.

In particular, in a multiprocessor, even if a task that cannot acquire a lock is kept in the Running state, another task that has acquired the lock can run on another processor. It is likely to be released, and there was no need to perform the control operation including the above overhead.

The present invention has been made in view of the above,
It is an object of the present invention to provide an inter-task exclusive control method having a small overhead associated with lock acquisition and release processing for a resource shared by a plurality of tasks performing parallel processing.

[0011]

In order to achieve the above object, an intertask exclusive control method of the present invention is a task in which a lock for a shared resource cannot be acquired in a shared memory type multiprocessor having an intertask exclusive control function. A shared resource is provided with control means for controlling whether a task that has once entered the READY state has passed the tasks that were previously in the READY state and is not in the RUNNING state. The task that cannot acquire the lock for the task keeps retrying to acquire the lock while it remains in the running state until a certain period of time elapses.If the lock cannot be acquired after the certain period of time, the task transits to the ready state and then again. The operation to acquire the lock is repeated from the beginning when it enters the execution state, and when releasing the lock, another operation is performed. And summarized in that no action is taken with respect to disk.

[0012]

In the inter-task exclusive control method of the present invention, a task that cannot acquire a lock for a shared resource repeats lock acquisition retries in the running state until a fixed time elapses, and locks even after the elapse of the fixed time. When the lock cannot be acquired, the state transits to the runnable state, and when the right to use the processor is assigned to this task, the task enters the running state, and the lock acquisition is retried and the lock is released again. , No processing other than release is performed.

[0013]

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows the state transition of task A, which was unable to acquire a new lock for the same resource because task B acquired the lock for the shared resource first. is there. Task A is Ru until then
Although the vehicle was running in the "nning" state 401, the state in which the lock could not be acquired passed for a certain period of time.
Transition to the y state 403. Next, when the right to use the processor is dispatched to the task A, the task A returns to the Running state 401 again and tries to acquire the lock for this resource again.

FIG. 2 is a flow chart showing a series of procedures from acquisition to release of a lock for a shared resource of one task when the intertask exclusive control method according to the present invention is used. First, the task of accessing the shared resource is performed by Test & S provided by the hardware.
An attempt is made to acquire a lock using an atomic and indivisible command such as et (step 210). If the lock acquisition is not successful, the lock acquisition trial is repeated until a fixed time has elapsed (step 220). If the lock cannot be acquired even after the elapse of a certain period of time, the state transits to the Ready state instead of the conventional Waiting state (step 23).
0), if there is another task that is in the Ready state first, the task control unit 302 (FIG. 3) determines that one of the tasks in the Task control unit 302 (see FIG. 3) is in the Ready state. Dispatch usage rights for. The task that was not able to acquire the lock returns to the R state when the processor usage right is dispatched from another task.
The state becomes the unning state (step 240), and the procedure from the beginning is repeated again. The task that can acquire the lock by the above procedure accesses the shared resource (step 250). After the access is completed, the lock is released (step 260), but the wakeup signal is not transmitted to other tasks as in the conventional method, and this series of procedures is immediately terminated.

In the above explanation, the reason why the other task in the Ready state first is executed first is that the task may have acquired a lock on the shared resource in question. This is because, in that case, a phenomenon in which a lock cannot be permanently acquired unless the task is executed first may occur.

[0017]

As described above, according to the present invention,
The task that could not acquire the lock for the shared resource keeps retrying to acquire the lock in the running state until a certain period of time elapses, and transits to the ready state when the lock cannot be acquired even after the certain period of time elapses. After that, when the usage right of the processor is assigned to this task, it will be in the execution state, and retrying to acquire the lock will be repeated again, and when releasing the lock, processing other than release will not be performed. When the client cannot acquire the lock for the shared resource, the lock is retried while keeping the Running state, so that the overhead associated with the task state transition can be removed. Further, when the lock cannot be acquired even after the elapse of a certain period of time, the state transits to the Ready state, but since the state does not go through the Waiting state as in the conventional technique, the number of state transitions is reduced by one, and the overhead is reduced accordingly. . Further, there is no need to send a wakeup signal to a task in the Waiting state by requesting the resource to acquire the lock at the stage of releasing the lock, and the overhead can be removed. Furthermore, queue management for tasks in the Waiting state becomes unnecessary, and this management overhead can be removed.

[Brief description of drawings]

FIG. 1 is a task state transition diagram for explaining an embodiment of the present invention.

FIG. 2 is a flowchart showing a series of procedures of a task for accessing a shared resource according to the present invention.

FIG. 3 is a basic configuration diagram of a shared memory type multiprocessor to which the present invention is applied.

FIG. 4 is a state transition diagram of a task for explaining the conventional technique.

FIG. 5 is a flowchart showing a series of procedures of a task of accessing a shared resource in the related art.

[Explanation of symbols]

 401 Running state 402 Waiting state 403 Ready state 301 Exclusive control unit 302 Task control unit

Claims (1)

[Claims] 1. In a shared memory type multiprocessor having an exclusive control function between tasks, an identification means for identifying whether or not a task for which a lock for a shared resource cannot be acquired has passed for a certain period of time, and a task which is once in an executable state. Has a control means to control so that it does not go into the running state by overtaking the task that was in the ready state before, and the task that cannot acquire the lock for the shared resource will acquire the lock in the running state until a certain time elapses. The lock is locked after a certain period of time.If the lock cannot be acquired after a certain period of time, the operation transitions to the ready state, and when the lock enters the run status again, the operation to acquire the lock is repeated from the beginning to lock An inter-task exclusive control method characterized by not performing operations on other tasks when releasing.