JPH01297760A - System for lock control and task control in multiprocessor - Google Patents

Abstract

PURPOSE:To lower a lock failure rate by enabling the task of a third party to use a shared resource at the time of completing the use of the shared resource and to prevent a lock occupant task from being sunk by changing the priority order of the execution of a POST accepting task. CONSTITUTION:When a POST issuing task completes the use of the shared resource, the lock of the shared resource is permitted to use by a third task if the number of times of retrying of the POST accepting task is less than a prescribed value. When it exceeds the prescribed value, a lock right is delivered directly to the POST accepting task. Also, the execution of the POST issuing task is interrupted after processing POST, and a processor is allocated to the POST accepting task, and also, the priority order of the execution is changed before the POST accepting task transits to a waiting state by a WAIT processing and before the wait state is cancelled by a POST processing, and the priority order of the execution is recovered at the time of releasing the shared resource.

Description

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

[Conventional technology]

Processing unit (task) CJ executed within the old computer system
, using various shared resources. In a system such as TCMP in which a plurality of tasks operate simultaneously, competition occurs among these tasks regarding the right to exclusively use a shared resource, so exclusive control is required for this purpose. For example -
, When multiple tasks are each performing separate ``sales processing 1'' in an online system, the separate tasks refer to and update the ``current sales amount'' stored in a common storage area. In such a situation, it is necessary to prohibit another task from accessing this data while one task is referencing and updating this "Sell/Hold Current Amount 1".

Many of the computer systems currently in practical use support, at the hardware level, an instruction that executes the reference and update of a single word in memory (main memory) as an inseparable operation as a basic function for exclusive control. (for example, TEST AND SET instruction (TS instruction) or COMPARE AND 5WAP instruction (C
8 instructions) etc. K, Hwa, ng, F, 8, Br1gg
5 co-authorll Computer Architecture
and Parallel Process
ng''.

McGraw Illill Publishing, pp. 559-56.
(see 0). However, the shared resource subject to exclusive control is not limited to one word on the main memory, but may also be a data cache on a disk device. Generally, exclusive control over this type of shared resource is performed as follows. That is, shared resource data (a large number of data A and B, each of which is several KB in size) is stored on the main memory.

In addition to the storage area for C2..., etc.), a reference table is provided to refer to these data, and this table contains the shared data A, B, C,...
・One word of reference information @ (lock word) is assigned and written corresponding to each. And each data A, B
, C, . . . are accessed through this lock word. Exclusive control over each data of the shared resource can be realized by writing an exclusive use (locked) flag in this lock word using the above instruction.

However, this method requires processing when exclusive usage rights for shared resources cannot be obtained. One of the exclusive control methods that takes this point into consideration is the WAIT/PO8T method (Suspend-Resume method, B 1ock-
It is also called the Activate method, S1sep-Wakeup method, etc. (see above-mentioned literature) is known.

The WAIT-PO5T method is a WAIT process that puts task 2, which has failed in occupying the shared resource, into a 1-waiting state when the shared resource is being occupied by task 1, and a WAIT process when task 1 releases the shared resource. , POST processing (notification processing) that releases the "waiting state" of task 2 performs exclusive control between tasks of the right to use the shared resource exclusively (hereinafter, in this specification, obtaining the right to use the shared resource exclusively is referred to as "obtaining the right to use the shared resource") It is expressed as taking a lock, securing lock rights, etc.Also, when attempting to take a lock but being unable to do so because it was being occupied by another task, it is expressed as lock failure, lock acquisition failure, etc. do).

In the following explanation, "execution state" means that a task is
``Executable state'' refers to the state in which a task cannot be executed because the CPU is occupied, but can be executed at any time as long as the CPU is free.On the other hand, "Waiting state" refers to a task state in which a task cannot be executed even if the CPU is available because no shared resources are available. Further, the right to use a shared resource is expressed as "exclusive right to use,""exclusiveright," or "lock right." The use of the CPU is simply expressed as "right to use."

When each task fails to lock, it passes control to the WAIT processing routine. The WAIT processing routine puts the task that failed to lock into a "wait state" and calls the dispatcher. The dispatcher assigns another task (third, fourth, . . . tasks) in the "ready state" to the CPU that was executing the task in the "waiting state". A dispatcher allocates a CPU to a task in an "executable state" according to an execution priority set roughly for each task.

On the other hand, each task (task that has been running so far) checks whether there is a task in a "waiting state" (WAIT task) immediately before releasing the shared resource (unrotting), and if there is a WAIT task, it transfers control to the POSTO3 queue. hand over. POST
The O3-chin returns the WAIT task to the "ready state". The task that has returned to the "executable state" is later assigned a CPU by the dispatcher, obtains exclusive use of the shared resource, and resumes processing.

In this manner, in the WAIT-POST method, exclusive control is achieved by placing a task that has failed in locking in WAIT processing into a "waiting state" and returning the task to an "executable state" in POST processing. Below, the task that starts PO8T processing (
Usually, the task that was in the running state until then) is called the POST issuing task, and the WAIT task that is released from the "waiting state" by POST processing is called the POST receiving task (POS
T-issue task, POST acceptance task, WAIT task, etc. are not unique names of each task. Each task may be a POST issuing task or a PO8T receiving task). The supervisor of many general-purpose computer systems currently in use includes the above-mentioned POSTO3.
It has a built-in WAIT processing routine.

[Problem to be solved by the invention]

By the way, this WAIT-POST method has the following problems.

This problem will be explained with reference to FIG. FIG. 10G4 is a timing diagram showing an example of the operation of a task when a lock conflict occurs in the conventional method, and the time axis is in a downward direction from 10. FIG. 10 shows that three CPUs 1.2.3 perform multiple tasks 1, 2, 3.4.5. . . . shows a situation in which . . . is executed.

The hatched area at the bottom left is task 1, the hatched area at the bottom right is task 2, the white frame area is the third task (tasks 3 to 5), and the opaque area is the supervisor who does not belong to any task (task mutual The small satin-like part (which acts as a bridge between the two) indicates the right to use the shared resource (the right to use it). L OG' K is lock processing, p o s 'r
indicates bonut processing, FALL indicates a lock failure by that task, and DISI) indicates processing by the dispatcher for the task shown below.

First, task 1 obtains the lock on the CPU (time t1), then task 2 fails to lock the CPU (time tz).
Enters wait state. After task 1 takes note of this and finishes using the shared resource, task 1 releases the lock right and issues PO8T processing to task 2 (time t3).
However, since the CPU is not available at that time (because it does not have the right to use the CPU), it cannot immediately enter the execution state (executable state). On the other hand, since multiple tasks in the executable state have priorities, the task that is dispatched when the CPU becomes free is not necessarily task 2, which has just received the notification.
When U2 becomes vacant, task 4 with a higher priority is dispatched first (times t5 to t6) and executed (times 16 to t).
's) sometimes. In that case, task 4 is executed first, and after its processing is completed, task 2 is dispatched and executed (times t, ~t8~tq). Task 1 outside the POSTO3 for task 2
Until the state moves to the execution state (time t3 to to),
Even if another task of another CPU 1, such as task 3, issues a lock request (time t4), the shared source is in a locked state even though no task is using it during this time. Lock will fail.

Furthermore, even if task 2 receives POST at time t3, if there is another task with a high execution priority such as task 4, task 2 will receive CPU usage rights until the processing of task 4 is finished. will not be obtained.

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

(Section ulj POST issuing task (task 1 in this case) is I) After starting PO5T processing for the OS T receiving task (task 2 in this case), the POST receiving task is reassigned by the dispatcher to harm the CPU and moves to the execution state. Until then, tasks other than the POST acceptance task (third party task 3) or shared resources cannot be used.
The ratio of lock occupancy steps to all processing steps (lock occupancy rate) becomes high, and system performance deteriorates.

In particular, in multi-processor systems, after a POST issuing task starts outside of POST3, a task running on another processor issues a lock request until the POST receiving task is assigned a CPU by the dispatcher and enters the execution state. As a result, the lock failure rate (probability of attempting to secure a lock and failing) increases, and PO5T processing
WA'lT processing overhead increases.

(Issue 2) When the POST receiving task is released from the waiting state and becomes executable, high execution priority tasks other than the POST receiving task are dispatched first.
There are cases where the POST receiving task cannot immediately obtain the right to use the CPU. (called "sinking"). If another task issues a lock request while the lock-occupying task is stuck, the lock will always fail and the POSTO3
IT processing overhead increases for external W.

Therefore, an object of the present invention is to solve the above-mentioned problems of the prior art (problems 1 and 2), and to prevent the POST receiving task from being assigned by a third party until it is assigned a CPU by the disk perature and enters the execution state. Lock control in a multi-processor system using a multi-tasking system that allows tasks to use shared resources and reduces the lock failure rate, prevents lock-occupying tasks from sinking, and further eliminates lock failures and to provide a task control method.

[Means to solve the problem]

In order to solve the above problem 1, the lock control method G of the present invention
A. Configure as in Solution 1 or 2 below.

(Solution 1) means for releasing the coexisting resource when all 3 POST tasks finish using the shared resource, and allowing a third task running on another processor to lock the shared resource; Thereafter, there is a means for transitioning the POST receiving task to an executable state through POST processing, and after that, the POST receiving task, which has obtained the right to use the processor through dispatch processing, attempts to secure the lock right for the shared resource (retry). and means.

Note that this method has the advantage that the lock occupancy rate can be kept low, so that throughput reduction due to lock contention is less likely to occur. However, before the POST receiving task secures the lock, the lock may be "preempted" by another task and the lock may fail again. For this reason,
The same task may be retried many times, leading to a slight decrease in response. This problem is solved by the following (Solution 2)
) is resolved by

(Solution 2) When all 3 POST tasks finish using the shared resource, the shared resource is released, and after allowing the third task running on another processor to lock the shared resource, the POST POST by processing
The POS transitions the accepting task to an executable state7, and then obtains processor usage rights through dispatch processing.
The T-accepting task secures the lock right for the shared resource1-
When the PO5T issuing task finishes using the shared resource, the lock right of the shared resource is directly transferred to the POST receiving task, and the POST receiving task can be executed by POST processing. After transitioning to the POST state, the POST receiving task, which has obtained the right to use the processor through dispatch processing, releases the lock right for the shared resource.
3. A switching means for dynamically switching between the first lock control method and the second lock control method, the switching means including a second lock control method for prohibiting tasks other than the T-receiving task from locking the shared resource; The configuration is such that

Specifically, the number of retries from POST acceptance task number 1 is counted, and if this number of retries is less than a predetermined upper limit value, the first lock control is performed, and when the number of retries reaches a predetermined upper limit value or more, The configuration is such that the second lock control is performed. In other words, basically the method of Solution 1 above is adopted, but when the POST receiving task cannot obtain the lock right even after requesting it many times, or when using a specific resource, the method of passing the lock right to the POST receiving task is adopted. It is.

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 POST acceptance task is released from the waiting state by POST processing, execution of all 3T POST tasks is interrupted, and the processor on which all 3T POST tasks are running is switched to POST.
Configure it to be assigned to the ST receiving task.

(Solution 4) Before the POST receiving task transitions to the waiting state by WAIT processing, change the priority to increase the execution priority of the POST receiving task, and this POS
The modified execution priority is restored when the shared resource of the T-receiving task is released.

(Solution 5) Before all 3T POST tasks release the waiting state of the PO5T receiving tasks through POST processing,
The priority order is changed to raise the execution priority of the OST receiving task, and the changed execution priority is restored when the shared resource of the POST receiving task is released.

[Effect]

The operation of the present invention based on the above configuration will be explained in comparison with the conventional system. Note that this action will be explained in detail later in [Example] with reference to FIGS. 10 to 13.

First, the operation of (Solution Means 1) will be explained.

In the conventional method, as explained earlier using FIG.
Task 2, which is in a waiting state, is sent to POS by task 1.
Task 3, which is being executed on CPU 3, fails to lock during the period until CPU 2 returns to the execution state. On the other hand, in the method (Solution 1) of the present invention,
Task 2, which was in the waiting state until task 1 released the shared resource before the start of POST3, is POSTed by task 1 and the task running on CPUa is re-entered into the running state by the CPU. 3 can lock shared resources. Therefore, the number of WAIT processes and POST processes can be reduced (details will be described later with reference to FIG. 11).

Next, the operation of (Solution Means 2) will be explained.

In the method of (Solution 1) described above, after task 2 in the waiting state is POSTed by task 1 and returns to the execution state, there is a possibility that the lock will fail again. In the worst case, task 2 will be retried endlessly.

Therefore, the number of retries for task 2 is counted 1, and if this number of retries exceeds the predetermined upper limit, the POSTO3
Lock control is switched so that task 2, which has been POSTed and returned to an execution state, securely obtains the lock right without releasing the shared resource before the start.

Next, the operation of (Solution 3-5) will be explained. In the conventional method, task 2 POSTed by task 1
Task 1 running on the CPUI and Task 3 running on CPUZ fail to lock during the period until the task is dispatched. In comparison, the present invention (solutions 3 to 5)
) method gives priority to task 2 after P○ST processing.
Since it is executed on the CPUI by dispatching to
The period from the start of OSTO 3 until task 2 is dispatched can be shortened, and lock failures of other tasks can be reduced.

〔Example〕

Hereinafter, one embodiment of the present invention will be described using FIGS. 1 to 9. This embodiment is an example of an online database system.

Before describing the lock control method and task control method of the present invention, an outline of the online database system to which this embodiment is applied will be explained.

Note that the present invention is not limited to online systems, but can also be applied to multi-systems.
Applicable to all task-based multiprocessor systems. FIG. 7 shows a schematic configuration of the system. CPU
I and CPU2 (101 and 102) share memory 1
Connect via 03.

The two CPUs can each operate the pro gamer 11 on the memory, refer to data on the memory, and perform processing in parallel. Each CPU is capable of transmitting and receiving data to and from the terminal device 105 via Tsushin Fujun's W2O3. Further, each CPU can access the database 107 of the disk "-" through the disk theft device 106.

Hereinafter, in this specification, a group of data reference/update processing in an online database system will be referred to as a transaction. For example, a series of processes such as "in response to a deposit withdrawal request, check the deposit balance, subtract the withdrawal amount from the deposit balance, and update the deposit balance in the database" is called a transaction. A transaction is triggered by data transmission from a terminal device.

Next, the basic method of managing tasks will be explained. When a transaction is entered, the supervisor creates one or more tasks corresponding to this transaction. Specifically, when the supervisor generates a task, the supervisor creates a TCB (Task Con) in which control information is stored for each task.
trol Block), 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 is in one of the following states: "waiting state", "executable state", or "executing state". A task in a "waiting state" cannot be assigned a CPU until it completes the event that caused it to wait and becomes "ready to run.""
A task in the "ready to run" state is
As soon as a PU becomes available, it is possible to allocate a CPU and make the transition to the "execution state". A task in the "execution state" is a task that has obtained the right to use the CPU and is being executed. If there are multiple tasks in the "ready to execute" state, the dispatcher allocates CPUs according to the execution priority assigned to each task. The task queue 140 includes a task queue head pointer 141, a task queue end pointer 142, and a chain of zero or more TCBs 143. T
The CB consists of the following fields (Figure 2).

(1) Task state 401 Stores the state of a task (waiting state, executable state, or execution state).

(2) Execution priority 402 Stores the execution priority assigned to the task.

(3) Next TCB pointer 403 Stores the next TCB address when chaining TCBs to form a task queue. TCB at the end of the task queue
In this case, this field stores O.

(4) Task information save area 404 This area is used to save the contents of PSW (program status word), registers, etc. so that the task can be restarted when the execution of a task is interrupted.

Next, a lock contention control method according to the present invention will be explained.

Hereinafter, it is assumed that in the online database system of this embodiment, the shared resource subject to lock contention is only one database.

That is, it is assumed that there is only one shared resource. Also, each transaction generates a single task. That is, consider a case where there is a one-to-one correspondence between transactions and tasks. These assumptions do not detract from the advantages of our scheme.

First, an outline of the lock control and task control method of the present invention will be explained using FIG. When each task locks a shared resource, it issues a LOCK macro 551,
Call the lock processing routine 500. If the necessary shared resource cannot be secured because it is being exclusively used by another task, the lock control method switching process (503) is performed according to the lock control method switching determination (process 502), and P
Select either the first lock control method that releases shared resources before the start of OSTO3 or the second lock control method that does not release the shared resources before the start of POST03. Next, the WAIT processing routine 510 in the supervisor is called (504) and the task that issued the LOCK macro is placed in a "waiting state" (processing 511). In this case, the supervisor-internal dispatcher 530 allocates the CPU to another task in the "ready to execute" state (processes 53'l, 532).

A task to which a CPU is assigned is placed in an "execution state" and continues processing until the right to use the CPU is taken away due to an interrupt or the like. On the other hand, a task that is in a ``wait state'' is in a 1-wait state until it is returned to an ``executable state'' by POST processing.''
Continue.

On the other hand, when a task that is exclusively using a shared resource unlocks the shared resource, it uses the UNLK macro 552
and calls the unlock processing routine 520.

In the unlock processing routine, it is checked whether there is any task in a waiting state (process 521). If there is a task in a waiting state, the lock control method switching process (503) determines which lock control method is selected (process 522). If the first lock control method of releasing the shared resource is selected before the start of POST3, the shared resource is released (523), and the PO5T processing routine is called to notify the WAIT task of the shared resource release (524). ).

P, the second method that does not release shared resources before starting O3T processing.
If the lock control method is selected, the shared resource is not released and the WAIT task is sent
Call the POST processing routine (524
,).

For POSTO3 - Chin 540, move the pos 'r issuing task from the "execution state" to the "ready state", and
o s ``r-receiving task is moved from 1 waiting state'' to ``executable state'' (process 541). The lock control method switching process (503) determines which lock control method is selected (process 542). If the first lock control method is selected, the dispatcher 530 is called (processing 544). If the second lock control method is selected, the CPU is assigned preferentially to the POST receiving task (processes 543, 532). A POST receiving task that is given CPU usage rights can occupy the shared resources and resume processing.

Above, we have explained the case where there is one WAIT task, but in general there can be multiple WAIT tasks, so the wait queue for WAIT tasks (WAIT queue 130
) is used. The task that has failed to lock must
Create an RB (abbreviation for I-0CkRequest Block) and chain it to the WAIT queue. Also,
Each task refers to the WAIT queue eight times to see if there are any tasks in a wait state before releasing the shared resource. If there is a task in rare state, i.e. WAIT
If one or more LRBs are chained in the queue, the first (oldest in time) LRB (the leftmost LRB 132 in Figures 7 and 8) is taken out from the WAIT queue and corresponds to this LRB13. A POST macro is issued to notify the WAIT task of releasing the shared resource.

Next, the data structure of this WAIT queue 130 and management block will be explained with reference to FIGS. 3-4 and 7-8. A WAIT queue is provided on the shared memory 103,
Make it accessible from each task in the system. W.A.I.
One T queue is provided for each shared resource. In this embodiment, as described above, the case where there is a single shared resource is considered, so there is only one WAIT queue in the system.

A WΔIT queue consists of one WCB (WA, ITCon
Trol B (abbreviation for 1ock) 131 and zero or more LRBs 132 provided for each task. The structures of w CB and LRB are shown in FIGS. 3 and 4.

The following information is stored in the WCB.

(1) WAIT queue lock word 301W, used for exclusive control of updating of the CB itself.

The lock key is stored when the WCB is occupied, and 0 is stored when the WCB is released.

(2) Resource lock word 302 Indicates the occupied state of a shared resource that is subject to exclusive control. Stores the lock key when the shared resource is occupied, and stores 0 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, □ stores 0.

(5) Maximum number of retries (MAχ-RETRY-CO
UNT) Indicates the maximum number of tries for LRB in the WAIT queue.

(6) RETRY, -LIl'1l
T) 3.060 A positive integer indicating the upper limit of the number of failures.

(7) Occupied task T, CB pointer 307 Stores the TCB address of the task occupying the shared resource. This field has no meaning while the shared resource is being released.

The following information is stored in LR813,2.

(1) ECB (Event Control B)
lock) 311 Generally, this is control information for managing the occurrence or non-occurrence of a wait event between the PO8T issuing task and the WAIT task in the WAIT-POST system. POST
When the upper O3 312 is O, the event has not occurred, and when it is ■, the event has completed. When WAIT is 1, it indicates that WAIT is in progress. In this embodiment, it is used to notify the release of shared resources. Also, POSTl-1' knee field 3 in ECB
14 to pass the lock key from the POST issuing task to the POST receiving task.

(2) Number of retries (RETRY -COUNT) 3
15 This is a counter indicating how many times the task has failed to lock. Clears O when the lock is secured.

(3) Next LRB Boink 316 When chaining L RBs to form a WAIT queue,
Next, store the RB address.

(4) WAIT task TCB pointer 317 L RB
The TCB address of the WAIT task corresponding to the WAIT task is stored.

Next, the algorithms for locking shared resources and unrotting processing will be explained. Note that in the following description, the resource lockword 302 will be simply referred to as a lockword.

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

First, lock processing will be explained using FIG.

First, by determination processing 701, POST from another task is
It is determined whether or not it is after the "waiting state". This means that POST bit 312 in ECB1.32 is 0.
It can be determined by whether it is 1 or 1. If after POST, register 1 (R1) contains the old lock key, that is, ECB.
Load 314 on PO5TO5 in 132 (processing 7
02). The posT code stores the identification information ID of the POST issuing task (TCB address of the POST issuing task). Otherwise, 0 is loaded into register 1 (process 703). Next, the new lock key, that is, the identification information TD of the self-task (TCB address of the self-task) is loaded into the register 2 (R2) (processing 704). Determination processing 705 is performed as follows using a CS command.

cs R1, R2, LOCKIIORD This command is
Old lock key and lock word 3, which are the contents of register 1
02 are compared, and if they are equal, the value of the lock word is replaced with the new lock key that is the contents of register 2 (
lock success).

If the results of the above comparison are not equal, no lock word replacement is performed (lock failure). The important features of the C8 instruction are from reading the lock word mentioned above to comparing and
During the update, access to the lock word by other CPUs can be prohibited.

As a result, unless the shared resource is in an unoccupied state or the value of the old lock key passed as a POST code from the POST issuing task is equal to the current value of the lock word (i.e. at the time of executing the CS instruction), A task attempting lock processing will fail to lock.

If the lock is successful in the determination process 705,
In process 706, the retry count 315 is returned to O, and the locking process is completed. If the lock fails, the number of retries is increased by 1 (707), or when the lock fails after starting to create an LRB), or the number of retries for LRB is updated 707).
15), lock the WAIT queue 130 (processing 70
8). If another task is locking the WAIT queue, it waits in a loop until the processing of other tasks is completed (708a).

Once the WAIT queue is locked, the number of runs is 315.
and the maximum number of retries (the one with the largest number of retries in the WAIT queue chain) 305 (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 1 - the number of retries (process 710), and the L RB of the own task is chained to the head of the WAIT queue (to the highest priority position) (process 711).
.

If the number of retries is the maximum number of retries, the LRB of the own task is chained to the end of the WAIT queue (processing 712). WA■T queue is being updated (WA
During the process of connecting an IT queue to a chain, removing it from a chain, or rewriting a counter, W A I T is used to prevent other processors from entering the WAIT queue.
Although the queue itself is locked, the WA'IT of LRB
When the chain to Kifu is completed, release the AIT queue (713) and call the WAIT macro. Processing 7
14). The task that issued the WAIT macro enters the "waiting state" and continues to be in the "waiting state" for m times until POST is performed.

When the process 701L is requested, the process returns again to try to secure the lock.

Note that initialization of the ECB 51 (clearing the PO5T bit 312) is performed immediately after processing 702.

In addition, in processing 711 and processing 712, in order to shorten the locking time of the WAIT queue, the WAIT queue head pointer 303. , the WAIT queue end pointer 303 is used, and no process of searching the WAIT queue is performed. or,
While the WAIT queue is locked, interrupts are disabled to prevent deadlock with interrupt tasks.

Next, the unlocking process will be explained using FIG. 6.

FIG. 6 shows the unlocking process 520 in FIG. 1 in detail. In the unlock process, first WAIT
The queue is locked (process 801).

If another task is occupying the W/', IT queue, it waits in a loop until it can be locked. Once the WAIT queue has been locked, it is checked whether the WA and IT queues are empty, that is, whether there are any tasks waiting for the release of the shared resource (process 802). If the WAIT task fails, the WAIT
Release queues and shared resources (processing 803~
804). The shared resource is released by writing the lock word (301 and 302) &0.

WAI]" If there is a task, first compare the maximum number of retries 305 with the upper limit of retries (preset value, control is switched at each value) 306 (processing 805
).

If the maximum number of retries is the retry upper limit, that is, if the number of failures has not reached 1-limit, the shared resource is released (process 807), and PQST code 3]4 is set to O (process 808).

If the maximum number of retries ≧ the retry upper limit, that is, if the number of failures has reached the upper limit, the PO
The ST code contains the current lock key, that is, the identification information 1 (TC
B address 307) is set to cell number 1 (processing 806). Next, a process 809 for extracting the LRB at the head of the WAIT queue (corresponding to the task with the maximum number of retries) and a process 811 or 81 for updating the maximum number of retries 305
2), Process to release WAIT queue 813), Process 8
Add PO to the task corresponding to the L RB retrieved in 09.
The ST macro is issued (step 814) to notify the release of the shared resource. At this time, the POST code set in process 806 or process 808 is passed to the P*ST receiving task. This p o s = "Code is processing 702 or 7
03 (Figure 5) p.

The ST receiving task accepts the request. With this mechanism, if the number of l-cock failures is less than the two-limit value, the shared resources released in process 807 are contested on a "first come, first served" basis between the POST acceptance task and other tasks. but,
If the number of lock failures exceeds the upper limit, PO8T
Shared resources are not released in all 8T disks, and po
s ”r Pass the lock right directly to the receiving task.

Next, the effect (operation) of the above embodiment will be explained using FIGS. 10 to 13 while comparing it with the conventional system!
In these figures, the meanings of the hatches, satin-like parts, and letter symbols on the left and right sides are 1. This is the same as described above with respect to FIG.

First, the operation of the embodiment regarding (Solution Means 1) will be explained. FIG. 10 is a timing diagram showing an example of the operation of a task when a lock conflict occurs in the conventional method, as described above. FIG. 11 is a timing diagram showing an example of the operation of a task when a lock conflict occurs in the method of B (Solution Means 1). In FIG. 11, as in FIG. 10, the lock is occupied by task 1 being executed on CPU 1, so CPU 2
An example of the operation when Task 2, which is being executed, fails to lock is shown. In the conventional method shown in FIG. 10, as mentioned above, task 2 in the waiting state is
During the period from ST to the time when the CPU 2 returns to the execution state, the task 3 being executed on the CPU 3 fails to lock. On the other hand, in the method shown in FIG. 11 (embodiment of solution means 1), task 1
s) (time t3), the shared resource is released before (time t3), so task 2, which was in the waiting state at time t4, is POSTed by task 1 and the period from time t5 to t' until it becomes running again on the CPU At step s), task 3 running on CPU 3 can lock the shared resource (time t6).

Therefore, the number of WAIT processing and POST processing can be reduced.

Next, the operation of the embodiment regarding (Solution Means 2) will be explained. In the method of (Solution 1) described above, after task 2 in the waiting state is POSTed by task 1 and returns to the execution state, there is a possibility that the lock will fail again. In the worst case, task 2 will be retried endlessly. Therefore, the number of attempts to cross task 2 is counted, and if the number of cross trials exceeds a predetermined upper limit, po
Without releasing the shared resources before starting s 'r processing, P
Lock control is switched so that task 2, which has returned to the execution state after O31, securely obtains the lock right. If the lock failure rate (probability of attempting to secure a lock and failing) is β and the upper limit of the number of retries is N, then the probability of lock failure N times in a row is β8, and since O〈β〈1, β8 is sufficient. It will be a small value. In other words, the probability (
-βN) can be kept extremely small, and at the same time, the number of retries of task 2 can be kept below N recoveries.

Next, the effects of the embodiments related to (Solutions 3 to 5) will be explained. FIG. 12 is a timing diagram showing an example of task operation when a lock conflict occurs in the conventional system. 13th
FIG. 6 is a timing diagram showing an example of the operation of a task when a lock conflict occurs in an embodiment of the method of solving means 3 to 5); Figure 12.

Both FIGS. 13A and 13B show an example of the operation in the case where Task 2, which is being executed by CPU 2, fails to lock because Task 1, which is executing by CPU 2, is occupying the lock. In the conventional method shown in FIG. 12, during the period until task 2, which has been PO8Ted by task 1, is dispatched, task 1 running on the CPUI and task 3 running on CPUZ fail to lock. In comparison, in Figure 13 (solutions 3 to 5)
) method, CPU task 1 is interrupted and the CPU
By assigning I to task 2, after PO8T processing (time t4), task 2 is dispatched preferentially (
Time t,) Since it is running on the CPUI, the POSTO
The period from the start of task 2 until task 2 is dispatched can be shortened, and lock failures of other tasks can be reduced. In addition, instead of this, WAIT processing of task 2 (time t3)
before task 2 transitions to the waiting state, or task 1's P
By raising the execution priority of task 2 before the waiting state of task 2 is released by the OST processing (time t4), task 2 is preferentially assigned to the CPUI or another CPU, and similarly can be shortened.

〔Effect of the invention〕

According to the present invention, in an online data storage system or the like, a request for exclusive use of a shared resource is
1) O3T processing overhead can be excluded from the shared resource occupancy time, and
Since it is possible to suppress the increase in the number of OST acceptance task retries to below a certain upper limit and avoid a phenomenon in which the response deteriorates, this is effective in improving the throughput performance of the system.

Locks, especially on multiprocessor systems
- The method of the present invention that keeps the occupancy low is effective in improving performance.

Furthermore, the retry upper limit value can be set for each shared resource, and the system's throughput performance monitor program and response performance monitor program are integrated with the method of the present invention to dynamically change the retry upper limit value. By that,
It is also possible to automatically tune the performance of the entire system.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing a schematic flow of the lock control and task control method of the present invention, FIG. 2 is a diagram showing the format of T'' CB,
FIG. 3 is a diagram showing the format of WCB, FIG. 4 is a diagram showing the format of LRB, and the fifth threshold is a diagram showing the flow of lock securing processing.
FIG. 6 is a diagram showing the flow of lock release processing, FIG. 7 is a diagram showing a schematic configuration of a multi-processor configured online data storage system according to an embodiment of the present invention, and FIG. 8 is a diagram showing a W
FIG. 9 is a diagram showing the format of the AIT queue, FIG. 9 is a diagram showing the format of the task queue, and FIGS. 10 to 13 are diagrams showing the operation of the present invention. 130...WAIT queue, 131...
・・・・・・WCB (WAIT Contr
ol old ock), 1 3 2---1-
1RB (Lock Request Block
) ,, + 40-task queue, 141...
...Task queue head pointer, 142...
...Tough skew end pointer, 143-TCB
(Task Control Block), 31
2......POST bin I..., 313...
... to W] T Hilla l-1314...
・・POS i' coat. Agent Patent Attorney 2 Kenjibu (1 other person) 〒→ Figure 11 Figure 12N

Claims (1)

[Claims] 1. Shared resource is exclusively used (locked) by task 1
a WAIT process in which task 2, which has failed to secure the lock right for the shared resource because the task was inside the shared resource, is placed in a waiting state;
Occupation of the shared resource is achieved by a POST process that transitions the task 2 to an executable state when the task 1 finishes using the shared resource, and a dispatch process that allocates processor usage rights to the task in the executable state. In a lock control method in a multi-task multi-processor system that performs exclusive control of usage rights between tasks, when task 1 finishes using the shared resource, the shared resource is released and used on other processors. means for allowing a third task being executed to lock the shared resource; means for transitioning task 2 to an executable state by POST processing after the lock is granted; and means for transitioning task 2 to an executable state by POST processing; 1. A lock control method, comprising means for causing a task 2, which has obtained the right to use a processor through dispatch processing after the transition, to retry securing the right to lock the shared resource. 2. A WAIT process in which task 2, which has failed to secure the lock right for the shared resource because the shared resource was locked by task 1, is placed in a waiting state, and when task 1 finishes using the shared resource. Through the POST process that transitions the task 2 to an executable state and the dispatch process that allocates processor usage rights to the task in the executable state,
In a lock control method in a multi-task multi-processor system that performs exclusive control between tasks on the exclusive right to use a shared resource, when task 1 finishes using the shared resource, the shared resource is released; After allowing the third task running on another processor to lock the shared resource, P
A first lock control method in which task 2, which has obtained processor usage rights through dispatch processing after transitioning task 2 to an executable state through OST processing, retries securing lock rights for the shared resource; When task 1 finishes using the shared resource, it directly transfers the locking right of the shared resource to task 2, and
After task 2 is transitioned to an executable state through T processing, tasks other than task 2 may be unable to access the shared resource until task 2, which has acquired processor usage rights through dispatch processing, releases the lock rights for the shared resource. a second lock control method for prohibiting locking of the shared resource, and further comprising a switching means for dynamically switching between the first lock control method and the second lock control method. method. 3. The switching means comprises means for counting the number of retries of task 2 and performing the first lock control if the number of retries is less than a predetermined upper limit value. Lock control method. 4. The switching means comprises means for counting the number of retries of task 2 and performing the second lock control when the number of retries reaches a predetermined upper limit or more. Lock control method. 5. The computer system according to any one of claims 2 to 4, further comprising means for interrupting the execution of task 1 after releasing the waiting state of task 2 by POST processing, and assigning the processor on which task 1 was running to task 2. A task control scheme for lock control schemes. 6. Before task 2 transitions to the wait state by WAIT processing, change the priority to raise the execution priority of task 2, and restore the changed execution priority when the shared resource of task 2 is released. 5. A task control method for a lock control method according to claim 2, further comprising means. 7. Before task 1 releases task 2 from the waiting state through POST processing, change the priority to raise task 2's execution priority, and when task 2's shared resources are released, the execution priority with the above change is changed. 5. The task control method for a lock control method according to claim 2, further comprising means for restoring the lock control method. 8. An online transaction system using the lock control method or task control method according to any one of claims 1 to 7.