JPS62100856A - Lock processing system for input and output system - Google Patents

Abstract

PURPOSE:To attain designation for a fine lock range by chaining a normal CCW for data transfer and a CCW showing a lock range vir a lock control routine set inside a CPU and delivering an input/output request. CONSTITUTION:A local lock manager 20 is set within a CPU10 and delivers the transfer request of the shared data and the lock acquiring request to a global lock manager 26 set on a controller 16 by the request of a user program group 21. The communication is carried out between both lock managers by a normal I/O interface via channels 12 and 13. The manager 20 delivers an I/O request through an I/O control program 22 and therefore delivers the lock request and the data transfer request to the manager 26. In the same way, the manager 20 delivers the request onto a CPU11 through an I/O control program 25 in response to the request given from a user program group 24.

Description

[Detailed Description of the Invention] [Field of Application of the Invention] The present invention relates to an input/output system lock processing method, and in particular,
This relates to lock processing for resources shared between PUs, and in particular, data processing methods for input/output systems (hereinafter abbreviated as ■/○ systems).

[Background of the invention]

As the amount of processing required for computer systems increases, system configurations equipped with multiple CPUs are becoming common. In this case, the overhead caused by locking, or occupancy, of data shared among multiple CPUs becomes a problem in terms of system performance. Reducing the overhead caused by this lock processing is an important issue for multiprocessor systems.

Conventionally, the following techniques are known as locking architectures for data shared among multiple CPUs. (a) First, as a communication method between CPUs,
There is a method described in Publication No. 7-68461, and (b) I1
As for the 0-system centralized method, [Analysis of multi-system data sharing J (The DC3-A ne
w approach to vau1hiisy
seem data-sharing, NCC
, 1984+PP, 59-68), and the (c) I10-based dispersion method includes the method described in [Hitachi Manual H-8538-CI Disk Controller, H-
There is a method described in ``8598 Disk Drive Device''. The inter-CPU communication method in (a) above involves a CPU that has a global lock manager (a manager that manages access rights to shared data) and a local lock manager (that accepts lock requests from user programs). manager) and the CPU where it resides,
Send and receive information about locks. In this case, lock information transfer processing occurs twice from the CPU where the local lock manager resides, and lock information processing occurs twice from the CPU where the global lock manager exists, for a total of four times. ／○Processing is required. Next, the ■/○ concentration method in (b) is D CS (D at
=a −5hare Cor+trol Syst
em). In this method, a new device is provided in the 10 series, and a global lock manager is implemented on this device for handling locks on resources shared between CPUs. A local lock manager on each CPU can acquire a lock on data in a single I10 operation. Next, in the I10-based distributed method (c), an I10 request and a lock request are simultaneously issued to a disk where data to be accessed exists.

In this method, the overhead for lock acquisition is
○ Since it is included in the processing, it has the best performance from the perspective of overhead. However, in the conventional method, the unit of lock is the entire disk device, so locking is performed in fine-grained lock units such as databases, such as records (units of data transfer between disk and main memory). Not suitable if you need it.

Furthermore, no consideration was given to simply issuing a lock request without data transfer.

[Purpose of the invention]

The purpose of the present invention is to solve such conventional problems, to specify a detailed lock range for locking data shared among multiple CP0s, and to significantly reduce the overhead of lock processing. The purpose of this invention is to provide an input/output lock processing method that allows for efficient input/output lock processing.

[Summary of the invention]

In order to achieve the above object, the input/output system lock processing method of the present invention provides a computer system that includes a control device connected to a plurality of CPUs and a plurality of input/output devices connected to the control device. The CPU has a lock management routine for resources shared by the system 11, and the lock management routine uses a CCW for normal data transfer and a CCW that indicates a lock range independent of the range targeted for data transfer.
It is characterized by issuing input/output requests by chaining with CW, and performing lock processing and data transfer processing that have separate lock ranges and data transfer ranges.

[Embodiments of the invention]

EMBODIMENT OF THE INVENTION Below, one embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 2 is a block diagram of a computer system to which the present invention is applied. In Figure 2, two CPUIo, 11
A channel 1.2.13 and a main storage device 14.15 are connected to each CPU10. ○The device group 18 is connected. Here, the CPU.

Although the system is equipped with two channels and two main storage devices, it can generally be expanded to include two or more n devices. Further, although only one set of the control device 16 and the I10 device group I8 are connected, it is generally possible to expand to n sets. However, it is assumed that each control device is connected to two or more CPUs via a channel dedicated to each CPU.

By the way, it is possible to reduce the overhead of locking processing for data shared between CPUs to almost zero by processing accesses to data on a disk and locking requests all at once.

However, in the various conventional methods, since the unit of lock is the entire disk, this method cannot be applied directly to cases where fine-grained locking is required, such as with databases. Therefore, in this embodiment, a CCW (channel command word) that specifies the lock range independently of the data to be transferred on the disk is chained with the conventional CCW for data transfer, so that one Ilo
Process in batch. In addition, when issuing a lock request that does not involve data transfer, or when receiving a notification that a lock wait has been completed, a virtual device is created to reduce the impact on the performance of other data transfer processes. I am trying to issue a request to .

FIG. 1 is a software related diagram of an input/output system lock processing method showing an embodiment of the present invention. That is, in FIG. 1, CPUs 1.0, 11. The relationship between each lock manager on controller 16 is shown. The local lock manager 20 exists in the CPU], 0, and issues shared data transfer or lock acquisition requests to the global lock manager 26 on the controller], according to requests from the user program group 21. do. Control device 16
If there are multiple lock managers, a global lock manager 26 is provided for each control unit.

At this time, the local lock manager 20 determines which global lock manager to issue the request to by identifying the content of the request from the user program group 21. If such a discrimination function is provided in the local lock manager 20, even when there are n control devices,
Since it is easily expandable, the case where there is only one control device will be described here. Communication between lock managers takes place over the normal I10 interface via channel 12.13, so that local lock managers 20 can communicate with global lock managers by issuing ■/○ requests through I10 management program 22. lock manager 26
Issue lock requests and data transfer requests to

Similarly, on the CPU 11, the local lock manager 23 accepts requests from the user program group 24 and issues requests to the global lock manager 26 through the ■/○ management program 25.

FIG. 3 is a functional block diagram of each local lock manager in FIG. Each symbol represents the same thing as in FIG. 1, and the local lock manager 20 or 23 includes a lock analysis section 30 and a lock wait completion notification section 31. Local lock managers 20 and 23 have exactly the same configuration and function, so only local lock manager 20 will be described here.

Lock analysis section 3 in local lock manager 20
0 is a lock request or (lock request) from one program in the user program 511 group 21 (24)
+ (data transfer request) shall be accepted. Generally, when issuing a D/○ request, it is necessary to specify the ■/○ device to which the ■/○ request is issued. When the lock analysis unit 3o receives a lock request from a program in the user program group 21, it determines the device to which the ■/○ request is to be issued. Here, a lock request refers to a lock acquisition request and a lock release request. Generally, locks have several modes, and there are cases in which the acquired mode may be allowed to be changed, but even in this case, this embodiment can be easily extended. In the case of (lock request) + (data transfer request), the device to which the r/○ request is issued must be a device in the machine/○ device group 18 that performs the data transfer, so the r/○ request was issued in the past. It is sufficient to issue a T/○ request with a CCW for locking added before the CCW for input/output processing.

FIG. 4 is an explanatory diagram of a CCW chain of lock requests involving data transfer in FIG. 3. The contents of the CCW for locking include the contents of the lock request (lock acquisition, release), lock range, program, and local lock manager ID.

Here, the program ID is the ID (identification symbol) of the program among the program group that issued the lock request.

If you want to lock multiple resources, you can chain multiple locking commands. Note that a method of locking multiple resources with one command is also conceivable. In the conventional example (for example, the document cited in CC above), the scope of the lock is the entire T/○ device, so there is only one lock command, and the target device for which the lock and the T/○ request is issued are the same. Therefore, there was no need to limit the lock range with a lock command. In this embodiment, the lock range may be different from the device to which the ■/○ request is issued, so it needs to be limited within the CCW. Therefore, it is possible to issue a lock request for data on a device different from the I10 device in the I10 device group 18 that performs the data transfer. Traditionally, which program ID, local
Although it was not necessary to notify the global lock manager 26 of the lock manager ID, in this embodiment, a method of notifying this as shown in FIG. 4 is used. The reason for this will be described later.

Next, a case will be described in which the lock analysis unit 30 receives only a lock request. In this case, there is no need for data transfer, so the I10
will issue a request.

Therefore, the CCW sequence in this case is as shown in FIG. That is, ccwrp, lock range, program ID, and local lock manager TD are the contents of the lock request. The problem at this time is the settings of the device to which this work/○ request is issued. If an I10 request is issued to a real I10 device and the I10 device is occupied even though data transfer processing is not necessary, a problem arises in that other ■/○ processes cannot be executed during that time. To solve this problem, a virtual device method is used. In this method, a virtual device is provided that is used only during lock processing, and lock processing is performed by issuing ■/○ requests to this device. Specifically, one device address that is not assigned to the I10 device of a certain I10 device group 18 is selected, and an I10 request is issued using this device address. This device is assumed to be a virtual device 32 (see FIG. 3).

In this embodiment, a virtual device 33 is further provided.
The purpose of use will be described later. By using this method, normal I10 processing involving other data transfer processing is not affected.

Lock processing is possible.

When a lock request is issued for data, it may be possible to lock the data, or there may be a conflict with other processing requests, resulting in a lock wait. When the global lock manager 26 receives a lock request from the local lock manager 20 or 23, it checks the status of the resource to be locked and determines whether there will be a conflict with a program in another program group 21 or 24. Check. If the access right can be granted, the locking process can be completed. In the case of a lock request for data transfer, normal data transfer processing is then started. In the case of only a lock request, the lock processing is ended at this stage and the virtual device 32 is released.

Next, we will discuss the case where lock waiting occurs due to contention with other programs. In the case of conventional locking for each machine/device unit, when a program enters the wait state, I1
A method is adopted in which the system enters a waiting state while occupying 10 devices in the 0 device group 18.

Since the entire machine/○ device is locked, this will terminate the I10 processing of that program and start the next I10 process.
This is due to the fact that even if the process is in progress, the next process cannot be executed. However, as in this example,
If the range of the lock is not the entire I10 device, the lock may be accepted if the subsequent program has a different lock range, so it is necessary to terminate the I10 processing and release the device. For the same reason, for locking operations that do not require data transfer,
If a lock wait occurs, terminate I10 processing,
Release the virtual device 32.

The lock analysis unit 30 detects an I
When processing 10 is completed, the corresponding program in the program group 21 is instructed to enter a waiting state. In this case, when the program currently locking the data to be accessed releases the lock, it must be possible to release the lock wait. Therefore, the global lock manager 26 needs to manage which programs currently hold locks on shared resources and which programs are waiting for locks.

FIG. 6 is an explanatory diagram of a lock acquisition request chain used in the present invention. This lock acquisition request chain is provided within the global lock manager 26. As shown in FIG. 6, the above management information includes the following information 62 to 6 for each lock range ID 60 that is a lock range.
4, the local lock manager TI requesting the lock) 62, the program ID requesting the lock 63
, and the lock state 64 are stored in a queue by the lock pointer 61. Lock request local lock manager ID62. Lock request program rD
63 is the ID of the local lock manager and program that issued the lock request. This information is
Local lock manager in CCW, CC
Store from WID. Lock status 64 indicates whether this request is occupying the lock or is in a waiting state. When the global lock manager receives a lock request, it must create queue information if there is currently no lock request for that resource. Furthermore, if a lock request by another program has already been accepted, it is checked whether they can coexist or if there is a conflict. On the other hand, when a release request is accepted, it is necessary to notify the program to which the new access right is granted. Also.

When there are no more lock requests for that resource, the queue information is deleted.

On the other hand, a lock wait completion notification section 31 exists on the local lock manager 20 side to receive a notification that the access right has been granted. In this case as well, the lock wait completion notification unit 31 receives a completion notification in the form of issuing an I10 request. I10 is issued to other ■/○ devices as in the case of lock requests that do not involve data transfer.
A virtual device method is used to avoid performance degradation due to processing requests. The virtual device used at this time is assumed to be a virtual device 33 (see FIG. 3). Since it is unknown when the lock will be released for other processing requests, the lock wait completion notification unit 31 issues a ■/○ request immediately after receiving a certain completion notification and releasing the lock wait for the user task. It is necessary to prepare to receive the secondary lock wait completion notification.

The CCW in this case may use a new command, or if the completion notification is interpreted as an input record from the virtual device 33, an existing read command can also be used. This embodiment does not limit this. On the other hand, the user task that has completed waiting for the lock has been granted access rights, so if data transfer is required, it can simply enter normal processing without going through the local lock manager. . On the other hand, the global lock manager 26 needs to have information regarding the status in order to accept the completion notification reception request. Each local lock manager has this information.

FIG. 7 is a configuration diagram of a lock completion notification information chain used in the present invention. This information is necessary in order to remember this completion notification information when a lock wait for a certain processing request is completed and a lock completion notification request has not been issued by the corresponding local lock manager. . Local lock manager ID 70 indicates which local lock manager this completion notification information is for. The program ID of the program in the program group 21 (or 23) that has completed the lock wait is stored in a queue in the completion notification program ID 72 via the lock wait completion pointer 71. If no program has completed lock waiting, the leading lock waiting completion pointer 71 becomes empty.

■/○ The management program 21 issues an I10 request in accordance with the request from the lock analysis section 30. In other words, in the case of a lock request that involves data transfer, C
In the case of only CW and lock requests, a CCW as shown in FIG. 5 is issued.

In this case, the devices targeted by the I10 request shall be limited by the local lock manager. However, this may be controlled by the ■/○ management program 22 side. Furthermore, when the user issues a work/○ request that does not include a lock request, the user issues the request directly to the I10 management program 22.

The operation of each lock manager will be explained below according to the processing flow. FIG. 8 is a processing block diagram of the lock analysis section 30 of the local lock manager 20 (or 23). First, it is determined whether this request is a lock request only or a lock request that involves data transfer (step 800). If data transfer is involved, the engineering/○ management program 22 is requested to issue a data transfer request and a lock request all at once to the I10 device in the I10 device group 18 that is the target of the data transfer (step 801). The scope of the lock is determined within the CCW for the lock. On the other hand, if there is only a lock request, the I/O management program 22 is requested to issue a lock request to the virtual device 32 (step 802). Thereafter, it waits for the completion of these processes (I10 wait for completion, step 803). ■／○After completion, check the completion status,
If a lock wait is occurring, the program in the program group 21 that issued the request is notified to enter a wait state (steps 804, 805).

If there is no lock waiting, a notification is sent that the process has been completed (step 806), and the process is terminated.

FIG. 9 is a processing flowchart of the lock wait completion notification section 31 of the local lock manager. Notification part 3
1 first requests the I10 management routine 22 to issue an instruction to the virtual device 33 to send lock completion notification information (step 900). next,
Wait for this I10 request to complete (step 901)
. Upon receiving this I10 completion notification, the lock completion notification information is analyzed and the locking status of the program in the corresponding program group 22 is released (step 902). and,
Return to the beginning and begin processing another lock request.

FIG. 10 is a processing flowchart of the global lock manager 26 in the present invention.

Global lock manager 26 resides on controller 16, as shown in FIG. Although there are functions other than global lock manager 26 on controller 16, only those portions related to this function are shown here.

First, the content of the received request is analyzed (step 100).
0). When receiving a request to send lock request completion information, it is checked whether there is already lock request completion information to be notified (step 1001). If there is this, lock completion information is notified and the ■/○ processing is terminated (step 1002). If not, the lock wait completion pointer 71 (
(see FIG. 7) is set to a completion notification state (step 1003). Next, when a lock acquisition request is received, it is checked whether the lock is granted (step 1004). If not recognized, it is notified that a lock wait has occurred, and the I10 process is terminated (step 1005). If the lock is approved, it is checked whether this request involves data transfer (step 1006). If data transfer is not involved, it is notified that the work/○ request has ended normally, and the process is ended (step 1007). Furthermore, if data transfer is involved, normal data transfer processing will then begin. Since this process is a well-known operation, a description thereof will be omitted. Next, when a lock release notification is received, it is checked whether there is a program that can newly acquire a lock by this release (step took).
. If this exists, the local lock managers are classified into those that have received lock wait completion notification requests for each program and those that have not received them (
Step 1009). The lock wait completion information is notified to the receiving request (step 101).
0).

Also, for those that have not issued a reception request, the completion notification program I
D, and connect to the queue from the lock wait completion pointer 71 (step 1011). After this, step 1
Jump to 006.

〔Effect of the invention〕

As explained above, according to the present invention, the lock processing is
/○/○, and it is possible to specify a detailed lock range by locking a part of the device rather than the entire device, and it is also possible to efficiently process only lock requests that do not require data transfer. Since it is executed frequently, the overhead of the computer system can be made very small.

[Brief explanation of drawings]

Fig. 1 is a relationship diagram of T/○ system lock processing system software showing an embodiment of the present invention, Fig. 2 is a block diagram of a computer system to which the present invention is applied, and Fig. 3 is a configuration of a local lock manager. 4 is a diagram showing the CCW chain of a lock request that involves data transfer in the present invention, and FIG. 5 is a diagram showing the CCW chain of a lock request that does not involve data transfer in the present invention. 6 is a diagram showing the lock acquisition request chain of the present invention; FIG. 7 is a diagram of the lock completion notification information chain of the present invention; FIG. 8 is a processing flowchart of the lock analysis unit in the present invention; 10 is a processing flowchart of the lock wait completion notification section of the present invention, and FIG. 10 is a processing flowchart of the global lock manager of the present invention. 10.11: CPU, 12, 13: Channel, 16: Control device, 18: I/○/○ group, 20, 23: Local
Lock Manager, 21, 24: User Program Group, 22.25: I10 Management Routine, 26: Global Lock Manager, 32.33: Virtual Device. Patent Applicant Hitachi, Ltd. Figure 1 Figure 2 Figure 3 10 Equipment Group Figure 5 Figure 6 Figure 7 Figure 8 Figure 9

Claims (4)

[Claims] (1) In a computer system equipped with a control device connected to multiple CPUs and a plurality of input/output devices connected to the control device, in each CPU there is a system 'from processing requests within each CPU'. When a control device has a local lock management routine that accepts lock requests for shared resources, and a global lock management routine that performs lock management of shared resources is provided in the control device, the local
Lock management routines allow the CC for normal data transfers to be
An input/output request is issued by chaining W and a CCW indicating a lock range independent of the range targeted for data transfer, and the lock range and data transfer range are separated on the control device side having a global lock management routine. An input/output lock processing method characterized by performing lock processing and data transfer processing. (2) In the case of issuing a lock request that does not involve data transfer, the lock processing is transmitted to the control device by issuing an input/output request to a virtual input/output device. The input/output system lock processing method described in item 1. (3) In the above-mentioned lock processing, when lock acquisition is not recognized, the corresponding input/output processing is immediately terminated and the input/output device that is the target of the input/output request is released. The input/output lock processing method described. (4) In the lock processing described above, when a request to receive notification that a lock acquisition request has been approved is issued, a virtual input/output device different from that for a lock request that does not involve data transfer is used to Claim 1 or 2 is characterized in that an input/output request is issued to an input/output device.
The input/output system lock processing method described in Section 1.