JPH03288933A - Method for controlling access to data resources - Google Patents

Abstract

PURPOSE:To obtain a high-functional locking mechanism with minimum spin weight by separately providing a locking word to show the possibility of access and a queue control word to control a queue showing the maintaining and waiting states of the lock, and utilizing a forming function in series at a low level. CONSTITUTION:On a computer system where plural CPUs10 share a main storage device 20, plural process control blocks (PCB) 1 - PCB 4 execute locking requirements LCB 11 - LCB 34 to plural shared resources RCB 1 - RCB 3. In such a case, the locking word showing the state of the lock to the shared resource is separated from the queue control word to control the queue of the locking requirement and the access to the shared resource is efficiently formed in series among the plural processes. Thus, the high-grade locking mechanism can be realized without increasing the load of the CPU by the spin lock so much.

Description

Detailed Description of the Invention [Field of Industrial Application] The present invention provides a method for controlling access to data resources, that is, a method for controlling access to data resources between processes that perform parallel processing in a multi-process, multi-programming environment on a computer. The present invention relates to a method of parallelizing access for sharing, and particularly to a method of controlling access to a shared resource suitable for a tightly coupled multiprocessor environment in which a plurality of instruction processors share a main memory.

[Conventional technology]

In a multi-process, multi-programming environment on a computer, many processes can perform various processes in parallel. Processes are
It is a unit of work for allocating U, and its operation requires various resources such as CPU, memory, and Ilo. Here, no problem arises regarding the management of resources that are fixedly tied to processes. but,
For resources that are shared by multiple processes, some way to control and serialize contention for access to those resources is needed.

The lowest level method for serializing access conflicts by multiple processes is provided by machine instructions commonly referred to as read-modify-write type instructions. This instruction refers to a state variable stored in main memory and executes an operation of rewriting the state variable according to its value as one atomic operation. For example, C8 (C
ompare and 5tzap) instructions, and CD
S (Compare Double and Swa
p) The instruction is such an instruction.

Details of these machine instructions can be found in the r published by Hitachi, Ltd.
It is described in the ``HITACM Series Processing Equipment'' manual.

In a read-modify-write type instruction, the main storage area containing the state variable is locked between the time the CPU executing the instruction refers to the state variable and the time it updates it. The control of waiting access to the storage area is implemented by hardware.

The access serialization mechanism at the software layer is
This is realized using the above-mentioned read-modify-write type instructions. Madnick (S, E.

Madnick) and Tonopan (J, J, Do
“Operating Systems (
As shown in Chapter 4.5 of ``Operating Systems'' (Monthly 1974, McGrat++-8111), such a mechanism typically consists of a series of instructions called ``Lock J'' and ``Unlock''.

In this mechanism, a resource-compatible state variable called a lockword is provided to indicate whether a certain shared resource is in use.

In a lock operation, the lock requesting process looks at the lock word and changes the lock word to in use if it is not in use.

Attempt the locking action again (this reversal of the locking action is called a spin-wait). In an unlock operation, the process changes the lock word from in use to not in use. in this way.

The process that has secured the lock has exclusive usage rights to the shared resource, and other processes cannot access the shared resource until the process that holds the lock unlocks it.

The lock operation is performed in order to refer to and update the lock word.
Use read-modify-write type instructions. This is to prevent another process from rewriting the lock word while a certain process determines that the lock word is not in use and changes the lock word to be in use.

Such locking mechanisms are often referred to as spin-type locks or simply spinlocks.

In addition to the above-mentioned spin lock, there is also a lock mechanism based on software called a suspend type lock (or suspend lock).

In the suspend lock locking operation, if the lock cannot be secured immediately, the lock requesting process is placed in a first-in, first-out queue and placed in a suspended state. In other words, the lock request process uses the CPU while waiting for the lock without occupying the CPU with spin wait processing.
Light passes the PU to another executable process. If a process that can newly secure a lock exists in the queue, the unlock operation execution process takes that process out of the queue and releases the suspended state. Suspend locks can utilize the CPU more effectively than spinlocks, but require extra operations for queue manipulation and process state change processing. In addition, a queue is generally realized by linking process-compatible control blocks provided in main memory by pointer chaining, but this pointer chain itself consists of multiple locking and unlocking operations performed in parallel. A shared resource that is accessed by processes and requires serialization of access. This serialization of access for queue operations was often achieved using spinlocks.

Japanese Patent Application Laid-Open No. 60-128537 discloses a method for realizing a suspend lock by directly using read-modify-write type instructions without relying on spinlocks. In this method, a lock word consists of a lock flag that indicates the possibility of access and a lock pointer that serves as an anchor for a queue that represents a process waiting for a lock, and the entire lock word is referenced by a read-modify-write type instruction. - By updating, a locking mechanism with two modes, exclusive and shared, is realized.

[Problem to be solved by the invention]

In the simple spinlock method described above, when a conflict of lock acquisition requests occurs, the CPUs, except for the CPU that was able to secure the lock and executes the simple process, are used for spin-wait processing and are not used for the original work. Processing is interrupted. This causes a considerable deterioration in business processing performance, particularly in a so-called tightly coupled multiprocessor environment in which a plurality of instruction processors share the main memory. Spinlocks are used to serialize the most basic and simple operations in operating systems, and are not suitable for serializing higher-level complex operations.

Although the spent lock method has more complicated processing than the spin lock method, it is suitable for serializing high-level processing because the process waiting for the lock does not occupy the CPU.

However, when suspend lock processing requests occur frequently, performance degradation due to spin locks for serializing lock wait queue operations becomes noticeable.

By using the method disclosed in JP-A-60-128537, a suspend-type lock with two lock modes, shared and exclusive, can be realized without using spinlocks, and high-level processing can be serialized efficiently. can do well. However, mere two-mode locking (shared/exclusive) cannot meet the demands of complex serialization functions in higher-level processing in the software hierarchy. A lock flag that displays the shared resource occupancy status and a sea lion pointer for a queue that manages lock waiting are provided in one lock word, and the lock flag and lock pointer can be referenced together by read/modify/write type instructions.
Updating introduces limitations on the locking functionality that can be achieved. This is because there is a restriction on the length of the lock word.

A read-modify-write type instruction implemented in typical hardware operates on a main memory area of double word length or less, and the anchor pointer usually occupies one word, so the lock flag only occupies one word. Must be expressed within the length. This becomes a major constraint when expressing a wide variety of lock modes.

In addition, in this method, in the operation of the queue that manages lock waiting, the last one or several consecutive elements of the queue are read, modified, and written using a read/modify/write type instruction.
It is deleted by updating the next pointer of the element. This method works only under the assumption that there is only one process at a time that is deleting queue elements. In two-mode locks (shared/exclusive), queue elements are deleted only during unlock processing at the time of lock mode change, that is, when an exclusive lock is released or when the last shared lock is released.
The above prerequisites are met.

However, with more complex locking functions, such prerequisites are not necessarily satisfied, and there may be times when multiple unlock processing execution processes operate on the queue simultaneously. Of course, by using this two-mode locking method to serialize internal control block operations, it is possible to create a more sophisticated locking program. However, it would be preferable if a high-performance locking method could be implemented by directly using low-level functions (ie, read-modify-write type instructions).

The present invention was devised against the following background, and its purpose is to efficiently implement a software locking mechanism with high-level functionality by utilizing as low-level serialization functionality as possible. The goal is to achieve this goal.

[Means to solve the problem]

An object of the present invention is to separately provide a lock word indicating accessibility and a queue control word for managing a queue indicating lock holding and waiting state, and the queue control word counts addition of elements to the queue. This can be accomplished by referencing and updating the lock word and queue control word, including an additional counter and a queue anchor pointer pointing to the last queued element, as follows: (1) Lock processing is performed using the lock word Determine whether the lock can be acquired immediately or if it is necessary to wait by referring to , register the lock request in the queue, and if you want to wait for the lock, after registering the lock, refer to the lock word and secure the lock. If possible, check again and if the lock can be secured, execute part of the unlock process to avoid waiting for the lock.

(2) The unlock process stores the additional counter of the hazuku cue control word, executes the lock permission process, and
The value of the additional counter is compared with the previously stored counter value, and if it has been changed, the unlocking process is retried.

(3) Lock permission processing scans the queue to secure waiting lock requests for which lock permission can be granted, updates the lock word to a new lock state, and releases the lock request.

Further, an object of the present invention is to provide a cue control area with
This is achieved by providing a queue lock flag indicating an exclusive/shared lock for queue access, providing a deletion flag for a queue element indicating that it is a deleted element, and performing queue operations as follows: (1 ) An element is added to the queue by setting the address of the added element to the queue anchor pointer and incrementing the addition counter.

(2) When deleting an element from a queue, a shared lock on the queue is secured, the queue is scanned, a deletion flag is set on the element to be deleted, and the shared lock on the queue is released. At this time, the process that is the last to release the shared lock on the queue simultaneously releases the shared lock and secures an exclusive lock on the queue, and actually deletes the element for which the deletion flag has been set from the queue. If an exclusive lock is set on a queue, a shared lock request on the queue will spin-wait.

[Effect]

A lock word indicating the state of a lock on a shared resource;
By separating the queue control word that manages the queue of lock requests, it becomes easier to implement complex locking functions. That is, the lock word and queue control word can each occupy up to the maximum operand length that can be handled by a read-modify-write type instruction, which is defined by the hardware of the computer system to which the present invention is applied.

On the other hand, since the lock word and queue control word are separated and updated separately, a mechanism is required to ensure consistency between the state of the lock word and the state of the queue. The revalidation of the lock word after queuing during lock processing and the storage and verification of additional counters in the queue control word during unlock processing provide such a mechanism.

Lock word reconfirmation during lock processing detects that the lock word has been changed by unlock processing after the lock word is referenced and before queuing. Further, the operation of the additional counter during unlock processing detects that a new pending lock request is added to the queue while scanning the queue to determine lock requests that can be granted lock. As a result, it is possible to relieve the timing in which a locking process and an unlocking process conflict and a locking request is not released from the waiting state even though locking is possible.

On the other hand, the exclusive/shared locking method of the queue control word makes it possible to perform morphometric queue operations with very little spin wait.

Adding elements to a queue is performed by manipulating the queue control word directly with read-modify-write type instructions, and setting a deletion flag on a queue element is performed by securing a shared lock on the queue. . These processes can be executed simultaneously by multiple processes. In particular, unlock processing allows multiple processes to simultaneously access the queue for lock grant processing. The process that is the last to release the shared lock simultaneously acquires an exclusive lock on the queue, actually removes the elements in the queue with the exclusive flag set from the queue, and releases the exclusive lock. During exclusive lock occupancy, if another process attempts to perform unlock processing and accesses the queue, it will spin-wait, but it can be expected that the probability of such contention occurring is sufficiently low.

As described above, according to the present invention, a highly functional locking mechanism can be realized with a minimum spin weight.

〔Example〕

Hereinafter, embodiments of the present invention will be described in detail based on the drawings.

Two examples will be described here. In the first embodiment, all lock requests, both granted and pending lock requests, are held in a queue. In the second embodiment, only pending lock requests are held in the queue.

(1) First Embodiment (1-1) Configuration of Control Block FIG. 1 is a block diagram of a computer system showing an outline of a first embodiment of the present invention. In FIG. 1, a process requests and is granted a lock on a shared resource. The state of waiting is expressed by a group of control blocks in main memory (or virtual memory) and a chain of pointers between them. Shared resources are handled by a resource control block (RCB) 100, processes are handled by a process control block (PCB) 110, and lock requests are handled by a lock control block (LCB) 120.
are shown respectively. Lock requests 120 for the shared resource 100 are connected by a pointer chain 140 in order from the most recently issued lock request.

Further, the lock requests 120 made by the process 110 are linked by a pointer chain 150.

That is, from which process is the lock request 120 issued?
The two types of pointer chains 140 and 150 uniquely specify which shared resource the request is for.

FIG. 2 shows an example of a computer system environment in which the present invention is implemented and a pointer chain between control blocks. In FIG. 2, a plurality of CPUs 10 (CPUI-CP
Un) shows that on a computer system sharing the main storage device 20, a plurality of processes PCB1 to PCB4 are making lock requests LCB11 to LCB34 to a plurality of shared resources RCB to RCB3. ing. The present invention provides a method for efficiently serializing access to shared resources among multiple processes in such a multiprogramming environment in a tightly coupled multiprocessor system in which multiple CPUs share a main memory. .

The present invention is also effective when serializing access to shared resources by multiple processes in a multiprogramming environment in a computer system with one CPU.

Among the pointer chains shown in FIG. 2, the horizontal chain represents a queue of lock requests for specific shared resources. For example, from RCBI to LCBll, LCB12. L
The pointer chain extending to the CB 14 connects lock requests for the shared resource represented by the RCBI in the order of request generation time. During LCB (wa
it) An indication indicates that the lock request is currently pending. In FIG. 2, the oldest lock request LCB14 issued to the RCBI was granted, but the lock requests LCB12 and LCB issued after that were granted.
II, the lock is not granted immediately and the lock request LCB
14 is shown waiting to be released.

The same goes for the pointer chains extending rightward from RCB2 and RCB3.

In contrast, a vertical pointer chain represents a list of lock requests issued by a particular process. For example, P
The pointer chain extending from CB 1 to LCBII to LCB31 indicates that the process indicated by PCBl is
This indicates that lock requests LCB11 and LCB31 were issued in the reverse order. Lock request 31 was granted, lock request 11 was not granted, and process PCB 1 is currently in a waiting state. PCB2. PCB3. The same goes for the pointer chain extending downward from PCB4. One process can wait for any number of granted lock requests greater than or equal to zero, but it can wait for at most one lock request.

Now, returning to FIG. 1 again, details of each control block will be explained.

A resource control block (R
CB) 100 includes a lock word LW that indicates the status of a lock on a shared resource, and a queue control word QCW that manages a queue of lock requests for the shared resource. Here, one feature of the present invention is that the LW and QCW do not need to be adjacent. Details of the contents of the lock word LW will be described later. The queue control word QCW includes an exclusive flag X and a shared counter SHR.

Deletion flag D7 consists of addition counter ADD and queue anchor pointer ANC. Exclusive flag X and shared counter SH
R is used to control serialization of access to the queue when unlock processing is performed simultaneously by multiple processes.

The deletion flag D is used to indicate that there is an LCB in the queue that is connected to the pointer chain but has been logically deleted.

The additional counter ADD is incremented each time an LCB is newly placed in the queue, and is used to detect the occurrence of a conflict between lock processing and unlock processing. Queue anchor pointer ANC is the start of a pointer chain 140 representing a queue of lock requests.

Process control block (P
CB) 110 contains a pointer LPT that is the start of a pointer chain 150 representing a list of lock requests that have been granted or are waiting to be granted to the process.

Lock control block (LCB) representing a lock request
) 120 is a pointer NIQ indicating the next LCB in the pointer chain 140 from RCB, a pointer NIS indicating the next LCB in the pointer chain 150 from PCB, and MO indicating the mode of the lock requested.
Contains DE and flag FLG. Flag FLG is LCB
The W flag indicates that the lock request is in a waiting state, and the LCB is in the queue, that is, the RC
The pointer chain 140 from B includes an ef flag, meaning invalid, and a P flag, meaning the lock request can be granted and needs to be released from the wait state. The LCB also contains a pointer NIP pointing to the next LCB in the pointer chain 160 that connects the lock requests that need to be released from the wait state.

Lock processing/unlock processing uses several work registers 130 in addition to one or more control blocks. One of the work registers is used as a pointer PPT that is the starting point of a pointer chain 160 that connects lock requests to be released from a wait state. The other work register is ΔMODE, which is used to store the mode of lock requests that can be newly granted during unlock processing.
used as.

FIG. 3 shows the contents of the lock word LW. The locks in this embodiment are EU/ER/PU/PR/
Wait for 6 different modes: SU/SR.

FIG. 4 shows the compatibility between these locking modes. In the matrix of FIG. 4, the O symbol indicates that two modes can be permitted simultaneously, and the X symbol indicates that the two modes are mutually exclusive.

As you can see from this matrix, E U/E R/P
U mode locks are granted to only one process, and PR/SU/SR mode locks can be granted to multiple processes at the same time. Therefore, in the lock word LW of FIG. 3, the EU/E R/PU modes are each represented by flags, and the PR/SU/SR modes are each represented by counters.

The lock word LW also includes a counter WA I T indicating the number of lock requests waiting to be granted; if there is even one lock request waiting, all lock requests that arrive after that are placed waiting. this is.

This is to ensure the time order of lock requests.

The type of lock mode and the method of expressing the lock mode in the lock word LW are not limited to those shown in FIGS. 3 and 4, but any other method is possible.

The only restriction here is that the lockword LW can be updated by read-modify-write type instructions.

(l-2) C3 and CDS Instructions Before going into details of lock processing/unlock processing, we will explain the C S (Compare and Swap) instruction and CD S (Compare Double), which are read-modify-write machine instructions used therein. an
dSwap) command will be briefly explained below.

The C8 instruction uses two general-purpose registers and main memory (virtual memory).
Using the one-word length area above as an operand, compare the contents of one word in the first register and main memory (virtual memory), and if they are equal, replace that one word with the contents of the second register. Rewrite and set the condition code to O, and if they are different, load the contents of that one word into the first register and set the condition code to 1, which is executed as one atomic operation.・This is a modify write type instruction.

The CDS instruction also performs the same operation as the CS instruction, but this instruction differs in that it uses four general-purpose registers to operate on a double-length area. In a tightly coupled multiprocessor where multiple CPUs share main memory, when a process being executed by one CPU compares the contents of a state variable in main memory and attempts to change the state variable according to the value, Using the load/conveyor/store instructions, we read the state variables (load) and compare them (conveyor).
, during the rewriting (store) process, the state variable is changed to another C
It may be rewritten by the PU and the consistency of processing may be lost. For this reason, a C8 instruction or a CDS instruction is used to perform comparison and rewriting in one atomic operation.

The lock processing/unlock processing will be explained in detail below based on a flowchart. Note that detailed initial setting processing and exception handling are omitted in the diagram to avoid making the explanation unnecessarily complicated.

(1-3) Lock processing FIG. 5 is a flow chart of lock processing. The process requesting the lock receives the RCB address, PC
Assign the B address and request lock mode, and call the lock process. In the locking process, an LCB is first created, its contents are initialized, and it is connected to the pointer chain from the PCB (step 1001). In this initialization, the NI
Q and NIP are set to null values, and all flags are reset.

MODE is set to request lock mode. Also, L.C.
To connect B to the pointer chain from the PCB, NI
The value of the old LPT is set in S, and the LCB address is set as the new LPT.

Next, referring to the lock word LW, it is determined whether the requested lock can be granted or whether it must be waited for (step 1002), and a new lock word is set using the CDS instruction (step 1003). A lock is granted only if there are no pending lock requests and the requested lock mode is compatible with lock modes already granted to other processes. A new lock word can be obtained by setting a flag corresponding to the requested lock mode or incrementing a counter if the lock can be granted, or by incrementing the WAIT counter if the lock is waiting.

Why does the CDS instruction in step 1003 fail?

This is because an access conflict with the update of the lock word LW by another process's locking process (step 1003) or unlocking process (step 1207 in FIG. 7, described later) has occurred, and step 1. Try again from OO2 (step 1004). If you need to wait for a lock, use LCB's W.
Set the flag (step 1005. Step 10
06).

Subsequently, a CDS instruction is used to queue the LCB (step 1007). This process copies the current ANC value to NIQ, then uses the CDS instruction to
Rewrite the ANC value to the LCB address while making sure that the contents have not been changed by other processes.
This is executed by increasing the value of the ADD counter by one. If the ADD counter is at the maximum value, it wraps around to l. Step 1007 CD
The S instruction fails because of lock processing (step 1007) or unlock processing (step 1107 in FIG. 6, steps 1302 and 1304 in FIG. 8, described later) of other processes.
This is because a conflict with the QCW update has occurred, and the queuing process is retried (step 1008).

After placing the LCB in the queue, if locking is permitted, the process returns to the lock processing caller, and if locking is required, the mode is reconfirmed (step 1009). In the mode reconfirmation process, the lock word is referenced again to confirm whether the lock can be granted (step 1).
010, step 1011), and if lock grant is still not possible, place the lock requesting process in a waiting state (
Step 1012). If the lock word has been changed to allow permission, unlock 2 processing is called to avoid waiting for the lock (step 1013). This kind of mode reconfirmation is performed after setting the lock word in step 1003 and then setting L in step 1007.
Until the CB is connected to the queue, if the process currently granted the lock executes the unlock process and the lock word LW is rewritten to a state where the lock can be granted, the current lock request remains waiting. This is to prevent it from remaining in the queue. If the LCB is queued, the unlock process can scan the queue to find the waiting LCB, and the lock wait is released. If the lock word is updated in the unlock process before the lock word is referenced in the lock process, the lock request will not wait.The problem is that before the conflicting unlock process updates the lock word, This is a case where two processes are executed at the same time as the lock word is referenced in the lock process, and the queue is scanned in the unlock process before the LCB is connected to the queue in the lock process. In this case, it cannot be expected that the waiting state of this LCB will be released by the unlock process, so the mode is reconfirmed during the lock process after the LCB is registered in the queue, and if necessary, the unlock process is simulated.

In the conventional method, the lock word LW and the queue control word QCW were integrated and updated simultaneously by one CDS instruction, so such a timing gap did not occur. In the present invention, the lock word LW and queue control word QCW are separated in order to increase the degree of freedom of locking, and therefore, mode reconfirmation processing is required.

(1-4) Unlocking process FIGS. 6 to 9 show the flow of the unlocking process. The unlock process has two entry points. The unlock 1 entry point is called when a process that has been granted a lock releases the lock.

On the other hand, the lock processing mode reconfirmation process (
The unlock 2 entry point is called in step 1013). The input information is the LCB address for both entry points.

FIG. 6 shows the flow of the initial part of the unlock process. In normal unlock processing, that is, processing starting from the unlock 1 entry point, first the work register ΔMOD
The change in the lock word LW caused by the lock release, that is, the reciprocal of the MODE of LCB is set in E (step 1101). Next, the CS instruction is used to set the ■ flag of the LCB (step 1102). This C8
The instruction is repeated until the ■ flag is successfully set (step 1103). Subsequently, the LCB is removed from the pointer chain from the PCB (step 1104). In other words, if this LCB is the head of the pointer chain, it is used as the LPT, otherwise it is used as the LCB immediately before this LCB.
Copy the NIS value of this LCB to the NIS of this LCB. The above is the preprocessing unique to the unlock 1 entry point, and the subsequent processing is common to the unlock 2 entry point. When processing is started from the unlock 2 entry point, the initial value of the work register ΔMODE is 0.

Next, in step 1105, the values of the ADD counter in the lock word LW and queue control word QCW are saved to a free word register or work area.
), check if the X flag is set (step 1
106). The fact that the X flag is set means that another process is occupying the queue and accessing it, and will spin-wait until the X flag is reset. After confirming that the X flag has been reset, the SHR of the queue control word QCW is counted up using the CDS command (step 1107). If this CDS instruction is successful, the unlock processing execution process has obtained shared access authority to the queue. The reason why the CDS instruction fails is because there is a conflict in the QCW update with lock processing or unlock processing by another process, and the process is retried from step 1105 (step 1108). That's it so far.

This is the first stage of the unlock process.

FIG. 7 is a flowchart of a process in which a lock request that can be granted is found in a queue and released from waiting. This process begins by tracing the pointer chain from the ANC pointer of the queue control word QCW and searching for the LCB that entered the wait state the oldest (step 1201).
. That is, find the last LCB in the pointer chain in which the W flag is set and the {circle around (2)} flag and P flag are reset. If there are no longer any grantable lock requests, the LCB in such a state
is not found, and the process moves to loop termination processing (step 120
2).

If an LCB to be released from the wait state is found.

Set the P flag in the LCB with the C8 instruction (step 1
203). If the C8 instruction is successful (step 1204)
, the difference information of the lock word is stored in the work register ΔMODE.
(step 1205), and connects the LCB to the pointer chain from the work register PPT (step 12
06). When changing ΔMODE, set the WAIT counter to 1.
set the flag corresponding to the lock mode requested by the LCB.

Or increment the counter. Also, LCB's NI
Copy the current PPT value to P and add this LCB to PPT.
By setting the address of PPT
You can connect to a pointer chain from . The C8 instruction in step 1203 fails when a conflict occurs in accessing the flag FLG of the LCB, and the process is retried from step 1201.

When the processing up to step 1206 is completed, the process returns to step 1201 to search for the next LCB to be released from the waiting state. In this way, differential information for changing the lock word is accumulated in ΔMODE, and a list of LCBs to be released from waiting is formed in the pointer chain from PPT.

When exiting the LCB search loop, new lock word contents are created using the mode difference information accumulated in ΔMODE, and set in the lock word LW with the CDS instruction (
Step 1207). In this case, what is compared with the LW in the CDS instruction is the content of the lock word saved in step 1105. This CDS instruction fails because
This is because another process updated the LW between step 1105 and step 12o7, and the process returns to the beginning of the loop (step 1201) to check whether there is any LCB that can be released from the wait state (step 1208). CDS
If the instruction is successful, all waits for the LCBs connected to the pointer chain from the PPT are released (step 1209), and control is transferred to the unlock termination process shown in FIG.

FIG. 8 shows the flow of the end portion of the unlock process. Here, the shared access authority for the queue secured in step 1107 is released.

First, check the contents of the SHR counter of the QCW (step 1301), and if there is another process accessing the queue, that is, if the SHR value is greater than 1,
Decrease the value of SHH using the CDS instruction (step 13
02). If the process has been started from the unlock process 1 entry point, the D flag is set at the same time by this CDS instruction. If the CDS command is successful, the unlock process is completed and the process returns to the source of the call (step 1303). On the other hand, if the only process accessing the queue is the own process, the SHR value is 1.
It is. In this case, use the CDS instruction to reduce the value of SHR and set the X flag at the same time (step 130
4). If the process is started from the unlock process 1 entry point, the D flag is also set at the same time. The fact that the CDS instruction in step 1304 is successful and sets the X flag in the QCW means that exclusive access authority to the queue has been secured. In this case, control is transferred to the LCB deletion process shown in FIG. 9 (step 1305).

The CDS instruction in step 1302 or step 1304 fails when a QCW access conflict with lock processing or unlock processing by another process occurs. In order to confirm with which process the conflict occurred, it is checked whether the value of ADD is equal to the value saved in step 1105 (step 1306). If the value of ADD has not changed, there is a conflict with the unlock process of another process, and the QCW update process can be retried from step 1301. If the value of ADD has changed, it is because a conflict with lock processing by another process has occurred.
The entire queue scanning process from step 1201 needs to be performed again. The fact that ADD has been updated by lock processing means that a new LCB has been added to the queue. The queue scan is retried to check whether this LCB is not a waiting LCB that can be granted a lock. This LCB state occurs because the lock process first refers to the lock word LW and decides to wait (step 1002), and then the unlock process scans the queue to find an LCB that can release the wait. Steps 1201 to 1206), then the lock process adds the LCB to the queue and puts the process in a waiting state (steps 1007 to 1012), and finally the unlock process allows the waiting lock request to be granted. This is a case where two processes are executed simultaneously at the timing of updating the lock word (step 1207). If the unlock process updates the lock word earlier than the lock process adds the LCB to the queue, the lock process mode reconfirmation process (step 1010) detects the occurrence of a conflict and waits for the LCB. Release. In this way, by providing both the mode reconfirmation operation in the lock process and the ADD counter confirmation operation in the unlock process, it is possible to prevent the occurrence of a timing in which a lock request is made to wait unnecessarily.

Finally, the process of deleting an LCB from the queue will be described with reference to FIG. First, it is determined whether there is an LCB to be deleted in the queue by referring to the D flag of the QCW (
Step 1401). If the D flag is not set, the X flag is reset and the unlocking process ends (step 14.12). If the D flag is set, the pointer chain is followed from the ANC to obtain the first LCB (step 1402). If the ■ flag of the first LCB is set, that LCB is
from the queue (step 1404゜step 1)
409), the LCB is released as a free memory area (step 1411). The first LCB is removed from the queue by setting the NIQ value of the LCB to ANC. The C8 instruction in step 1409 fails when there is a conflict with the QCW update process of another process, and the process is retried from step 1402 (step 1410). Even if the LCB is released in step 1411, the process returns to step 1402 to obtain the primary LCB. In this way, if the first LCB pointed to by ANC no longer exists, the loop exits (step 1403
).

If the X flag of the first LCB is not set,
Obtain the next LCB by following the NIQ (step 1405)
, if the LCB's eff flag is set (step 1407), the LCB is removed from the queue and released (
step 1408).

In this case, the LC to be removed is set to the NIQ of the previous LCB.
Dequeuing is performed by copying B's NIQ. There is no need to use the C8 instruction to update NIQ here. In this way, the last LC in the queue
When the process progresses to B, the loop is exited (step 14).
06).

In the unlock process, an LCB at an arbitrary position in the queue may be deleted and released, so it is necessary to limit the number of processes that operate the queue pointer to only one. Since the LCB deletion process is executed by setting the QCW X flag, there is no possibility that the pointer chain will become invalid due to conflict with the queue operation due to the unlock process of another process.

The unlock processing of other processes spins wait until the X flag is reset (step 05 to step 1106). It is set only by the process that is the last to finish queue access among the multiple processes that were in progress, and is reset immediately after the LCB for which the X flag has been set has been deleted from the queue. Therefore, the probability that spin weight will occur is very small. On the other hand, queue access contention due to lock processing is caused by C in step 1409.
Detected with 8 instructions. In lock processing, access to the queue is limited to adding new LCBs to the ANC, so unlock processing queue operations and processing can be serialized without using spin waits.

(2) Second Embodiment FIG. 10 is a block diagram of a computer system showing an outline of a second embodiment of the present invention. The difference between the second embodiment and the first embodiment is that in the second embodiment, L
CB no longer has the role of indicating a state in which a certain process is permitted to hold a lock, but is used only to indicate that a process is waiting for a lock. Therefore, each process corresponds to at most one LCBL, and a PCB and a pointer chain connecting the PCB to the LCB are not required.

The RCB and work registers are the same as in the first embodiment.

The lock processing and unlock processing in the second embodiment are almost the same as in the first embodiment, except that the LCB is registered in the queue only when waiting for a lock, and will be described in detail here. I have nothing to say. In FIG. 5, step 1001 is deleted and Y is selected in step 1005.
In the case of ES, return immediately, and in step 1006 L
If the process is changed to create a CB, a flowchart of the lock process in the second embodiment can be obtained. Similarly, the sixth
In the figure, all unlock processing is started from the unlock 2 entry point, and in Figure 7,
If the process flow is changed to set the D flag at the same time as the P flag of the LCB in step ↓203, the flow chart of the unlock process in the second embodiment can be obtained.

〔Effect of the invention〕

As described above, according to the present invention, a locking mechanism with complicated modes can be efficiently realized using only read-modify-write type instructions and a minimum number of spinlocks. Particularly in a tightly coupled multiprocessor environment where multiple CPUs share main memory, an advanced locking function can be achieved without significantly increasing the load on the CPU due to spin locks.

[Brief explanation of drawings]

Fig. 1 is a block diagram of a computer system showing a first embodiment of the present invention, Fig. 2 is a block diagram showing the computer environment and main memory contents in which the invention effectively operates, and Fig. 3 is a detailed diagram of the lock word. FIG. 4 is an explanatory diagram of a lock word compatibility matrix, FIG. 5 is a flowchart of the locking process, FIGS. 6 to 9 are a flowchart of the unlocking process, and FIG. 10 is a diagram of the second embodiment of the present invention. 1 is a block diagram of a computer system illustrating an embodiment of the present invention. 10... CPU, 20... Main memory (virtual memory) device, 100... Resource control block (RCB)
, 110...Process control block (PCB)
), 120...Lock control block (LCB
), 130...work register, 140...ANC
Pointer chain, 150...LPT pointer chain, Figure 2 Figure 1 Figure 3 Figure 4 Lock compatibility matrix (1) 1st character of mode = Process S allowed to other processes
(Shared): Permit read/write P (Protected): Permit read but not write E (Exclusive):
Lead/Lie h'-! 'f E not (2> 2nd character of mode = process R (ReLriev
e) U to read (υpdate)
・ Lead/Lie] Figure 6 Figure 5 Figure 7 Figure 8 Figure 9

Claims (1)

[Claims] 1. In a multi-process, multi-programming system, access to a data resource shared by multiple processes is granted or made to wait for a lock request issued by each process. A control method, wherein a control block corresponding to a shared resource and a lock request is provided, and the control block corresponding to the shared resource includes a lock word indicating a lock state of the shared resource and a control block corresponding to the lock request. The queue control word has a queue control word for managing the queue, the queue control word includes means for detecting that a control block corresponding to a lock request is added to the queue between a certain point in time, and (1) a lock word is added to the queue. It references it to determine whether the lock is granted, then adds the control block corresponding to the lock request to the queue, and if it needs to wait for a lock, it references the lock word again.
(2) scanning the queue to find a grantable lock request and setting a lock word to correspond to the newly granted lock request; (2) scanning the queue to find a grantable lock request; If it is detected that a control block corresponding to the lock request has been added to the queue between the queue scan start point and the lock wait release point, processing is restarted from queue scan. A method for controlling access to a data resource, comprising the steps of: attempting. 2. A method for controlling access to data resources shared by multiple processes in a multi-process, multi-programming system by granting or making lock requests issued by each process wait. , a control block corresponding to a shared resource and a lock request is provided, and the control block corresponding to the shared resource is a queue control that manages a queue including a lock word indicating the lock state of the shared resource and a control block corresponding to the lock request. a control block corresponding to a lock request, the queue control word having an anchor pointer pointing to the last enqueued control block and an additional counter recording the number of times the control block was enqueued; A data resource characterized in that it includes a pointer to a control block placed in a queue earlier, a word indicating the type of lock being requested, and a wait flag indicating that the lock request is being waited for. How to control access. 3. Claim 2 further provides the steps of: (1) determining whether the lock request can be granted by referring to the lock word; and (2) adding a control block corresponding to the lock request to a queue and counting the additional counter. (3) After adding the control block to the above queue, if it is necessary to wait for a lock, refer to the lock word again and check whether the contents of the lock word have been changed to allow locking. and, if permissible, avoiding lock waits. 4. Claim 3 further provides the steps of: (1) saving an additional counter for the queue control word; (2) scanning the queue to create a list of control blocks for which locking is permitted; and (3) locking is permitted. (4) Compare the additional counters saved in (1) above with the current additional counters, and if they are different, change the lock word in accordance with the lock word (1) above.
); and (5) releasing the lock waiting state in the list of control blocks created in (2) above. 5. Claim 2 further provides that the queue control word includes an exclusive flag representing the possibility of exclusive access to the queue and a shared counter representing the possibility of shared access to the queue, and the control block corresponding to the lock request (1) If the exclusive flag is not set, increment the shared counter and start scanning the queue; (2) performing a queue scan and setting an invalid flag in the target control block; and (3) decrementing the shared counter if the result of decrementing the shared counter is 1 or more. If it becomes 0, the shared counter is decremented, the exclusive flag is set and the queue is scanned, the control block with the invalid flag set is deleted from the queue, the exclusive flag is reset, and the queue is scanned. A method for controlling access to a data resource, comprising: terminating a scan. 6. A computer system comprising a method for controlling access to data resources according to any one of claims 1 to 5.