JPH06337798A - Deadlock detecting device - Google Patents

Abstract

PURPOSE:To provide an efficient deadlock detecting method. CONSTITUTION:A multitask system, having a task management part(TM) 102 for executing plural tasks 100 in parallel and a lock management part(LM) 103 managing that which task 100 occupies (locks) which resource 101, is provided with a wait management table (LT) 105 and also provided with a deadlock detection part(DD) 104 which registers 'wait relation' of the respective tasks 100 in the management table (LT) 105 and performs asynchronous operation separately from the lock management part 103. Then the deadlock detection part(DD) 104 detects a deadlock from the 'wait relation' registered in the wait management table (LT) 105. Further, a timer is provided with and re-issues a resource acquisition request to a task which is still in wait relation, thereby giving a change of deadlock detection again. Further, information communication for deadlock detection in a distribution system is reduced as much as possible.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a deadlock detecting device in a multitasking system.

[0002]

2. Description of the Related Art In recent years, in an information processing system using a computer, a multi-task system for simultaneously executing a plurality of tasks or transactions has been developed. A task is a unit of work inside the CPU. A transaction is a collection of operations that perform one complete data operation. Multitasking is multiple programs (tasks, transactions)
Is a state in which it is simultaneously executed in parallel on a single computer system or a plurality of computer systems connected to each other so that information can be exchanged with each other.

In this multitasking system, two or more tasks may share resources. In that case, a case may occur in which two or more tasks each occupy (lock) a plurality of resources that are necessary to execute that tax and also to execute the other tax. In that case, the other task waits for the resource occupied (locked) by the other tax, so both tasks are stopped, and the process cannot be executed any more. Such a state is called a deadlock state.

FIG. 3 shows an example of a deadlock state.
The example of FIG. 3 shows an example in a distributed system including two computer systems i and j. Task x is executed on one computer system i, and task y is executed on the other computer system j. It is also assumed that there are two resources A and B that can be accessed by each computer system i and j. The resource refers to software such as programs, files, and data assigned to tasks. Here, the contents (pages, records, etc.) of the database existing outside each computer system i, j will be described.

In FIG. 3, task x has locked resource A and task y has locked B. At the same time, task y also needs resource A, so it is waiting to lock resource A. Similarly, task x also needs resource B, so it is waiting for resource B to become lockable. In this case, task y cannot lock resource A unless task x unlocks resource A. On the other hand, task x cannot lock resource B unless task y unlocks resource B. As a result, the tasks x and y wait for A and B locked by each other and stop. When both tasks x and y are stopped, the resources A and B that are already locked by each task cannot be released, and this state continues forever. Therefore, each task cannot execute any more processes.

Such a deadlock is due to whether the computer system is a multiprocessor system or a single processor system, or
This is a problem that can occur if the system is a multi-task system regardless of whether the computer system is operated as a stand-alone system or constitutes a distributed processing system.

When such a deadlock occurs, it is necessary to take measures to repair it. For that purpose, it is necessary to detect that a deadlock has occurred as a premise.

Deadlock detection is required to meet the following specifications for the purpose of improving practicality. First, it is necessary to prevent the detection of a phenomenon of erroneously recognizing a deadlock even though it is not a deadlock, that is, a pseudo deadlock (first request).

Second, all deadlocks must be detected. In other words, when a deadlock actually occurs, there must be no deadlock detection time and no deadlock detection time, and all deadlock detection must be performed (second request). ).

Third, the influence on the system due to the deadlock detection must be suppressed to a small level. That is, it is necessary to avoid stopping the task to detect the deadlock (third request).

When implementing a multitasking system on a distributed processing system, the following specifications are required in addition to the above requirements. That is, it is necessary to communicate between the systems in order to detect the deadlock, but the overhead of this communication must be reduced as much as possible (fourth request).

In the conventional deadlock detecting device, the deadlock is detected by satisfying the following conditions and satisfying the first to third requirements described above. The conditions are: (a) The asynchronous abort (abnormal end) of the transaction does not occur,
(b) When implementing a multitasking system on a distributed processing system, communication messages between systems should not be delayed or lost, and (c) Transaction wait relations during deadlock detection should not be changed.

(D) When the multitask system is realized on the distributed processing system, the asynchronous down of the system does not occur.

The relationship between the above-mentioned first to third requirements and the conditions (a) to (d) will be described. Regarding the condition (a), when an asynchronous abort (abnormal end) of a transaction occurs, a pseudo deadlock (p
It is not possible to prevent the detection of hunt deadlock). For example, task (transaction) x
Is locked by resource A, and task (transaction) y is locked by resource B. When task y waits for resource A and task x issues a wait request to resource B, task y is asynchronous. Suppose it ended abnormally.
In this case, the lock of the resource B by the task y is released by the asynchronous end of the task y.
Can be locked. Therefore, the deadlock should not occur normally. However, since the unlocking of the resource B due to the asynchronous abend of the task y cannot be immediately detected, in reality, it is treated as if a deadlock has occurred even though the deadlock has not occurred.

With respect to the condition (b), if the system goes down asynchronously, deadlocks may or may not be detected, so that it is not possible to detect all deadlocks in the second request. The reason is that in a distributed processing system, common resources are accessed by communication between systems, but if the transmission of the communication message is delayed or disappears due to communication error, a deadlock occurs. This is because it is unknown.

Similarly, with respect to the condition (d), if a communication message between the systems is delayed or lost, a deadlock may be detected and a deadlock may not be detected.
Cannot detect all deadlocks in the request. This is because if one system is down while the other system is operating, management information related to tasks in the system will be lost and deadlock detection cannot be determined.

Further, regarding the condition (c), if the transaction wait relation is changed during the deadlock detection, the information about which task actually locks which resource is confused. The second requirement cannot be met.

[0018]

However, the condition (c) is to prohibit all occurrence of new transactions (tasks) and wait relations during deadlock detection. That is, it is a condition that it is necessary to temporarily stop the request reception in the system in order to detect the deadlock. Therefore, even if there is a task that makes a request to a resource that is not originally related to deadlock (that resource is assumed to be resource Z), the request must be stopped. Therefore, if this condition (c) is pursued, the smooth operation of the system cannot be achieved, and the third requirement cannot be satisfied.

In reality, it is impossible to prevent the detection of the pseudo deadlock caused by the condition (a). That is, it is impossible to predict what kind of abnormality will occur in each system and avoid all of them, and it is impossible to prevent the task from abnormally ending asynchronously.

Therefore, in view of the above problems, the first technical problem of the present invention is that the deadlock detection can be continued even if the transaction waiting relation is changed during the deadlock detection, and the deadlock detection can be performed by the deadlock detection. An object of the present invention is to provide a deadlock detection device that can reduce the influence on the system due to the operation.

A second technical object of the present invention is to wait for a transaction during deadlock detection in a deadlock detection device for a distributed processing system when a communication message between the systems is delayed or lost. Whether there is a change in the relationship or when an asynchronous down of the system occurs, all deadlocks can be detected, pseudo deadlocks are not detected, communication overhead can be reduced as much as possible, deadlock detection It is another object of the present invention to provide a deadlock detection device that can reduce the influence on the system due to the above.

[0022]

In order to solve the first problem, the present invention adopts the following means as shown in the principle diagram of FIG.

<Summary of the Present Invention> That is, a plurality of tasks 10
0 is a deadlock detection device for detecting a deadlock in which a plurality of tasks 100 wait and stop resources 100 occupied by each other in a multi-task system using a common resource 101. In order to execute the tasks 100 in parallel,
Task management unit (TM) 102 that manages the execution of a task, a lock management unit (LM) 103 that manages which resource 100 each task has locked, and a resource that one task has locked by another task When the acquisition request is made, the one task is assumed to be waiting for the other task, and the "wait relationship" of each task is registered in the wait management table (L
T) 105 and the lock management unit (LM) 103 operate asynchronously, and the waiting management table (LM)
A deadlock detection unit (DD) 104 that detects a deadlock from the “wait relationship” registered in 103 is provided.

The outline of the components of the present invention and the points thereof will be briefly summarized below.

[Task] "Task" usually means a unit of work in the CPU. In the present invention,
"Task" can be restated as "transaction". The "transaction" means a collection of operations for performing one complete data operation, is a concept included in the "task", and is executed by a program. In essence, the present invention seeks to detect when a plurality of programs execute concurrently in parallel, each program sharing resources and entering a locked state. Therefore, whether the term “task”, the term “transaction”, or the term “execution unit of a program” is used in the present invention, the difference in terms is not a particular problem. I won't. Less than,
There is no problem in implementing the present invention even if it is understood that “task” = “transaction”. Further, in the present invention, the resource shared by each task is a file that is a set of data, a record recorded in the lower layer of the file, or the like. In the present invention, a lock means that a certain task or transaction occupies the entire file or a certain record under the file.

[Deadlock Detection] Deadlock detection in the deadlock detection unit (DD) 104 is performed by, for example,
You can do the following: That is, the occupation relationship between the task (transaction) and the resource, that is, the “waiting relationship” is registered by the waiting management table (LT) 105. The deadlock detector (DD) 104 looks at the waiting management table (LT) 105 to detect a deadlock. This detection is performed separately from the lock management by the lock management unit (LM) 103. Preferably, when the lock management unit (LM) 103 detects that "a task has entered a" wait relationship "for a resource", the deadlock detection unit (DD) 104 waits for the "wait relationship". Request to register in the table (LT) 105. Then, the presence or absence of deadlock is determined by referring to the registered content.

The following method is suitable as a method for registering a transaction wait relationship in the wait management table (LT) 105 for detecting deadlock. That is, the transaction wait relationship is represented by a graph.
This graph is the weight for graph (WF
G: Wait-for graph). This graph is registered in the waiting management table (LT) 105.

In this graph, transaction x generated in system i is defined by T (i, x), and transaction y generated in system j is defined by T (j, y). Also, T (i, x) waits for T (j, y), that is, T (i, x) waits for T (j, y) to release the locked resource. i, x) → T (j, y). In this case, T (i, x) cannot proceed any further until T (j, y) has finished.

When T (i, x) → T (j, y) and T (j, y) → T (i, x) are satisfied at the same time, T (i, x) → T (j, y) → A loop called T (i, x) is formed. In this case, since the deadlock state is set, the deadlock can be detected by detecting this loop.

By the way, the above is a description of an example of deadlock detection between two systems. Deadlock within the own system is T (i, x) → T (i, y) → T (i, x).

A feature of the present invention is that the task management unit (TM)
102, a lock management unit (LM) 103, etc., a deadlock detection unit (D
D) 104 is provided in the system (i, j), and the deadlock detection unit (DD) 104 is operated asynchronously with the lock management unit (LM) 103.

In the conventional deadlock detection method,
Execution of each task was temporarily stopped to detect deadlock. In the meantime, the lock management unit (L
M) The presence or absence of deadlock is determined based on the lock information in 103. However, this cannot ensure the smooth execution of the task.

On the other hand, according to the present invention, a wait management table (LT) separated from the task management unit (TM) 102 and the lock management unit (LM) 103 is provided to lock the lock from the lock management unit (LM) 103. Information is registered in the waiting management table (LT) 105. Then, a deadlock detection unit (DD) 1 that operates independently of task execution
04 is provided. This deadlock detector (DD) 104
When the lock management unit (LM) 103 receives information that a task has entered the state of waiting for a resource, the wait management table (LT) is also taken into consideration in consideration of the wait relationship of the task.
It can be configured to judge the presence or absence of deadlock by looking at the registered contents of 105.

As described above, according to the present invention, the task management unit (T
M) 102 and lock management unit (LM) 103, etc. are separated from the system necessary for executing the task, and a deadlock detection unit (DD) 104 is provided to operate independently, so that the task for deadlock detection is executed. Does not need to stop running.

By the way, the deadlock detector (DD) 1
The deadlock detection by 04 is performed by the lock management unit (L
This is preferably performed when a task waiting relationship is detected by M) 103. That is, the lock management unit (LM) 1
When the wait relation of the task is detected by 03, the deadlock detection unit (DD) 104 registers the wait relation in the management table (LT) 105. This registration serves as a trigger for starting the deadlock detection. Upon receiving this notification of registration, the deadlock detection unit (DD) 104 refers to the waiting management table (LT) 105 to detect the presence or absence of deadlock.

When a deadlock is detected, the deadlock cannot be repaired unless any task is forcibly terminated abnormally. Which task is forced to end abnormally depends on the system. For example, the task may be terminated assuming that the later the task start time is, the smaller the workload is. Alternatively, the work amount may be actually counted and the task with the small work amount may be ended.

<Application to Distributed System> The deadlock detection device according to the present invention can be realized on a distributed system having a plurality of systems. When adopting such a distributed system, in addition to the above-mentioned first problem,
The achievement of the second task must be considered. The deadlock detection in this case is as follows.

That is, the waiting management table (LT) 10
In the case of registering the “waiting relationship” in 5, if two or more tasks (x, y) are in the same system,
Waiting management table (LT) 105 provided in the system
It is sufficient to register the "waiting relationship" for each task in.

On the other hand, when a task of one system is in a "waiting" state for a task of another system, the "waiting relationship" is transferred from one system to the waiting management table (LT) 105 of the other system. Please notify to. The waiting management table (LT) 105 that has received this notification registers this “waiting relationship”. Simultaneously with this registration, the deadlock detection unit (DD) 104 of the other system can go to the waiting management table (LT) 105 and determine the presence or absence of deadlock. On the contrary, "waiting relationship"
Is notified from the other system to the waiting management table (LT) 105 of one system, one system can determine the presence or absence of deadlock by looking at the waiting management table (LT) 105. The above is the case of registering both the "wait relationship" of the task of the own system and the "wait relationship" of the task of the wait destination system in the wait management table (LT) 105 of the own system. .

Apart from this, only the “waiting relationship” of the own system may be registered in the own management table (LT) 105. In this case, when the deadlock is detected, the wait management table (L
T) 105 is accessed by communication. Then, the "wait relationship" of the task of its own system and the "wait relationship" of the task at the wait destination are matched, and if the above-mentioned loop is formed, it can be detected as a deadlock.

When the present invention is applied to a distributed system, with respect to deadlock within its own system, communication of information for deadlock detection is not performed between a plurality of systems. That is, information communication is performed only when a deadlock occurs between the duplicate systems. However, since the deadlock almost always occurs between the two parties, the deadlock can be detected by one communication. Therefore, the second subject can be achieved.

<Addition of Waiting Time Management Table> A waiting time monitoring unit (WT) 106 may be provided as shown in the principle diagram of FIG. The waiting time monitoring unit (WT) 106 is a block that issues a resource acquisition request again for a task (transaction) when the “waiting relationship” for the task (transaction) continues for a certain time. The purpose of providing the waiting time monitoring unit (WT) 106 is as described below.

That is, even if a deadlock occurs, if the deadlock cannot be detected, the deadlock cannot be repaired.
The reason why the deadlock cannot be detected in spite of the occurrence of the deadlock may be that the information on the “waiting relation” is not registered in the management table (LT) 105 due to communication loss. Therefore, when the “waiting relationship” for a certain task continues for a certain period of time, the waiting time monitoring unit (WT) 106 issues a resource acquisition request again. As a result, "waiting relationship"
Information in the wait management table (L
The T) 105 can be given an opportunity to retransmit.
Therefore, the deadlock can be reliably detected.

[0044]

In the deadlock detection device according to the present invention, the task execution status is managed by the task management unit (TM) 102. At this time, when each task occupies a resource, the lock management unit (LM) 103 manages information about which task occupies which resource.
Then, when one task requests acquisition of resources occupied by another task, the one task must wait for the other task to end. This “waiting relationship” is registered and managed in the waiting management table (LT) 105.

The deadlock detector (DD) 104 looks at the wait management table (LT) 105 to detect a deadlock. This detection is performed by the lock management unit (LM) 103.
It is performed separately from the lock management by. Therefore, even if the deadlock detection unit (DD) 104 is deadlocked, the lock management unit (LM) 103 can perform the operation. Therefore, it is not necessary to prohibit the generation of new tasks and the occurrence of wait relations. Therefore, it is possible to reduce the influence of deadlock detection on the system.

[0046]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT A preferred embodiment of the present invention will be described below with reference to the drawings. Here, the term “task” used up to now is replaced with “transaction” for explanation.
In addition, this preferred embodiment is a specific example in which the present invention is implemented in a distributed processing system.

<Outline of System> FIG. 4 shows the configuration of the distributed processing system. In this distributed processing system, two computer systems (system i and system j) are provided in a distributed manner and are connected to each other by a network (NW) 30. Also, both computer systems (i, j) and network (NW) 30
Connected by both computer systems (i,
A database (DB) 20 accessible from j) is provided. Such a system is used, for example, in a deposit system.

As is clear from FIG. 4, each computer system (system i and system j) has a transaction management unit (TM) 10, a resource management unit (RM) 11, a lock management unit (LM) 12, and deadlock detection. Department (DD)
15, a waiting management table T3, and a watchdog timer (WT) 13 are provided. System j has exactly the same configuration as system i. Therefore, in FIG. 4, the detailed configuration of only the system i is shown, and the detailed configuration of the system j is omitted.

The database (DB) 20 stores a plurality of files or records as resources. In FIG. 4, resource A and resource B are illustrated as these resources.

Each constituent block will be described in detail below.

<Transaction Management Unit (TM)> The transaction management unit (TM) 10 manages execution of a plurality of transactions. The transaction management unit (TM) 10 may be called the task management unit (TM) 10.

This transaction management unit (TM) 10
Accepts transaction start, normal end (commit), and abnormal end (abort) communications from the application program,
This block manages transactions in the system. More specifically, for example, when transaction x is started in system i, T (i, x)
The data of the form T (i, x) is deleted when the transaction x ends / abnormally ends.

The transaction management unit (TM) 10 is
When a request for a resource is received from a transaction, the request is passed to the resource management unit (RM) 11, and the response (ok
/ No). In addition, the transaction management unit (T
M) 10 accepts the deadlock notification of the transaction transmitted from the deadlock detector (DD) 15 and ends the transaction. Further, the transaction management unit (TM) 10 includes a deadlock detection unit (D
D) Retry notification transmitted from 15 is received, and a resource acquisition request is reissued to the resource management unit (RM) 11. Further, the transaction management unit (TM) 10 receives communication of normal end or abnormal end of a transaction of another computer system (system j), and requests the deadlock detection unit (DD) 15 to register / delete a graph. .

In FIG. 4, "start" means the start of execution of a transaction, "abort" means the abnormal end of the transaction, and "commit" means the normal end of the transaction.

A resource acquisition request / resource release request in the transaction management unit (TM) 10 is a two-phase lock (2
PL: Two Phase Lock). This is a pseudo deadlock (phantom de)
It is effective in preventing the detection of the address.

Pseudo deadlock generally occurs when graph registration and deletion conflict. For example, when a graph of T (i, x) → T (j, y) is already registered, a deletion request of T (i, x) → T (j, y) and T (j, y) → It is assumed that the request to register T (i, x) is simultaneously issued to the deadlock detector (DD) 15. At this time, if the deletion request is accepted first, deadlock does not occur. On the other hand, if the registration request is accepted first, a pseudo deadlock occurs.

A deletion request of T (i, x) → T (j, y) occurs when the waiting relation represented by this graph disappears (that is, T (j, y) is a resource. If you unlock the.). The lock is released when the transaction releases the lock of the resource by itself or asynchronously aborts.

The two-phase lock system is a lock system consisting of two phases: one process continues to lock (occupy) data and continues to lock, and one to start unlocking continues to release. According to this method, the same result is obtained as if a plurality of tasks or transactions were sequentially executed.

Transactions abort asynchronously
If not (abnormal termination), this method guarantees that no request for acquisition of a new lock will occur once the lock is released. That is, the graph T (i, x) → T (j, y) once generated is not deleted until T (j, y) ends. Therefore, after the T (i, x) → T (j, y) deletion request has occurred, T (j, y) has ended, so T (j, y) is a new resource. There is no demand for acquisition. Therefore, it can be guaranteed that the registration request of T (j, y) → T (i, x) does not occur.

For this reason, by adopting this method, the cause of the pseudo deadlock can be limited to the asynchronous abort of the transaction (abnormal termination).

<Resource Management Unit (RM)> Resource Management Unit (R)
M) 11 is the transaction management unit (TM) 10
Is bidirectionally connected to. Resource Management Department (RM) 11
Has a resource management table T1. The resource management unit (RM) 11 is a transaction management unit (TM) 10
The correspondence relationship between a transaction and the resource requested by the transaction is mapped and managed on the resource management table T1 based on the contents of the resource acquisition request and the resource release request from the.

Further, the resource management unit (RM) 11 makes a lock request to the lock management unit (LM) 12 in response to a resource acquisition request from the transaction management unit (TM) 10, and the transaction management unit (TM). In response to the resource release request from 10, the lock release request is issued to the lock management unit (L
M) 12

<Lock Management Unit (LM)> The lock management unit (LM) 12 is bidirectionally connected to the resource management unit (RM) 11. The lock management unit (LM) 12 has a lock management table T2. That is, the lock management unit (L
M) 12 is a control unit that manages the lock state by the lock management table T2.

When there are transactions x and y and resources A and B, when the transaction x locks (occupies) the resource A and the transaction y locks B, the lock management unit (LM) 12 establishes this relationship. Register in the lock management table T2. That is, as shown in FIG. 4, a state in which x locks A is defined as, for example, (x: A), and a state in which y locks B is defined as, for example, (y: B). Register in table T2.

The lock management table T2 not only manages lock information about transactions in the computer system (i or j), but also holds lock information about transactions in other computer system (j or i). to manage. The lock information about the transaction in the other system can be acquired by communicating between the computer systems. However, if a single lock management table T2 is created on the shared memory shared by each computer system (i, j) and lock information regarding all transactions in all computer systems (i, j) is collectively managed, There is no need for communication between each computer system.

Now, in the above-mentioned state, it is assumed that the resource management unit (RM) 11 further requests the lock of the resource A by the transaction y and the lock request of the resource B by the transaction x. Then, the lock management unit (LM) 12 refers to the information in the lock management table T2 and recognizes that such a lock cannot be performed. In this case, transaction y must wait for the lock release of resource A by transaction x, and transaction x must wait for the lock release of resource B by transaction y. The wait states are (x
→ B) and (y → A) are defined. When such a definition occurs, the lock management unit (LM) 12 determines that “wait” has occurred.

In this embodiment, such a "wait relationship"
Is separated from the lock management unit (LM) 12 and registered and managed in the waiting management table T3. That is, when a “waiting relationship” occurs, the lock management unit (LM) 12
Based on the above definition, the deadlock detection unit (DD) 15 is requested to perform wait-forgraph registration. At the time of this request, in which computer system the transaction (x, y) in the above definition is the transaction, and in which computer system the resource (A, B) in the above definition is currently locked. This information is also notified to the deadlock detector (DD) 15.

If the lock request from the resource management unit (RM) 11 does not become "wait", the lock management unit (LM) 12 immediately sends a response (ok) to the resource management unit (RM) 11. return. Only when the lock management unit (LM) 12 judges and "waits", a wait request graph indicating a wait relationship is issued to the registration request queue for registering in the wait management table T3. Therefore, with respect to the "resource acquisition request without waiting", the execution process of the transaction making the resource acquisition request is not stopped regardless of whether the deadlock is being detected.

<Deadlock Detection Unit (DD)> The deadlock detection unit (DD) 15 is a unit for determining the presence or absence of deadlock based on the registered contents of the waiting management table T3.

The deadlock detector (DD) 15 has a request queue receiver (QR) 14. The request queue reception unit (QR) 14 is the lock management unit (LM) of the own system.
A registration / deletion request queue of wait relation (wait forgraph) is accepted from 12. Also, it receives a queue / wait request registration / deletion request queue from another computer system. Further, when a transaction of another system ends abnormally (abort) or ends normally (commit), a wait request (wait-forgraph) deletion request queue from the transaction management unit (TM) 10 is accepted.

According to these request queues, the deadlock detector (DD) 15 first registers or deletes the wait-for graph with respect to the waiting management table T3. This wait for graph
The format of h) is as follows. That is, for example, a transaction x = T (i,
x), transaction y = T that occurred in system j
When (j, y), T (i, x) waits for T (j, y) is expressed as T (i, x) → T (j, y).

When registering the wait-forgraph, the deadlock detector (DD) 15 creates a wait-forgraph in advance based on the notified information.
When the wait-for graph is registered, the deadlock detector (DD) 15 starts deadlock detection.
When a deadlock is detected, the deadlock detection unit (DD) 15 operates as the transaction management unit (TM) 10.
Deadlock notification to. When the wait-forgraph deletion request is accepted, the wait-forgraph is deleted and a retry notification is issued to the transaction that can operate.

<Wait Management Table T3> A wait-for graph is registered in the wait management table T3. As described above, transaction x that occurred in system i
(Occupying resource A) = T (i, x), transaction y generated in system j (occupying resource B) = T (j,
y), T (i, x) waits for T (j, y) is expressed as T (i, x) → T (j, y). In this case, the transaction x cannot use the resource B to be acquired unless T (j, y) is updated by updating the resource B occupied by the transaction y. This state is called "waiting relationship", and "T (i,
x) waits for T (j, y). "

The deadlock detector (DD) 15 registers the graph of T (i, x) → T (j, y) in the wait management table T3 as a "wait relationship".

On the other hand, at the same time that the graph of T (i, x) → T (j, y) is established, T (j, y) → T (i, x) may be established. In this case, the transaction y cannot use the resource A to be acquired unless the resource A occupied by the transaction x is updated and T (i, x) ends. When these two waiting relations are compared, T (i, x) → T (j, y) → T (j, y) → T (i,
A loop called x) is formed. Therefore, if this loop is detected, it can be said that deadlock has occurred.

This waiting relationship occurs between transaction x of system i and transaction y of system j. Then, the graph of T (i, x) → T (j, y) is registered in the wait management table T3 of the system i, and the graph of T (j, y) → T (i, x) is the wait management of the system j. It is registered in the table (T3). Therefore, in order to match the two, either must be transmitted to the other. here,
When the "waiting relationship" is registered, the "waiting relationship" is transmitted to the waiting destination.

That is, when T (i, x) → T (j, y) is registered in the waiting management table (T3) of the system i, the deadlock detector (DD) 15 of the system i:
The graph having the same content is transmitted and registered in the waiting management table T3 of the system j.

As a result, the deadlock can be detected in the waiting system (that is, the system j) by referring to the waiting management table T3. It should be noted that when the "wait relationship" of the transaction x is resolved, the deadlock is detected forever unless the "wait relationship" information regarding the transaction x is collected (deleted) from the waiting system (that is, the system j). . Therefore, when the "waiting relationship" is resolved, the graph showing the "waiting relationship" must be deleted or collected from the waiting management table T3 of the waiting system (that is, the system j).
The deadlock detector (DD) 15 also has such a graph deletion / collection function.

When the wait-forgraph loop is not detected, if the end of the wait-forgraph is a transaction of another system, there is a possibility of deadlock in the other system. Therefore, the graph registration is requested to the other system. When a graph registration request from another system is received, the deadlock detection unit (DD) 15 registers the necessary graph and performs loop detection.

This waiting relationship may occur within the own system. For example, when the transaction x1 = T (i, x1) generated in the system i is in the transaction y1 = T (i, y1) generated in the own system (that is, the system i) and waits, the own system (that is, the system i) T (i, x1) → T (i, y1) is registered in the waiting management table T3. Here, if T (i, y1) → T (i, x1) is registered in the waiting management table T3 of the own system (that is, system i), T (i, x1) → T (i, y1) ) → T (i, y1) → T
Since a loop (i, x1) is formed, deadlock can be detected.

By the way, in the distributed processing system,
The registration contents such as the wait-forgraph related to the transaction that occurred in a certain system are called the local wait-forgraph of the system. Further, a graph expressing a waiting relation in the entire distributed processing system, that is, a set of all local weight graphs in the distributed system is called a global weight graph. FIG. 5 shows an example of the relationship between the local weight graph and the global weight graph.

In each computer system, only the local wait-for graph is managed by the wait management table T3. Here, as described above, the deadlock detection unit (DD) 15 does not transmit the registered contents such as the wait-for graph indicating the waiting relationship between transactions in the own computer system to other computer systems. On the other hand, the deadlock detection unit (DD) 15 transmits a wait-for graph representing a wait relationship with a transaction in another computer system only to another system having the relationship. Considering that 90% or more of deadlocks statistically occur between two tasks, even deadlocks related to transactions of other systems can be detected in almost one communication.
Moreover, a deadlock within the own computer system can be detected without communication. Therefore, the communication overhead for deadlock detection can be reduced.

<Waiting Time Monitoring Unit (WT)> Next, the waiting time monitoring unit (WT) 13 is a timer for monitoring the waiting management table T3. This timer monitors the “waiting relationship” registered in the waiting management table T3. Then, if the "wait relationship" is still continuing after a certain period of time has passed since the "wait relationship" was registered, the waiting transaction in the "wait relationship" reissues the resource acquisition request. Issue a retry notification as you would issue. This retry notification is sent to the request queue reception unit (Q
R) 14. When this retry notification is input to the request queue reception unit (QR) 14, the deadlock detection unit (DD) 15 causes the transaction management unit (TM) 1 to operate.
Send retry notification to 0. Transaction manager (T
Upon receiving the retry signal, M) 10 again issues a resource acquisition request to the transaction in the waiting relationship.

When delay or loss of communication messages between systems or asynchronous down of a computer system occurs,
In some cases, this cannot be detected even though the deadlock condition is actually entered. The waiting time monitoring unit (WT) 13 prevents such inconvenience. That is, when communication is performed between the computer systems in the distributed processing system, the graph displaying the deadlock state may be missing due to the lack of communication. Then, the deadlock cannot be detected. In order to prevent this, the waiting time monitoring section (W
T: Watchdog Timer) 13 is provided.

This timer urges a transaction having a wait-forgraph waiting relationship for a certain period of time or more to make a resource acquisition request again via the deadlock detector (DD) 15, as described above. Then, the transaction monitoring unit (TM: Transaction)
The manager 10 again issues a resource acquisition request. At this time, if the "wait" has already been resolved,
This resource acquisition request is satisfied. On the other hand, if the wait is not canceled, the wait-for graph is transmitted again to another computer system. This compensates for the loss of wait-for graph, and deadlock can be detected.

<Operation Example of Each Section> The operation of each section will be described below with reference to a flowchart. [Operation of Transaction Management Unit (TM)] As shown in the flowchart of FIG. 6, the transaction management unit (TM) 10 has a start (start request), abort
Various requests such as (abnormal end), commit (normal end), resource acquisition request, deadlock notification, and retry notification are waited for (step S101). In addition, abor said here
The t (abnormal end) and the commit (normal end) include those notified from other computer systems. When receiving any request (step S102), the transaction management unit (TM) 10 distributes the processing according to the type of the request.

The request accepted in step S102 is st
In the case of an art (start request), the transaction management unit (TM) 10 itself issues the transaction
Let T (i, x). ) Is registered (step S10)
3) Wait for subsequent requests.

The request accepted in step S102 is ab
If it is ort (abnormal end) or commit (normal end), first, the transaction to be ended (here, T (i, x)) is deleted (step S104). Next, a resource release request is issued to the resource management unit (RM) 11 (step S105). When a response to the resource release request is received from the resource management unit (RM) 11 (step S106), the deadlock detection unit (D
D) Issue a graph deletion request to 15 (step S10)
7). Then, it is determined whether the request is from the own computer system (step S108). If it is a request from another computer system, leave it as it is.
On the other hand, if the request is from the own computer system, the other computer system is notified of the commit or abort (step S109). In the other computer system that received the notification, step S104
Through 107 are performed.

If the request accepted in step S102 is a resource acquisition request, a resource acquisition request is issued to the resource management unit (RM) 11 (step S110). When a response to the request is received from the resource management unit (RM) 11 (step S111), the response is returned to the transaction (step S112).

If the request accepted in step S102 is a deadlock notification, first, a transaction to be aborted is selected from among deadlocked transactions (step S120). That is, the deadlock notification includes all deadlock-related transactions (here, T (i, x), T
Let (j, y). ) Is included. The transaction management unit (TM) 10 selects a transaction to be aborted from the transaction names included in the deadlock notification. Therefore,
The transaction management unit (TM) 10 can specify a transaction of another computer system as an abort target. Next, the transaction management unit (TM) 10 notifies the selected transaction that it should abort (step S12).
1). If the selected transaction belongs to another computer system, the transaction management unit (TM) 10 of the other computer system notifies the selected transaction that it should abort.

If the request accepted in step S102 is a retry notification, first, a resource acquisition request is issued to the resource management unit (RM) 11 (step S130). When a response to the request is received from the resource management unit (RM) 11 (step S131), the response is returned to the transaction (step S131).

[Operation of Resource Management Unit (RM)] As shown in the flowchart of FIG. 7, the resource management unit (RM) 11
Waits for a resource acquisition request and a resource release request (step S201). If there is any request and it is accepted (step S202), the resource shown in the table is tried to be locked, and the relation is acquired in the resource acquisition table T1.
(Step S203). That is, it registers which transaction tries to lock which resource.

Then, it is determined whether the request is a resource acquisition request or a resource release request (step S204). If the request is a resource acquisition request, a lock acquisition request is issued to the lock management unit (LM) 12 (step S205). On the other hand, if the request is a resource release request, a lock release request is issued to the lock management unit (LM) 12 (step S206).

Then, the response (ok / no) to the lock acquisition request or the lock release request is sent to the lock management unit (LM).
After receiving from 12 (step S207), a response (ok / no) is returned to the transaction management unit (TM) 10 (step S208).

[Operation of Lock Management Unit (LM)] As shown in the flowchart in FIG. 8, the resource management unit (RM) 11
When there is a request in step S205 or step S206 in step S301 (step S301), the lock management unit (LM)
12 receives the request (step S302). Then, it is determined whether the request is a lock acquisition request or a lock release request (step S303). If the request is a lock acquisition request, the lock management unit (LM) 12 determines whether lock acquisition is possible (step S304).

If the resource can be locked, the lock status is registered in the lock management table T2 (step S).
305). If the resource cannot be locked, there is a "wait relationship". Therefore, the deadlock detection unit (registering the wait transaction table T3 with the relationship between the requesting transaction and the waiting transaction in the waiting management table T3) DD) 15 is requested (step S30)
6). Thereafter, the resource management unit (RM) 11 is replied that the lock could not be made (no) (step S309).

If it is determined in step S303 that the request is a resource release request, the lock management table T2
The lock registration is deleted from (step S307). After registering the lock (step S305) and deleting it (step S307), a response indicating the completion (ok) is returned to the resource management unit (RM) 11 (step S308).

[Operation of Deadlock Detecting Unit (DD)] As shown in the flowchart of FIG. 9, the deadlock detecting unit (DD) 15 receives a graph registration request, a graph deletion request, and a retry notification. Queue reception part (QR) 1
4 is accepted. Therefore, when there is the request (step S401), the request is taken out from the request queue reception unit (QR) 14 (step S402), and the type of the request is determined (step S403).

If the request is to register a graph, first, a wait-for graph is registered in the waiting management table T3 (step S404). However, if the same graph is already registered as a result of searching the waiting management table T3, the graph is not registered. Then, the registered graph is traced to the top of the graph (step S40).
5). Based on the traced result, it is determined whether a loop is formed (step S406). If the loop is formed, the transaction management unit (TM) 10 is notified of the deadlock (step S407). If the loop is not formed, it is determined whether or not the leading end of the graph is the own computer system (step S408). If it is the own computer system, the process directly returns to step S401. On the other hand, if it is another computer system,
Other computer system deadlock detector (D
D) The wait-for graph is transmitted to 15, and the graph is registered in the waiting management table T3 of the other system (step S409).

Next, in step S403, when the request is to delete a graph, the waiting management table T3 is searched for the corresponding graph (step S410).
When the corresponding graph is found, the corresponding graph is deleted (step S411). After that, the transaction management unit (TM) 10 is notified of a retry in order to operate the transaction whose waiting relationship has been released (step S41).
2).

When the request is a retry notification in step S403, first, the wait-forgraph of the transaction to be retried is deleted (step S420). Then, the transaction management unit (TM) 10 is notified of a retry (step S421).

[Operation of Waiting Time Monitoring Unit (WT)] FIG.
As shown in the flowchart in Fig.
T) 13 sequentially searches each transaction (T (i, x), etc.) registered in the waiting management table T3 (step S501). Then, it is determined whether or not the transaction x has a "waiting relationship" (step S).
502). Transactions retrieved are in "wait relations"
If not, the process returns to step S501 to search for the next transaction.

On the other hand, if the retrieved transaction is "waiting", time counting is started,
When the time-out occurs (step S503), the deadlock detection unit (DD) 15 is notified of a retry (step S504). If the "waiting relationship" is resolved before the time-out occurs in step S503, step S50
It returns to 1 (step S502).

<Specific Example of Deadlock Detection> Next,
Deadlock detection examples in the above configuration will be described along three cases. [Example 1 Deadlock Detection in Own Computer System] Example 1 is an example of deadlock detection in the own computer system. Specifically, the following operation is performed.
Here it can be seen that no communication occurs with other computer systems.

(1) First, the transaction T (1,
It is assumed that 1) notifies the transaction management unit (TM) 10 of the start of a transaction. (2) Then, the transaction management unit (TM) 10 sends the transaction T to the deadlock detection unit (DD) 15.
Request registration of (1,1). (3) On the other hand, it is assumed that the transaction T (1,2) notifies the transaction management unit (TM) 10 of the start of the transaction.

(4) Then, the transaction management unit (TM) 10 requests the deadlock detection unit (DD) 15 to register the transaction T (1, 2). (5) It is assumed that the transaction T (1,1) requests the resource A from the transaction management unit (TM) 10. (6) Then, the transaction management unit (TM) 10 requests the resource management unit (RM) 11 to acquire the resource A.

(7) Then, the resource management unit (RM) 11 requests the lock management unit (LM) 12 to acquire the lock of the resource A. (8) If resource A is not locked, lock management unit (L
M) 12 responds to the resource management unit (RM) 11 with OK. (9) Then, the resource management unit (RM) 11 responds OK to the transaction management unit (TM) 10.

(10) On the other hand, the transaction T (1,
It is assumed that 2) requests the resource B from the transaction management unit (TM) 10. (11) Then, the transaction management unit (TM) 10 requests the resource management unit (RM) 11 to acquire the resource B. (12) Then, the resource management unit (RM) 11 requests the lock management unit (LM) 12 to acquire the lock of the resource B.

(13) If the resource B is not locked, the lock management unit (LM) 12 returns OK to the resource management unit (RM) 11. (14) Then, the resource management unit (RM) 11 responds OK to the transaction management unit (TM) 10. (15) In this state, transaction T (1,
It is assumed that 1) requests the resource B from the transaction management unit (TM) 10.

(16) Then, the transaction management unit (TM) 10 requests the resource management unit (RM) 11 to acquire the resource B. (17) Then, the resource management unit (RM) 11 requests the lock management unit (LM) 12 to acquire the lock of the resource B.

(18) However, since the resource B has already been locked by the transaction T (1,2), T
(1,1) will wait for transaction T (1,2). Therefore, the lock management unit (LM) 12 requests the deadlock detection unit (DD) 15 to register the graph T (1,1) → T (1,2). The deadlock detector (DD) 15 that has received the request registers this graph in the waiting management table T3.

(19) On the other hand, the transaction T (1,
2) requests the resource A from the transaction management unit (TM) 10. (20) Then, the transaction management unit (TM) 10 requests the resource management unit (RM) 11 to acquire the resource A. (21) Then, the resource management unit (RM) 11 requests the lock management unit (LM) 12 to acquire the lock of the resource A.

(22) However, since resource A has already been locked by transaction T (1,1), T
(1,2) waits for transaction T (1,1). Therefore, the lock management unit (LM) 12 requests the deadlock detection unit (DD) 15 to register the graph T (1,2) → T (1,1). The deadlock detector (DD) 15 that has received the request registers this graph in the waiting management table T3. (23) The deadlock detection unit (DD) 15 detects a loop, and the deadlock occurrence is detected by the transaction management unit (T
M) Notify 10.

[Example 2 Deadlock Detection of Two Transactions Between Two Computer Systems] Example 2 shows a case where a deadlock occurs between two computer systems (system 1 and system 2). Here, it can be seen that the communication for deadlock detection only needs to be performed once. (1) First, the transaction T in the system 1
It is assumed that (1,1) notifies the transaction management unit (TM) 10 of the system 1 of the start of a transaction. (2) Then, the transaction management unit (TM) 10 of the system 1 requests the deadlock detection unit (DD) 15 to register the transaction T (1,1). (3) Now, the transaction T (1,1) is transferred to the transaction management unit (TM) 10 of the system 1 by the resource A.
Request.

(4) Then, the transaction management unit (TM) 10 of the system 1 requests the resource management unit (RM) 11 to acquire the resource A. (5) Then, the resource management unit (RM) 11 of the system 1
Requests the lock management unit (LM) 12 to acquire the lock of the resource A. (6) If the resource A is not locked, the lock management unit (LM) 12 of the system 1 is ok to the resource management unit (RM) 11.
To respond.

(7) Then, the resource management unit (RM) 11 of the system 1 becomes the transaction management unit (TM) 10
To OK. (1) ′ On the other hand, it is assumed that the transaction transaction T (2,1) in the system 2 notifies the transaction management unit (TM) 10 in the system 2 of the start of the transaction. (2) ′ Then, the transaction management unit (TM) 10 of the system 2 requests the deadlock detection unit (DD) 15 to register the transaction T (2,1).

(3) 'Now, transaction T (2,
1) is the transaction management unit (TM) of system 2
Assume that resource B is requested to 10. (4) ′ Then, the transaction management unit (TM) 10 of the system 2 requests the resource management unit (RM) 11 to acquire the resource B. (5) 'Then, the resource management unit (RM) 11 of the system 2
Requests the lock management unit (LM) 12 to acquire the lock of the resource B. (6) 'If the resource B is not locked, the lock management unit (LM) 12 of the system 2 is OK in the resource management unit (RM) 11.
To respond.

(7) 'Then, the resource management unit (RM) 11 of the system 2 becomes the transaction management unit (TM) 10
To OK. (8) Under the above circumstances, transaction T
(1,1) is the transaction management part (T
Suppose M) 10 requests resource B. (9) Then, the transaction management unit (TM) 10 of the system 1 requests the resource management unit (RM) 11 to acquire the resource B.

(10) Then, the resource management unit (RM) 11 of the system 1 requests the lock management unit (LM) 12 to acquire the lock of the resource B. (11) However, since resource B has already been locked by transaction T (2,1) of system 2, transaction T (1,1) is transaction T (2).
You will have to wait for (2,1). Therefore, the lock management unit (LM) 12 of the system 1 requests the deadlock detection unit (DD) 15 to register the graph T (1,1) → T (2,1).

(12) In response to this request, the deadlock detector (DD) 15 of the system 1 sends the graph T (1,1) → T (2,1) to the system 2. At the same time, the deadlock detector (DD) 15 of the system 1 registers this graph in the waiting management table T3 of the system 1. (13) Deadlock detector (DD) 15 of system 2
Receives this graph T (1,1) → (2,1) and registers it in the waiting management table T3 of the system 2.

(14) After this, the transaction T
(2, 1) is the transaction management part (T
Suppose M) 10 requests resource A. (15) Then, the transaction management unit (TM) 10 of the system 2 requests the resource management unit (RM) 11 to acquire the resource A. (16) Then, the resource management unit (RM) 11 of the system 2
Requests the lock management unit (LM) 12 to acquire the lock of the resource A.

(17) However, since the resource A has already been locked by the transaction T (1,1) of the system 1, the transaction T (2,1) waits for the transaction T (1,1). Become. Therefore,
The lock management unit (LM) 12 of the system 2 requests the deadlock detection unit (DD) 15 to register the graph T (2,1) → T (1,1). (18) The deadlock detection unit (DD) 15 of the system 2 detects a loop and notifies the transaction management unit (TM) 10 of the system 2 that a deadlock has occurred.

[Example 3 Occurrence of Message Loss During Deadlock Detection of Two Transactions Between Two Computer Systems] In Example 3, a message is generated due to a communication error between the two computer systems (system 1 and system 2). This is an example of the case where the disappearance occurs. (1) First, it is assumed that the transaction transaction T (1,1) in the system 1 notifies the transaction management unit (TM) 10 of the system 1 of the start of the transaction.

(2) Then, the transaction management unit (TM) 10 of the system 1 detects the deadlock detection unit (D).
D) Request 15 to register transaction T (1,1). (3) Now, the transaction T (1,1) is transferred to the transaction management unit (TM) 10 of the system 1 by the resource A.
Request. (4) Then, the transaction management unit (TM) 10 of the system 1 requests the resource management unit (RM) 11 to acquire the resource A. (5) Then, the resource management unit (RM) 11 of the system 1
Requests the lock management unit (LM) 12 to acquire the lock of the resource A.

(6) If the resource A is not locked, the lock management unit (LM) 12 of the system 1 makes the resource management unit (R)
M) 11 is answered OK. (7) Then, the resource management unit (RM) 11 of the system 1
Responds to the transaction management unit (TM) 10 with OK. (1) 'Meanwhile, transaction T in system 2
It is assumed that (2, 1) notifies the transaction management unit (TM) 10 of the system 2 of the start of a transaction.

(2) 'Then, the transaction management unit (TM) 10 of the system 2 detects the deadlock detection unit (D).
D) Request 15 to register transaction T (2,1). (3) 'Now, the transaction T (2,1) is stored in the transaction management unit (TM) 10 of the system 2 by the resource B.
Request. (4) ′ Then, the transaction management unit (TM) 10 of the system 2 requests the resource management unit (RM) 11 to acquire the resource B.

(5) 'Then, the resource management unit (RM) 11 of the system 2 requests the lock management unit (LM) 12 to acquire the lock of the resource B. (6) 'If the resource B is not locked, the lock management unit (LM) 12 of the system 2 is OK in the resource management unit (RM) 11.
To respond.

(7) 'Then, the resource management unit (RM) 11 of the system 2 becomes the transaction management unit (TM) 10
To OK. (8) Under the above circumstances, transaction T
(1,1) is the transaction management part (T
Suppose M) 10 requests resource B. (9) Then, the transaction management unit (TM) 10 of the system 1 requests the resource management unit (RM) 11 to acquire the resource B.

(10) Then, the resource management unit (RM) 11 of the system 1 requests the lock management unit (LM) 12 to acquire the lock of the resource B. (11) However, since resource B has already been locked by transaction T (2,1) of system 2, transaction T (1,1) is transaction T (2).
You will have to wait for (2,1). Therefore, the lock management unit (LM) 12 of the system 1 requests the deadlock detection unit (DD) 15 to register the graph T (1,1) → T (2,1).

(12) In response to this request, the deadlock detector (DD) 15 of the system 1 registers this graph in the wait management table T3 of the system 1. At the same time, the deadlock detector (DD) 15 of the system 1
The graph T (1,1) → T (2,1) is transmitted to the system 2. (13) However, the transmitted contents were lost due to a communication error and did not reach System 2.

(14) After this, the transaction T
(2, 1) is the transaction management part (T
Suppose M) 10 requests resource A. (15) Then, the transaction management unit (TM) 10 of the system 2 requests the resource management unit (RM) 11 to acquire the resource A. (16) Then, the resource management unit (RM) 11 of the system 2
Requests the lock management unit (LM) 12 to acquire the lock of the resource A.

(17) However, since the resource A is already locked by the transaction T (1,1) of the system 1, the transaction T (2,1) waits for the transaction T (1,1). Become. Therefore,
The lock management unit (LM) 12 of the system 2 requests the deadlock detection unit (DD) 15 to register the graph T (2,1) → T (1,1). At this point, a deadlock condition has actually occurred.

However, since the deadlock state cannot be detected due to the message loss, the deadlock state continues. (18) After a certain period of time, the waiting time monitoring unit (W
T) 13 is activated, and a retry notification is sent to the deadlock detection unit (DD) 15 of the system 1. (19) Then, the deadlock detection part (D
D) 15 notifies the transaction management unit (TM) 10 of the retry of the transaction T (1, 1).

(20) In accordance with the retry notification, the system 1
The transaction management unit (TM) 10 requests the resource management unit (RM) 11 to acquire the resource B. (21) Then, the resource management unit (RM) 11 of the system 1
Requests the lock management unit (LM) 12 again to acquire the lock of the resource B. (22) However, since the resource B has already been locked by the transaction T (2,1) of the system 2, the transaction T (1,1) is the transaction T.
You will have to wait for (2,1). Therefore, the lock management unit (LM) 12 of the system 1 requests the deadlock detection unit (DD) 15 again to register the graph T (1,1) → T (2,1).

(23) In response to this request, the deadlock detector (DD) 15 of the system 1 registers this graph in the wait-for graph table T3 of the system 1.
At the same time, the graph T (1,1) → T (2,1) is transmitted to the system 2 again. (24) Deadlock detector (DD) 15 of system 2
Receives the graph T (1,1) → T (2,1) and registers it in the waiting management table T3 of the system 2. This compensates for missing graphs. (25) The deadlock detector (DD) 15 of the system 2 detects a loop, and the deadlock is detected by the system 2 TM.
To notify.

[0136]

As described above, according to the present invention, the lock management unit (LM) 103 for managing the resource lock state by the task (transaction) and the deadlock detection unit (DD) 104 are separated, and both are separated. Now works asynchronously. Therefore, even if a task (transaction) is newly generated and requests resources, if the lock can be acquired without waiting, the deadlock detection unit (DD) 1
It can operate without 04. Therefore, the system can be operated smoothly and the processing speed can be increased. Even if the lock cannot be acquired, the registration of the lock state (graph) and the detection of the deadlock operate asynchronously with the request for the lock, so the influence is small.

In particular, in a system designed to reduce deadlock, the effect of deadlock detection is extremely small. When the present invention is applied to a distributed system, the system communicates for deadlock only when it enters a waiting relationship with another system. Therefore,
No communication occurs when a deadlock is detected only within the own system. Even if there is a relationship with another system, more than 90% of deadlocks occur between two parties, so in most cases, deadlocks are detected in one communication. Therefore, communication overhead can be reduced and efficient system operation can be achieved.

Further, in the present invention, the waiting time monitoring unit (WT)
In the case where 13 is provided, even if a message is delayed or lost during message communication in the distributed system, the waiting time monitoring unit (WT) 13 again gives a trigger for deadlock detection, so all deadlocks are detected. can do.

[Brief description of drawings]

FIG. 1 is a diagram showing the principle of the present invention.

FIG. 2 is a diagram showing the principle of the present invention.

FIG. 3 is an explanatory diagram showing a deadlock.

FIG. 4 is a block diagram showing an embodiment.

FIG. 5 is a diagram showing a relationship between a local WFG and a global WFG.

FIG. 6 is a flowchart showing the operation of the transaction management unit.

FIG. 7 is a flowchart showing the operation of the resource management unit.

FIG. 8 is a flowchart showing the operation of the lock management unit.

FIG. 9 is a flowchart showing the operation of the deadlock detection unit.

FIG. 10 is a flowchart showing the operation of the waiting time monitoring unit.

[Explanation of symbols]

 10 Transaction Management Section 11 Resource Management Section 12 Lock Management Section 13 Wait Time Monitoring Section 14 Request Queue Reception Section 15 Deadlock Detection Section 20 Database T3 Wait Management Table

Claims (18)

[Claims] 1. A plurality of tasks (100) share a common resource (1
01), the resources (10) occupied by the plurality of tasks (100) with each other are used.
A deadlock detection device for detecting a deadlock that waits for (0) and stops, and manages the execution of the task (100) in order to execute a plurality of tasks (100) in parallel. Division (10
2), a lock management unit (103) for managing which resource (101) is locked by each task, and when one task requests acquisition of a resource locked by another task, A wait management table (105) for registering a “wait relationship” of each task assuming that one task is waiting for the other task, and the wait management table that operates asynchronously with the lock management unit (103). A deadlock detection device comprising: a deadlock detection unit (104) that detects a deadlock from a "wait relationship" registered in (105). 2. The lock management unit (103) has a lock management table (T2) in which a relationship as to whether resources such as tasks are locked is registered. Deadlock detection device described. 3. When a "wait relationship" occurs in a task, the deadlock detection unit (104) registers the "wait relationship" in the wait management table (105), and at the same time, the wait management table (105). The deadlock detecting device according to claim 1, wherein the presence or absence of deadlock is detected by searching for. 4. The deadlock detection unit (104) has a request queue reception unit (14), and the request queue reception unit (14) uses the deadlock detection command "a wait-related registration request". A request is received.
Deadlock detection device described. 5. The multitask system is realized on a distributed system having a plurality of systems, each system including the task management unit (102), the lock management unit (103), and the wait management table (1).
05), The deadlock detection device according to claim 1, further comprising the deadlock detection unit (104). 6. The dead according to claim 5, wherein when each of two or more tasks in the waiting relationship is in the same system, the “waiting relationship” of each task is registered in the waiting management table (105) of the system. Lock detection device. 7. When a task of one system is "waiting" for a task of the other system, the "waiting relationship" is communicated from the one system to the other system and the other system is communicated. The deadlock detecting device according to claim 5, wherein the deadlock detecting device is registered in a wait management table (105) of the system, and the presence or absence of deadlock is determined by looking at the wait management table (105) in the other system. 8. When each of the two or more tasks in the waiting relationship is in another system, the “waiting relationship” of each task is registered in the waiting management table (105) provided in each system, and When the task of its own system is in the "waiting" state for the task of the other system, the deadlock detection unit (104) of each system stores in the wait management table (105) of the system of the waiting destination. While accessing by communication, the registered contents of the waiting management table (105) of its own system are transmitted, and the waiting management table (105) of its own system is sent to the deadlock detection unit (104) of the waiting system. Of the deadlock is checked by matching the registered content of the system with the registered content of the wait management table (105) of the system at the waiting destination. DOO deadlock detecting device according to claim 5, wherein. 9. The "wait relationship" of the tasks is a relationship of waiting for another task that has locked the resource that the task is trying to acquire to release the resource. Deadlock detection device described. 10. The dead according to claim 1, wherein the "wait relationship" of the tasks is a relationship of waiting for the completion of another task that locks the resource that the task is trying to acquire. Lock detection device. 11. A task x generated in a system i is T
It is defined by (i, x), the task y generated in system j is defined by T (j, y), and T (i, x) waits for T (j, y). → T (j, y) is registered in the waiting management table (T3) as information of "waiting relationship", and T (i, x) → T (j, y) and T
When (j, y) → T (i, x) holds, T (i,
11. The deadlock detection device according to claim 10, wherein a deadlock is determined by detecting a loop of x) → T (j, y) → T (i, x). 12. The multi-task system is realized on a distributed system having a plurality of systems, and when a “waiting relationship” for a certain task continues for a certain period of time,
The deadlock detecting device according to claim 1, further comprising a waiting time monitoring unit (106) for issuing a resource acquisition request again to the task. 13. The task management unit (102) keeps locking when a process starts locking (occupying) data,
The task management is performed by a two-phase lock method in which the lock is continuously released when the lock is released.
Alternatively, the deadlock detection device according to item 9. 14. The lock management unit (103) registers a "wait relationship" in the wait management table (105) and detects a deadlock only when a "wait relationship" occurs with respect to a resource acquisition request. 2. The deadlock detection device according to claim 1, wherein the deadlock detection command is issued, and the transaction execution process is not stopped in response to a resource acquisition request for which a "wait relationship" does not occur. 15. The deadlock according to claim 1, wherein when the "wait relationship" is resolved, the registration of the "wait relationship" is deleted from the wait management table (T3) of the waiting system. Detection device. 16. In a multi-task system in which a plurality of tasks (100) use a common resource (101), resources (101) occupied by the plurality of tasks (100) wait and stop. A deadlock detection device for detecting a deadlock, comprising a task management unit (10) for managing execution of the tasks (100) in order to execute a plurality of tasks (100) in parallel.
2) and the first table (T2) for registering the relationship between the task (100) and the resource (101) locked by the task (100).
And managing which resource (101) is locked by each task (100), and the resources registered in the first table (T2) as being locked by another task are treated as one task. When a request for acquisition is made, a lock management unit (103) that detects the occurrence of a "waiting relationship" in which the one task is waiting for the other task, and a second table (T3 that registers the waiting relationship) ) And the lock management unit (103) operate asynchronously, and the deadlock detection unit (104) that detects a deadlock from the “waiting relationship” registered in the second table (T3). A deadlock detection device characterized by the following. 17. The multi-task system is realized on a distributed system having a plurality of systems, and when a “waiting relationship” for a certain task (100) continues for a certain time, 17. The deadlock detection device according to claim 16, further comprising a waiting time monitoring unit (106) for issuing a resource acquisition request again. 18. In a multi-task system in which a plurality of tasks (100) use a common resource (101), resources (101) occupied by the plurality of tasks (100) wait and stop. A deadlock detection method for detecting deadlock, in which each task (100) recognizes which resource (101) is locked, and the resource requested by one task has already been acquired by another task. When it is detected that the resource is already locked by another task, it is recognized that the one task is waiting for the other task, and A deadlock characterized by detecting a deadlock from a field in which registered "relationships" indicate that the tasks are waiting for each other. Detecting method.