JP2850863B2 - Exclusive control unit - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an exclusive control device for a computer system, and more particularly to an exclusive control device for performing a deadlock check process asynchronously with a lock request command from a host computer.

[0002]

2. Description of the Related Art In a conventional exclusive control device provided independently of a host computer, when a lock request is issued from a certain host computer, it is first determined whether or not lock is possible. Then, if the lock is possible, the lock is permitted. If the lock is not possible, it is checked whether or not a deadlock occurs due to the lock request waiting for the lock. Waiting registration of the lock request is refused, and if no deadlock occurs, the lock request is waited and registered. When the cause of the waiting lock request has disappeared (for example, when the host computer which previously locked the resource releases the lock on the resource), the lock request registered in the waiting state is issued. , And notify the requesting host computer by attention. As described above, the conventional exclusive control device immediately determines whether a deadlock occurs due to waiting and registering a lock request from a certain host computer when the exclusive control device receives the lock request. I was trying to check.

[0003] Here, a lock request means that in a situation where a plurality of host computers share resources such as a disk device and a memory device, a certain host computer has a certain resource (for example, a specific resource in the disk device). Requesting exclusive use right when it is necessary to exclusively use the file), and a state in which exclusive use is permitted under certain conditions is called resource locking.

[0004] Deadlock refers to the following state. For example, in a state where the host computer A locks the resource α and is waiting for the lock on the resource β at the same time, the host computer B locking the resource β requests the lock on the resource α and waits for the lock. Then, since neither of the host computers A and B can successfully release the locked resource until the lock requesting resource is successfully locked (until all necessary resources can be locked, Since the processing is not completed), neither of the host computers A and B can continue the processing. This state is called deadlock, and in the conventional exclusive control device, as described above, before waiting and registering a lock request, a deadlock check is performed, and after confirming that no deadlock occurs, waiting registration is performed. Was.

In the above description, the request source of the lock request is a host computer for the sake of simplicity. However, in a general computer system, a processing unit of software called a process or a task is usually performed. The deadlock described above also occurs due to contention of lock requests output from a plurality of processes and the like in the same host computer. It is not unusual for the relationship to wait and wait in order.

A deadlock check for checking a deadlock is such that when a certain lock request is waiting, the lock source of the resource requested by the lock request is waiting for a lock on another resource. In order to determine whether or not there is a closed loop that causes the lock by the request source of the lock request that eventually triggered the deadlock check, the closed loop is regarded as deadlock. Here, the cause of the lock request waiting has been described above as being the case where there is a host computer that has previously locked the requested resource. In general, there are several lock levels, such as a lock and a shared lock that permits a plurality of processes performing only read access at the same time to lock a file resource. Therefore, the above-described deadlock check requires not only searching a single loop but also branching one after another as the search progresses, and checking all of them.

Also, during execution of the deadlock check, if the state of the table changes due to a lock or unlock from another process due to the deadlock check, it is obvious that correct deadlock check cannot be performed. In the conventional exclusive control device, during the deadlock check processing for a certain lock request, all other lock requests and unlock requests are made to wait at the time of command reception processing from the host computer.

[0008]

In the above-mentioned prior art, the exclusive control device receives a lock request from a host computer as to whether or not deadlock occurs due to waiting for a lock from the lock request. In such a case, the check is performed immediately, and therefore, there is a problem that the deadlock check processing becomes a bottleneck and the performance of the entire system is reduced. In other words, a lock request from a certain host computer waits for a lock, and if deadlock check processing is performed on the request, other lock requests cannot be processed during that time.

It is an object of the present invention to provide an exclusive control device capable of improving the performance of the entire system by preventing deadlock check processing from becoming a bottleneck.

Japanese Patent Application Laid-Open No. 1-223558 discloses that
In a system composed of a plurality of host computers, waiting information for exclusive control from the first wait state of a transaction by exclusive control to the occurrence of a wait state until a predetermined time elapses is collectively transferred to one host computer. Although a technique for collecting deadlocks is disclosed, this technique has a problem that a load on a host computer increases.

[0011]

SUMMARY OF THE INVENTION The present invention achieves the above objects and provides a deadlock check for each lock request command.
Check after a lapse of the specified time or immediately
In order to enable control, a lock request command from the request source is accepted, it is determined whether or not the resource can be locked in response to the lock request by the lock request command . The lock request frame
Perform a deadlock check synchronously with the command
It is determined whether or not the instruction is included, and the instruction is included.
If it is determined that it is not locked, it is determined that lock is not possible
Outputs a lock request and determines that the instruction is included.
If the lock request waits for a lock,
An instruction to check whether a lock occurs
Output and the check result indicates that deadlock may occur.
Indicates a deadlock to the requestor.
Notification that a deadlock does not occur.
The timer processing is unnecessary.
A lock request command processing unit which outputs the lock request as well as the force, as well as the lock wait a lock request that is outputted from the lock request command processing section, the locking
Timer processing may not be required from the request command processing unit
If not instructed, start of timer processing for the event waiting for the lock is instructed, and the lock request command is issued.
The processing unit indicates that timer processing is unnecessary.
If the timer processing is
A lock wait queue processing unit that does not instruct start, a timer process is started for an event for which the start of timer processing is instructed by the lock wait queue processing unit, and a timer process of the events that started the timer process is started. A timer processing unit that times out an event after a predetermined period of time has elapsed, and checks whether a deadlock has occurred for the event that has been timed out by the timer processing unit, and executes the lock request command processing. Finger from department
And a attention processing means for notifying the request source of the occurrence of deadlock when the deadlock check processing unit detects a deadlock.

In this configuration, the lock request command processing section determines whether or not the resource can be locked in response to the lock request by the lock request command, and determines that the lock is not possible.
If a judgment is made, the lock request command is added to the request.
Instructions to perform a deadlock check in anticipation
Is determined. And the instructions are not included
If it is determined that the lock is not possible,
Output the request. As a result, the lock waiting queue processing unit sets the lock request determined to be impossible to lock to the lock waiting state, and instructs the timer processing unit to start timer processing for the lock waiting event. Upon receiving this instruction, the timer processing unit starts timer processing, and sets an event in which a predetermined time has elapsed as a timeout. The deadlock check processing unit checks whether a deadlock has occurred for an event that has timed out.

On the other hand, synchronization with the lock request command
Includes instructions to perform a deadlock check
If the lock request command processing unit determines that the
Immediately, the deadlock check
Deadlock occurs when waiting for a lock request
Indicates that a check should be made. In response to this
Deadlock check processing block performs deadlock check
Do. Deadlock occurred in deadlock check processing section
If it is determined not to be generated, the lock request command processing unit
Sends the lock request to the lock wait queue processing unit.
Notify and indicate that timer processing is not required
You.

In the above-mentioned second configuration, if the resource cannot be locked for the lock request command and the lock request command includes designation of time, the timer initial value setting processing unit performs Notify the timer processing unit of the time,
The timer processing unit sets a time-out for an event for which time has been notified from the timer initial value setting processing unit when the notified time has elapsed.

Further, according to the present invention, in order to control whether a deadlock check is performed after a lapse of a predetermined time or immediately after each lock request command, the lock request command processing in the first configuration described above is performed. The department is
If the resource cannot be locked in response to a lock request by a lock request command from the request source, and the lock request command includes an instruction to perform a deadlock check in synchronization therewith, If the deadlock check processing unit instructs the lock request to wait for a lock to check whether a deadlock occurs, and if the check result indicates that a deadlock occurs, When the deadlock occurrence is notified to the request source and the deadlock does not occur, the lock wait queue processing unit is instructed that timer processing is unnecessary, and the lock request is issued. It has a timer operation control processing unit that outputs,
The deadlock check processing unit has a configuration for performing a deadlock check in accordance with an instruction from the lock request command processing unit, and the lock waiting queue processing unit does not need timer processing from the timer operation control processing unit. A configuration is provided in which the start of timer processing is not instructed for an event for which there is an instruction.

In the third configuration described above, the lock request command includes an instruction to perform a deadlock check in synchronization with the lock request command, and the lock request cannot lock resources. In this case, the timer operation control processing unit immediately instructs the deadlock check processing unit to check whether a deadlock occurs when waiting for the lock request. In response, the deadlock check processing unit performs a deadlock check. If the deadlock check processing unit determines that no deadlock occurs, the timer operation control processing unit notifies the lock waiting queue processing unit of the lock request and indicates that timer processing is not required.

[0017]

Embodiments of the present invention will now be described in detail with reference to the drawings.

FIG. 12 is a block diagram showing a typical example of a computer including the exclusive control device of the present invention. The host computers A and B share one disk device 12, and the exclusive control device 11 performs lock control for exclusive use of the disk device 12 in accordance with commands from the host computers A and B.

Hereinafter, the exclusive control device of the present invention will be described in detail with reference to the example shown in FIG. 12. However, the exclusive control device of the present invention includes a host computer including a single host computer. Not depend on the number of
It goes without saying that the resources to be subjected to the exclusive control are not limited to the disk devices but to all resources shared and used by a plurality of host computers or software processing units such as a plurality of processes in the host computers.

FIG. 1 illustrates a technique on which the present invention is based .
A host interface processing unit 1, a lock request command processing unit 2, an attention processing unit 3, a lock management table 4, a lock waiting queue processing unit 5, a timer processing unit 6, a deadlock And a check processing unit 7.

The host interface processing unit 1 manages a physical and logical interface between the host computer A and the host computer B. The lock request command processing unit 2 updates the lock management table 4 according to the lock request commands received from the host computers A and B via the host interface processing unit 1. If the lock cannot be locked immediately, the lock waiting queue processing unit 5 is requested to perform the processing. The timer processing unit 6 performs timer processing for each event notified from the lock waiting queue processing unit 5, and when a predetermined time has elapsed (when a timeout occurs), a deadlock check process is performed on the event that has timed out. Notify the unit 7. The deadlock check processing unit 7 checks whether a deadlock has occurred for the notified event, and if a deadlock has occurred, notifies the request source via the attention processing unit 3 of the occurrence of the deadlock. Notice.

FIG. 2 is a flowchart showing a processing example of the lock request command processing unit 2, FIG. 3 is a flowchart showing a processing example of the lock waiting queue processing unit 5, and FIGS. FIG. 6 is a flowchart showing the deadlock check processing unit 7.
FIG. 7 is a diagram showing how the contents of the lock management table 4 change. Hereinafter, the operation of this embodiment will be described with reference to the drawings. In this embodiment, each processing unit is configured by software, but a part or all of the same functions can be realized by hardware.

Now, it is assumed that a lock request command requesting the lock of the resource α is output from the process a of the host computer A to the exclusive control device 11. At this time, it is assumed that the resource α is not locked.

This lock request command is sent to the lock request command processing unit 2 via the host interface processing unit 1.
To be notified.

Thus, the lock request command processing unit 2
Starts the process shown in the flowchart of FIG. 2, and first checks with reference to the lock management table 4 whether or not the resource α is already locked (S1, S2). In this example, since the resource α is not locked (NO in S2), the host interface processing unit 1 stores the resource α in the lock management table 4 as shown in FIG.
As shown in (A), information 41 indicating that the resource α has been locked by the process a of the host computer A is registered, and then the lock request is notified to the requesting process a via the host interface processing unit 1. (S3
S4). In this embodiment, it is assumed that the lock is a completely exclusive lock that permits a lock only for a single process.

Thereafter, it is assumed that a lock request command for requesting the lock of the resource β is output from the process b of the host computer B to the exclusive control device 11. At this time, it is assumed that the resource β is not locked.

This lock request command is sent to the lock request command processing unit 2 via the host interface processing unit 1.
Will be notified.

As a result, the lock request command processing unit 2
Performs the same processing as described above, and registers information 42 indicating that the resource β has been locked by the process b of the host computer B in the lock management table 4 as shown in FIG. Then, the lock permission is notified to the requesting process b via the host interface processing unit 1 (S1 to S4).

Thereafter, it is assumed that the command requesting the lock of the resource β output from the process a of the host computer A is notified to the lock request command processing unit 2 via the host interface processing unit 1.

In this case, by referring to the lock management table 4, it is known that the resource β has already been locked by the process b of the host computer B (S1, S2), so that the lock request command processing unit 2 The lock request by the lock request command is not permitted, the lock request is notified to the lock waiting queue processing unit 5, and the lock request is put into the lock waiting state to the requesting process a via the host interface processing unit 1. Is notified (S5, 6).

When a lock request is notified from the lock request command processing unit 2, the lock waiting queue processing unit 5
As shown in (C), information 4 indicating that the process a of the host computer A is waiting for the release of the resource β.
3 is registered in the lock management table 4, and the timer processing unit 6 is notified of an event that the process a of the host computer A is waiting for the release of the resource β (FIG. 3, S11,
S12).

The timer processing unit 6 determines whether the event β, wa
When it is notified that it = A (a), the event is registered in the timer management table 61 provided therein in association with the predetermined time Ti, as shown in FIG. (S21 in FIG. 4). The timer processing unit 6
FIG. 5 shows that every time a fixed time ΔT (ΔT≪Ti) elapses.
As shown in (3), ΔT is subtracted from the remaining time of each event, and if there is an event whose remaining time is 0 or less, that is, if there is an event that has timed out, the event is output to the deadlock check processing unit 7. Processing is also performed (FIG. 5, S3
1, S32). It should be noted that information on the event that the remaining time has become 0 or less is deleted from the timer management table 61.

Thereafter, the above-mentioned event β, wait = A
Before (a) times out, the host computer B
If the lock request command for requesting the lock of the resource α is output from the process b of the host computer A, since the resource α has already been locked by the process a of the host computer A, the lock request command processing unit 2 The lock wait queue processing unit 5 notifies that the lock request has become a lock wait (S6 in FIG. 2).
As shown in (4), information 44 indicating that the process b of the host computer B is waiting for the release of the resource α is registered in the lock management table 4, and the process b of the host computer B An event α, wait = B (b) indicating that α is waiting to be released is notified (FIG. 3, S11, S12).

Thereafter, a predetermined time Ti elapses, and the events β,
When wait = A (a) times out, the timer processing unit 6 outputs the above event to the deadlock check processing unit 7 (FIG. 5, S31, S32).

The deadlock check processing unit 7 checks whether or not a deadlock has occurred for the output event β, wait = A (a) by referring to the lock management table 4 (FIG. 6, S41, S41). S42). In this example, the resource β waiting for the process a of the host computer A to be released is the resource locked by the process b of the host computer B.
Process b of the host computer A is waiting for the release of the resource α locked by the process a of the host computer A. Therefore, the deadlock check processing unit 7 determines that the process a of the host computer A and the process b of the host computer B are dead. It is determined that the lock has occurred (YES at S42),
This is notified to the attention processing unit 3 (S4
3).

Upon receiving this notification, the attention processing unit 3 notifies the process a of the host computer A of the occurrence of the deadlock via the host interface processing unit 1. In a general computer system, a process notified of occurrence of a deadlock stops execution and releases all locked resources. In this embodiment, the process a of the host computer A notified of the occurrence of the deadlock
Releases the lock on the resource α. As a result, the lock waiting queue processing unit 5 permits the process b of the host computer B to lock the resource α, and notifies the timer processing unit 6 of the timer for the event waiting for the resource α of the process b of the host computer B. Instructs to stop processing.
Upon receiving this instruction, the timer processing unit 6 deletes information on the above event from the timer management table 61.

In the above description, when a deadlock occurs, only the process a of the host computer A is executed.
Notifying that a deadlock has occurred, and requesting release of the locked resource,
The deadlock occurrence may be notified to the process b or to all the processes that have become deadlock.

[0038]

[0039]

[0040]

[0041]

[0042]

[0043]

[0044]

[0045]

[0046]

[0047] Figure 9 is a block diagram of a real施例of the present invention, 1 in that, a lock request command processing section 2b having a timer operation control unit 22 in place of the lock request command processing section 2 point, point with a lock queue processor 5b instead of lock queue processor 5, data
The difference is that a timer processing unit 6a is provided in place of the image processing unit 6, and a deadlock check processing unit 7b is provided in place of the deadlock check processing unit 7. Note that the same reference numerals as those in FIG. 1 indicate the same parts.

The timer operation control processing section 22 in the lock request command processing section 2b notifies the timer processing section 6a of the specified time when the lock request command determined to be unlockable includes designation of time. function, if it contains the specified synchronization in the lock request command it is determined that the lock not may check whether or not a deadlock when the lock wait the lock request occurs for deadlock check processing section 7 b instructing to perform the function, if the deadlock check processing portion 7 b of the check result indicates that a deadlock occurs, notifies the deadlock to the requesting, a deadlock does not occur Indicates that the lock waiting queue processing unit 5
b has a function of instructing that the timer processing is unnecessary and outputting the lock request. Also Thailand
The timer processing unit 6a receives the time from the timer operation control processing unit 22.
For the notified event, a predetermined time
Instead, the event occurs when the notified time elapses
Output function.

The deadlock check processing unit 7b has a function of performing a deadlock check when an event is output from the timer processing unit 6a and when a deadlock check is instructed from the timer operation control processing unit 22.

When it is not instructed from the timer operation control processing section 22 that the timer processing is unnecessary, the lock waiting queue processing section 5b responds to the lock request notified from the lock waiting queue processing section 5b as described above. The same processing as that performed by the lock wait queue processing unit 5 is performed. If it is instructed that the timer processing is unnecessary, only the update processing for the lock management table 4 is performed.

FIG . 10 shows a processing example of the timer processing section 6a.
FIG. 11 is a flowchart showing a processing example of the timer operation control processing section 22, and the operation of the present embodiment will be described below with reference to the drawings.

When the lock request command processing unit 2b can lock the resource in response to the lock request by the lock request command notified via the host interface processing unit 1, the lock request command processing unit 2b
The same processing as in step 2 is performed. If the lock is not possible,
It passes control to the timer operation control processing unit 22 to perform the processing shown in the flowchart of FIG 11.

When the control is passed, the timer operation control processing section 22 determines whether or not a time designation is included in the lock request command (FIG. 11 , S71). If the designation of the time is included (YES in S71), the time is notified to the timer processing unit 6a (S72).
The lock request is notified to the lock waiting queue processing unit 5b, and the request source is notified that the lock request is waiting for the lock (S78, S79). This ensures that the lock wait queue processing unit 5 lock wait queue processing unit 5b described above
The same processing is performed. Also, the timer processing unit 6a
0, as shown in the flowchart of FIG.
When the event is notified from the timer operation control processing unit 22
If the time has been notified (YES in S61), the
Timer management table in which the known event is associated with the time
61 is registered (S62), and the time is not notified.
(NO in S61) is determined in advance as the notified event.
Timer management table 6
1 (S63). In this case, the timer is activated
Since the time has been notified from the control processing unit 22, the timer
The processing unit 6a associates the notified event with the time, and
It will be registered in the image management table 61. In addition, Thailand
The processing section 6a is the same as the timer processing section 6 in FIG.
And the remaining time has become 0 or less.
Output the elephant to the deadlock check processing section 7b.
You.

If the lock request command includes a synchronization designation (YES in S73), the lock request command processing unit 2 immediately sends the lock request to the deadlock check processing unit 7b. When waiting for a lock, an instruction is issued to check whether a deadlock occurs (S74).

In response to this instruction, the deadlock check processing section 7b performs a deadlock check and notifies the timer operation control processing section 22 of the result.

If the check result indicates that a deadlock has occurred (YES in S75), the timer operation control processing section 22 notifies the request source of the occurrence of the deadlock via the host interface processing section 1 (S76). If no deadlock is indicated (NO in S75), the lock request processing unit 5b instructs the lock wait queue processing unit 5b not to perform the timer process, and then passes the lock request to the lock wait queue processing unit 5b ( (S77, S78), and then notifies the request source that the lock has been waited. (S79).

When the lock request is passed after the instruction not to perform the timer processing, the lock waiting queue processing section 5b performs only the update processing of the lock management table 4 and starts the timer processing for the timer processing section 6a. No instructions are given.

As described above, since the present embodiment includes the lock request command processing unit 2b and the timer processing unit 6b,
The deadlock check synchronized with the lock request command can be performed, and the deadlock check can be performed at a timing asynchronous with the lock request command.

[0059]

As described above, according to the present invention, the lock
Ri Do the lock request is a lock wait by the request command, 且
One of the above lock request commands
If you do not include instructions to perform a check,
Since the deadlock check is performed for the event after the lapse of the predetermined time, the processing of the subsequent lock request is not waited for by the deadlock check, and as a result, the processing performance of the computer system can be improved. Further, before the predetermined time has elapsed,
When a lock request waiting for a lock becomes lockable, deadlock check itself can be dispensed with, so that the load on the exclusive control device can be reduced and the throughput of the exclusive control device can be increased.

[0060]

The present invention also provides a lock request command
If the instruction to perform the deadlock check in synchronization with the lock request command is included, and the resource cannot be locked for the lock request, immediately wait for the lock request to the deadlock check processing unit. Since the timer operation control processing unit for instructing to check whether a deadlock occurs is provided, it is possible to control whether the deadlock check is performed after a predetermined time elapses or immediately for each lock request command. . Therefore, if the request source is a system that requires a high-speed response such as the TSS, the lock request command may include an instruction to perform a deadlock check in synchronization with the request, and may be flexible according to the characteristics of the request source. System operation becomes possible.

[Brief description of the drawings]

FIG. 1 is a block diagram for explaining a technique which is a premise of the present invention.

FIG. 2 is a flowchart illustrating a processing example of a lock request command processing unit 2;

FIG. 3 is a flowchart illustrating a processing example of a lock waiting queue processing unit 5;

FIG. 4 is a flowchart illustrating a processing example of a timer processing unit 6;

FIG. 5 is a flowchart showing a processing example of a timer processing unit 6;

FIG. 6 is a flowchart illustrating a processing example of a deadlock check processing unit 7;

FIG. 7 is a diagram showing how the contents of the lock management table 4 change.

FIG. 8 is a diagram showing a content example of a timer management table 61;

FIG. 9 is a block diagram of an embodiment of the present invention .

FIG. 10 is a flowchart showing a processing example of a timer processing unit 6a .
You.

FIG. 11 is a flowchart showing a processing example of a timer operation control processing unit 22 ;

FIG. 12 shows a computer system to which the present invention is applied .
It is a block diagram showing an example .

[Explanation of symbols]

1 ... host interface unit 2 ... lock request command processing section 3 ... Attention processor 4 ... lock management table 5 ... lock queue processor 6 ... timer processing unit 61 ... timer management table 7 ... deadlock check processing unit 6 a ... Timer processing unit 2b Lock request command processing unit 22 Timer operation control processing unit 5b Lock wait queue processing unit 7b Deadlock check processing unit 11 Exclusive control unit 12 Disk device A, B Host computer

──────────────────────────────────────────────────続 き Continued on the front page (58) Field surveyed (Int.Cl. ⁶ , DB name) G06F 9/46 G06F 11/30 G06F 12/00 G06F 15/16 G06F 3/06 G06F 13/14

Claims (1)

(57) [Claims] 1. A accepts the lock request command from the request source, and determines whether it is possible to lock a resource with respect to the lock request by the lock request command, if it is determined that the lock impossible, further, the locking With it to the request command
Includes instructions for performing synchronous deadlock checks
It is determined whether or not the instruction has been included.
If determined, the lock request that is determined to be impossible to lock
Output, and if it is determined that the instruction is included,
Deadlock occurs when a lock request is made to wait for a lock
Output an instruction to check whether or not to
The check result indicates that a deadlock occurs
The deadlock has occurred to the requestor.
And that no deadlock occurs
Outputs an indication that timer processing is not required.
Wherein the lock request command processing section for outputting a lock request, as well as the lock wait a lock request that is outputted from the lock request command processing section, the lock request command processing
Has not indicated that timer processing is unnecessary.
If the lock request command processing unit issues a timer
If it is indicated that no processing is required,
Do not give an instruction to start timer processing for an event waiting for lock.
A lock wait queue processing unit, and a timer process is started for an event for which the start of timer processing is instructed by the lock wait queue processing unit. a timer unit for the event a certain time has elapsed which is a time-out, as for the event is timed out by said timer processing unit checks whether a deadlock is occurring co
In accordance with the instruction from the lock request command processing unit
Exclusive control comprising: a deadlock check processing unit for performing a deadlock check; and attention processing means for notifying the request source of the occurrence of a deadlock when the deadlock check processing unit detects a deadlock. apparatus.