JP2804478B2 - Task control system and online transaction system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Industrial Application Field] The present invention relates to a tightly coupled multi processor in which a plurality of processors share a memory.
r, hereinafter referred to as TCMP), and particularly to a task control method for lock control suitable for exclusive access control of shared resources.

[Conventional technology]

Processing unit (task) executed in the computer system
Uses various shared resources. In a system in which a plurality of tasks operate at the same time, such as TCMP, a conflict regarding the exclusive use right of the shared resource occurs between these tasks, and thus exclusive control is required for this. For example, when a plurality of tasks perform different “sales processing” in the online system, different tasks refer to and update “current sales” in a common storage area. In such a situation, it is necessary to prohibit another task from accessing this data while one task refers to this “sales current” and updates it.

Many of the computer systems that are currently in practical use support, at the hardware level, instructions for executing one-word referencing and updating in memory (main memory) as inseparable operations as a basic function for exclusive control. (For example, TEST AND SET instruction (TS instruction) or COMPARE AND
SWAP instruction (CS instruction) etc. K. Hwang and FABriggs, “Comp
uter Architecture and Parallel Processing ", McGraw
Hill Publishing, pp. 559-560). However, the shared resource subject to exclusive control is not limited to one word in the main memory, and may be a database on a disk device. Generally, exclusive control of this type of shared resource is performed as follows. That is, the data of the shared resources (a large number of data A, B, C,
.., Etc.), and a reference table for referencing these data is provided. In this table, one-word reference corresponding to the shared data A, B, C,. Information (lock word) is assigned and described. And access to each data A, B, C, ...
This is done through the lock word. The exclusive control for each data of the shared resource can be realized by writing the occupied in use (locked) flag in the lock word using the above-mentioned instruction. However, this method requires processing when the exclusive use right of the shared resource cannot be obtained. WAIT / POST (Suspend / Resume, Block / Ac
It is also called the tivate method, Sleep / Wakeup method, etc. The above document is known).

In the WAIT / POST method, when the shared resource is being occupied by the task 1, the WAIT process that sets the task 2 that has failed to occupy the shared resource to a “waiting state”;
When the shared resource is released, the exclusive control of the exclusive use right of the shared resource is performed between the tasks by the POST process (notification process) for releasing the “waiting state” of the task 2 (hereinafter, the shared resource is shared in the present specification). To obtain the exclusive use right of the resource, take the lock, secure the lock right, etc. Also, express that the lock could not be taken because another task was in the exclusive use while trying to take the lock. Lock failure, failure to secure lock, etc.).

In the following description, "execution state" means that a task
Refers to the state in which it is actually operating with the right to use it, and the `` executable state '' refers to the task state that cannot be executed because the CPU is blocked, but can be executed at any time as long as the CPU is available, On the other hand, the “waiting state” refers to a task state that cannot be executed even if the CPU is vacant because the shared resource is not vacant. The right to use a shared resource is expressed as “exclusive use right”, “exclusive right”, or “lock right”. The use of the CPU is simply expressed as "right to use".

Each task transfers control to the WAIT processing routine when the lock fails. The WAIT processing routine puts the task whose lock failed into a "waiting state" and calls the dispatcher. The dispatcher assigns another task (third, fourth,...) In the “executable state” to the CPU executing the task in the “waiting state”. A dispatcher allocates a CPU to a task in the “executable state” according to an execution priority set in advance for each task. On the other hand, each task (the task that has been executed so far) checks whether there is a "waiting" task (WAIT task) immediately before releasing (unlocking) the shared resource, and if there is a WAIT task, passes control to the POST processing routine. . The POST processing routine returns the WAIT task to the “executable state”. The task that has returned to the “executable state” is assigned a CPU by the dispatcher later, and obtains the right to occupy shared resources, and resumes processing.

As described above, in the WAIT / POST method, exclusive control is realized by setting a task whose lock failed in WAIT processing to a “waiting state” and returning the task to an “executable state” in the POST processing.
Hereinafter, the task that starts the POST process (the task that has been in the running state until now) is called the POST issue task, and the WAIT task that is released from the “waiting state” by the POST process is called the POST accept task (the POST issue task, POST (Receiving tasks, WAIT tasks, etc. are not unique names of each task. Each task may be a POST issuing task or a POST receiving task.) The above-described POST processing routine and WAIT processing routine are incorporated in supervisors of many general-purpose computer systems that are currently in practical use.

[Problems to be solved by the invention]

By the way, the WAIT / POST method has the following problems.

This problem will be described with reference to FIG. FIG. 10 is a timing chart showing an operation example of a task when a lock conflict occurs in the conventional method, and the time axis is a direction from top to bottom. Fig. 10 shows multiple tasks performed by three CPUs 1, 2, and 3.
1, 2, 3, 4, 5,... Are shown. The hatch that descends to the left is task 1, the hatch that descends to the right is task 2,
The white frame portion is the third task (tasks 3 to 5), the coarse satin portion is a supervisor (to bridge tasks) that does not belong to any task, and the fine satin portion is the locking right ( Exclusive use right). LO
CK indicates lock processing, POST indicates post processing, FALL indicates lock failure due to the task at that point, and DISP indicates dispatch processing for the task below.

First, task 1 obtains the lock right on CPU1 (time
t ₁ ), then task 2 fails to lock (time t ₂ ) and enters a wait state. Upon seeing this, when the use of the shared resource ends, the task 1 releases the lock right and issues a POST process to the task 2 (time t ₃ ), whereby the task 2 temporarily locks the shared resource (exclusive right). However, since the CPU is not available at that time (because it does not have the right to use the CPU), it does not immediately enter the execution state (executable state). On the other hand, since a plurality of tasks in the executable state have a priority, the task dispatched when the CPU becomes available does not necessarily become the task 2 that has just been notified. For example, when the CPU 2 becomes available, higher priority task 4 may be dispatching previously (time t ₅ ~t ₆₎ is performed (t ₆ ~t _7). If so, task 4 after the process is executed first was Tsuitsu, so that the task 2 is being dispatching executed (time t ₇ ~t ₈ ~t _9). During the POST process by the task 1 to the task 2 to move to the execution state by task 2 (time t ₃ ~t _8), even if another task on such tasks 3 other CPU issues a lock request ( At time t ₄ ), the lock fails during this time because the lock is in a locked state even though the shared resource is not using any task.

Further, connexion and the task 2, even when receiving the POST at time t _3, the other has a high execution priority tasks, such as task 4, until the end processing of the task 4 is executed, the task 2 You will not be able to get CPU usage rights.

To summarize the above, the prior art has the following problems 1 and 2.

(Issue 1) POST issuance task (task 1 in this case) is POST
After starting the POST process for the accepting task (task 2 in this case), until the POST accepting task is assigned a CPU by the dispatcher and shifts to the execution state, a task other than the POST accepting task (task 3 of the third party). ) Cannot use the shared resource, the ratio of the lock occupation step to all the processing steps (lock occupancy) increases, and the performance of the system decreases. In particular, in a multi-processor system, after a POST issuing task starts POST processing, a task running on another processor will receive a lock request until the POST reception task is assigned to the CPU by the dispatcher and enters the execution state. The lock failure rate (probability of trying to secure the lock and fail) increases, and POST processing
WAIT processing overhead increases.

(Issue 2) When the POST accepting task is released from the waiting state and becomes executable, the high-priority tasks other than the POST accepting task are dispatched first. There is a case where the lock occupation right of the shared resource is obtained but the right to use the CPU is not obtained (hereinafter, the case where the lock occupation task sinks). When the lock occupation task sinks and another task issues a lock request, the lock always fails and the overhead of the POST process and the WAIT process increases.

Therefore, an object of the present invention is to solve the above-mentioned problems (problems 1 and 2) of the prior art, and to prevent the POST acceptance task from being assigned a CPU by the dispatcher and shifting to the execution state. For the purpose of lock control in a multi-task type multi-processor system in which a task can use a shared resource to reduce a lock failure rate and prevent a lock-occupied task from sinking to further eliminate a lock failure. And a task control method.

[Means for solving the problem]

In order to solve the above problem 1, the task control method of the present invention is configured as the following means 1 or 2.

(Solution 1) Means for releasing the shared resource when the POST issuing task finishes using the shared resource, and for permitting the third task running on another processor to lock the shared resource. After that, the PO processing
Means are provided for transitioning the ST acceptance task to the executable state, and thereafter, means for the POST acceptance task, which has obtained the processor use right by the dispatch processing, to retry (retry) securing the lock right of the shared resource. Configuration.

This method has an advantage in that the lock occupancy can be kept low, so that a decrease in throughput due to lock competition is unlikely to occur. However, before the POST receiving task secures the lock, it "steals" the lock to other tasks
And the lock may fail again. For this reason, the same task may repeat the retry many times, and the response may slightly decrease. The problem is as follows (Solution 2)
Is solved by

(Solution 2) When the POST issue task finishes using the shared resource, the shared resource is released, and after the third task running on another processor locks the shared resource, the POST processing is performed. A first lock control method in which the POST receiving task transits to the executable state according to the above, and then the POST receiving task that has obtained the right to use the processor by the dispatch processing retries to secure the right to lock the shared resource; and When the POST issuing task finishes using the shared resource, the lock right of the shared resource is directly transferred to the POST accepting task, and the POST accepting task is shifted to the executable state by the POST process, and then the dispatching process is performed. Therefore, until the POST receiving task that has obtained the right to use the processor releases the locking right of the shared resource, the shared resource by a task other than the POST receiving task is released. And a second lock control method for prohibiting lock, and be provided with a switching means for dynamically switching between the first lock control method and a second lock control system.

Specifically, the number of retries of the POST acceptance task is counted, and if the number of retries is less than a predetermined upper limit, the first lock control is performed. 2 to perform the lock control. In other words, basically, the method of the above-mentioned solution 1 is adopted. However, when the POST acceptance task cannot acquire the lock right even if it requests the lock right many times, or when the specific resource is used,
In this method, the lock right is passed to the POST acceptance task.

Next, in order to solve the above problem 2, the task control method of the present invention is configured as the following solving means 3, 4, and 5.

(Solution 3) After the waiting state of the POST accepting task is released by the POST process, the execution of the POST issuing task is interrupted, and the processor on which the POST issuing task is running is assigned to the POST accepting task.

(Solution 4) Prior to the transition of the POST accepting task to the waiting state by the WAIT processing, the priority is changed to increase the execution priority of the POST accepting task, and the change is performed when the shared resources of the POST accepting task are released. It is configured to restore the execution priority that has been set.

(Solution 5) The POST issuance task performs the POST by the POST processing.
Before releasing the waiting state of the receiving task, change the priority order to increase the execution priority of the POST receiving task.
When the shared resource of the ST acceptance task is released, the changed execution priority is restored.

[Action]

The operation of the present invention based on the above configuration will be described in comparison with a conventional system. This operation will be described later (Example).
The details will be described with reference to FIGS. 10 to 13.

First, the operation of (Solution 1) will be described. In the conventional method, as described earlier with reference to FIG. 10, the task 2 in the waiting state is POSTed by the task 1 and the
During the period until the state becomes the execution state again at U2, the task 3 being executed on the CPU 3 fails to lock. On the other hand, in the method of (Solution 1) of the present invention, the task 2 in the waiting state is POSTed by the task 1 until the task 1 releases the shared resource before the POST processing starts, and the CPU 1 Then, the task 3 running on the CPU 3 can lock the shared resource until the state becomes the execution state again. For this reason, WAIT processing,
The number of times of the POST process can be reduced (details will be described later with reference to FIG. 11).

Next, the operation of (Solution 2) will be described. According to the above-mentioned (solution 1), the task 2 in the waiting state
Is returned by POST by task 1 to the execution state.
The lock may fail again. In the worst case, the task 2 repeats infinitely. Therefore, the number of retries of task 2 is counted, and if the number of retries exceeds a predetermined upper limit, the task 2 that has been POST and returned to the execution state without releasing the shared resource before the start of the POST process is surely performed. The lock control is switched to obtain the lock right.

Next, the operation of (Solutions 3 to 5) will be described. In the conventional system, the task 1 running on the CPU 1 and the task 3 running on the CPU 2 have failed in locking until the task 2 POSTed by the task 1 is dispatched. In contrast, in the method of (Solutions 3 to 5) of the present invention, after POST processing, task 2 is preferentially dispatched and executed on CPU 1, so task 2 is dispatched from the start of POST processing. The time required to complete the task can be reduced, and lock failures of other tasks can be reduced.

[Embodiment] An embodiment of the present invention will be described below with reference to FIGS. This embodiment is an example of an online database system.

Before describing a task control method for the lock control method of the present invention, an outline of an online database system to which the present embodiment is applied will be described. Note that the present invention is not limited to the online system, but can be applied to general multi-processor multiprocessor systems. FIG. 7 shows a schematic configuration of the system. CPU1 and CPU2 (101 and 102) are connected via a shared memory 103. Two CP
Each U operates a program on a memory, and can execute processing in parallel with reference to data on the memory.
Each CPU can transmit and receive data to and from the terminal device 105 via the communication control device 104. In addition, each CPU communicates with the database 1 on the disk via the disk controller 106.
You can access 07.

Hereinafter, in this specification, a set of data reference / update processing in an online database system is referred to as a transaction. For example, "In response to a withdrawal request,
The process of checking the deposit balance, subtracting the withdrawal amount from the deposit balance, and updating the deposit balance in the database "is called a transaction. The transaction starts when data is transmitted from the terminal device.

Next, a basic task management method will be described. When a transaction is input, the supervisor creates one or more tasks corresponding to this transaction. Specifically, the TCB (Task Control Block) in which the supervisor stores control information for each task when the task is created
k) is created, and these TCBs are registered and managed in the task queue 140 shown in FIG. 9 until the end of the transaction. Each task registered in the task queue takes one of a “waiting state”, an “executable state”, and an “executing state”. A task in the "waiting state" completes the event causing the waiting state and cannot allocate a CPU until the task becomes "executable state". The task in the “executable state” can assign a CPU and transition to the “executable state” as soon as any CPU in the system becomes available.
A task in the “running state” is a task that is executing with the right to use the CPU. When there are a plurality of tasks in the “executable state”, the dispatcher allocates a CPU according to the execution priority assigned to each task. The task queue 140
It is composed of a task queue start pointer 141, a task queue end pointer 142, and a chain of zero or more TCBs 143. The TCB consists of the following fields (Fig. 2).

(1) Task state 401 The task state (waiting state, executable state, or execution state) is stored.

(2) Execution priority 402 The execution priority assigned to the task is stored.

(3) When configuring the task queue by chaining the next TCB pointer 403 TCB,
Stores the CB address. In the case of the TCB at the end of the task queue, this field stores 0.

(4) Task information save area 404 Used to save the contents of a PSW (program state word), register, and the like so that when the execution of a task is suspended, the task can be resumed.

Next, a lock contention control method according to the present invention will be described. Hereinafter, in the online database system of the present embodiment, it is assumed that the shared resource subject to lock contention is only one database. That is, it is assumed that there is a single shared resource. In addition, a single task is generated by each transaction. That is, a case is considered where a one-to-one correspondence is established between a transaction and a task. With these assumptions, the advantages of the inventive scheme are not lost.

First, an outline of the lock control and task control method of the present invention will be described with reference to FIG. When each task locks a shared resource, it issues a LOCK macro 551 and calls a lock processing routine 500. If the required shared resources cannot be secured because they are being occupied by another task, the lock control method switching process (503) is performed according to the lock control method switch determination (process 502), and shared before the POST process starts. The first lock control method to release resources or PO
Selects the second lock control method that does not release shared resources before the start of ST processing. Next, WAIT in the supervisor
The processing routine 510 is called (504), and the task which has issued the LOCK macro is set to the "waiting state" (processing 511). In this case, the dayspatcher 530 in the supervisor allocates the CPU to another task in the "executable state" (processing 531 and 53).
2). The task to which the CPU is assigned is in the "running state",
Processing continues until CPU usage is deprived by an interrupt or the like. On the other hand, the task in the “waiting state” continues in the “waiting state” until the task is returned to the “executable state” by the POST process.

On the other hand, when the task that has exclusively used the shared resource unlocks the shared resource, it issues the UNLK macro 552 and calls the unlock processing routine 520. In the unlock processing routine, it is checked whether or not there is a task waiting (process 521). If there is a task in a waiting state, it is determined which lock control method is selected by the lock control method switching processing (503) (processing
522). First to release shared resources before POST processing starts
If the lock control method is selected, the shared resource is released (process 523), and the POST processing routine is called to notify the shared resource release to the WAIT task (524). POS
If the second lock control method that does not release the shared resource before the start of the processing is selected, the PO is used to notify the WAIT task of the release of the shared resource without releasing the shared resource.
The ST processing routine is called (524).

The POST processing routine 540 shifts the POST issuing task from the “executing state” to the “executable state”, and shifts the POST receiving task from the “waiting state” to the “executable state” (processing 54
1). In the lock control system switching process (503), it is determined which lock control system is selected (processing
542). If the first lock control method has been selected, the dispatcher 530 is called (step 544). If the second lock control method is selected, the CPU is preferentially assigned to the POST accepting task (processing 543, 532). The POST accepting task given the right to use the CPU can occupy the shared resource and resume processing.

The case where there is only one WAIT task has been described above. However, in general, there may be a plurality of WAIT tasks.
A task queue (WAIT Queue 130) is used. Before issuing the WAIT macro and calling the WAIT processing routine, the task that failed the lock creates an LRB (abbreviation of Lock Request Block) and chains it to the WAIT queue. Before releasing the shared resource, each task refers to the WAIT queue to check whether there is a task waiting. If there are waiting tasks, that is, one or more tasks in the WAIT queue
If the LRB is chained, the first (oldest in time) LRB (leftmost LRB 132 in FIGS. 7 and 8) is WAIT
Take out from the queue and issue a POST macro that notifies the WAIT task corresponding to this LRB of the release of shared resources.

Next, the data structure of the WAIT queue 130 and the management block will be described with reference to FIGS. 3 and 4 and FIGS. The WAIT queue is provided on the shared memory 103 and can be accessed from each task in the system. One WAIT queue is provided for each shared resource. In this embodiment, as described above, the case where the shared resource is single is considered.
The IT queue is the only one in the system. The WAIT queue is composed of one WCB (abbreviation of WAIT Control Block) 131 and zero or more LRBs 132 provided for each task. Figures 3-4
Figure shows the structure of WCB and LRB.

 The following information is stored in the WCB.

(1) WAIT queue lock word 301 Used for exclusive control of updating of the WCB itself.

When this WCB is occupied, the lock key is stored, and when it is released, 0 is stored.

(2) Resource Lockword 302 Indicates the occupation state of a shared resource subject to exclusive control. The lock key is stored when the shared resource is occupied, and 0 is stored when the shared resource is released.

(3) WAIT queue head pointer 303 Stores the address of the LRB at the head of the WAIT queue. If the WAIT queue is empty, 0 is stored.

(4) WAIT queue end pointer 304 Stores the address of the LRB at the end of the WAIT queue. If the WAIT queue is empty, 0 is stored.

(5) Maximum number of retries (MAX-RETRY-COUNT) 305 Indicates the maximum value of the number of retries in the LRB during the WAIT queue.

(6) Retry upper limit (RETRY-LIMIT) 306 A positive integer indicating the upper limit of the number of lock failures.

(7) Occupied task TCB pointer 307 The TCB address of the task occupying the shared resource is stored. This field has no meaning while the shared resource is released.

 The following information is stored in the LRB 132.

(1) ECB (Event Control Block) 311 In general, POST issue task and WAIT in WAIT / POST method
This is control information for managing occurrence / non-occurrence of a wait event between tasks. No event occurred when POST bit 312 is 0, 1
Indicates that the event has occurred. WAIT 1 indicates WAIT. In this embodiment, it is used to notify the release of the shared resource. The lock key is passed from the POST issuing task to the POST receiving task using the POST code field 314 in the ECB.

(2) Retry count (RETRY-COUNT) 315 This counter indicates how many times the task has failed. When the lock is secured, it is cleared to zero.

(3) When configuring the WAIT queue by chaining the next LRB pointer 316 LRB, the next LRB pointer
Stores the address of

(4) WAIT task TCB pointer 317 Stores the TCB address of the WAIT task corresponding to this LRB.

Next, a description will be given of an algorithm of the lock processing and the unlock processing of the shared resource. In the following description, the resource lock word 302 is simply called a lock word.

When the shared resource is occupied, the TCB address of the occupied task is stored in the lock word, and when not occupied, 0 is stored in the lock word. Since the TCB is generated for each task, the TCB address is used as the task identification information ID.
Hereinafter, this TCB address is used as a lock key.

First, the lock processing will be described with reference to FIG. First,
According to the determination processing 701, it is determined whether or not a POST has been made by another task, that is, after a “waiting state”. This is ECB1
It can be determined by whether the POST bit 312 in 32 is 0 or 1. If the POST has been performed, the old lock key, that is, the POST code 314 in the ECB 132 is loaded into the register 1 (R1) (process 702). In the POST code, the identification information ID of the POST issuance task
(TCB address of the POST issuing task) is stored.
Otherwise, load 0 into register 1 (step 70
3). Next, the new lock key, that is, the identification information ID of the own task (TCB address of the own task) is loaded into the register 2 (R2) (process 704). The determination process 705 is performed as follows using the CS instruction.

CS R1, R2, LOCKWORD This instruction compares the old lock key, which is the content of register 1, with the value of the lock word 302, and if equal, replaces the value of the lock word with the new lock key, which is the content of register 2 (lock succeeded). . If the results of the above comparisons are not equal, no lock word replacement is performed (lock failure). An important point of the function of the CS instruction is that access to the lock word by other CPUs can be prohibited during the above-described read, comparison, and update of the lock word. As a result, when the shared resource is not occupied, or when the PO
Unless the value of the old lock key passed as the POST code from the ST issuing task is equal to the current value of the lock word (that is, at the time of executing the CS instruction), the task that attempted the lock processing fails in lock.

If the lock is successful according to the determination process 705,
In processing 706, the number of retries 315 is returned to 0, and the lock processing is completed. If the lock fails, the number of retries is increased by one (process 707), an LRB is created (when the lock fails for the first time) or the number of retries of the LRB is updated (715), and the WAIT queue 130 is locked (process 708). While the other task is locking the WAIT queue, it loops and waits until the processing of the other task is completed (708a). If the WAIT queue is locked, the number of retries 315 and the maximum number of retries (the number of retries in the WAIT queuing chain that is the largest) 305 are compared (processing 709).

If the number of retries ≧ the maximum number of retries, the maximum number of retries is updated to the current number of retries (processing 710), and the LRB of the invoking task is chained to the head of the WAIT queue (to the highest priority position) (processing 711).

If the number of retries <the maximum number of retries, the LRB of the invoking task is chained to the end of the WAIT queue (processing 712). While the WAIT queue is being updated (during the process of connecting the WAIT queue to the chain, removing it from the chain, and rewriting the counter), the WAIT queue itself is locked so that it cannot be entered from other processors.
When the chain of the LRB to the WAIT queue is completed, the WAIT queue is released (713), and the WAIT macro is called (process 714).
The task that issued the WAIT macro enters "Waiting state" and the PO
Continue "waiting" until ST is performed. When POST is performed, the process returns to the process 701 again to try to secure the lock.

The initialization of the ECB 311 (clearing of the POST bit 312) is performed immediately after the process 702. In steps 711 and 712, the WAIT queue start pointer 303 and the WAIT queue end pointer 303 are used to reduce the lock time of the WAIT queue.
The process of searching for the WAIT queue is not performed. While the WAIT queue is locked, interrupts are prohibited to prevent deadlock with the interrupt task.

Next, the unlocking process will be described with reference to FIG. Sixth
The figure shows in detail the part of the unlocking process 520 of FIG. In the unlock processing, first, the WAIT queue is locked (processing 801). While another task is occupying the WAIT queue, it loops and waits until it can be locked. When the WAIT queue is locked, it is checked whether the WAIT queue is empty, that is, whether there is a task waiting for release of the shared resource (process 802). If there is no WAIT task, the WAIT queue and the shared resources are released (processes 803 to 804). WA
IT ku, release of shared resources, lock word (301
And 302) by writing 0.

If there is a WAIT task, the maximum retry count is 305 first.
Then, the retry upper limit value (the value is set in advance and the control is switched on the basis of this value) 306 is compared (process 805).

If the maximum number of retries <the retry upper limit value, that is, if the number of failures has not reached the upper limit value, the shared resource is released (processing 807), and the POST code 314 is issued.
Is set to 0 (process 808).

If the maximum number of retries ≥ upper limit of retry, that is, if the number of failures has reached the upper limit, PO
The current lock key, that is, the identification information (TCB address 307) of the current lock right occupied task (the task currently occupying the lock right) is set in the ST code (process 806). Next, the LRB at the head of the WAIT queue (corresponding to the task having the maximum number of retries) is extracted (processing 809), the maximum number of retries 305 is updated (processing 811 or 812), and the WAIT queue is released (processing).
813), issue a POST macro to the task corresponding to the LRB extracted in process 809 (process 814), and notify the release of the shared resource. At this time, the POST code set in the processing 806 or 808 is passed to the POST receiving task. This POST code is received by the POST receiving task by the processing 702 or 703 (FIG. 5). With this mechanism, if the number of lock failures is less than the upper limit, the shared resources released by the process 807 compete for "first-come, first-served" between the POST accepting task and other tasks. However, if the number of lock failures exceeds the upper limit, the lock right is passed directly to the POST accepting task without releasing the shared resources in the POST issuing task.

Next, the operation (operation) of the above embodiment will be described with reference to FIGS. 10 to 13 in comparison with the conventional system. In these figures, the hatch, satin-shaped part,
The meanings of the character symbols are the same as those described above with reference to FIG.

First, the operation of the embodiment relating to (Solution 1) will be described. FIG. 10 is a timing chart showing an operation example of a task when a lock conflict occurs in the conventional method, as described above. FIG. 11 is a timing chart showing an operation example of a task when a lock conflict occurs in the method of (Solution 1). FIG. 11 also shows an operation example in the case where the lock of the task 2 being executed by the CPU 2 fails because the lock is occupied by the task 1 being executed by the CPU 1 as in the tenth embodiment. In the conventional method shown in FIG. 10, as described above, the task 2 in the waiting state is POSTed by the task 1 and is being executed on the CPU 3 until the task 2 is again executed. Task 3 fails to lock. In contrast, in the method shown in FIG. 11 (Example of solutions 1), since the task 1 POST processing start (time t ₅₎ before (time t ₃₎ to release the shared resources, at time t ₄ During the period (time t _{5 to} t ₇ ) until the task 2 in the waiting state is POSTed by the task 1 and becomes the execution state again in the CPU 1 (time t _{5 to} t ₇ ), the task 3 running on the CPU 3 uses the shared resource. Can be locked (time t ₆ ). For this reason WAIT
The number of processing and POST processing can be reduced.

Next, the operation of the embodiment relating to (solution means 2) will be described. In the method of (Solution 1) described above, there is a possibility that the task 2 which has been in the waiting state is POSTed by the task 1 and returns to the execution state, and then the lock fails again. In the worst case, the task 2 repeats infinitely. Therefore, the number of retries of task 2 is counted, and if the number of retries exceeds a predetermined upper limit, the task 2 that has been POST and returned to the execution state without releasing the shared resource before the start of the POST process is surely performed. The lock control is switched to obtain the lock right. Assuming that the lock failure rate (probability of trying to secure the lock and fail) is β and the upper limit of the number of retries is ^N , the probability of ^N consecutive lock failures is βN,
Since 0 <β <1, β ^N is a sufficiently small value. That is, the probability that the shared resource is locked (= β ^N ) during the period from when the number of retries exceeds the upper limit and when the POST processing is started to when the task 2 is again in the execution state (= β ^N ) is extremely small. The number of retries can be suppressed to N or less.

Next, the operation of the embodiment relating to (Solutions 3 to 5) will be described. FIG. 12 is a timing chart showing an operation example of a task when a lock conflict occurs in the conventional method. FIG. 13 is a timing chart showing an operation example of a task when a lock conflict occurs in the embodiment of the method of (solution means 3 to 5).
FIG. 12 and FIG. 13 both show an operation example in the case where the lock of task 2 being executed by CPU2 fails because the lock is occupied by task 1 being executed by CPU1. In the conventional method shown in FIG. 12, while the task 2 POSTed by the task 1 is dispatched, the task 1 running on the CPU 1 and the
Task 3 running on CPU2 has failed to lock. On the other hand, in the method of (solution means 3 to 5) in FIG.
After the POST process (time t ₄ ) by interrupting task 1 of the above and allocating the CPU 1 to task 2, the task 2 is preferentially dispatched (time t ₅ ) and executed on the CPU 1. The period from the start of processing to the time when task 2 is dispatched can be shortened, and lock failures of other tasks can be reduced. Instead of this, the WAIT process (time
Before task 2 transitions to the wait state at t ₃ ), or task 1
Before the waiting state of the task 2 is released by the POST processing (time t ₄ ), the task 2 is given priority to the CPU 1 or another CPU by increasing the execution priority of the task 2, and The above period can be shortened.

〔The invention's effect〕

According to the present invention, in an online database system or the like, a request for exclusive use of a shared resource
Controlled by the ST method, and the POST processing overhead can be excluded from the occupation time of the shared resource, and the increase in the number of retries of the POST accepting task can be suppressed to a certain upper limit or less, and the phenomenon that the response deteriorates can be avoided. This is effective for improving the throughput performance of the apparatus. In particular, in the case of a multi-processor system, the method of the present invention for keeping the lock occupancy low is effective in improving the performance.

Furthermore, the retry upper limit can be set for each shared resource, and the system of the present invention is integrated with the system throughput performance monitor program and response performance monitor program, and the retry upper limit is dynamically changed,
Automatic tuning of the performance of the entire system is also possible.

[Brief description of the drawings]

FIG. 1 is a diagram showing a schematic flow of a task control system for lock control according to the present invention, FIG. 2 is a diagram showing a TCB format, FIG. 3 is a diagram showing a WCB format, and FIG. FIG. 5 is a diagram showing a flow of a lock securing process, FIG. 6 is a diagram showing a flow of a lock release process, and FIG. 7 is an online database system having a multi-processor configuration according to an embodiment of the present invention. FIG. 8 is a diagram showing the format of a WAIT key, FIG. 9 is a diagram showing the format of a task queue, and FIGS. 10 to 13 are diagrams showing the operation of the present invention. 130 …… WAIT Queue, 131 …… WCB (WAIT Control Bloc)
k), 132: LRB (Lock Request Block), 140: Task queue, 141: Start pointer of task queue, 142 ...
Task queue end pointer, 143 ... TCB (Task Control
Block), 312 …… POST bit, 313 …… WAIT bit, 31
4… POST code.

Continued on the front page (72) Inventor Shoji Yamamoto 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside the Hitachi, Ltd.Software Factory (72) Inventor Kazuo Masai 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Co., Ltd. Hitachi, Ltd. Software Factory (72) Inventor Tetsuro Saito 1479, Kamizuhoncho, Kodaira-shi, Tokyo Hitachi Microcomputer Engineering Co., Ltd. (56) References JP-A-59-172029 (JP, A) JP-A Sho 62-262171 (JP, A) (58) Field surveyed (Int. Cl. ⁶ , DB name) G06F 15/16 JICST Science and Technology Literature Database

Claims (4)

(57) [Claims] 1. A WAIT process for transitioning a task 2 that has failed in securing a right to lock a shared resource because the shared resource is being used exclusively (locked) by a task 1 to a wait state, and the task 1 Exclusive control of the exclusive use right of the shared resource is performed by a POST process for transitioning the task 2 to the executable state when the use of the task 2 is completed and a dispatch process for assigning the processor use right to the task in the executable state. In a task control method for lock control in a multi-task type multi-processor system, after releasing a wait state of task 2 by POST processing, execution of task 1 is interrupted, and the processor on which task 1 is running is stopped. Means for allocating to the task 2; and when the task 1 has finished using the shared resource, Means for releasing the shared resource, means for transitioning the task 2 to the executable state by the POST processing after the release, and task 2 which has obtained the processor use right by the dispatch processing after the transition to the executable state for the task 2 is the shared resource. Means for retrying to secure the lock right, and that the third task running on another processor requests use of the shared resource after the release and before the task 2 secures the lock right. A first lock control method having means for permitting the third task to lock the shared resource, and a task right to lock the shared resource when the task 1 finishes using the shared resource. Means for transferring the task 2 to an executable state by POST processing, and means for processing by dispatch processing. A second lock control method having means for prohibiting a task other than the task 2 from locking the shared resource until the task 2 that has obtained the right to use the shared resource releases the lock right to the shared resource. A task control system comprising a switching unit for dynamically switching between the first lock control system and the second lock control system. 2. A WAIT process for transitioning a task 2 in which a lock right to the shared resource has failed to be secured because the shared resource is being used exclusively (locked) by the task 1 to a waiting state; Exclusive control of the exclusive use right of the shared resource is performed by a POST process for transitioning the task 2 to the executable state when the use of the task 2 is completed and a dispatch process for assigning the processor use right to the task in the executable state. In a task control method for lock control in a multi-task multiprocessor system, before a task 2 transitions to a wait state by WAIT processing,
Means for performing a priority change to increase the execution priority of the task 2 and restoring the changed execution priority when the shared resource of the task 2 is released, and further comprising: when the task 1 finishes using the shared resource. Means for releasing the shared resource, means for transitioning task 2 to an executable state by POST processing after the release, and task 2 which has obtained a processor use right by dispatch processing after transition to the executable state of task 2. Means for retrying to secure the lock right of the shared resource, and a third task running on another processor after the release and before the task 2 secures the lock right, requests the use of the shared resource. A first lock control method having means for permitting the third task to lock the shared resource, Means for directly transferring the lock right of the shared resource to the task 2 when the task 1 has finished using the shared resource, means for transitioning the task 2 to the executable state by the POST process, and processor use right by the dispatch process. A second lock control method having means for inhibiting a task other than the task 2 from locking the shared resource until the task 2 that has obtained the lock resource releases the shared resource. A task control method comprising a switching unit for dynamically switching between a lock control method and a second lock control method. 3. A WAIT process for transitioning a task 2 in which a lock right to the shared resource has failed to be secured because the shared resource has been exclusively used (locked) by the task 1 to a waiting state; Exclusive control of the exclusive use right of the shared resource is performed by a POST process for transitioning the task 2 to the executable state when the use of the task 2 is completed and a dispatch process for assigning the processor use right to the task in the executable state. In a task control method for lock control in a multi-task type multi-processor system, a priority change that raises the execution priority of task 2 before task 1 releases the wait state of task 2 by POST processing And a means for restoring the changed execution priority when the shared resource of task 2 is released. Means for releasing the shared resource when the task 1 finishes using the shared resource, means for causing the task 2 to transition to the executable state by POST processing after the release, and transition to the executable state for the task 2 Means for retrieving the lock right for the shared resource by the task 2 which has obtained the processor use right by the dispatch process later, and executed on another processor after the release and before the task 2 obtains the lock right A first lock control method having means for permitting the third task to lock the shared resource in response to a third task of the shared task requesting use of the shared resource; A means for directly transferring the lock right of the shared resource to the task 2 when the use of the resource is finished, and the task 2 can be executed by the POST processing. And a means for inhibiting a task other than the task 2 from locking the shared resource until the task 2 which has obtained the processor use right by the dispatch processing releases the lock right on the shared resource. A task control method, comprising: a lock control method; and a switching unit for dynamically switching between the first lock control method and the second lock control method. 4. An online transaction system using the task control method according to claim 1, 2 or 3.