JPS6151245A - Deadlock detecting method in sequential request of resource - Google Patents

Abstract

PURPOSE:To prevent generation of deadlock state by providing a process identification table PID, a PID header and pointer so as to detect the possibility of deadlock state in advance when a sequential request of resource is issued. CONSTITUTION:Process identification tables PID14a-14d are connected to a PID header provided in the inside of a cental vector table CVT3 in an optional sequence. Further, the PID14a-14d represent a process of resource sequential request issue and is used to represent the relation between the process having a resource use right and the standby process. The PID14a-14d are formed by each one to a process issuing the resource sequential request and PID pointers 15a- 15d corresponding to the process being a cause are set in the PID when the process is in the resource standby state. Then, whether or not the pointer is in a loop is checked to detect the possibility of deadlock state generation in advance thereby preventing the deadlock from being generated.

Description

DETAILED DESCRIPTION OF THE INVENTION [Technical Field of the Invention] The present invention relates to a deadlock detection method during a resource serialization request in a multiple programming computer system.

[Prior art]

Conventionally, in a computer system under a multiple programming environment, there has been a method shown in FIG. 1 for serializing arbitrary resources. Figure 1 shows how each process, which is an independent processing unit, uses an arbitrary resource given an arbitrary name according to an arbitrary arrangement, with the aim of making exclusive use of the resource. This shows the method of serialization when a resource serialization request is issued, and the method is to serialize the resource name of the serialized resource by queuing the process that requests the serialized resource. It is. In this Figure 1, (la) and (lb) are processes that issue serialization requests, (Ja) and (2b)
is the control f-1 representing the arbitrary resource for which the serialization request was made.
，! 1/QcB (queue control block) (
3) is the central control table of the system, CvT (Central Vector Table), (riha. CB (2a)
, a header queuing (:lb), (5a).

(, tb), (tυ, (sd) is a QKL (QKL) that indicates the priority of resource use, request conditions, etc. for the process that issued the jt source serialization request. QCB (2a) corresponding to the resource, (
sb) according to the order of serialization. (
6) is the resource e of process A, (7) is the resource e of process B, C1,) is the resource e2 to the process, (9) is the acquisition request for the resource e of process B, and (
10) is the resource e to the process, , (//) is the resource e of process B, , (tx) is the resource e to the process, , (
tJ) respectively indicate process B's release request for resource e.

The serialization of resources begins with the acquisition of resources and ends with the release of resources. In Figure 1, process A has resource e, (
6) ~Cl0), requests serialization of resource e1 between (ff) and (/), and process B requests resource e, rough
3″～(′υ・ 7°・+<n-<ttn0～1″
Request for further development.

Next, the operation will be explained. Figure 1 shows the process (la)
, process B (lb) issues a serialization request for resource ei+er. That is, process A (
la), process B (lb) is (6).

It is assumed that ENQ macros, which are serialization requests, are issued in the order of (7) and CI). QCB header of CVT (,7) which is the central control table of the system (QCB of resource e2.e, which indicates the resource that is the target of the serialization request
(-2a), (cob) are created, and the process that issued the serialization request and the QEL of process A that indicates the priority of the request and the conditions of the request (ja), (yc), process B
QKL(Jb,) is created at the time of issuing each serialization request. QCB ('2a) indicating serialization request resource,
QEL (5a) connected to the beginning of (,2b) respectively
)'s process A has resource e7, QEL(Jb)'s process B has resource e7, and QEL(,!rb) has the usage right of 5[eyu].
Process A of QEL (!rd) connected to the back of
is in a waiting state for the resource e. At this point, when process B, which has the right to use the resource e, issues a DEQ macro (//) to relinquish the right to use the resource, a QFL indicating process B's right to use the resource e is issued. (Jb)
is deleted, and the QEL (,td) of process A becomes the first QEL of the QCB (yub) of the resource e, and the
You will be released from the waiting state for the right to use the service.

In this way, the serialization of arbitrary resources is realized.

However, in the conventional resource serialization processing method, process A (la) and process B (lb)
:When serialization requests are issued to L in the order of (su, (7')Aza), (?), the generated QcB
.

The relationship of Qi is as shown in Figure f, and process A uses resources e7. Process B has the right to use resource e1, process A has the right to use resource e, and process B has the right to use resource e.

They will have to wait until they receive the right to use it. That is, the first
In the sequential serialization request shown in the figure, process A ultimately waits for process B's resources, and process B
will cause a deadlock situation in which process A waits for resources to be used. Such deadlock conditions can also occur as a result of complex serialization requests in multiple process CCs, as shown in Figure 3. Inawachi, the number of processes A illustrated in FIG. 2(a),
In B, C, and D, process A first issues a request for resource e, and then process B issues a request for resource e.
Issuing request J, and so on, ■, ■.

Assuming that the predetermined requests are issued in the order of ■...■, process A waits for the resource eU that process B has the right to use, process B waits for the resource e3 that process C has the right to use, and the process C is resource e7 that process D has the right to use.
The process D then waits for the resource e that the process AK has the right to use, resulting in a deadlock situation as shown in FIG. 2(b). In order to prevent such a deadlock situation from occurring, it is necessary for the requester of the serialization request to determine the order in which resources are requested, and after a deadlock situation has occurred,
There were drawbacks to this deadlock, such as the need to forcefully release it by measuring the waiting time.

[Summary of the invention]

This invention was made in order to eliminate the drawbacks of the conventional method as described above, and when issuing a resource serialization request,
It is an object of the present invention to provide a detection method that detects in advance the possibility of a deadlock situation occurring and makes it possible to prevent the deadlock situation itself from occurring.

[Embodiments of the invention]

The method of the invention will now be explained with reference to FIG. In this FIG. 3, (2a), (b), and (c).

(Ud) is a control table QCB representing the resource that is the target of the serialization request, (3) is CVT which is the central control table of the system, (Ri is a header for queuing the QCB, Da), ( &b), (tc),
(rd).

De), Of), Dg), Oh) are Qllf with pointers indicating the priority of use for the resource for which the serialization request was made, the conditions of the request, and the request issuing process.
iL, each resource is queued in the QCB of its corresponding resource.

(/Fa), (/fb), (/Fc), and (/+d) are control table PIDs that indicate processes that have issued 9 serialization requests for resources, and are provided inside CVT (3,). PID headers (tS) in any order.

PID (Process identification table is used to indicate the process that issues the resource serialization request, as well as to indicate the relationship between the process that has the right to use the resource and the process that is in the waiting state. (ltaJ, (/&b) ).

(ltc) and (lya) are pointers indicating the waiting relationship between processes.

Next, the operation will be explained. In FIG. 3, processes A, B, C, and D have resources e,, e,, e,, e.

Issue the following serialization request to . First, a process person issues a serialization request to resource e, process B to resource eJ, process C to resource eJ, and process D to resource e7, respectively. Resource e 1 + 82.

QCB (yu a), (yu b), (-
For process A
has resource e, process B has resource e, process CI
It is shown that the process D has the resource e, and the PID (to be described later)
lta).

From the relationship between
Process C has resource θ, and process D has resource e.
, it is shown that it is in a waiting state. This state is a deadlock state in which multiple processes wait for each other's resources. Such a deadlock situation occurs when process D
This occurs when a request for serialization is issued to resource e7. To detect this deadlock condition,
P ID (/1lta) indicating the process requesting the resource
), (/Fb), C/1lc), (/!,
d) is created for each process that issued a resource serialization request, and in this P ID is used for the process that causes the process to be in a resource waiting state, that is, for the waiting resource. Pl, pointer to D corresponding to the process that has the right (isa), (tsb)<t
Set rc) and Ct left 6). And this P
Said boy/ri in ID (/j-a), (/, tb)
, (/70), (/&d) are in a loop state, a deadlock condition can be detected.

Assume that we are now at a stage before issuing a serialization request for process DfJ''-source e.At this time, the pointer (lta) corresponding to process A points to (141b) from P of process B, The pointer (/ffb) corresponding to process B points to the PID (l+c) of process C, and then the pointer (ltc) corresponding to process C
points to the PID (/4(d,)) of process D.Here, when process D issues a serialization request for resource e, the pointer (/1cl) corresponding to process D is transferred to process A. This means that a loop condition is established and a deadlock is detected.If a deadlock is detected in this way, the final cause of it is Reports an error without granting the request of the process (process D in this example).

In general, requests for serialization of resources include a method of hierarchizing arbitrary resources into one person and a subname in order to speed up the process, or setting a shared use condition in addition to exclusive use as a requirement condition, so that the same resource can be used at the same time. There is a system that allows the existence of a plurality of processes having equal rights to use a resource, and the method for detecting deadlock in advance according to the present invention can be applied to any of them.
show.

〔Effect of the invention〕

As described above, according to the present invention, for arbitrary resources,
Since the occurrence of a tedlock state can be detected in advance when issuing a serialization request, it is possible to issue a serialization request without any other restrictions even if it is impossible to predict the level of resource requests in advance.

[Brief explanation of drawings]

Figure 1 is an explanatory diagram of the conventional resource serialization method, and Figure 2 is
FIG. 3 is an explanatory diagram of the occurrence of a tedlock state, and is an explanatory diagram of the resource serialization method according to the embodiment of the present invention. 2a-yud; QCLI (queue control block), 3; CV'L'' (central vector table), ri; QCB header', ja~jh; Q
EL (cue element list), lpa・~/4
'd; PID (process identification table, lj; PI
D header, /! r a S-/k d; pointer, A, B, C. D; Process, e7-e2; Resource. In each figure, the same reference numerals refer to the same numbers or corresponding parts to the 1st ward, 2nd ward (q) (b) Guan 3 figure

Claims (2)

[Claims] (1) When multiple processes make serialization requests to any resource in any order, a process that currently has usage rights to a certain resource and a serialization request to the resource are A relationship between a different process that issues a resource and enters a waiting state is determined, and each time a serialization request for a resource is issued, the relationship is examined to detect whether or not a deadlock has occurred. Deadlock detection method for serialization requests. (2) The resource according to claim 1, wherein when the occurrence of deadlock is detected as a result of the investigation of the relationship, the serialization request that causes the deadlock is not permitted and an error is reported. Deadlock detection method for serialization requests.