JPH06337798A - Deadlock detecting device - Google Patents
Deadlock detecting deviceInfo
- Publication number
- JPH06337798A JPH06337798A JP6061771A JP6177194A JPH06337798A JP H06337798 A JPH06337798 A JP H06337798A JP 6061771 A JP6061771 A JP 6061771A JP 6177194 A JP6177194 A JP 6177194A JP H06337798 A JPH06337798 A JP H06337798A
- Authority
- JP
- Japan
- Prior art keywords
- task
- deadlock
- waiting
- resource
- wait
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
Description
【0001】[0001]
【産業上の利用分野】本発明はマルチタスクシステムに
おけるデッドロックの検出装置に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a deadlock detecting device in a multitasking system.
【0002】[0002]
【従来の技術】近年、コンピュータを用いた情報処理シ
ステムにおいて、複数のタスクあるいはトランザクショ
ンを同時に実行するマルチタスクシステムが発達してき
た。タスクとは、CPU内部における仕事の単位であ
る。トランザクションとは、ひとつの完結したデータ操
作を行うオペレーションの集まりである。マルチタスク
とは、複数のプログラム(タスク,トランザクション)
が、単一のコンピュータシステム,又は相互に情報交換
可能に接続された複数のコンピュータシステム上で、同
時に並行して実行される状態である。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.
【0003】このマルチタスクシステムでは、2以上の
タスクが資源を共用する場合がある。その場合におい
て、2以上のタスクの夫々が、そのタクスの実行に必要
であり且つ他方のタクスの実行にも必要な複数の資源
を、一部づつを占有(ロック)し合うケースが生じ得
る。そのケースでは、お互いに他方のタクスが占有(ロ
ック)している資源を待ち合うので、双方のタスクが停
止し、それ以上プロセスを実行できない状態となってし
まう。このような状態は、デッドロックの状態と呼ばれ
ている。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.
【0004】図3に、デッドロックの状態の例を示す。
図3の例は、2つのコンピュータシステムi,jから構
成される分散システムにおける例を示している。一方の
コンピュータシステムiではタスクxが実行され、他方
のコンピュータシステムjではタスクyが実行されてい
る。また、各コンピュータシステムi,jでアクセスで
きる資源として、A,Bという2つの資源があるとす
る。なお、資源とは、タスクに割り当てられるプログラ
ム,ファイル,データ等のソフトウェアを指す。ここで
は、各コンピュータシステムi,j外に存在するデータ
ベースの中身(ページ,レコード等)として説明する。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.
【0005】図3において、タスクxは資源Aをロック
しており、タスクyはBをロックしている。同時に、タ
スクyは資源Aをも必要としているので、資源Aをロッ
クすることを待っている。同様に、タスクxは資源Bを
も必要としているので、資源Bがロックできるようにな
ることを待っている。この場合、タスクxが資源Aのロ
ックを解除しない限り、タスクyは資源Aをロックでき
ない。一方、タスクyが資源Bのロックを解除しない限
り、タスクxは資源Bをロックできない。この結果、タ
スクx,yは互いがロックしているA,Bを待ち合って
停止する。両タスクx,yが停止すると、各々が既にロ
ックしている資源A,Bの解除もできなくなってしまう
ので、この状態は永遠に続くことになる。よって、各タ
スクはそれ以上のプロセスを実行できない。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.
【0006】このようなデッドロックは、コンピュータ
システムがマルチプロセッサ方式のシステムであるかシ
ングルプロセッサ方式のシステムであるか,あるいは、
コンピュータシステムがスタンドアローンで運用される
のか分散処理システムを構成するのかに拘らず、システ
ムがマルチタスクシステムであれば生じ得る問題であ
る。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.
【0007】このようなデッドロックが生じたとき、こ
れを修復する手段を講じなければならない。そのために
は、前提としてデッドロックが生じたことを検出しなけ
ればならない。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.
【0008】デッドロック検出には、実用性を向上させ
る理由から、以下のスペックを満たすことが要求され
る。第1に、実際はデッドロックではないにも拘らずデ
ッドロックと誤認してしまう現象,すなわち疑似デッド
ロック(phantom deadlock)の検出が
防止されていなければならない(第1の要求)。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).
【0009】第2に、全てのデッドロックが検出されな
ければならない。換言すれば、現実にデットロックが生
じているに場合には、デッドロックを検出できるときと
検出できないときがあってはならず、全てデッドロック
であると検出されなければならない(第2の要求)。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). ).
【0010】第3に、デッドロック検出を行うことによ
るシステムへの影響を小さく抑えなければならない。即
ち、デッドロックを検出するためにタスクを停止するよ
うなことは、できるだけ避けなければならない(第3の
要求)。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).
【0011】なお、マルチタスクシステムを分散処理シ
ステム上で実現する場合には、上記各要求の他に次のス
ペックが要求される。即ち、デッドロックを検出するた
めにシステム間で通信を行う必要があるが、この通信の
オーバーヘッドをできるだけ削減しなければならない
(第4の要求)。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).
【0012】従来のデッドロック検出装置では、以下の
ようなような条件を満足させることによって、上述した
第1乃至第3の要求を満足してデッドロックを検出しよ
うとしていた。その条件とは、(a) トランザクション
の非同期abort(異常終了)が発生しないこと,
(b) マルチタスクシステムを分散処理システム上で実
現する場合には、各システム間の通信メッセージの遅延
・消失が発生しないこと,(c) デッドロック検出中の
トランザクション待ち関係の変更がないこと。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.
【0013】(d) マルチタスクシステムを分散処理シ
ステム上で実現する場合には、システムの非同期ダウン
が発生していないこと,である。(D) When the multitask system is realized on the distributed processing system, the asynchronous down of the system does not occur.
【0014】上述の第1乃至第3の要求と(a)乃至(d)の
条件との関係の関係を説明する。(a)の条件に関し、ト
ランザクションの非同期abort(異常終了)が発生
すると、前記第1の要求における疑似デッドロック(p
hantom deadlock)の検出防止を図るこ
とができない。例えば、タスク(トランザクション)x
が資源Aをロックしており、タスク(トランザクショ
ン)yが資源Bをロックしている場合、タスクyが資源
Aを待ち、タスクxが資源Bに待ち要求を出した時点
で、タスクyが非同期に異常終了してしまったとする。
この場合、タスクyの非同期終了によってタスクyによ
る資源Bのロックが解除されるので、タスクxは資源B
をロックできる。従って、本来ならばデッドロックは発
生しないはずである。しかし、タスクyの非同期異常終
了による資源Bのロック解除は直ちに検出できないの
で、現実には、デッドロックが発生していないにもかか
わらずデッドロックが発生したものとして扱われてしま
う。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.
【0015】(b)の条件に関し、システムの非同期ダウ
ンが生じると、デッドロックを検出できるときと検出で
きないときが生じ、前記第2の要求における全デッドロ
ックの検出を行うことができない。なぜならば、分散処
理システムにおいてはシステム間の通信によって共通資
源へのアクセスをするわけであるが、その通信メッセー
ジの伝達が遅れる場合や通信異常により消失する場合が
あると、デッドロックが発生したこと自体不明となるか
らである。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.
【0016】同様に、(d)の条件に関し、システム間の
通信メッセージの遅延・消失が生じると、デッドロック
を検出できるときと検出できないときが生じ、前記第2
の要求における全デッドロックの検出を行うことができ
ない。なぜならば、一方のシステム作動中に他方のシス
テムがダウンしてしまうと、システムにおけるタスクに
関する管理情報が失われ、デッドロック検出の判定がで
きなくなるからである。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.
【0017】さらに、(c)の条件に関し、デッドロック
検出中にトランザクション待ち関係の変更があると、現
実にどのタスクがどの資源をロックしているかに関する
情報が混乱してしまうので、第1又は第2の要求を満た
すことができない。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】[0018]
【発明が解決しようとする課題】しかしながら、(c)の
条件は、デッドロック検出中における新たなトランザク
ション(タスク)の発生や待ち関係の発生を全て禁止す
ることを内容とするものである。すなわち、デッドロッ
ク検出のためには、システムにおける要求受付を一旦停
止する必要があるとする条件である。従って、本来デッ
ドロックに関係ない資源(その資源を仮に資源Zとす
る。)に要求を出しているタスクがあっても、その要求
を停止しなけらればならないことになる。従って、この
条件(c)を追求すると、かえってシステムの円滑な運用
が図れなくなり、第3の要求を満足できない結果とな
る。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.
【0019】なお、条件(a)に起因する疑似デッドロッ
クの検出を防ぐことは、現実には不可能である。すなわ
ち、各システムにどのような異常が生ずるかを予想しこ
れをすべて回避することは不可能であって、タスクが非
同期に異常終了することは防止することはできないから
である。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.
【0020】そこで、本発明の第1の技術的課題は、以
上の問題点に鑑み、デッドロック検出中のトランザクシ
ョン待ち関係の変更があってもデッドロック検出を継続
でき、それによりデッドロック検出を行うことによるシ
ステムへの影響を小さくすることができるデッドロック
検出装置を提供することである。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.
【0021】なお、本発明の第2の技術的課題は、分散
処理システムを対象としたデッドロック検出装置におい
て、システム間の通信メッセージの遅延・消失が発生し
た場合,デッドロック検出中のトランザクション待ち関
係の変更が有った場合,及びシステムの非同期ダウンが
生じた場合の何れにおいても、全てのデッドロックを検
出でき、疑似デッドロックを検出せず、通信のオーバー
ヘッドをできるだけ削減でき、デッドロック検出を行う
ことによるシステムへの影響を小さくすることができる
デッドロック検出装置を提供することをである。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】[0022]
【課題を解決するための手段】本発明は、前記第1の課
題を解決するために、図1の原理図のように、以下の手
段を採用した。In order to solve the first problem, the present invention adopts the following means as shown in the principle diagram of FIG.
【0023】<本発明の要旨>即ち、複数のタスク10
0が共通の資源101を利用するマルチタスクシステム
において前記複数のタスク100が互いに占有している
資源100を待ち合って停止してしまうデッドロックを
検出するためのデッドロック検出装置であって、複数の
タスク100を並列実行するために、前記タスク100
の実行を管理するタスク管理部(TM)102と、各タ
スクがどの資源100をロックしているかを管理するロ
ック管理部(LM)103と、一のタスクが他のタスク
がロックしている資源を獲得要求した場合には、前記一
のタスクが前記他のタスクを待っているとしてこの各タ
スクの「待ち関係」を登録する待ち管理テーブル(L
T)105と、前記ロック管理部(LM)103と非同
期で動作するとともに、前記待ち管理テーブル(LM)
103に登録された「待ち関係」からデッドロックを検
出するデッドロック検出部(DD)104とを備えたこ
とを特徴とする。<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.
【0024】以下に、本発明の構成要素の概要と、その
ポイントを簡単にまとめる。The outline of the components of the present invention and the points thereof will be briefly summarized below.
【0025】〔タスク〕“タスク”とは、通常CPU内
部における仕事の単位を意味する。本発明においては、
“タスク”を“トランザクション”と言い替えることが
できる。この“トランザクション”とは、ひとつの完結
したデータ操作を行うオペレーションの集まりを意味
し、“タスク”に含まれる概念であり、プログラムによ
って実行されるものである。要するに、本発明は、複数
のプログラムが同時に並行して実行されるとき、各プロ
グラムが資源を共有してロック状態となるのを検出しよ
うとするものである。よって、“タスク”との用語を用
いても、“トランザクション”との用語を用いても、単
にプログラムの実行単位との用語を用いても、本発明に
おいては、用語の差異は特に問題とはならない。以下、
“タスク”=“トランザクション”と理解しても本発明
の実施において何等の問題もない。また、本発明におい
て、各タスクが共有する資源とは、データの集合である
ファイルやファイルの中の下層的に記録されたレコード
などである。本発明でロックとは、或るタスク又はトラ
ンザクションがファイル全体を占有すること、あるい
は、ファイルの下の或るレコードを占有することをい
う。[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.
【0026】〔デッドロック検出〕デッドロック検出部
(DD)104におけるデッドロック検出は、例えば、
次の通りにすることができる。即ち、タスク(トランザ
クション)と資源の占有関係,即ち「待ち関係」を前記
待ち管理テーブル(LT)105により登録する。この
待ち管理テーブル(LT)105をデッドロック検出部
(DD)104が見て、デッドロックを検出する。この
検出は、前記ロック管理部(LM)103によるロック
管理とは別個に行われる。好ましくは、前記ロック管理
部(LM)103が、「あるタスクがある資源について
「待ち関係」となった」ことを検出したとき、デッドロ
ック検出部(DD)104に「待ち関係」を待ち管理テ
ーブル(LT)105に登録するよう要求する。そし
て、その登録内容を参照することでデッドロックの有無
を判定する。[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.
【0027】デッドロック検出のためにトランザクショ
ンの待ち関係を待ち管理テーブル(LT)105に登録
する方法としては、以下の方法が好適である。即ち、ト
ランザクションの待ち関係をグラフによって表現する。
このグラフを、ここではウェイトフォーグラフ(WF
G:Wait-forーgraph)と呼ぶ。このグラフを前記待ち管
理テーブル(LT)105に登録するのである。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.
【0028】このグラフにおいて、システムiで発生し
たトランザクションxをT(i,x)で定義し、システ
ムjで発生したトランザクションyをT(j,y)で定
義する。また、T(i,x)がT(j,y)について待
つこと,即ちT(j,y)がロックしている資源を解放
するのをT(i,x)が待つことを、 T(i,x)→T(j,y) と表すこととする。この場合、T(j,y)が終了しな
い限り、T(i,x)はそれ以上プロセスを進めること
ができない。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.
【0029】T(i,x)→T(j,y) と T(j,y)→T(i,x) とが同時に成立したときには、 T(i,x)→T(j,y)→T(i,x) というループが形成される。この場合はデッドロック状
態であるので、このループを検出することにより、デッ
ドロックの検出をすることができる。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.
【0030】ところで、以上は2つのシステム間でのデ
ッドロック検出例の説明であるが、自システム内でのデ
ッドロックは、 T(i,x)→T(i,y)→T(i,x) で表現される。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).
【0031】本発明の特徴点は、タスク管理部(TM)
102やロック管理部(LM)103等,タスクの実行
に必要なブロックから独立したデッドロック検出部(D
D)104をシステム(i,j)内に設け、このロック
管理部(LM)103とは非同期にデッドロック検出部
(DD)104を作動させる点にある。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.
【0032】従来のデッドロック検出方法においては、
デッドロックを検出するために、各タスクの実行を一旦
停止させていた。そして、その間に、ロック管理部(L
M)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.
【0033】これに対し、本発明では、タスク管理部
(TM)102やロック管理部(LM)103から分離
した待ち管理テーブル(LT)を設けて、前記ロック管
理部(LM)103からのロック情報を待ち管理テーブ
ル(LT)105に登録しておく。そして、タスクの実
行とは独立して作動するデッドロック検出部(DD)1
04を設けた。このデッドロック検出部(DD)104
は、あるタスクが資源を待つ状態に入ったという情報を
ロック管理部(LM)103が受けた時、そのタスクの
待ちの関係も踏まえて、前記待ち管理テーブル(LT)
105の登録内容を見てデッドロックの有無を判定する
ように構成することができる。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.
【0034】このように、本発明は、タスク管理部(T
M)102やロック管理部(LM)103等,タスクの
実行に必要なシステムから分離して、デッドロック検出
部(DD)104を設け、独立して作動させるため、デ
ッドロック検出の為にタスクの実行を停止する必要がな
い。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.
【0035】ところで、デッドロック検出部(DD)1
04によるデッドロック検出は、前記ロック管理部(L
M)103によってタスクの待ち関係が検出された時に
行うのが好ましい。すなわち、ロック管理部(LM)1
03によりタスクの待ち関係が検出された場合には、デ
ッドロック検出部(DD)104がその待ち関係を管理
テーブル(LT)105に登録する。この登録は、デッ
ドロック検出の開始用トリガーとなる。デッドロック検
出部(DD)104は、この登録の通知を受けることを
契機に、待ち管理テーブル(LT)105を参照してデ
ッドロックの有無検出を行う。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.
【0036】デッドロックが検出されたとき、いずれか
のタスクを強制的に異常終了させなければデッドロック
を修復できない。いずれのタスクを強制的に異常終了さ
せるかはシステムにより異なる。例えば、タスクの開始
時刻の遅い方が仕事量が少ないとみてそのタスクを終了
させても良い。あるいは、仕事量を実際に計上して少な
い仕事量のタスクを終了させるようにしても良い。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.
【0037】<分散システムへの適用>本発明によるデ
ッドロック検出装置は、複数のシステムを有する分散シ
ステム上に実現することができる。この様な分散システ
ムを採用する場合には、上記した第1の課題に加えて、
第2の課題の達成を考慮しなければならない。この場合
のデッドロック検出は以下の様になる。<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.
【0038】即ち、前記待ち管理テーブル(LT)10
5に前記「待ち関係」を登録する場合において、2以上
のタスク(x,y)が同一システム内のものであれば、
そのシステムに設けた待ち管理テーブル(LT)105
に各タスクにおける「待ち関係」を登録すれば足りる。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.
【0039】一方、あるシステムのタスクが他のシステ
ムのタスクに対して「待ち」の状態にある場合には、そ
の「待ち関係」を一方のシステムから他方のシステムの
待ち管理テーブル(LT)105へ通知すれば良い。こ
の通知を受けた待ち管理テーブル(LT)105は、こ
の「待ち関係」を登録する。この登録と同時に、他方の
システムのデッドロック検出部(DD)104がその待
ち管理テーブル(LT)105を見に行き、デッドロッ
クの有無を判定することができる。逆に、「待ち関係」
を他方のシステムから一方のシステムの待ち管理テーブ
ル(LT)105へ通知すれば、一方のシステムで、そ
の待ち管理テーブル(LT)105を見てデッドロック
の有無を判定できる。以上は、自己のシステムの待ち管
理テーブル(LT)105に、自己のシステムのタスク
の「待ち関係」と、その待ち先のシステムのタスクの
「待ち関係」を両方とも登録する場合のことである。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. .
【0040】これとは別に、自己のシステムの「待ち関
係」のみを自己の管理テーブル(LT)105に登録す
るようにしても良い。この場合には、デッドロック検出
をする際に、待ち先のシステムの待ち管理テーブル(L
T)105に通信でアクセスする。そして、自己のシス
テムのタスクの「待ち関係」と、その待ち先のタスクの
「待ち関係」とを突き合わせ、上述したループが形成さ
れていればデッドロックとして検出することができる。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.
【0041】本発明を分散システムに適用した場合、自
己システム内でのデッドロックに対しては、複数のシス
テム相互間でデッドロック検出のための情報の通信は行
わない。即ち、復数のシステム間でデッドロックが発生
した場合のみ情報の通信を行う。但し、デッドロックは
二者間で生じることがほとんどであるので、1回の通信
でデッドロックを検出できる。従って、上記第2の課題
を達成することができる。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.
【0042】<待ち時間管理テーブルの付加>上記した
本発明の必須の構成要件に、図2の原理図に示すよう
に、待ち時間監視部(WT)106を設けてもよい。こ
の待ち時間監視部(WT)106は、あるタスク(トラ
ンザクション)について「待ち関係」が一定時間継続し
ている場合に、そのタスク(トランザクション)につい
て再度資源獲得要求を出すブロックである。この待ち時
間監視部(WT)106を設ける目的は、以下に説明す
る通りである。<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.
【0043】即ち、デッドロックが生じても、デッドロ
ックを検出できないと、デッドロックを修復できない。
デッドロックが発生しているにも拘らずデッドロックを
検出することができない原因としては、通信の欠落によ
り管理テーブル(LT)105に「待ち関係」の情報が
登録されていないことが考えられる。そこで、あるタス
クにつき「待ち関係」が一定時間継続している場合に
は、待ち時間監視部(WT)106が再度資源獲得要求
を出すようにするのである。これにより、「待ち関係」
の情報をその待ち先のシステムの待ち管理テーブル(L
T)105に再度送信する契機を与えることができる。
従って、確実にデッドロックを検出することができる。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】[0044]
【作用】本発明によるデッドロック検出装置では、タス
クの実行状況は、タスク管理部(TM)102によって
管理される。この際、各タスクが資源を占有する場合に
は、ロック管理部(LM)103によって、どのタスク
がどの資源を占有したかについての情報が管理される。
そして、他のタスクが占有している資源を一のタスクが
獲得要求すると、この一のタスクは他のタスクの終了を
待たねばならない。この「待ち関係」は、待ち管理テー
ブル(LT)105において登録管理される。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.
【0045】この待ち管理テーブル(LT)105をデ
ッドロック検出部(DD)104が見て、デッドロック
を検出する。この検出は、ロック管理部(LM)103
によるロック管理とは別個に行われる。従って、デッド
ロック検出部(DD)104によるデッドロックが行わ
れていても、ロック管理部(LM)103はその動作を
行うことができる。よって、新たなタスクの発生や待ち
関係の発生を禁ずる必要がなくなる。そのため、デッド
ロック検出を行うことによるシステムへの影響を小さく
することができるのである。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】[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.
【0047】<システムの概要>図4には分散処理シス
テムの構成が示されている。この分散処理システムにお
いては、二つのコンピュータシステム(システムi及び
システムj)が分散して設けられ、相互にネットワーク
(NW)30によって接続されている。また、両コンピ
ュータシステム(i,j)とネットワーク(NW)30
によって接続され、且つ両コンピュータシステム(i,
j)からアクセス可能なデータベース(DB)20が設
けられている。このようなシステムは、例えば、預金シ
ステムに利用される。<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.
【0048】図4から明かなように、各コンピュータシ
ステム(システムi及びシステムj)は、トランザクシ
ョン管理部(TM)10,資源管理部(RM)11,ロ
ック管理部(LM)12,デッドロック検出部(DD)
15,待ち管理テーブルT3,及びウォッチドックタイ
マ(WT)13を備えている。なお、システムjはシス
テムiと全く同じ構成を有している。そのため、図4に
おいては、システムiについてのみその詳細な構成を示
し、システムjについてはその詳細な構成の図示を省略
した。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.
【0049】データベース(DB)20には、資源とし
てのファイル又はレコードが複数個格納されている。図
4においては、これら資源として、資源A及び資源Bを
例示した。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.
【0050】以下、各構成ブロックを詳細に説明する。Each constituent block will be described in detail below.
【0051】<トランザクション管理部(TM)>トラ
ンザクション管理部(TM)10は、複数のトランザク
ションの実行を管理している。トランザクション管理部
(TM)10を、タスク管理部(TM)10と言っても
良い。<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.
【0052】このトランザクション管理部(TM)10
は、応用プログラムからのトランザクション開始・正常
終了(commit)・異常終了(abort)の通信を受付け、
システム内でのトランザクションを管理するブロックで
ある。より詳しく言うと、例えばシステムiにおいてト
ランザクションxが開始されたときには、T(i,x)
という形式のデータを登録し、トランザクションxが終
了・異常終了したときにはこのT(i,x)という形式
のデータを削除するのである。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.
【0053】トランザクション管理部(TM)10は、
トランザクションから資源の要求を受け付けると、その
要求を資源管理部(RM)11に渡し、その応答(ok
/no)をもらう。また、トランザクション管理部(T
M)10は、デッドロック検出部(DD)15から送信
されたトランザクションのデッドロック通知を受け付け
て、トランザクションを終了させる。また、トランザク
ション管理部(TM)10は、デッドロック検出部(D
D)15から送信されたリトライ通知を受け付けて、資
源管理部(RM)11に資源獲得要求を再発行する。ま
た、トランザクション管理部(TM)10は、他のコン
ピュータシステム(システムj)のトランザクションの
正常終了や異常終了の通信を受信し、デッドロック検出
部(DD)15にグラフの登録・削除を要求する。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. .
【0054】図4において、“start”はトランザ
クションの実行開始を意味し、“abort”はトラン
ザクションの異常終了を意味し、“commit”はト
ランザクションの正常終了を意味する。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.
【0055】トランザクション管理部(TM)10にお
ける、資源獲得要求・資源解放要求は、二相ロック(2
PL:Two Phase Lock)方式で実行され
る。これは、疑似デッドロック(phantom de
adlock)の検出を防止するのに効果的である。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.
【0056】疑似デッドロックは、一般にグラフの登録
と削除が競合した場合に発生する。例えば、 T(i,x)→T(j,y) のグラフが既に登録されている場合において、 T(i,x)→T(j,y) の削除要求と T(j,y)→T(i,x) の登録要求とが、デッドロック検出部(DD)15に対
して同時に発生したとする。この際、削除要求が先に受
理された場合にはデッドロックが発生しない。これに対
して、登録要求が先に受理された場合には、疑似デッド
ロックとなる。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.
【0057】T(i,x)→T(j,y) の削除要求が発生するのは、このグラフで表される待ち
関係がなくなった場合である(即ち、T(j,y)が資
源のロックを解除した場合である。)。ロックの解除
は、トランザクションが自ら資源のロックを解除する場
合か非同期にabort(異常終了)する場合に行われ
る。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.
【0058】二相ロック方式は、ある処理がデータのロ
ック(占有)を始めたらロックし続け、ロックを解除し
始めたら解除し続けるという2つの相(フェーズ)から
なるロック方式である。この方式によれば、複数のタス
クやトランザクションがそれぞれ逐次実行されたのと同
一結果となる。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.
【0059】トランザクションが非同期にabort
(異常終了)しないとすれば、この方式により、一旦ロ
ックが解除されると、新たなロック獲得の要求が発生し
ないことを保証する。つまり、一旦発生したグラフ T(i,x)→T(j,y) は、T(j,y)が終了するまで削除されることはな
い。従って、上記の T(i,x)→T(j,y) の削除要求が発生した後においては、T(j,y)が終
了しているので、T(j,y)が新たな資源獲得要求を
することはない。よって、 T(j,y)→T(i,x) の登録要求が発生しないことを保証できる。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.
【0060】以上の理由により、この方式を採用するこ
とによって、疑似デッドロックの発生原因をトランザク
ションの非同期abort(異常終了)のみに限定する
ことができる。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).
【0061】<資源管理部(RM)>資源管理部(R
M)11は、このトランザクション管理部(TM)10
に双方向で接続されている。資源管理部(RM)11
は、資源管理デーブルT1を有している。資源管理部
(RM)11は、トランザクション管理部(TM)10
からの資源獲得要求及び資源解放要求の内容に基づい
て、トランザクションとそのトランザクションが要求し
ている資源との対応関係を、資源管理テーブルT1上に
マッピングして管理している。<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.
【0062】また、資源管理部(RM)11は、トラン
ザクション管理部(TM)10からの資源獲得要求に応
じてロック要求をロック管理部(LM)12に対して行
い、トランザクション管理部(TM)10からの資源解
放要求に応じて、ロック解放要求をロック管理部(L
M)12に対して行う。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
【0063】<ロック管理部(LM)>ロック管理部
(LM)12は、資源管理部(RM)11に双方向で接
続されている。ロック管理部(LM)12は、ロック管
理テーブルT2を有している。即ち、ロック管理部(L
M)12は、このロック管理テーブルT2によりロック
状態の管理を行う制御部である。<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.
【0064】トランザクションx,yと資源A、Bがあ
る場合において、トランザクションxが資源Aをロック
(占有)し、トランザクションyがBをロックしたとき
には、ロック管理部(LM)12は、この関係をロック
管理テーブルT2に登録する。即ち、図4に示すよう
に、xがAをロックした状態を例えば(x:A)と定義
し、yがBをロックした状態を例えば(y:B)と定義
し、この情報をロック管理テーブル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.
【0065】なお、このロック管理テーブルT2は、そ
のコンピュータシステム(i又はj)におけるトランザ
クションについてのロック情報を管理するばかりでな
く、他のコンピュータシステム(j又はi)におけるト
ランザクションについてのロック情報をも管理する。こ
の他のシステムにおけるトランザクションについてのロ
ック情報は、コンピュータシステム間で通信を行うこと
により獲得することができる。但し、各コンピュータシ
ステム(i,j)によって共用される共用メモリ上に単
一のロック管理テーブルT2を作成し、全コンピュータ
システム(i,j)における全トランザクションに関す
るロック情報を一括管理させれば、各コンピュータシス
テム間における通信の必要はなくなる。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.
【0066】いま、上述した状態において、更に資源管
理部(RM)11から、トランザクションyによる資源
Aのロック要求がなされ、トランザクションxによる資
源Bのロック要求がなされるとする。そうすると、ロッ
ク管理部(LM)12はロック管理テーブルT2の情報
を参照し、このようなロックができないことを認識す
る。この場合には、トランザクションyはトランザクシ
ョンxによる資源Aのロック解放を待ち、トランザクシ
ョンxはトランザクションyによる資源Bのロック解放
を待たねばならない。この待ち状態は、それぞれ、(x
→B)、(y→A)と定義される。このような定義が発
生したとき、ロック管理部(LM)12は「待ち」が発
生したと判断するのである。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.
【0067】本実施例では、このような「待ち関係」
を、ロック管理部(LM)12とは切り離して、待ち管
理テーブルT3に登録して管理する。即ち、「待ち関
係」が生じたときには、ロック管理部(LM)12は、
上記定義に基づいて、ウェイトフォーグラフ登録をデッ
ドロック検出部(DD)15に要求する。この要求の際
には、上記定義におけるトランザクション(x,y)が
どのコンピュータシステムにおけるトランザクションで
あるのか、及び、上記定義における資源(A,B)が現
在どのコンピュータシステムのどのトランザクションに
よってロックされているのかの情報も、デッドロック検
出部(DD)15に通知する。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.
【0068】ロック管理部(LM)12は、資源管理部
(RM)11からのロック要求が「待ち」にならない場
合には、資源管理部(RM)11に対してすぐに応答
(ok)を返す。ロック管理部(LM)12が判断して
「待ち」が発生した場合のみ、待ち関係を示すウェイト
フォーグラフを、待ち管理テーブルT3に登録する登録
要求キューを発行する。従って、「待ちが発生しない資
源獲得要求」に関しては、デッドロック検出中か否かに
拘らず、その資源獲得要求を行ったトランザクションの
実行処理は停止されない。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.
【0069】<デッドロック検出部(DD)>デッドロ
ック検出部(DD)15は、待ち管理テーブルT3の登
録内容からデッドロックの有無を判定する部分である。<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.
【0070】デッドロック検出部(DD)15は、要求
キュー受付部(QR)14を有する。この要求キュー受
付部(QR)14は自システムのロック管理部(LM)
12から待ち関係(ウェイトフォーグラフ)の登録・削
除要求キューを受け付ける。また、他のコンピュータシ
ステムからの待ち関係(ウェイトフォーグラフ)の登録
・削除要求キューを受け付ける。さらに、他システムの
トランザクションが異常終了(abort)又は正常終
了(commit)した場合には、トランザクション管
理部(TM)10からの待ち関係(ウェイトフォーグラ
フ)の削除要求キューを受け付ける。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.
【0071】デッドロック検出部(DD)15は、これ
ら要求キューに従い、先ずウェイトフォーグラフの登録
又は削除を、待ち管理テーブルT3に対して行う。この
ウェイトフォーグラフ(Wait・for・grap
h)の形式は以下の通りである。即ち、例えば、 システムiで発生したトランザクションx=T(i,
x)、システムjで発生したトランザクションy=T
(j,y) としたとき、 T(i,x)がT(j,y)について待
つことを T(i,x)→T(j,y)と表す。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).
【0072】ウェイトフォーグラフの登録を行う際に
は、デッドロック検出部(DD)15は、通知された情
報に基づいて、予めウェイトフォーグラフを作成する。
ウェイトフォーグラフの登録がなされると、デッドロッ
ク検出部(DD)15はデッドロック検出を開始する。
デッドロックが検出されたときは、デッドロック検出部
(DD)15は、トランザクション管理部(TM)10
にデッドロック通知を行う。ウェイトフォーグラフの削
除要求を受け付けた場合は、当該ウェイトフォーグラフ
を削除し、動作できるトランザクションに対しリトライ
通知を行う。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.
【0073】<待ち管理テーブルT3>待ち管理テーブ
ルT3には、ウェイトフォーグラフが登録される。上述
した通り、システムiで発生したトランザクションx
(資源Aを占有中)=T(i,x),システムjで発生
したトランザクションy(資源Bを占有中)=T(j,
y)としたとき、T(i,x)がT(j,y)について
待つことを T(i,x)→T(j,y) と表す。この場合、トランザクションyが占有している
資源Bを更新してT(j,y)が終了しない限り、トラ
ンザクションxは獲得しようとしている資源Bを使用で
きない。この状態を「待ち関係」といい、「T(i,
x)がT(j,y)について待つ」という。<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). "
【0074】デッドロック検出部(DD)15は、待ち
管理テーブルT3に、この T(i,x)→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".
【0075】一方、この T(i,x)→T(j,y) のグラフの成立と同時に T(j,y)→T(i,x) が成立していることがある。この場合、トランザクショ
ンxが占有している資源Aを更新してT(i,x)が終
了しない限り、トランザクションyは獲得しようとして
いる資源Aを使用できない。この2つの待ち関係を突き
合わせると、 T(i,x)→T(j,y)→T(j,y)→T(i,
x) というループが形成される。よって、このループが検出
されればデッドロックが発生しているということができ
るのである。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.
【0076】この待ち関係は、システムiのトランザク
ションxとシステムjのトランザクションyとの間で生
じている。そして、 T(i,x)→T(j,y) のグラフはシステムiの待ち管理テーブルT3に登録さ
れ、 T(j,y)→T(i,x) のグラフはシステムjの待ち管理テーブル(T3)に登
録される。このため、両者を突き合わせるためには、い
ずれかを他方に送信しなければならない。ここでは、
「待ち関係」が登録されるとき、その待ち先に「待ち関
係」を送信する。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.
【0077】すなわち、 T(i,x)→T(j,y) がシステムiの待ち管理テーブル(T3)に登録された
とき、システムiのデッドロッ検出部(DD)15は、
システムjの待ち管理テーブルT3に同一の内容のグラ
フを送信して登録する。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.
【0078】これにより、待ち先のシステム(即ち、シ
ステムj)において、待ち管理テーブルT3を参照すれ
ば、デッドロックを検出できる。なお、トランザクショ
ンxの「待ち関係」が解消したとき、トランザクション
xに関する「待ち関係」の情報を待ち先のシステム(即
ち、システムj)から回収(削除)しないと、いつまで
もデッドロックを検出してしまう。そこで、「待ち関
係」が解消した場合には、待ち先のシステム(即ち、シ
ステムj)の待ち管理テーブルT3から「待ち関係」を
示すグラフを削除・あるいは回収しなければならない。
デッドロック検出部(DD)15は、このようなグラフ
削除・回収機能をも有する。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.
【0079】ウェイトフォーグラフのループが検出され
ない場合、ウェエイトフォーグラフの先端が他のシステ
ムのトランザクションであれば、当該他のシステムにデ
ッドロックの可能性があることになる。そこで、当該他
のシステムにグラフ登録を要求する。他のシステムから
のグラフ登録の要求をを受け付けた場合は、デッドロッ
ク検出部(DD)15は必要なグラフを登録し、ループ
検出を行う。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.
【0080】この待ち関係は、自システム内で生じると
きがある。例えば、システムiで発生したトランザクシ
ョンx1=T(i,x1)が自システム(即ち、システム
i)で発生したトランザクションy1=T(i,y1)に
いて待つとき、自システム(即ち、システムi)の待ち
管理テーブルT3に、 T(i,x1)→T(i,y1) が登録される。ここで、自システム(即ち、システム
i)の待ち管理テーブルT3に、 T(i,y1)→T(i,x1) が登録されているなら、 T(i,x1)→T(i,y1)→T(i,y1)→T
(i,x1) というループが形成されるので、デッドロックが検出で
きる。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.
【0081】ところで、分散処理システムにあっては、
あるシステムで発生したトランザクションに関係するウ
ェイトフォーグラフ等の登録内容を、そのシステムのロ
ーカルウェイトフォーグラフという。また、分散処理シ
ステム全体での待ち関係を表現したグラフ,即ち、その
分散システムにおける全ローカルウェイトフォーグラフ
の集合を、グローバルウェイトフォーグラフという。図
5は、ローカルウェイトフォーグラフとグローバルウェ
イトフォーグラフの関係の例を示したものである。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.
【0082】各コンピュータシステムでは、ローカルウ
ェイトフォーグラフのみを待ち管理テーブルT3で管理
する。ここでは、前記したように、デッドロック検出部
(DD)15は、自コンピュータシステム内のトランザ
クション間の待ち関係を表すウェイトフォーグラフ等の
登録内容を他のコンピュータシステムに送信しない。一
方、デッドロック検出部(DD)15は、他のコンピュ
ータシステム内のトランザクションとの間の待ち関係を
表すウェイトフォーグラフを、関係を持った他システム
にのみ送信する。統計的に見てデッドロックの90%以
上が2つのタスク間で発生することを考慮すると、他シ
ステムのトランザクションに関連するデッドロックであ
っても、ほとんど1回の通信で検出することができる。
しかも、自コンピュータシステム内でのデッドロックで
あれば、通信なしで検出できる。従って、デッドロック
検出のための通信のオーバーヘッドを削減できる。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.
【0083】<待ち時間監視部(WT)>次に、待ち時
間監視部(WT)13は、待ち管理テーブルT3を監視
するタイマーである。このタイマーは、待ち管理テーブ
ルT3に登録されている「待ち関係」を監視する。そし
て、その「待ち関係」が登録されてから一定時間経過し
た時点で、なおその「待ち関係」が継続しているなら
ば、その「待ち関係」にある待ち元のトランザクション
が資源獲得要求を再発行するように、リトライ通知を発
行する。このリトライ通知は、要求キュー受付部(Q
R)14に投入される。このリトライ通知が要求キュー
受付部(QR)14に投入されると、デッドロック検出
部(DD)15は、トランザクション管理部(TM)1
0にリトライ通知を送る。トランザクション管理部(T
M)10は、このリトライ信号を受けて、待ち関係にあ
るトランザクションに対し、再度資源獲得要求を出す。<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.
【0084】システム間の通信メッセージの遅延・消失
やコンピュータシステムの非同期ダウンが発生すると、
実際はデッドロック状態であるのにこれを検出できない
場合がある。待ち時間監視部(WT)13は、このよう
な不都合を防止する。すなわち、分散処理システムにお
いて各コンピュータシステム間で通信するとき、通信の
欠落によりデッドロック状態を表示するグラフが欠落す
ることがある。すると、デッドロック検出ができなくな
る。これを防止するために、待ち関係にあるトランザク
ションを監視する機構として、前記待ち時間監視部(W
T:Watchdog Timer)13を設けたので
ある。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.
【0085】このタイマーは、一定時間以上ウェイトフ
ォーグラフの待ち先の関係にあるトランザクションに対
し、前述した様に、デッドロック検出部(DD)15を
介して、再度資源獲得要求することを促す。すると、ト
ランザクション監視部(TM:Transaction
Manager)10から、再度資源獲得要求が出さ
れる。このとき、既に「待ち」が解消されているなら、
この資源獲得要求は満たされる。これに対して、待ちが
解消されていないなら、他のコンピュータシステムに対
して再度ウェイトフォーグラフが送信される。これによ
りウェイトフォーグラフ欠落が補われ、デッドロックが
検出できる。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.
【0086】<各部の動作例>以下、前記各部の動作を
フローチャート図に従って説明する。 〔トランザクション管理部(TM)の動作〕図6に示し
たフローチャートのように、トランザクション管理部
(TM)10は、start(開始要求),abort
(異常終了),commit(正常終了),資源獲得要
求,デッドロック通知,リトライ通知などの各種要求を
待つ(ステップS101)。なお、ここで言うabor
t(異常終了),commit(正常終了)には、他の
コンピュータシステムから通知されたものも含む。何れ
かの要求を受け付ける(ステップS102)と、トラン
ザクション管理部(TM)10は、その要求の種類に従
って処理を振り分ける。<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.
【0087】ステップS102で受け付けた要求がst
art(開始要求)の場合、トランザクション管理部
(TM)10自身にそのトランザクション(ここでは、
仮にT(i,x)とする。)を登録し(ステップS10
3)、その後の要求を待つ。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.
【0088】ステップS102で受け付けた要求がab
ort(異常終了)又はcommit(正常終了)であ
る場合、先ず、その終了するトランザクション(ここで
は、仮にT(i,x)とする。)を削除する(ステップ
S104)。次に、資源管理部(RM)11に対し、資
源解放要求を発行する(ステップS105)。その資源
開放要求に対する応答を資源管理部(RM)11から受
けると(ステップS106)、デッドロック検出部(D
D)15にグラフ削除要求を出す(ステップS10
7)。その後、その要求が自コンピュータシステムから
の要求か否かを判定する(ステップS108)。他コン
ピュータシステムからの要求であればそのままとする。
これに対して、自コンピュータシステムからの要求であ
れば、他のコンピュータシステムに、commit又は
abortを通知する(ステップS109)。通知を受
けた他のコンピュータシステムでは、ステップS104
乃至107の処理を行う。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.
【0089】ステップS102で受け付けた要求が資源
獲得要求である場合、資源管理部(RM)11に資源獲
得要求を出す(ステップS110)。その要求に対する
応答を資源管理部(RM)11から受けたら(ステップ
S111)、トランザクションに応答を返す(ステップ
S112)。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).
【0090】ステップS102で受け付けた要求がデッ
ドロック通知である場合、まず、デッドロックとなって
いるトランザクションの中からabortさせるべきト
ランザクションを選択する(ステップS120)。即
ち、デッドロック通知には、デッドロックの関係にある
全トランザクション(ここでは、仮にT(i,x),T
(j,y)とする。)の特定が含まれている。トランザ
クション管理部(TM)10は、このデッドロック通知
に含まれているトランザクション名からabortさせ
るべきトランザクションを選択するのである。従って、
トランザクション管理部(TM)10は、他のコンピュ
ータシステムのトランザクションをも、abort対象
として特定することができる。次いで、トランザクショ
ン管理部(TM)10は、選択されたトランザクション
にabortすべき旨の通知をする(ステップS12
1)。選択されたトランザクションが他のコンピュータ
システムのものである場合には、当該他のコンピュータ
システムのトランザクション管理部(TM)10を介し
て、選択されたトランザクションにabortすべき旨
を通知する。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.
【0091】ステップS102で受け付けた要求がリト
ライ通知である場合、まず、資源管理部(RM)11に
資源獲得要求を出す(ステップS130)。その要求に
対する応答を資源管理部(RM)11からもらったら
(ステップS131)、トランザクションに応答を返す
(ステップS131)。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).
【0092】〔資源管理部(RM)の動作〕図7に示し
たフローチャートのように、資源管理部(RM)11
は、まず、資源獲得要求及び資源解放要求を待つ(ステ
ップS201)。何れかの要求があり、それが受理され
ると(ステップS202)、テーブル上に示された資源
をロックしようとし、その関係を資源獲得テーブルT1
に登録する(ステップS203)。即ち、どのトランザ
クションがどの資源をロックしようとするのかを登録す
る。[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.
【0093】その後、要求が資源獲得要求か資源解放要
求かを判定する(ステップS204)。要求が資源獲得
要求の場合、ロック管理部(LM)12にロック獲得要
求を出す(ステップS205)。これに対して、要求が
資源解放要求の場合、ロック管理部(LM)12にロッ
ク解放要求を出す(ステップS206)。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).
【0094】そして、ロック獲得要求又はロック解放要
求に対する応答(ok/no)をロック管理部(LM)
12から受けた後(ステップS207)、トランザクシ
ョン管理部(TM)10に応答(ok/no)を返す
(ステップS208)。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).
【0095】〔ロック管理部(LM)の動作〕図8に示
したフローチャートのように、資源管理部(RM)11
におけるステップS205又はステップS206の要求
があると(ステップS301)、ロック管理部(LM)
12は、要求を受け付ける(ステップS302)。その
後、要求がロック獲得要求かロック解放要求かを判定す
る(ステップS303)。要求がロック獲得要求である
場合には、ロック管理部(LM)12は、ロック獲得が
可能か否かを判定する(ステップS304)。[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).
【0096】資源のロックが可能であれば、そのロック
状態をロック管理テーブルT2に登録する(ステップS
305)。資源のロックが不可能であれば、「待ち関
係」であるので、要求側のトランザクションと待ち先の
トランザクションとの関係をウェイトフォーグラフとし
て待ち管理テーブルT3に登録する旨を、デッドロック
検出部(DD)15に対して要求する(ステップS30
6)。その後、資源管理部(RM)11にロックできな
かった旨(no)を返答する(ステップS309)。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).
【0097】ステップS303において要求が資源解放
要求であると判定された場合、ロック管理テーブルT2
からロックの登録を削除する(ステップS307)。ロ
ックの登録(ステップS305)とその削除(ステップ
S307)の後は、その完了(ok)を示す応答を、資
源管理部(RM)11に返す(ステップS308)。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).
【0098】〔デッドロック検出部(DD)の動作〕図
9に示したフローチャート図のように、デッドロック検
出部(DD)15には、グラフ登録要求,グラフ削除要
求,及びリトライ通知が、要求キュー受付部(QR)1
4に受け付けられる。従って、その要求があると(ステ
ップS401)、要求キュー受付部(QR)14から要
求を取り出し(ステップS402)、要求の種別を判定
する(ステップS403)。[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).
【0099】要求が、グラフ登録である場合には、先
ず、待ち管理テーブルT3にウェイトフォーグラフを登
録する(ステップS404)。但し、待ち管理テーブル
T3を検索した結果同一グラフが既に登録されていれ
ば、そのグラフは登録しない。次いで、登録したグラフ
につき、グラフの先端までたどる(ステップS40
5)。たどった結果によって、ループが形成されている
か判断する(ステップS406)。ループが形成されて
いれば、トランザクション管理部(TM)10にデッド
ロックを通知する(ステップS407)。ループが形成
されていなければ、グラフの先端が自コンピュータシス
テムか否かを判定する(ステップS408)。自コンピ
ュータシステムであればそのままステップS401に戻
る。これに対して、他コンピュータシステムであれば、
その他コンピュータシステムのデッドロック検出部(D
D)15に当該ウェイトフォーグラフを送信して、その
他システムの待ち管理テーブルT3に当該グラフを登録
させる(ステップS409)。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).
【0100】次に、ステップS403において、要求が
グラフの削除であるときは、待ち管理テーブルT3を検
索して、該当するグラフを探す(ステップS410)。
該当グラフを探しあてたら、該当グラフを削除する(ス
テップS411)。その後、待ち関係が解除されたトラ
ンザクションを動作させるため、トランザクション管理
部(TM)10にリトライ通知をする(ステップS41
2)。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).
【0101】ステップS403で要求がリトライ通知で
あるとき、まず、リトライするトランザクションのウェ
イトフォーグラフを削除する(ステップS420)。次
いで、トランザクション管理部(TM)10にリトライ
通知をする(ステップS421)。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).
【0102】〔待ち時間監視部(WT)の動作〕図10
に示したフローチャートのように、待ち時間監視部(W
T)13は、待ち管理テーブルT3に登録されている各
トランザクション(T(i,x)等)を順次検索する
(ステップS501)。次いで、そのトランザクション
xが「待ち関係」にあるか否かを判断する(ステップS
502)。検索されたトランザクションが「待ち関係」
でなければ、ステップS501に戻り、次のトランザク
ションを検索する。[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.
【0103】これに対して、検索されたトランザクショ
ンが「待ち関係」であれば、タイムカウントを開始し、
タイムアウトとなったら(ステップS503)、デッド
ロック検出部(DD)15にリトライ通知を行う(ステ
ップS504)。ステップS503でタイムアウトにな
る前に「待ち関係」が解消されたなら、ステップS50
1に戻る(ステップS502)。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).
【0104】<具体的なデッドロック検出の例>次に、
以上の構成におけるデッドロック検出例を、3通りの場
合に沿って説明する。 [例1 自コンピュータシステム内におけるデッドロッ
ク検出]例1は、自コンピュータシステム内におけるデ
ッドロック検出の例で、具体的には以下の動作を行う。
ここでは、他のコンピュータシステムとの間に通信が発
生しないことが解る。<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.
【0105】(1) 先ず、トランザクションT(1,
1)がトランザクション管理部(TM)10に対してト
ランザクションの開始を通知したとする。 (2) すると、トランザクション管理部(TM)10は
デッドロック検出部(DD)15にトランザクションT
(1,1)の登録を要求する。 (3) 一方、トランザクションT(1,2)がトランザ
クション管理部(TM)10に対してトランザクション
の開始を通知したとする。(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.
【0106】(4) すると、トランザクション管理部
(TM)10はデッドロック検出部(DD)15にトラ
ンザクションT(1,2)の登録を要求する。 (5) いま、トランザクションT(1,1)がトランザ
クション管理部(TM)10に資源Aを要求したとす
る。 (6) すると、トランザクション管理部(TM)10が
資源管理部(RM)11に資源Aの獲得を要求する。(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.
【0107】(7) すると、資源管理部(RM)11が
ロック管理部(LM)12に資源Aのロック獲得を要求
する。 (8) 資源Aが未ロックであれば、ロック管理部(L
M)12が資源管理部(RM)11にOKを応答する。 (9) すると、資源管理部(RM)11がトランザクシ
ョン管理部(TM)10にOKを応答する。(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.
【0108】(10) 一方、トランザクションT(1,
2)がトランザクション管理部(TM)10に資源Bを
要求したとする。 (11) すると、トランザクション管理部(TM)10が
資源管理部(RM)11に資源Bを獲得を要求する。 (12) すると、資源管理部(RM)11がロック管理部
(LM)12に資源Bのロック獲得を要求する。(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.
【0109】(13) 資源Bが未ロックであれば、ロック
管理部(LM)12が資源管理部(RM)11にOKを
応答する。 (14) すると、資源管理部(RM)11がトランザクシ
ョン管理部(TM)10にOKを応答する。 (15) この状態において、トランザクションT(1,
1)がトランザクション管理部(TM)10に資源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.
【0110】(16) すると、トランザクション管理部
(TM)10が資源管理部(RM)11に資源Bの獲得
を要求する。 (17) すると、資源管理部(RM)11がロック管理部
(LM)12に資源Bのロック獲得を要求する。(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.
【0111】(18) ところが、資源Bはトランザクショ
ンT(1,2)によって既にロック済みであるので、T
(1,1)がトランザクションT(1,2)に対して待
つことになる。そこで、ロック管理部(LM)12がデ
ッドロック検出部(DD)15にグラフ T(1,1)→T(1,2) の登録を要求する。要求を受けたデッドロック検出部
(DD)15は、このグラフを待ち管理テーブルT3に
登録する。(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.
【0112】(19) 一方、トランザクションT(1,
2)がトランザクション管理部(TM)10に資源Aを
要求したとする。 (20) すると、トランザクション管理部(TM)10が
資源管理部(RM)11に資源Aの獲得を要求する。 (21) すると、資源管理部(RM)11がロック管理部
(LM)12に資源Aのロック獲得を要求する。(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.
【0113】(22) ところが、資源Aはトランザクショ
ンT(1,1)によって既にロック済みであるので、T
(1,2)がトランザクションT(1,1)に対して待
つことになる。そこで、ロック管理部(LM)12がデ
ッドロック検出部(DD)15にグラフ T(1,2)→T(1,1) の登録を要求する。要求を受けたデッドロック検出部
(DD)15は、このグラフを待ち管理テーブルT3に
登録する。 (23) デッドロック検出部(DD)15がループを検出
し、デッドロック発生をトランザクション管理部(T
M)10に通知する。(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.
【0114】[例2 2つのコンピュータシステム間に
おける2つのトランザクションのデッドロック検出]例
2は、2つのコンピュータシステム(システム1,シス
テム2)間でデッドロックが発生する場合を示してい
る。ここでは、デッドロック検出のための通信が1回で
済むことがわかる。 (1) 先ず、システム1におけるトランザクションT
(1,1)が、システム1のトランザクション管理部
(TM)10に対しトランザクションの開始を通知した
とする。 (2) すると、システム1のトランザクション管理部
(TM)10は、デッドロック検出部(DD)15にト
ランザクションT(1,1)の登録を要求する。 (3) いま、トランザクションT(1,1)が、システ
ム1のトランザクション管理部(TM)10に、資源A
を要求したとする。[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.
【0115】(4) すると、システム1のトランザクシ
ョン管理部(TM)10が、資源管理部(RM)11に
資源Aの獲得を要求する。 (5) すると、システム1の資源管理部(RM)11
が、ロック管理部(LM)12に資源Aのロック獲得を
要求する。 (6) 資源Aが未ロックであれば、システム1のロック
管理部(LM)12が、資源管理部(RM)11にOK
を応答する。(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.
【0116】(7) すると、システム1の資源管理部
(RM)11が、トランザクション管理部(TM)10
にOKを応答する。 (1)’一方、システム2におけるトランザクショントラ
ンザクションT(2,1)が、システム2のトランザク
ション管理部(TM)10に対しトランザクションの開
始を通知したとする。 (2)’すると、システム2のトランザクション管理部
(TM)10は、デッドロック検出部(DD)15にト
ランザクションT(2,1)の登録を要求する。(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).
【0117】(3)’いま、トランザクションT(2,
1)が、システム2のトランザクション管理部(TM)
10に、資源Bを要求したとする。 (4)’すると、システム2のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Bの獲
得を要求する。 (5)’すると、システム2の資源管理部(RM)11
が、ロック管理部(LM)12に資源Bのロック獲得を
要求する。 (6)’資源Bが未ロックであれば、システム2のロック
管理部(LM)12が、資源管理部(RM)11にOK
を応答する。(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.
【0118】(7)’すると、システム2の資源管理部
(RM)11が、トランザクション管理部(TM)10
にOKを応答する。 (8) 以上の状況下において、トランザクションT
(1,1)がシステム1のトランザクション管理部(T
M)10に資源Bを要求したとする。 (9) すると、システム1のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Bの獲
得を要求する。(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.
【0119】(10) すると、システム1の資源管理部
(RM)11が、ロック管理部(LM)12に資源Bの
ロック獲得を要求する。 (11) ところが、資源Bはシステム2のトランザクショ
ンT(2,1)によって既にロック済みであるので、ト
ランザクションT(1,1)がトランザクションT
(2,1)に対して待つことになる。そこで、システム
1のロック管理部(LM)12が、デッドロック検出部
(DD)15にグラフ T(1,1)→T(2,1) の登録を要求する。(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).
【0120】(12) この要求を受けて、システム1のデ
ッドロック検出部(DD)15は、システム2にグラフ T(1,1)→T(2,1) を送信する。これと同時に、システム1のデッドロック
検出部(DD)15は、このグラフをシステム1の待ち
管理テーブルT3に登録する。 (13) システム2のデッドロック検出部(DD)15
が、このグラフ T(1,1)→(2,1) を受信し、これをシステム2の待ち管理テーブルT3に
登録する。(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.
【0121】(14) この後で、トランザクションT
(2,1)がシステム2のトランザクション管理部(T
M)10に資源Aを要求したとする。 (15) すると、システム2のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Aの獲
得を要求する。 (16) すると、システム2の資源管理部(RM)11
が、ロック管理部(LM)12に資源Aのロック獲得を
要求する。(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.
【0122】(17) ところが、資源Aはシステム1のト
ランザクションT(1,1)によって既にロック済みで
あるので、トランザクションT(2,1)がトランザク
ションT(1,1)に対して待つことになる。そこで、
システム2のロック管理部(LM)12が、デッドロッ
ク検出部(DD)15にグラフ T(2,1)→T(1,1) の登録を要求する。 (18) システム2のデッドロック検出部(DD)15が
ループを検出し、デッドロック発生をシステム2のトラ
ンザクション管理部(TM)10に通知する。(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.
【0123】[例3 2つのコンピュータシステム間に
おける2つのトランザクションのデッドロック検出中
に、メッセージの消失発生]例3では、2つのコンピュ
ータシステム(システム1,システム2)間での通信エ
ラーにより、メッセージ消失が発生した場合の例であ
る。 (1) 先ず、システム1におけるトランザクショントラ
ンザクションT(1,1)が、システム1のトランザク
ション管理部(TM)10に対しトランザクションの開
始を通知したとする。[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.
【0124】(2) すると、システム1のトランザクシ
ョン管理部(TM)10は、デッドロック検出部(D
D)15にトランザクションT(1,1)の登録を要求
する。 (3) いま、トランザクションT(1,1)が、システ
ム1のトランザクション管理部(TM)10に、資源A
を要求したとする。 (4) すると、システム1のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Aの獲
得を要求する。 (5) すると、システム1の資源管理部(RM)11
が、ロック管理部(LM)12に資源Aのロック獲得を
要求する。(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.
【0125】(6) 資源Aが未ロックであれば、システ
ム1のロック管理部(LM)12が、資源管理部(R
M)11にOKを応答する。 (7) すると、システム1の資源管理部(RM)11
が、トランザクション管理部(TM)10にOKを応答
する。 (1)’一方、システム2におけるトランザクションT
(2,1)が、システム2のトランザクション管理部
(TM)10に対しトランザクションの開始を通知した
とする。(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.
【0126】(2)’すると、システム2のトランザクシ
ョン管理部(TM)10は、デッドロック検出部(D
D)15にトランザクションT(2,1)の登録を要求
する。 (3)’いま、トランザクションT(2,1)が、システ
ム2のトランザクション管理部(TM)10に、資源B
を要求したとする。 (4)’すると、システム2のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Bの獲
得を要求する。(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.
【0127】(5)’すると、システム2の資源管理部
(RM)11が、ロック管理部(LM)12に資源Bの
ロック獲得を要求する。 (6)’資源Bが未ロックであれば、システム2のロック
管理部(LM)12が、資源管理部(RM)11にOK
を応答する。(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.
【0128】(7)’すると、システム2の資源管理部
(RM)11が、トランザクション管理部(TM)10
にOKを応答する。 (8) 以上の状況下において、トランザクションT
(1,1)がシステム1のトランザクション管理部(T
M)10に資源Bを要求したとする。 (9) すると、システム1のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Bの獲
得を要求する。(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.
【0129】(10) すると、システム1の資源管理部
(RM)11が、ロック管理部(LM)12に資源Bの
ロック獲得を要求する。 (11) ところが、資源Bはシステム2のトランザクショ
ンT(2,1)によって既にロック済みであるので、ト
ランザクションT(1,1)がトランザクションT
(2,1)に対して待つことになる。そこで、システム
1のロック管理部(LM)12が、デッドロック検出部
(DD)15にグラフ T(1,1)→T(2,1) の登録を要求する。(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).
【0130】(12) この要求を受けて、システム1のデ
ッドロック検出部(DD)15は、このグラフをシステ
ム1の待ち管理テーブルT3に登録する。これと同時
に、システム1のデッドロック検出部(DD)15は、
システム2にグラフ T(1,1)→T(2,1) を送信する。 (13) ただし、その送信内容は、通信エラーにより消失
して、システム2に届かなかった。(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.
【0131】(14) この後で、トランザクションT
(2,1)がシステム2のトランザクション管理部(T
M)10に資源Aを要求したとする。 (15) すると、システム2のトランザクション管理部
(TM)10が、資源管理部(RM)11に資源Aの獲
得を要求する。 (16) すると、システム2の資源管理部(RM)11
が、ロック管理部(LM)12に資源Aのロック獲得を
要求する。(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.
【0132】(17) ところが、資源Aはシステム1のト
ランザクションT(1,1)によって既にロック済みで
あるので、トランザクションT(2,1)がトランザク
ションT(1,1)に対して待つことになる。そこで、
システム2のロック管理部(LM)12が、デッドロッ
ク検出部(DD)15にグラフ T(2,1)→T(1,1) の登録を要求する。この時点で、実際にはデッドロック
状態が生じている。(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.
【0133】しかしながら、メッセージ消失によりデッ
ドロック状態は検出できないので、デッドロック状態が
持続することになる。 (18) 一定時間後、システム1の待ち時間監視部(W
T)13が起動され、システム1のデッドロック検出部
(DD)15に対してリトライ通知を行う。 (19) すると、システム1のデッドロック検出部(D
D)15は、トランザクション管理部(TM)10にト
ランザクションT(1,1)のリトライを通知する。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).
【0134】(20) リトライ通知に従って、システム1
のトランザクション管理部(TM)10が、資源管理部
(RM)11に資源Bの獲得を要求する。 (21) すると、システム1の資源管理部(RM)11
が、ロック管理部(LM)12に資源Bのロック獲得を
再度要求する。 (22) ところが、資源Bはシステム2のトランザクショ
ンT(2,1)によって既にロック済みであるので、ト
ランザクションT(1,1)がトランザクションT
(2,1)に対して待つことになる。そこで、システム
1のロック管理部(LM)12が、デッドロック検出部
(DD)15にグラフ T(1,1)→T(2,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).
【0135】(23) この要求を受けて、システム1のデ
ッドロック検出部(DD)15は、このグラフをシステ
ム1のウェイトフォーグラフテーブルT3に登録する。
これと同時に、システム2にグラフ T(1,1)→T(2,1) を再度送信する。 (24) システム2のデッドロック検出部(DD)15
が、このグラフ T(1,1)→T(2,1) を受信し、これをシステム2の待ち管理テーブルT3に
登録する。これにより、グラフの欠落が補われる。 (25) システム2のデッドロック検出部(DD)15が
ループを検出し、デッドロック発生をシステム2のTM
に通知する。(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】[0136]
【発明の効果】本発明では、以上説明したように、タス
ク(トランザクション)による資源のロック状態を管理
するロック管理部(LM)103と、デッドロック検出
部(DD)104とを分離し、双方が非同期に動作する
ようにした。そのため、タスク(トランザクション)が
新たに発生して資源を要求しても、待ちが発生せずロッ
クが獲得できる場合は、デッドロック検出部(DD)1
04を介せずに動作できる。従って、システムの円滑な
運用が図れ、処理の高速化を図れる。また、ロックが獲
得できない場合でも、ロック状態(グラフ)の登録やデ
ッドロックの検出はロックの要求とは非同期に動作する
ので影響は小さい。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.
【0137】特に、デッドロックを少なくするように設
計されたシステムで、デッドロック検出の与える影響は
極めて小さくなる。本発明が分散システムに適用された
場合、システムは他のシステムと待ち関係に陥った場合
にのみデッドロックのための通信を行う。したがって、
自システム内のみのデッドロックの検出では通信は発生
しない。他システムとの関連があった場合も、デッドロ
ックの90%以上が2者間で発生することから、ほとん
どの場合、1回の通信でデッドロックは検出される。こ
のため、通信のオーバーヘッドを削減でき、効率のよい
システム運用を図ることができる。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.
【0138】また、本発明で、待ち時間監視部(WT)
13を設けた場合、分散システムでのメッセージ通信中
にメッセージが遅延した場合や消失した場合でも、待ち
時間監視部(WT)13が再びデッドロック検出の契機
を与えるため、すべてのデッドロックを検出することが
できる。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]
【図1】 本発明の原理図1FIG. 1 is a diagram showing the principle of the present invention.
【図2】 本発明の原理図2FIG. 2 is a diagram showing the principle of the present invention.
【図3】 デッドロックを示す説明図FIG. 3 is an explanatory diagram showing a deadlock.
【図4】 実施例を示すブロック図FIG. 4 is a block diagram showing an embodiment.
【図5】 ローカルWFGとグローバルWFGの関係を
示す図FIG. 5 is a diagram showing a relationship between a local WFG and a global WFG.
【図6】 トランザクション管理部の動作を示すフロー
チャートFIG. 6 is a flowchart showing the operation of the transaction management unit.
【図7】 資源管理部の動作を示すフローチャートFIG. 7 is a flowchart showing the operation of the resource management unit.
【図8】 ロック管理部の動作を示すフローチャートFIG. 8 is a flowchart showing the operation of the lock management unit.
【図9】 デッドロック検出部の動作を示すフローチャ
ートFIG. 9 is a flowchart showing the operation of the deadlock detection unit.
【図10】 待ち時間監視部の動作を示すフローチャー
トFIG. 10 is a flowchart showing the operation of the waiting time monitoring unit.
10 トランザクション管理部 11 資源管理部 12 ロック管理部 13 待ち時間監視部 14 要求キュー受付部 15 デッドロック検出部 20 データベース T3 待ち管理テーブル 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)
01)を利用するマルチタスクシステムにおいて前記複
数のタスク(100)が互いに占有している資源(10
0)を待ち合って停止してしまうデッドロックを検出す
るためのデッドロック検出装置であって、 複数のタスク(100)を並列実行するために、前記タ
スク(100)の実行を管理するタスク管理部(10
2)と、 各タスクがどの資源(101)をロックしているかを管
理するロック管理部(103)と、 一のタスクが他のタスクがロックしている資源を獲得要
求した場合には、前記一のタスクが前記他のタスクを待
っているとしてこの各タスクの「待ち関係」を登録する
待ち管理テーブル(105)と、 前記ロック管理部(103)と非同期で動作するととも
に、前記待ち管理テーブル(105)に登録された「待
ち関係」からデッドロックを検出するデッドロック検出
部(104)とを備えたことを特徴とするデッドロック
検出装置。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).
クなどの資源をロックしているかの関係が登録されるロ
ック管理テーブル(T2)を有していることを特徴とす
る請求項1記載のデッドロック検出装置。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.
き、前記デッドロック検出部(104)は、前記待ち管
理テーブル(105)に「待ち関係」を登録するととも
に、前記待ち管理テーブル(105)を検索してデッド
ロックの有無を検出することを特徴とする請求項1記載
のデッドロック検出装置。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.
求キュー受付部(14)を有し、この要求キュー受付部
(14)で、前記デッドロック検出命令である「待ち関
係の登録要求」を受け付けることを特徴とする請求項1
記載のデッドロック検出装置。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.
テムを有する分散システム上に実現され、 各システムがそれぞれ前記タスク管理部(102)、前
記ロック管理部(103)、前記待ち管理テーブル(1
05)、前記デッドロック検出部(104)を備えてい
ることを特徴とする請求項1記載のデッドロック検出装
置。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).
ぞれが同一システム内にあるとき、そのシステムの待ち
管理テーブル(105)に各タスクにおける「待ち関
係」を登録する請求項5記載のデッドロック検出装置。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.
のタスクに対して「待ち」の状態にあるときには、その
「待ち関係」を前記一方のシステムから前記他方のシス
テムに通信して前記他方のシステムの待ち管理テーブル
(105)に登録し、前記他方のシステムにおいてその
待ち管理テーブル(105)を見てデッドロックの有無
を判定することを特徴とする請求項5記載のデッドロッ
ク検出装置。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.
ぞれが別のシステム内にあるときには、 各システムに設けた前記待ち管理テーブル(105)に
各タスクにおける「待ち関係」を登録するとともに、 自己のシステムのタスクが他のシステムのタスクに対し
て「待ち」の状態にある場合には、各システムのデッド
ロック検出部(104)は、その待ち先のシステムの待
ち管理テーブル(105)に通信でアクセスして自己の
システムの待ち管理テーブル(105)の登録内容を送
信するとともに、前記待ち先のシステムのデッドロック
検出部(104)に対して、自己のシステムの待ち管理
テーブル(105)の登録内容と待ち先のシステムの待
ち管理テーブル(105)の登録内容とを突き合わせて
デッドロックの有無を判定させることを特徴とする請求
項5記載のデッドロック検出装置。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.
獲得しようとしている資源をロックしている他のタスク
がその資源を解放することを待つ関係であることを特徴
とする請求項1記載のデッドロック検出装置。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.
が獲得しようとしている資源をロックしている他のタス
クが終了することを待つ関係であることを特徴とする請
求項1記載のデッドロック検出装置。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.
(i,x)で定義し、システムjで発生したタスクyを
T(j,y)で定義し、T(i,x)がT(j,y)に
ついて待つことをT(i,x)→T(j,y)と表して
これを「待ち関係」の情報として前記待ち管理テーブル
(T3)に登録し、T(i,x)→T(j,y)とT
(j,y)→T(i,x)とが成立したとき、T(i,
x)→T(j,y)→T(i,x)というループを検出
することでデッドロックと判定することを特徴とする請
求項10記載のデッドロック検出装置。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).
ステムを有する分散システム上に実現され、あるタスク
について「待ち関係」が一定時間継続している場合に、
そのタスクに対して再度資源獲得要求を出す待ち時間監
視部(106)を備えたことを特徴とする請求項1記載
のデッドロック検出装置。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.
理がデータのロック(占有)を始めたらロックし続け、
ロックを解除し始めたら解除し続けるという二相ロック
方式によりタスク管理をすることを特徴とする請求項1
又は9記載のデッドロック検出装置。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.
得要求に対し「待ち関係」が発生した場合のみ「待ち関
係」を待ち管理テーブル(105)に登録して、デッド
ロック検出を行うためのデッドロック検出命令を発行
し、「待ち関係」が発生しない資源獲得要求に対しては
トランザクションの実行処理を停止しないことを特徴と
する請求項1記載のデッドロック検出装置。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.
先のシステムの待ち管理テーブル(T3)から、当該
「待ち関係」の登録を削除することを特徴とする請求項
1記載のデッドロック検出装置。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.
(101)を利用するマルチタスクシステムにおいて前
記複数のタスク(100)が互いに占有している資源
(101)を待ち合って停止してしまうデッドロックを
検出するためのデッドロック検出装置であって、 複数のタスク(100)を並列実行するために、前記タ
スク(100)の実行を管理するタスク管理部(10
2)と、 タスク(100)とそれによりロックされている資源
(101)との関係を登録する第1のテーブル(T2)
と、 各タスク(100)がどの資源(101)をロックして
いるかを管理し、他のタスクによりロックされているも
のとして前記第1のテーブル(T2)に登録されている
資源を一のタクスが獲得要求した場合には、前記一のタ
スクが前記他のタスクを待っている「待ち関係」の発生
を検出するロック管理部(103)と、 前記待ち関係を登録する第2のテーブル(T3)と、 前記ロック管理部(103)とは非同期に動作するとと
もに、この第2のテーブル(T3)に登録された「待ち
関係」から、デッドロックを検出するデッドロック検出
部(104)とからなることを特徴とするデッドロック
検出装置。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.
テムを有する分散システム上に実現され、あるタスク
(100)について「待ち関係」が一定時間継続してい
る場合に、そのタスク(100)に対して再度資源獲得
要求を出す待ち時間監視部(106)を備えたことを特
徴とする請求項16記載のデッドロック検出装置。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.
(101)を利用するマルチタスクシステムにおいて前
記複数のタスク(100)が互いに占有している資源
(101)を待ち合って停止してしまうデッドロックを
検出するためのデッドロック検出方法であって、 各タスク(100)がどの資源(101)をロックして
いるかを認識し、 一のタスクが獲得要求している資源が既に他のタスクに
よってロックされているか否かを検知し、 資源が既に他のタスクによってロックされていることを
検知した場合には、前記一のタスクが前記他のタスクを
待っていると認識し、この「待ち関係」を登録し、 登録された「待ち関係」が各タスクが互いに待ち合って
いることを示す場から、デッドロックとして検出するこ
とを特徴とするデッドロック検出方法。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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP06177194A JP3681415B2 (en) | 1993-03-30 | 1994-03-30 | Deadlock detection device |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP5-96928 | 1993-03-30 | ||
JP9692893 | 1993-03-30 | ||
JP06177194A JP3681415B2 (en) | 1993-03-30 | 1994-03-30 | Deadlock detection device |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH06337798A true JPH06337798A (en) | 1994-12-06 |
JP3681415B2 JP3681415B2 (en) | 2005-08-10 |
Family
ID=26402842
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP06177194A Expired - Fee Related JP3681415B2 (en) | 1993-03-30 | 1994-03-30 | Deadlock detection device |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3681415B2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006525573A (en) * | 2003-05-01 | 2006-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Managing locks and transactions |
JP2007219809A (en) * | 2006-02-16 | 2007-08-30 | Nec Corp | Data storage system, data storage method, and data storage program |
JP2009271858A (en) * | 2008-05-09 | 2009-11-19 | Toshiba Corp | Computing system and program |
WO2010038280A1 (en) * | 2008-10-01 | 2010-04-08 | 富士通株式会社 | Virtual machine system and deadlock release method |
JP2015075871A (en) * | 2013-10-08 | 2015-04-20 | 株式会社リコー | Exclusive control program, information processing apparatus, and exclusive control method |
US9590908B2 (en) | 2014-03-31 | 2017-03-07 | Fujitsu Limited | Distributed data processing device and distributed data processing method |
US9723167B2 (en) | 2015-04-02 | 2017-08-01 | Canon Kabushiki Kaisha | Managing the activation of an application in an information processing apparatus on which a plurality of applications operate |
-
1994
- 1994-03-30 JP JP06177194A patent/JP3681415B2/en not_active Expired - Fee Related
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006525573A (en) * | 2003-05-01 | 2006-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Managing locks and transactions |
JP2007219809A (en) * | 2006-02-16 | 2007-08-30 | Nec Corp | Data storage system, data storage method, and data storage program |
JP2009271858A (en) * | 2008-05-09 | 2009-11-19 | Toshiba Corp | Computing system and program |
WO2010038280A1 (en) * | 2008-10-01 | 2010-04-08 | 富士通株式会社 | Virtual machine system and deadlock release method |
JP2015075871A (en) * | 2013-10-08 | 2015-04-20 | 株式会社リコー | Exclusive control program, information processing apparatus, and exclusive control method |
US9590908B2 (en) | 2014-03-31 | 2017-03-07 | Fujitsu Limited | Distributed data processing device and distributed data processing method |
US9723167B2 (en) | 2015-04-02 | 2017-08-01 | Canon Kabushiki Kaisha | Managing the activation of an application in an information processing apparatus on which a plurality of applications operate |
Also Published As
Publication number | Publication date |
---|---|
JP3681415B2 (en) | 2005-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5845117A (en) | Deadlock detecting device | |
JP3392236B2 (en) | Distributed transaction processing system | |
US8286182B2 (en) | Method and system for deadlock detection in a distributed environment | |
AU707393B2 (en) | System and method for space efficient object locking | |
US8181183B2 (en) | Method, system and program products for managing thread pools of a computing environment to avoid deadlock situations | |
US7600063B2 (en) | Techniques for improved read-write concurrency | |
KR930000853B1 (en) | Database processing system using multiprocessor system | |
JP2705717B2 (en) | Locking device and method, device and method for determining granularity of lock request | |
US6879981B2 (en) | Sharing live data with a non cooperative DBMS | |
US5317739A (en) | Method and apparatus for coupling data processing systems | |
US6658490B1 (en) | Method and system for multi-threaded processing | |
EP0684569A1 (en) | Database system | |
US20090300017A1 (en) | Transaction Parallel Control Method, and Database Managemet System | |
JPH03161859A (en) | Request control method and access control system | |
JPH07191944A (en) | System and method for prevention of deadlock in instruction to many resources by multiporcessor | |
JPH05197604A (en) | Multiprocessor computer and operating method thereof | |
US5764976A (en) | Method and system of deadlock detection in a data processing system having transactions with multiple processes capable of resource locking | |
US6721775B1 (en) | Resource contention analysis employing time-ordered entries in a blocking queue and waiting queue | |
US20210318985A1 (en) | Leader election with lifetime term | |
US7574439B2 (en) | Managing a nested request | |
US6681241B1 (en) | Resource contention monitoring employing time-ordered entries in a blocking queue and waiting queue | |
JPH06337798A (en) | Deadlock detecting device | |
JP2804478B2 (en) | Task control system and online transaction system | |
US6236995B1 (en) | Distributed object system with deadlock prevention | |
JP2610926B2 (en) | Transaction control method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040224 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040426 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040525 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050412 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050518 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080527 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090527 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090527 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100527 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |