JP3681415B2 - デッドロック検出装置 - Google Patents

デッドロック検出装置 Download PDF

Info

Publication number
JP3681415B2
JP3681415B2 JP06177194A JP6177194A JP3681415B2 JP 3681415 B2 JP3681415 B2 JP 3681415B2 JP 06177194 A JP06177194 A JP 06177194A JP 6177194 A JP6177194 A JP 6177194A JP 3681415 B2 JP3681415 B2 JP 3681415B2
Authority
JP
Japan
Prior art keywords
waiting
deadlock
task
resource
transaction
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.)
Expired - Fee Related
Application number
JP06177194A
Other languages
English (en)
Other versions
JPH06337798A (ja
Inventor
和彦 藤田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP06177194A priority Critical patent/JP3681415B2/ja
Publication of JPH06337798A publication Critical patent/JPH06337798A/ja
Application granted granted Critical
Publication of JP3681415B2 publication Critical patent/JP3681415B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Description

【0001】
【産業上の利用分野】
本発明はマルチタスクシステムにおけるデッドロックの検出装置に関する。
【0002】
【従来の技術】
近年、コンピュータを用いた情報処理システムにおいて、複数のタスクあるいはトランザクションを同時に実行するマルチタスクシステムが発達してきた。タスクとは、CPU内部における仕事の単位である。トランザクションとは、ひとつの完結したデータ操作を行うオペレーションの集まりである。マルチタスクとは、複数のプログラム(タスク,トランザクション)が、単一のコンピュータシステム,又は相互に情報交換可能に接続された複数のコンピュータシステム上で、同時に並行して実行される状態である。
【0003】
このマルチタスクシステムでは、2以上のタスクが資源を共用する場合がある。その場合において、2以上のタスクの夫々が、そのタクスの実行に必要であり且つ他方のタクスの実行にも必要な複数の資源を、一部づつを占有(ロック)し合うケースが生じ得る。そのケースでは、お互いに他方のタクスが占有(ロック)している資源を待ち合うので、双方のタスクが停止し、それ以上プロセスを実行できない状態となってしまう。このような状態は、デッドロックの状態と呼ばれている。
【0004】
図3に、デッドロックの状態の例を示す。図3の例は、2つのコンピュータシステムi,jから構成される分散システムにおける例を示している。一方のコンピュータシステムiではタスクxが実行され、他方のコンピュータシステムjではタスクyが実行されている。また、各コンピュータシステムi,jでアクセスできる資源として、A,Bという2つの資源があるとする。なお、資源とは、タスクに割り当てられるプログラム,ファイル,データ等のソフトウェアを指す。ここでは、各コンピュータシステムi,j外に存在するデータベースの中身(ページ,レコード等)として説明する。
【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の解除もできなくなってしまうので、この状態は永遠に続くことになる。よって、各タスクはそれ以上のプロセスを実行できない。
【0006】
このようなデッドロックは、コンピュータシステムがマルチプロセッサ方式のシステムであるかシングルプロセッサ方式のシステムであるか,あるいは、コンピュータシステムがスタンドアローンで運用されるのか分散処理システムを構成するのかに拘らず、システムがマルチタスクシステムであれば生じ得る問題である。
【0007】
このようなデッドロックが生じたとき、これを修復する手段を講じなければならない。そのためには、前提としてデッドロックが生じたことを検出しなければならない。
【0008】
デッドロック検出には、実用性を向上させる理由から、以下のスペックを満たすことが要求される。
第1に、実際はデッドロックではないにも拘らずデッドロックと誤認してしまう現象,すなわち疑似デッドロック(phantom deadlock)の検出が防止されていなければならない(第1の要求)。
【0009】
第2に、全てのデッドロックが検出されなければならない。換言すれば、現実にデットロックが生じているに場合には、デッドロックを検出できるときと検出できないときがあってはならず、全てデッドロックであると検出されなければならない(第2の要求)。
【0010】
第3に、デッドロック検出を行うことによるシステムへの影響を小さく抑えなければならない。即ち、デッドロックを検出するためにタスクを停止するようなことは、できるだけ避けなければならない(第3の要求)。
【0011】
なお、マルチタスクシステムを分散処理システム上で実現する場合には、上記各要求の他に次のスペックが要求される。即ち、デッドロックを検出するためにシステム間で通信を行う必要があるが、この通信のオーバーヘッドをできるだけ削減しなければならない(第4の要求)。
【0012】
従来のデッドロック検出装置では、以下のようなような条件を満足させることによって、上述した第1乃至第3の要求を満足してデッドロックを検出しようとしていた。その条件とは、
(a) トランザクションの非同期abort(異常終了)が発生しないこと,
(b) マルチタスクシステムを分散処理システム上で実現する場合には、各システム間の通信メッセージの遅延・消失が発生しないこと,
(c) デッドロック検出中のトランザクション待ち関係の変更がないこと。
【0013】
(d) マルチタスクシステムを分散処理システム上で実現する場合には、システムの非同期ダウンが発生していないこと,である。
【0014】
上述の第1乃至第3の要求と(a)乃至(d)の条件との関係の関係を説明する。
(a)の条件に関し、トランザクションの非同期abort(異常終了)が発生すると、前記第1の要求における疑似デッドロック(phantom deadlock)の検出防止を図ることができない。例えば、タスク(トランザクション)xが資源Aをロックしており、タスク(トランザクション)yが資源Bをロックしている場合、タスクyが資源Aを待ち、タスクxが資源Bに待ち要求を出した時点で、タスクyが非同期に異常終了してしまったとする。この場合、タスクyの非同期終了によってタスクyによる資源Bのロックが解除されるので、タスクxは資源Bをロックできる。従って、本来ならばデッドロックは発生しないはずである。しかし、タスクyの非同期異常終了による資源Bのロック解除は直ちに検出できないので、現実には、デッドロックが発生していないにもかかわらずデッドロックが発生したものとして扱われてしまう。
【0015】
(b)の条件に関し、システムの非同期ダウンが生じると、デッドロックを検出できるときと検出できないときが生じ、前記第2の要求における全デッドロックの検出を行うことができない。なぜならば、分散処理システムにおいてはシステム間の通信によって共通資源へのアクセスをするわけであるが、その通信メッセージの伝達が遅れる場合や通信異常により消失する場合があると、デッドロックが発生したこと自体不明となるからである。
【0016】
同様に、(d)の条件に関し、システム間の通信メッセージの遅延・消失が生じると、デッドロックを検出できるときと検出できないときが生じ、前記第2の要求における全デッドロックの検出を行うことができない。なぜならば、一方のシステム作動中に他方のシステムがダウンしてしまうと、システムにおけるタスクに関する管理情報が失われ、デッドロック検出の判定ができなくなるからである。
【0017】
さらに、(c)の条件に関し、デッドロック検出中にトランザクション待ち関係の変更があると、現実にどのタスクがどの資源をロックしているかに関する情報が混乱してしまうので、第1又は第2の要求を満たすことができない。
【0018】
【発明が解決しようとする課題】
しかしながら、(c)の条件は、デッドロック検出中における新たなトランザクション(タスク)の発生や待ち関係の発生を全て禁止することを内容とするものである。すなわち、デッドロック検出のためには、システムにおける要求受付を一旦停止する必要があるとする条件である。従って、本来デッドロックに関係ない資源(その資源を仮に資源Zとする。)に要求を出しているタスクがあっても、その要求を停止しなけらればならないことになる。従って、この条件(c)を追求すると、かえってシステムの円滑な運用が図れなくなり、第3の要求を満足できない結果となる。
【0019】
なお、条件(a)に起因する疑似デッドロックの検出を防ぐことは、現実には不可能である。すなわち、各システムにどのような異常が生ずるかを予想しこれをすべて回避することは不可能であって、タスクが非同期に異常終了することは防止することはできないからである。
【0020】
そこで、本発明の第1の技術的課題は、以上の問題点に鑑み、デッドロック検出中のトランザクション待ち関係の変更があってもデッドロック検出を継続でき、それによりデッドロック検出を行うことによるシステムへの影響を小さくすることができるデッドロック検出装置を提供することである。
【0021】
なお、本発明の第2の技術的課題は、分散処理システムを対象としたデッドロック検出装置において、システム間の通信メッセージの遅延・消失が発生した場合,デッドロック検出中のトランザクション待ち関係の変更が有った場合,及びシステムの非同期ダウンが生じた場合の何れにおいても、全てのデッドロックを検出でき、疑似デッドロックを検出せず、通信のオーバーヘッドをできるだけ削減でき、デッドロック検出を行うことによるシステムへの影響を小さくすることができるデッドロック検出装置を提供することをである。
【0022】
【課題を解決するための手段】
本発明は、前記第1の課題を解決するために、図1の原理図のように、以下の手段を採用した。
【0023】
<本発明の要旨>
即ち、複数のタスク100が共通の資源101を利用するマルチタスクシステムにおいて前記複数のタスク100が互いに占有している資源100を待ち合って停止してしまうデッドロックを検出するためのデッドロック検出装置であって、複数のタスク100を並列実行するために、前記タスク100の実行を管理するタスク管理部(TM)102と、各タスクがどの資源100をロックしているかを管理するロック管理部(LM)103と、一のタスクが他のタスクがロックしている資源を獲得要求した場合には、前記一のタスクが前記他のタスクを待っているとしてこの各タスクの「待ち関係」を登録する待ち管理テーブル(LT)105と、前記ロック管理部(LM)103と非同期で動作するとともに、前記待ち管理テーブル(LM)103に登録された「待ち関係」からデッドロックを検出するデッドロック検出部(DD)104とを備えたことを特徴とする。
【0024】
以下に、本発明の構成要素の概要と、そのポイントを簡単にまとめる。
【0025】
〔タスク〕
“タスク”とは、通常CPU内部における仕事の単位を意味する。本発明においては、“タスク”を“トランザクション”と言い替えることができる。この“トランザクション”とは、ひとつの完結したデータ操作を行うオペレーションの集まりを意味し、“タスク”に含まれる概念であり、プログラムによって実行されるものである。要するに、本発明は、複数のプログラムが同時に並行して実行されるとき、各プログラムが資源を共有してロック状態となるのを検出しようとするものである。よって、“タスク”との用語を用いても、“トランザクション”との用語を用いても、単にプログラムの実行単位との用語を用いても、本発明においては、用語の差異は特に問題とはならない。以下、“タスク”=“トランザクション”と理解しても本発明の実施において何等の問題もない。また、本発明において、各タスクが共有する資源とは、データの集合であるファイルやファイルの中の下層的に記録されたレコードなどである。本発明でロックとは、或るタスク又はトランザクションがファイル全体を占有すること、あるいは、ファイルの下の或るレコードを占有することをいう。
【0026】
〔デッドロック検出〕
デッドロック検出部(DD)104におけるデッドロック検出は、例えば、次の通りにすることができる。即ち、タスク(トランザクション)と資源の占有関係,即ち「待ち関係」を前記待ち管理テーブル(LT)105により登録する。この待ち管理テーブル(LT)105をデッドロック検出部(DD)104が見て、デッドロックを検出する。この検出は、前記ロック管理部(LM)103によるロック管理とは別個に行われる。好ましくは、前記ロック管理部(LM)103が、「あるタスクがある資源について「待ち関係」となった」ことを検出したとき、デッドロック検出部(DD)104に「待ち関係」を待ち管理テーブル(LT)105に登録するよう要求する。そして、その登録内容を参照することでデッドロックの有無を判定する。
【0027】
デッドロック検出のためにトランザクションの待ち関係を待ち管理テーブル(LT)105に登録する方法としては、以下の方法が好適である。即ち、トランザクションの待ち関係をグラフによって表現する。このグラフを、ここではウェイトフォーグラフ(WFG:Wait-forーgraph)と呼ぶ。このグラフを前記待ち管理テーブル(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)はそれ以上プロセスを進めることができない。
【0029】
T(i,x)→T(j,y)

T(j,y)→T(i,x)
とが同時に成立したときには、
T(i,x)→T(j,y)→T(i,x)
というループが形成される。この場合はデッドロック状態であるので、このループを検出することにより、デッドロックの検出をすることができる。
【0030】
ところで、以上は2つのシステム間でのデッドロック検出例の説明であるが、自システム内でのデッドロックは、
T(i,x)→T(i,y)→T(i,x)
で表現される。
【0031】
本発明の特徴点は、タスク管理部(TM)102やロック管理部(LM)103等,タスクの実行に必要なブロックから独立したデッドロック検出部(DD)104をシステム(i,j)内に設け、このロック管理部(LM)103とは非同期にデッドロック検出部(DD)104を作動させる点にある。
【0032】
従来のデッドロック検出方法においては、デッドロックを検出するために、各タスクの実行を一旦停止させていた。そして、その間に、ロック管理部(LM)103におけるロック情報に基づいてデッドロックの有無を判定していた。しかしながら、これでは、タスクの円滑な実行を確保できない。
【0033】
これに対し、本発明では、タスク管理部(TM)102やロック管理部(LM)103から分離した待ち管理テーブル(LT)を設けて、前記ロック管理部(LM)103からのロック情報を待ち管理テーブル(LT)105に登録しておく。そして、タスクの実行とは独立して作動するデッドロック検出部(DD)104を設けた。このデッドロック検出部(DD)104は、あるタスクが資源を待つ状態に入ったという情報をロック管理部(LM)103が受けた時、そのタスクの待ちの関係も踏まえて、前記待ち管理テーブル(LT)105の登録内容を見てデッドロックの有無を判定するように構成することができる。
【0034】
このように、本発明は、タスク管理部(TM)102やロック管理部(LM)103等,タスクの実行に必要なシステムから分離して、デッドロック検出部(DD)104を設け、独立して作動させるため、デッドロック検出の為にタスクの実行を停止する必要がない。
【0035】
ところで、デッドロック検出部(DD)104によるデッドロック検出は、前記ロック管理部(LM)103によってタスクの待ち関係が検出された時に行うのが好ましい。すなわち、ロック管理部(LM)103によりタスクの待ち関係が検出された場合には、デッドロック検出部(DD)104がその待ち関係を管理テーブル(LT)105に登録する。この登録は、デッドロック検出の開始用トリガーとなる。デッドロック検出部(DD)104は、この登録の通知を受けることを契機に、待ち管理テーブル(LT)105を参照してデッドロックの有無検出を行う。
【0036】
デッドロックが検出されたとき、いずれかのタスクを強制的に異常終了させなければデッドロックを修復できない。いずれのタスクを強制的に異常終了させるかはシステムにより異なる。例えば、タスクの開始時刻の遅い方が仕事量が少ないとみてそのタスクを終了させても良い。あるいは、仕事量を実際に計上して少ない仕事量のタスクを終了させるようにしても良い。
【0037】
<分散システムへの適用>
本発明によるデッドロック検出装置は、複数のシステムを有する分散システム上に実現することができる。この様な分散システムを採用する場合には、上記した第1の課題に加えて、第2の課題の達成を考慮しなければならない。この場合のデッドロック検出は以下の様になる。
【0038】
即ち、前記待ち管理テーブル(LT)105に前記「待ち関係」を登録する場合において、2以上のタスク(x,y)が同一システム内のものであれば、そのシステムに設けた待ち管理テーブル(LT)105に各タスクにおける「待ち関係」を登録すれば足りる。
【0039】
一方、あるシステムのタスクが他のシステムのタスクに対して「待ち」の状態にある場合には、その「待ち関係」を一方のシステムから他方のシステムの待ち管理テーブル(LT)105へ通知すれば良い。この通知を受けた待ち管理テーブル(LT)105は、この「待ち関係」を登録する。この登録と同時に、他方のシステムのデッドロック検出部(DD)104がその待ち管理テーブル(LT)105を見に行き、デッドロックの有無を判定することができる。逆に、「待ち関係」を他方のシステムから一方のシステムの待ち管理テーブル(LT)105へ通知すれば、一方のシステムで、その待ち管理テーブル(LT)105を見てデッドロックの有無を判定できる。以上は、自己のシステムの待ち管理テーブル(LT)105に、自己のシステムのタスクの「待ち関係」と、その待ち先のシステムのタスクの「待ち関係」を両方とも登録する場合のことである。
【0040】
これとは別に、自己のシステムの「待ち関係」のみを自己の管理テーブル(LT)105に登録するようにしても良い。この場合には、デッドロック検出をする際に、待ち先のシステムの待ち管理テーブル(LT)105に通信でアクセスする。そして、自己のシステムのタスクの「待ち関係」と、その待ち先のタスクの「待ち関係」とを突き合わせ、上述したループが形成されていればデッドロックとして検出することができる。
【0041】
本発明を分散システムに適用した場合、自己システム内でのデッドロックに対しては、複数のシステム相互間でデッドロック検出のための情報の通信は行わない。即ち、復数のシステム間でデッドロックが発生した場合のみ情報の通信を行う。但し、デッドロックは二者間で生じることがほとんどであるので、1回の通信でデッドロックを検出できる。従って、上記第2の課題を達成することができる。
【0042】
<待ち時間管理テーブルの付加>
上記した本発明の必須の構成要件に、図2の原理図に示すように、待ち時間監視部(WT)106を設けてもよい。この待ち時間監視部(WT)106は、あるタスク(トランザクション)について「待ち関係」が一定時間継続している場合に、そのタスク(トランザクション)について再度資源獲得要求を出すブロックである。この待ち時間監視部(WT)106を設ける目的は、以下に説明する通りである。
【0043】
即ち、デッドロックが生じても、デッドロックを検出できないと、デッドロックを修復できない。デッドロックが発生しているにも拘らずデッドロックを検出することができない原因としては、通信の欠落により管理テーブル(LT)105に「待ち関係」の情報が登録されていないことが考えられる。そこで、あるタスクにつき「待ち関係」が一定時間継続している場合には、待ち時間監視部(WT)106が再度資源獲得要求を出すようにするのである。これにより、「待ち関係」の情報をその待ち先のシステムの待ち管理テーブル(LT)105に再度送信する契機を与えることができる。従って、確実にデッドロックを検出することができる。
【0044】
【作用】
本発明によるデッドロック検出装置では、タスクの実行状況は、タスク管理部(TM)102によって管理される。この際、各タスクが資源を占有する場合には、ロック管理部(LM)103によって、どのタスクがどの資源を占有したかについての情報が管理される。そして、他のタスクが占有している資源を一のタスクが獲得要求すると、この一のタスクは他のタスクの終了を待たねばならない。この「待ち関係」は、待ち管理テーブル(LT)105において登録管理される。
【0045】
この待ち管理テーブル(LT)105をデッドロック検出部(DD)104が見て、デッドロックを検出する。この検出は、ロック管理部(LM)103によるロック管理とは別個に行われる。従って、デッドロック検出部(DD)104によるデッドロックが行われていても、ロック管理部(LM)103はその動作を行うことができる。よって、新たなタスクの発生や待ち関係の発生を禁ずる必要がなくなる。そのため、デッドロック検出を行うことによるシステムへの影響を小さくすることができるのである。
【0046】
【実施例】
以下、本発明の好適実施例を、図面を参照して説明する。ここでは、今まで使用した“タスク”という言葉を“トランザクション”で置き換えて説明する。また、この好適実施例は、本発明を分散処理システムにおいて実施する場合の具体例である。
【0047】
<システムの概要>
図4には分散処理システムの構成が示されている。この分散処理システムにおいては、二つのコンピュータシステム(システムi及びシステムj)が分散して設けられ、相互にネットワーク(NW)30によって接続されている。また、両コンピュータシステム(i,j)とネットワーク(NW)30によって接続され、且つ両コンピュータシステム(i,j)からアクセス可能なデータベース(DB)20が設けられている。このようなシステムは、例えば、預金システムに利用される。
【0048】
図4から明かなように、各コンピュータシステム(システムi及びシステムj)は、トランザクション管理部(TM)10,資源管理部(RM)11,ロック管理部(LM)12,デッドロック検出部(DD)15,待ち管理テーブルT3,及びウォッチドックタイマ(WT)13を備えている。なお、システムjはシステムiと全く同じ構成を有している。そのため、図4においては、システムiについてのみその詳細な構成を示し、システムjについてはその詳細な構成の図示を省略した。
【0049】
データベース(DB)20には、資源としてのファイル又はレコードが複数個格納されている。図4においては、これら資源として、資源A及び資源Bを例示した。
【0050】
以下、各構成ブロックを詳細に説明する。
【0051】
<トランザクション管理部(TM)>
トランザクション管理部(TM)10は、複数のトランザクションの実行を管理している。トランザクション管理部(TM)10を、タスク管理部(TM)10と言っても良い。
【0052】
このトランザクション管理部(TM)10は、応用プログラムからのトランザクション開始・正常終了(commit)・異常終了(abort)の通信を受付け、システム内でのトランザクションを管理するブロックである。より詳しく言うと、例えばシステムiにおいてトランザクションxが開始されたときには、T(i,x)という形式のデータを登録し、トランザクションxが終了・異常終了したときにはこのT(i,x)という形式のデータを削除するのである。
【0053】
トランザクション管理部(TM)10は、トランザクションから資源の要求を受け付けると、その要求を資源管理部(RM)11に渡し、その応答(ok/no)をもらう。また、トランザクション管理部(TM)10は、デッドロック検出部(DD)15から送信されたトランザクションのデッドロック通知を受け付けて、トランザクションを終了させる。また、トランザクション管理部(TM)10は、デッドロック検出部(DD)15から送信されたリトライ通知を受け付けて、資源管理部(RM)11に資源獲得要求を再発行する。また、トランザクション管理部(TM)10は、他のコンピュータシステム(システムj)のトランザクションの正常終了や異常終了の通信を受信し、デッドロック検出部(DD)15にグラフの登録・削除を要求する。
【0054】
図4において、“start”はトランザクションの実行開始を意味し、“abort”はトランザクションの異常終了を意味し、“commit”はトランザクションの正常終了を意味する。
【0055】
トランザクション管理部(TM)10における、資源獲得要求・資源解放要求は、二相ロック(2PL:Two Phase Lock)方式で実行される。これは、疑似デッドロック(phantom deadlock)の検出を防止するのに効果的である。
【0056】
疑似デッドロックは、一般にグラフの登録と削除が競合した場合に発生する。例えば、
T(i,x)→T(j,y)
のグラフが既に登録されている場合において、
T(i,x)→T(j,y)
の削除要求と
T(j,y)→T(i,x)
の登録要求とが、デッドロック検出部(DD)15に対して同時に発生したとする。この際、削除要求が先に受理された場合にはデッドロックが発生しない。これに対して、登録要求が先に受理された場合には、疑似デッドロックとなる。
【0057】
T(i,x)→T(j,y)
の削除要求が発生するのは、このグラフで表される待ち関係がなくなった場合である(即ち、T(j,y)が資源のロックを解除した場合である。)。ロックの解除は、トランザクションが自ら資源のロックを解除する場合か非同期にabort(異常終了)する場合に行われる。
【0058】
二相ロック方式は、ある処理がデータのロック(占有)を始めたらロックし続け、ロックを解除し始めたら解除し続けるという2つの相(フェーズ)からなるロック方式である。この方式によれば、複数のタスクやトランザクションがそれぞれ逐次実行されたのと同一結果となる。
【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)
の登録要求が発生しないことを保証できる。
【0060】
以上の理由により、この方式を採用することによって、疑似デッドロックの発生原因をトランザクションの非同期abort(異常終了)のみに限定することができる。
【0061】
<資源管理部(RM)>
資源管理部(RM)11は、このトランザクション管理部(TM)10に双方向で接続されている。資源管理部(RM)11は、資源管理デーブルT1を有している。資源管理部(RM)11は、トランザクション管理部(TM)10からの資源獲得要求及び資源解放要求の内容に基づいて、トランザクションとそのトランザクションが要求している資源との対応関係を、資源管理テーブルT1上にマッピングして管理している。
【0062】
また、資源管理部(RM)11は、トランザクション管理部(TM)10からの資源獲得要求に応じてロック要求をロック管理部(LM)12に対して行い、トランザクション管理部(TM)10からの資源解放要求に応じて、ロック解放要求をロック管理部(LM)12に対して行う。
【0063】
<ロック管理部(LM)>
ロック管理部(LM)12は、資源管理部(RM)11に双方向で接続されている。ロック管理部(LM)12は、ロック管理テーブルT2を有している。即ち、ロック管理部(LM)12は、このロック管理テーブルT2によりロック状態の管理を行う制御部である。
【0064】
トランザクションx,yと資源A、Bがある場合において、トランザクションxが資源Aをロック(占有)し、トランザクションyがBをロックしたときには、ロック管理部(LM)12は、この関係をロック管理テーブルT2に登録する。即ち、図4に示すように、xがAをロックした状態を例えば(x:A)と定義し、yがBをロックした状態を例えば(y:B)と定義し、この情報をロック管理テーブルT2に登録する。
【0065】
なお、このロック管理テーブルT2は、そのコンピュータシステム(i又はj)におけるトランザクションについてのロック情報を管理するばかりでなく、他のコンピュータシステム(j又はi)におけるトランザクションについてのロック情報をも管理する。この他のシステムにおけるトランザクションについてのロック情報は、コンピュータシステム間で通信を行うことにより獲得することができる。但し、各コンピュータシステム(i,j)によって共用される共用メモリ上に単一のロック管理テーブルT2を作成し、全コンピュータシステム(i,j)における全トランザクションに関するロック情報を一括管理させれば、各コンピュータシステム間における通信の必要はなくなる。
【0066】
いま、上述した状態において、更に資源管理部(RM)11から、トランザクションyによる資源Aのロック要求がなされ、トランザクションxによる資源Bのロック要求がなされるとする。そうすると、ロック管理部(LM)12はロック管理テーブルT2の情報を参照し、このようなロックができないことを認識する。この場合には、トランザクションyはトランザクションxによる資源Aのロック解放を待ち、トランザクションxはトランザクションyによる資源Bのロック解放を待たねばならない。この待ち状態は、それぞれ、(x→B)、(y→A)と定義される。このような定義が発生したとき、ロック管理部(LM)12は「待ち」が発生したと判断するのである。
【0067】
本実施例では、このような「待ち関係」を、ロック管理部(LM)12とは切り離して、待ち管理テーブルT3に登録して管理する。即ち、「待ち関係」が生じたときには、ロック管理部(LM)12は、上記定義に基づいて、ウェイトフォーグラフ登録をデッドロック検出部(DD)15に要求する。この要求の際には、上記定義におけるトランザクション(x,y)がどのコンピュータシステムにおけるトランザクションであるのか、及び、上記定義における資源(A,B)が現在どのコンピュータシステムのどのトランザクションによってロックされているのかの情報も、デッドロック検出部(DD)15に通知する。
【0068】
ロック管理部(LM)12は、資源管理部(RM)11からのロック要求が「待ち」にならない場合には、資源管理部(RM)11に対してすぐに応答(ok)を返す。ロック管理部(LM)12が判断して「待ち」が発生した場合のみ、待ち関係を示すウェイトフォーグラフを、待ち管理テーブルT3に登録する登録要求キューを発行する。従って、「待ちが発生しない資源獲得要求」に関しては、デッドロック検出中か否かに拘らず、その資源獲得要求を行ったトランザクションの実行処理は停止されない。
【0069】
<デッドロック検出部(DD)>
デッドロック検出部(DD)15は、待ち管理テーブルT3の登録内容からデッドロックの有無を判定する部分である。
【0070】
デッドロック検出部(DD)15は、要求キュー受付部(QR)14を有する。この要求キュー受付部(QR)14は自システムのロック管理部(LM)12から待ち関係(ウェイトフォーグラフ)の登録・削除要求キューを受け付ける。また、他のコンピュータシステムからの待ち関係(ウェイトフォーグラフ)の登録・削除要求キューを受け付ける。さらに、他システムのトランザクションが異常終了(abort)又は正常終了(commit)した場合には、トランザクション管理部(TM)10からの待ち関係(ウェイトフォーグラフ)の削除要求キューを受け付ける。
【0071】
デッドロック検出部(DD)15は、これら要求キューに従い、先ずウェイトフォーグラフの登録又は削除を、待ち管理テーブルT3に対して行う。このウェイトフォーグラフ(Wait・for・graph)の形式は以下の通りである。即ち、例えば、
システムiで発生したトランザクションx=T(i,x)、
システムjで発生したトランザクションy=T(j,y)
としたとき、 T(i,x)がT(j,y)について待つことを
T(i,x)→T(j,y)と表す。
【0072】
ウェイトフォーグラフの登録を行う際には、デッドロック検出部(DD)15は、通知された情報に基づいて、予めウェイトフォーグラフを作成する。
ウェイトフォーグラフの登録がなされると、デッドロック検出部(DD)15はデッドロック検出を開始する。デッドロックが検出されたときは、デッドロック検出部(DD)15は、トランザクション管理部(TM)10にデッドロック通知を行う。
ウェイトフォーグラフの削除要求を受け付けた場合は、当該ウェイトフォーグラフを削除し、動作できるトランザクションに対しリトライ通知を行う。
【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)について待つ」という。
【0074】
デッドロック検出部(DD)15は、待ち管理テーブルT3に、この
T(i,x)→T(j,y)
のグラフを、「待ち関係」として登録する。
【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)
というループが形成される。よって、このループが検出されればデッドロックが発生しているということができるのである。
【0076】
この待ち関係は、システムiのトランザクションxとシステムjのトランザクションyとの間で生じている。そして、
T(i,x)→T(j,y)
のグラフはシステムiの待ち管理テーブルT3に登録され、
T(j,y)→T(i,x)
のグラフはシステムjの待ち管理テーブル(T3)に登録される。このため、両者を突き合わせるためには、いずれかを他方に送信しなければならない。ここでは、「待ち関係」が登録されるとき、その待ち先に「待ち関係」を送信する。
【0077】
すなわち、
T(i,x)→T(j,y)
がシステムiの待ち管理テーブル(T3)に登録されたとき、システムiのデッドロッ検出部(DD)15は、システムjの待ち管理テーブルT3に同一の内容のグラフを送信して登録する。
【0078】
これにより、待ち先のシステム(即ち、システムj)において、待ち管理テーブルT3を参照すれば、デッドロックを検出できる。なお、トランザクションxの「待ち関係」が解消したとき、トランザクションxに関する「待ち関係」の情報を待ち先のシステム(即ち、システムj)から回収(削除)しないと、いつまでもデッドロックを検出してしまう。そこで、「待ち関係」が解消した場合には、待ち先のシステム(即ち、システムj)の待ち管理テーブルT3から「待ち関係」を示すグラフを削除・あるいは回収しなければならない。デッドロック検出部(DD)15は、このようなグラフ削除・回収機能をも有する。
【0079】
ウェイトフォーグラフのループが検出されない場合、ウェエイトフォーグラフの先端が他のシステムのトランザクションであれば、当該他のシステムにデッドロックの可能性があることになる。そこで、当該他のシステムにグラフ登録を要求する。他のシステムからのグラフ登録の要求をを受け付けた場合は、デッドロック検出部(DD)15は必要なグラフを登録し、ループ検出を行う。
【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)
というループが形成されるので、デッドロックが検出できる。
【0081】
ところで、分散処理システムにあっては、あるシステムで発生したトランザクションに関係するウェイトフォーグラフ等の登録内容を、そのシステムのローカルウェイトフォーグラフという。また、分散処理システム全体での待ち関係を表現したグラフ,即ち、その分散システムにおける全ローカルウェイトフォーグラフの集合を、グローバルウェイトフォーグラフという。図5は、ローカルウェイトフォーグラフとグローバルウェイトフォーグラフの関係の例を示したものである。
【0082】
各コンピュータシステムでは、ローカルウェイトフォーグラフのみを待ち管理テーブルT3で管理する。ここでは、前記したように、デッドロック検出部(DD)15は、自コンピュータシステム内のトランザクション間の待ち関係を表すウェイトフォーグラフ等の登録内容を他のコンピュータシステムに送信しない。一方、デッドロック検出部(DD)15は、他のコンピュータシステム内のトランザクションとの間の待ち関係を表すウェイトフォーグラフを、関係を持った他システムにのみ送信する。統計的に見てデッドロックの90%以上が2つのタスク間で発生することを考慮すると、他システムのトランザクションに関連するデッドロックであっても、ほとんど1回の通信で検出することができる。しかも、自コンピュータシステム内でのデッドロックであれば、通信なしで検出できる。従って、デッドロック検出のための通信のオーバーヘッドを削減できる。
【0083】
<待ち時間監視部(WT)>
次に、待ち時間監視部(WT)13は、待ち管理テーブルT3を監視するタイマーである。このタイマーは、待ち管理テーブルT3に登録されている「待ち関係」を監視する。そして、その「待ち関係」が登録されてから一定時間経過した時点で、なおその「待ち関係」が継続しているならば、その「待ち関係」にある待ち元のトランザクションが資源獲得要求を再発行するように、リトライ通知を発行する。このリトライ通知は、要求キュー受付部(QR)14に投入される。このリトライ通知が要求キュー受付部(QR)14に投入されると、デッドロック検出部(DD)15は、トランザクション管理部(TM)10にリトライ通知を送る。トランザクション管理部(TM)10は、このリトライ信号を受けて、待ち関係にあるトランザクションに対し、再度資源獲得要求を出す。
【0084】
システム間の通信メッセージの遅延・消失やコンピュータシステムの非同期ダウンが発生すると、実際はデッドロック状態であるのにこれを検出できない場合がある。待ち時間監視部(WT)13は、このような不都合を防止する。すなわち、分散処理システムにおいて各コンピュータシステム間で通信するとき、通信の欠落によりデッドロック状態を表示するグラフが欠落することがある。すると、デッドロック検出ができなくなる。これを防止するために、待ち関係にあるトランザクションを監視する機構として、前記待ち時間監視部(WT:Watchdog Timer)13を設けたのである。
【0085】
このタイマーは、一定時間以上ウェイトフォーグラフの待ち先の関係にあるトランザクションに対し、前述した様に、デッドロック検出部(DD)15を介して、再度資源獲得要求することを促す。すると、トランザクション監視部(TM:Transaction Manager)10から、再度資源獲得要求が出される。このとき、既に「待ち」が解消されているなら、この資源獲得要求は満たされる。これに対して、待ちが解消されていないなら、他のコンピュータシステムに対して再度ウェイトフォーグラフが送信される。これによりウェイトフォーグラフ欠落が補われ、デッドロックが検出できる。
【0086】
<各部の動作例>
以下、前記各部の動作をフローチャート図に従って説明する。
〔トランザクション管理部(TM)の動作〕
図6に示したフローチャートのように、トランザクション管理部(TM)10は、start(開始要求),abort(異常終了),commit(正常終了),資源獲得要求,デッドロック通知,リトライ通知などの各種要求を待つ(ステップS101)。なお、ここで言うabort(異常終了),commit(正常終了)には、他のコンピュータシステムから通知されたものも含む。何れかの要求を受け付ける(ステップS102)と、トランザクション管理部(TM)10は、その要求の種類に従って処理を振り分ける。
【0087】
ステップS102で受け付けた要求がstart(開始要求)の場合、トランザクション管理部(TM)10自身にそのトランザクション(ここでは、仮にT(i,x)とする。)を登録し(ステップS103)、その後の要求を待つ。
【0088】
ステップS102で受け付けた要求がabort(異常終了)又はcommit(正常終了)である場合、先ず、その終了するトランザクション(ここでは、仮にT(i,x)とする。)を削除する(ステップS104)。次に、資源管理部(RM)11に対し、資源解放要求を発行する(ステップS105)。その資源開放要求に対する応答を資源管理部(RM)11から受けると(ステップS106)、デッドロック検出部(DD)15にグラフ削除要求を出す(ステップS107)。その後、その要求が自コンピュータシステムからの要求か否かを判定する(ステップS108)。他コンピュータシステムからの要求であればそのままとする。これに対して、自コンピュータシステムからの要求であれば、他のコンピュータシステムに、commit又はabortを通知する(ステップS109)。通知を受けた他のコンピュータシステムでは、ステップS104乃至107の処理を行う。
【0089】
ステップS102で受け付けた要求が資源獲得要求である場合、資源管理部(RM)11に資源獲得要求を出す(ステップS110)。その要求に対する応答を資源管理部(RM)11から受けたら(ステップS111)、トランザクションに応答を返す(ステップS112)。
【0090】
ステップS102で受け付けた要求がデッドロック通知である場合、まず、デッドロックとなっているトランザクションの中からabortさせるべきトランザクションを選択する(ステップS120)。即ち、デッドロック通知には、デッドロックの関係にある全トランザクション(ここでは、仮にT(i,x),T(j,y)とする。)の特定が含まれている。トランザクション管理部(TM)10は、このデッドロック通知に含まれているトランザクション名からabortさせるべきトランザクションを選択するのである。従って、トランザクション管理部(TM)10は、他のコンピュータシステムのトランザクションをも、abort対象として特定することができる。次いで、トランザクション管理部(TM)10は、選択されたトランザクションにabortすべき旨の通知をする(ステップS121)。選択されたトランザクションが他のコンピュータシステムのものである場合には、当該他のコンピュータシステムのトランザクション管理部(TM)10を介して、選択されたトランザクションにabortすべき旨を通知する。
【0091】
ステップS102で受け付けた要求がリトライ通知である場合、まず、資源管理部(RM)11に資源獲得要求を出す(ステップS130)。その要求に対する応答を資源管理部(RM)11からもらったら(ステップS131)、トランザクションに応答を返す(ステップS131)。
【0092】
〔資源管理部(RM)の動作〕
図7に示したフローチャートのように、資源管理部(RM)11は、まず、資源獲得要求及び資源解放要求を待つ(ステップS201)。何れかの要求があり、それが受理されると(ステップS202)、テーブル上に示された資源をロックしようとし、その関係を資源獲得テーブルT1に登録する(ステップS203)。即ち、どのトランザクションがどの資源をロックしようとするのかを登録する。
【0093】
その後、要求が資源獲得要求か資源解放要求かを判定する(ステップS204)。要求が資源獲得要求の場合、ロック管理部(LM)12にロック獲得要求を出す(ステップS205)。これに対して、要求が資源解放要求の場合、ロック管理部(LM)12にロック解放要求を出す(ステップS206)。
【0094】
そして、ロック獲得要求又はロック解放要求に対する応答(ok/no)をロック管理部(LM)12から受けた後(ステップS207)、トランザクション管理部(TM)10に応答(ok/no)を返す(ステップS208)。
【0095】
〔ロック管理部(LM)の動作〕
図8に示したフローチャートのように、資源管理部(RM)11におけるステップS205又はステップS206の要求があると(ステップS301)、ロック管理部(LM)12は、要求を受け付ける(ステップS302)。その後、要求がロック獲得要求かロック解放要求かを判定する(ステップS303)。要求がロック獲得要求である場合には、ロック管理部(LM)12は、ロック獲得が可能か否かを判定する(ステップS304)。
【0096】
資源のロックが可能であれば、そのロック状態をロック管理テーブルT2に登録する(ステップS305)。資源のロックが不可能であれば、「待ち関係」であるので、要求側のトランザクションと待ち先のトランザクションとの関係をウェイトフォーグラフとして待ち管理テーブルT3に登録する旨を、デッドロック検出部(DD)15に対して要求する(ステップS306)。その後、資源管理部(RM)11にロックできなかった旨(no)を返答する(ステップS309)。
【0097】
ステップS303において要求が資源解放要求であると判定された場合、ロック管理テーブルT2からロックの登録を削除する(ステップS307)。ロックの登録(ステップS305)とその削除(ステップS307)の後は、その完了(ok)を示す応答を、資源管理部(RM)11に返す(ステップS308)。
【0098】
〔デッドロック検出部(DD)の動作〕
図9に示したフローチャート図のように、デッドロック検出部(DD)15には、グラフ登録要求,グラフ削除要求,及びリトライ通知が、要求キュー受付部(QR)14に受け付けられる。従って、その要求があると(ステップS401)、要求キュー受付部(QR)14から要求を取り出し(ステップS402)、要求の種別を判定する(ステップS403)。
【0099】
要求が、グラフ登録である場合には、先ず、待ち管理テーブルT3にウェイトフォーグラフを登録する(ステップS404)。但し、待ち管理テーブルT3を検索した結果同一グラフが既に登録されていれば、そのグラフは登録しない。次いで、登録したグラフにつき、グラフの先端までたどる(ステップS405)。たどった結果によって、ループが形成されているか判断する(ステップS406)。ループが形成されていれば、トランザクション管理部(TM)10にデッドロックを通知する(ステップS407)。ループが形成されていなければ、グラフの先端が自コンピュータシステムか否かを判定する(ステップS408)。自コンピュータシステムであればそのままステップS401に戻る。これに対して、他コンピュータシステムであれば、その他コンピュータシステムのデッドロック検出部(DD)15に当該ウェイトフォーグラフを送信して、その他システムの待ち管理テーブルT3に当該グラフを登録させる(ステップS409)。
【0100】
次に、ステップS403において、要求がグラフの削除であるときは、待ち管理テーブルT3を検索して、該当するグラフを探す(ステップS410)。該当グラフを探しあてたら、該当グラフを削除する(ステップS411)。その後、待ち関係が解除されたトランザクションを動作させるため、トランザクション管理部(TM)10にリトライ通知をする(ステップS412)。
【0101】
ステップS403で要求がリトライ通知であるとき、まず、リトライするトランザクションのウェイトフォーグラフを削除する(ステップS420)。次いで、トランザクション管理部(TM)10にリトライ通知をする(ステップS421)。
【0102】
〔待ち時間監視部(WT)の動作〕
図10に示したフローチャートのように、待ち時間監視部(WT)13は、待ち管理テーブルT3に登録されている各トランザクション(T(i,x)等)を順次検索する(ステップS501)。次いで、そのトランザクションxが「待ち関係」にあるか否かを判断する(ステップS502)。検索されたトランザクションが「待ち関係」でなければ、ステップS501に戻り、次のトランザクションを検索する。
【0103】
これに対して、検索されたトランザクションが「待ち関係」であれば、タイムカウントを開始し、タイムアウトとなったら(ステップS503)、デッドロック検出部(DD)15にリトライ通知を行う(ステップS504)。ステップS503でタイムアウトになる前に「待ち関係」が解消されたなら、ステップS501に戻る(ステップS502)。
【0104】
<具体的なデッドロック検出の例>
次に、以上の構成におけるデッドロック検出例を、3通りの場合に沿って説明する。
[例1 自コンピュータシステム内におけるデッドロック検出]
例1は、自コンピュータシステム内におけるデッドロック検出の例で、具体的には以下の動作を行う。ここでは、他のコンピュータシステムとの間に通信が発生しないことが解る。
【0105】
(1) 先ず、トランザクションT(1,1)がトランザクション管理部(TM)10に対してトランザクションの開始を通知したとする。
(2) すると、トランザクション管理部(TM)10はデッドロック検出部(DD)15にトランザクションT(1,1)の登録を要求する。
(3) 一方、トランザクションT(1,2)がトランザクション管理部(TM)10に対してトランザクションの開始を通知したとする。
【0106】
(4) すると、トランザクション管理部(TM)10はデッドロック検出部(DD)15にトランザクションT(1,2)の登録を要求する。
(5) いま、トランザクションT(1,1)がトランザクション管理部(TM)10に資源Aを要求したとする。
(6) すると、トランザクション管理部(TM)10が資源管理部(RM)11に資源Aの獲得を要求する。
【0107】
(7) すると、資源管理部(RM)11がロック管理部(LM)12に資源Aのロック獲得を要求する。
(8) 資源Aが未ロックであれば、ロック管理部(LM)12が資源管理部(RM)11にOKを応答する。
(9) すると、資源管理部(RM)11がトランザクション管理部(TM)10にOKを応答する。
【0108】
(10) 一方、トランザクションT(1,2)がトランザクション管理部(TM)10に資源Bを要求したとする。
(11) すると、トランザクション管理部(TM)10が資源管理部(RM)11に資源Bを獲得を要求する。
(12) すると、資源管理部(RM)11がロック管理部(LM)12に資源Bのロック獲得を要求する。
【0109】
(13) 資源Bが未ロックであれば、ロック管理部(LM)12が資源管理部(RM)11にOKを応答する。
(14) すると、資源管理部(RM)11がトランザクション管理部(TM)10にOKを応答する。
(15) この状態において、トランザクションT(1,1)がトランザクション管理部(TM)10に資源Bを要求したとする。
【0110】
(16) すると、トランザクション管理部(TM)10が資源管理部(RM)11に資源Bの獲得を要求する。
(17) すると、資源管理部(RM)11がロック管理部(LM)12に資源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に登録する。
【0112】
(19) 一方、トランザクションT(1,2)がトランザクション管理部(TM)10に資源Aを要求したとする。
(20) すると、トランザクション管理部(TM)10が資源管理部(RM)11に資源Aの獲得を要求する。
(21) すると、資源管理部(RM)11がロック管理部(LM)12に資源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がループを検出し、デッドロック発生をトランザクション管理部(TM)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を要求したとする。
【0115】
(4) すると、システム1のトランザクション管理部(TM)10が、資源管理部(RM)11に資源Aの獲得を要求する。
(5) すると、システム1の資源管理部(RM)11が、ロック管理部(LM)12に資源Aのロック獲得を要求する。
(6) 資源Aが未ロックであれば、システム1のロック管理部(LM)12が、資源管理部(RM)11にOKを応答する。
【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)の登録を要求する。
【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を応答する。
【0118】
(7)’すると、システム2の資源管理部(RM)11が、トランザクション管理部(TM)10にOKを応答する。
(8) 以上の状況下において、トランザクションT(1,1)がシステム1のトランザクション管理部(TM)10に資源Bを要求したとする。
(9) すると、システム1のトランザクション管理部(TM)10が、資源管理部(RM)11に資源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)
の登録を要求する。
【0120】
(12) この要求を受けて、システム1のデッドロック検出部(DD)15は、グラフT(1,1)→T(2,1)を待ち管理テーブルT3に登録し、待ち管理テーブルT3に登録されたグラフにループが形成されているかどうか(デッドロックが発生しているかどうか)を判断し、デッドロックを検出しないときにシステム2にグラフT(1,1)→T(2,1)を送信する。 (13) システム2のデッドロック検出部(DD)15が、このグラフT(1,1)→(2,1)を受信し、これをシステム2の待ち管理テーブルT3に登録する。
【0121】
(14) この後で、トランザクションT(2,1)がシステム2のトランザクション管理部(TM)10に資源Aを要求したとする。
(15) すると、システム2のトランザクション管理部(TM)10が、資源管理部(RM)11に資源Aの獲得を要求する。
(16) すると、システム2の資源管理部(RM)11が、ロック管理部(LM)12に資源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は、グラフT(2,1)→T(1,1)を待ち管理テーブルT3に登録し、待ち管理テーブルT3に登録されたグラフにループが形成されているか判断する。その結果、システム2のデッドロック検出部(DD)15は、ループを検出し、デッドロック発生をシステム2のトランザクション管理部(TM)10に通知する。
【0123】
[例3 2つのコンピュータシステム間における2つのトランザクションのデッドロック検出中に、メッセージの消失発生]
例3では、2つのコンピュータシステム(システム1,システム2)間での通信エラーにより、メッセージ消失が発生した場合の例である。
(1) 先ず、システム1におけるトランザクショントランザクションT(1,1)が、システム1のトランザクション管理部(TM)10に対しトランザクションの開始を通知したとする。
【0124】
(2) すると、システム1のトランザクション管理部(TM)10は、デッドロック検出部(DD)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のロック獲得を要求する。
【0125】
(6) 資源Aが未ロックであれば、システム1のロック管理部(LM)12が、資源管理部(RM)11にOKを応答する。
(7) すると、システム1の資源管理部(RM)11が、トランザクション管理部(TM)10にOKを応答する。
(1)’一方、システム2におけるトランザクションT(2,1)が、システム2のトランザクション管理部(TM)10に対しトランザクションの開始を通知したとする。
【0126】
(2)’すると、システム2のトランザクション管理部(TM)10は、デッドロック検出部(DD)15にトランザクションT(2,1)の登録を要求する。
(3)’いま、トランザクションT(2,1)が、システム2のトランザクション管理部(TM)10に、資源Bを要求したとする。
(4)’すると、システム2のトランザクション管理部(TM)10が、資源管理部(RM)11に資源Bの獲得を要求する。
【0127】
(5)’すると、システム2の資源管理部(RM)11が、ロック管理部(LM)12に資源Bのロック獲得を要求する。
(6)’資源Bが未ロックであれば、システム2のロック管理部(LM)12が、資源管理部(RM)11にOKを応答する。
【0128】
(7)’すると、システム2の資源管理部(RM)11が、トランザクション管理部(TM)10にOKを応答する。
(8) 以上の状況下において、トランザクションT(1,1)がシステム1のトランザクション管理部(TM)10に資源Bを要求したとする。
(9) すると、システム1のトランザクション管理部(TM)10が、資源管理部(RM)11に資源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)
の登録を要求する。
【0130】
(12) この要求を受けて、システム1のデッドロック検出部(DD)15は、このグラフをシステム1の待ち管理テーブルT3に登録する。これと同時に、システム1のデッドロック検出部(DD)15は、システム2にグラフ
T(1,1)→T(2,1)
を送信する。
(13) ただし、その送信内容は、通信エラーにより消失して、システム2に届かなかった。
【0131】
(14) この後で、トランザクションT(2,1)がシステム2のトランザクション管理部(TM)10に資源Aを要求したとする。
(15) すると、システム2のトランザクション管理部(TM)10が、資源管理部(RM)11に資源Aの獲得を要求する。
(16) すると、システム2の資源管理部(RM)11が、ロック管理部(LM)12に資源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)
の登録を要求する。この時点で、実際にはデッドロック状態が生じている。
【0133】
しかしながら、メッセージ消失によりデッドロック状態は検出できないので、デッドロック状態が持続することになる。
(18) 一定時間後、システム1の待ち時間監視部(WT)13が起動され、システム1のデッドロック検出部(DD)15に対してリトライ通知を行う。
(19) すると、システム1のデッドロック検出部(DD)15は、トランザクション管理部(TM)10にトランザクション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)
の登録を再度要求する。
【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に通知する。
【0136】
【発明の効果】
本発明では、以上説明したように、タスク(トランザクション)による資源のロック状態を管理するロック管理部(LM)103と、デッドロック検出部(DD)104とを分離し、双方が非同期に動作するようにした。そのため、タスク(トランザクション)が新たに発生して資源を要求しても、待ちが発生せずロックが獲得できる場合は、デッドロック検出部(DD)104を介せずに動作できる。従って、システムの円滑な運用が図れ、処理の高速化を図れる。また、ロックが獲得できない場合でも、ロック状態(グラフ)の登録やデッドロックの検出はロックの要求とは非同期に動作するので影響は小さい。
【0137】
特に、デッドロックを少なくするように設計されたシステムで、デッドロック検出の与える影響は極めて小さくなる。
本発明が分散システムに適用された場合、システムは他のシステムと待ち関係に陥った場合にのみデッドロックのための通信を行う。したがって、自システム内のみのデッドロックの検出では通信は発生しない。他システムとの関連があった場合も、デッドロックの90%以上が2者間で発生することから、ほとんどの場合、1回の通信でデッドロックは検出される。このため、通信のオーバーヘッドを削減でき、効率のよいシステム運用を図ることができる。
【0138】
また、本発明で、待ち時間監視部(WT)13を設けた場合、分散システムでのメッセージ通信中にメッセージが遅延した場合や消失した場合でも、待ち時間監視部(WT)13が再びデッドロック検出の契機を与えるため、すべてのデッドロックを検出することができる。
【図面の簡単な説明】
【図1】 本発明の原理図1
【図2】 本発明の原理図2
【図3】 デッドロックを示す説明図
【図4】 実施例を示すブロック図
【図5】 ローカルWFGとグローバルWFGの関係を示す図
【図6】 トランザクション管理部の動作を示すフローチャート
【図7】 資源管理部の動作を示すフローチャート
【図8】 ロック管理部の動作を示すフローチャート
【図9】 デッドロック検出部の動作を示すフローチャート
【図10】 待ち時間監視部の動作を示すフローチャート
【符号の説明】
10 トランザクション管理部
11 資源管理部
12 ロック管理部
13 待ち時間監視部
14 要求キュー受付部
15 デッドロック検出部
20 データベース
T3 待ち管理テーブル

Claims (8)

  1. 複数のタスクが共通の資源を利用するマルチタスクシステムにおいて前記複数のタスクが互いに占有している資源を待ち合って停止してしまうデッドロックを検出するためのデッドロック検出装置であって、複数のタスクを並列実行するために、前記タスクの実行を管理するタスク管理部と、各タスクがどの資源をロックしているかを管理するロック管理部と、一のタスクが他のタスクがロックしている資源を獲得要求した場合には、前記一のタスクが前記他のタスクを待っているとしてこの各タスクの「待ち関係」を登録する待ち管理テーブルと、前記ロック管理部と非同期で動作するとともに、前記待ち管理テーブルに登録された「待ち関係」からデッドロックを検出するデッドロック検出部とを備え、
    前記マルチタスクシステムは、複数のシステムを有する分散システム上に実現され、各システムがそれぞれ前記タスク管理部、前記ロック管理部、前記待ち管理テーブル、前記デッドロック検出部を備え、
    一方のシステムのタスクが他方のシステムのタスクに対して「待ち」の状態にあるときには、その「待ち関係」を前記一方のシステムの待ち管理テーブルに登録し、デッドロックを検出しないときは前記一方のシステムから前記他方のシステムに通信して前記他方のシステムの待ち管理テーブルに登録し、前記他方のシステムにおいてその待ち管理テーブルを見てデッドロックの有無を判定することを特徴とするデッドロック検出装置。
  2. 前記ロック管理部には、各タスクとそれによりロックされている資源との関係が登録されるロック管理テーブルを有していることを特徴とする請求項1記載のデッドロック検出装置。
  3. タスクにおいて「待ち関係」が発生したとき、前記デッドロック検出部は、前記待ち管理テーブルに「待ち関係」を登録するとともに、前記待ち管理テーブルを検索してデッドロックの有無を検出することを特徴とする請求項1記載のデッドロック検出装置。
  4. 前記デッドロック検出部は、要求キュー受付部を有し、この要求キュー受付部で、前記デッドロック検出命令である「待ち関係の登録要求」を受け付けることを特徴とする請求項1記載のデッドロック検出装置。
  5. 前記待ち関係にある2以上のタスクのそれぞれが別のシステム内にあるときには、各システムに設けた前記待ち管理テーブルに各タスクにおける「待ち関係」を登録するとともに、自己のシステムのタスクが他のシステムのタスクに対して「待ち」の状態にある場合には、各システムのデッドロック検出部は、その待ち先のシステムの待ち管理テーブルに通信でアクセスして自己のシステムの前記「待ち」の状態を示す「待ち関係」を送信するとともに、前記待ち先のシステムのデッドロック検出部に対して、自己のシステムの前記「待ち関係」と待ち先のシステムの待ち管理テーブルの登録内容とを突き合わせてデッドロックの有無を判定させることを特徴とする請求項1記載のデッドロック検出装置。
  6. 前記マルチタスクシステムは、複数のシステムを有する分散システム上に実現され、あるタスクについて「待ち関係」が一定時間継続している場合に、そのタスクに対して再度資源獲得要求を出す待ち時間監視部を備えたことを特徴とする請求項1記載のデッドロック検出装置。
  7. 複数のタスクが共通の資源を利用するマルチタスクシステムにおいて前記複数のタスクが互いに占有している資源を待ち合って停止してしまうデッドロックを検出するためのデッドロック検出装置であって、複数のタスクを並列実行するために、前記タスクの実行を管理するタスク管理部と、タスクとそれによりロックされている資源との関係を登録する第1のテーブルと、各タスクがどの資源をロックしているかを管理し、他のタスクによりロックされているものとして前記第1のテーブルに登録されている資源を一のタクスが獲得要求した場合には、前記一のタスクが前記他のタスクを待っている「待ち関係」の発生を検出するロック管理部と、前記待ち関係を登録する第2のテーブルと、前記ロック管理部とは非同期に動作するとともに、この第2のテーブルに登録された「待ち関係」から、デッドロックを検出するデッドロック検出部とを備え、
    前記マルチタスクシステムは、複数のシステムを有する分散システム上に実現され、各システムがそれぞれ前記タスク管理部、前記ロック管理部、前記第2のテーブル、前記デッドロック検出部を備え、
    一方のシステムのタスクが他方のシステムのタスクに対して「待ち」の状態にあるときには、その「待ち関係」を前記一方のシステムの第2のテーブルに登録し、デッドロックを検出しないときは前記一方のシステムから前記他方のシステムに通信して前記他方のシステムの第2のテーブルに登録し、前記他方のシステムにおいてその第2のテーブルを見てデッドロックの有無を判定することを特徴とするデッドロック検出装置。
  8. 複数のタスクが共通の資源を利用するマルチタスクシステムにおいて前記複数のタスクが互いに占有している資源を待ち合って停止してしまうデッドロックを検出するためのデッドロック検出方法であって、
    前記マルチタスクシステムは、複数のシステムを有する分散システム上に実現され、各システムがそれぞれタスク管理部、ロック管理部、待ち管理テーブル、デッドロック検出部を備え、
    前記ロック管理部が、各タスクがどの資源をロックしているかを認識し、一のタスクが獲得要求している資源が既に他のタスクによってロックされているか否かを検知し、資源が既に他のタスクによってロックされていることを検知した場合には、前記一のタスクが前記他のタスクを待っていると認識し、この「待ち関係」を前記待ち管理テーブルに登録し、
    前記デッドロック検出部が、登録された「待ち関係」が各タスクが互いに待ち合っていることを示す場から、デッドロックとして検出し、
    一方のシステムのタスクが他方のシステムのタスクに対して「待ち」の状態にあるときには、その「待ち関係」を前記一方のシステムの待ち管理テーブルに登録し、デッドロックを検出しないときは前記一方のシステムから前記他方のシステムに通信して前記他方のシステムの待ち管理テーブルに登録し、前記他方のシステムにおいてその待ち管理テーブルを見てデッドロックの有無を判定することを特徴とするデッドロック検出方法。
JP06177194A 1993-03-30 1994-03-30 デッドロック検出装置 Expired - Fee Related JP3681415B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP06177194A JP3681415B2 (ja) 1993-03-30 1994-03-30 デッドロック検出装置

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP9692893 1993-03-30
JP5-96928 1993-03-30
JP06177194A JP3681415B2 (ja) 1993-03-30 1994-03-30 デッドロック検出装置

Publications (2)

Publication Number Publication Date
JPH06337798A JPH06337798A (ja) 1994-12-06
JP3681415B2 true JP3681415B2 (ja) 2005-08-10

Family

ID=26402842

Family Applications (1)

Application Number Title Priority Date Filing Date
JP06177194A Expired - Fee Related JP3681415B2 (ja) 1993-03-30 1994-03-30 デッドロック検出装置

Country Status (1)

Country Link
JP (1) JP3681415B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496574B2 (en) * 2003-05-01 2009-02-24 International Business Machines Corporation Managing locks and transactions
JP4997784B2 (ja) * 2006-02-16 2012-08-08 日本電気株式会社 データ記憶システム、データ記憶方法、データ記憶プログラム
JP2009271858A (ja) * 2008-05-09 2009-11-19 Toshiba Corp 計算機システム及びプログラム
WO2010038280A1 (ja) * 2008-10-01 2010-04-08 富士通株式会社 仮想計算機システム及びデッドロック解除方法
JP6263940B2 (ja) * 2013-10-08 2018-01-24 株式会社リコー 排他制御プログラム、情報処理装置、排他制御方法
JP2015194886A (ja) 2014-03-31 2015-11-05 富士通株式会社 分散データ処理装置、分散データ処理方法および分散データ処理プログラム
JP6465719B2 (ja) 2015-04-02 2019-02-06 キヤノン株式会社 情報処理装置、情報処理装置の制御方法、及びプログラム

Also Published As

Publication number Publication date
JPH06337798A (ja) 1994-12-06

Similar Documents

Publication Publication Date Title
EP0618532B1 (en) Deadlock detecting device
US5317739A (en) Method and apparatus for coupling data processing systems
US8286182B2 (en) Method and system for deadlock detection in a distributed environment
US7600063B2 (en) Techniques for improved read-write concurrency
US6665814B2 (en) Method and apparatus for providing serialization support for a computer system
EP0783150B1 (en) System, method, storage medium and computer-readable modules for space efficient object locking
US5339427A (en) Method and apparatus for distributed locking of shared data, employing a central coupling facility
US6078955A (en) Method for controlling a computer system including a plurality of computers and a network processed as a user resource
US6862595B1 (en) Method and apparatus for implementing a shared message queue using a list structure
EP0532333A2 (en) A system and method for preventing deadlock in a multiprocessor environment
JPH05197604A (ja) マルチプロセッサ・コンピュータ及びその動作方法
JPH1165863A (ja) 共有資源管理方法
CN1327336C (zh) 用于使用记录板机制处理加载锁定指令的方法
JPH06301581A (ja) 過ち許容トランザクション指向データ処理
JPH03161859A (ja) リクエスト管理方法及びアクセス制御システム
US7089564B2 (en) High-performance memory queue
US6865741B1 (en) Determining completion of transactions processing in a dynamically changing network
US6721775B1 (en) Resource contention analysis employing time-ordered entries in a blocking queue and waiting queue
US9411661B2 (en) Deadlock avoidance
US20030110232A1 (en) Distributing messages between local queues representative of a common shared queue
US6681241B1 (en) Resource contention monitoring employing time-ordered entries in a blocking queue and waiting queue
US7574439B2 (en) Managing a nested request
JP3681415B2 (ja) デッドロック検出装置
JPS63228335A (ja) 計算機システムにおける事象通知・受取処理方式
JPH11203193A (ja) 共有メモリ管理装置及び方法

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