JPH0814800B2 - データベース排他制御方法 - Google Patents

Description

【発明の詳細な説明】 〔産業上の利用分野〕 一般に、電子計算機システム上の実現されるデータベ
ースシステムにおいて、複数のプログラムがデータベー
ス中の資源を共通に利用し、非同期にデータベースをア
クセスする。このため、同一の資源あるいは資源群に対
する複数プログラムからのアクセス、例えば更新動作と
参照動作、あるいは更新動作と更新動作、が同時に発生
しないようにして、データベース中の資源の不整合や、
他のプログラムか更新途上である資源の読み出しを防止
する必要がある。

本発明は、このようなデータベース中の資源の排他制
御に係り、特に各プログラムに資源の排他制御のための
手続きなどを負担させることなく、効率のよい、かつ信
頼度の高いデータの排他制御を実現するために好適な、
データベースシステムの資源のデータベース排他制御方
法に関するものである。

〔従来の技術〕

前述のようなデータベース中のデータの排他制御を行
うに当つては、一般に、次に示すようなデータのロツキ
ング方式がとられているロツキング方式とは、プログラ
ムがある一連のデータベース処理を行う際、アクセスし
ようとするデータ群を前もつて占有（ロツク）し、アク
セスが終了した時点で、占有していたデータ群を解放
（アンロツク）する、といつた手続を各プログラムが実
施し、占有しようとしたデータ群が、他のプログラムに
よつて占有された場合には、その占有状態が解放される
まで持つ、といつた規約をもつことにより、あるプログ
ラムが処理中のデータを他のプログラムが同時に使用す
ることがないようにする方式である。

しかしながら、ロツキング方式には、各プログラムが
無秩序にデータの占有を行うと、プログラム間で互いに
他のプログラムが占有しているデータが解放されるのを
待ち合い、永遠にプログラムが動けなくなつてしまう状
態、すなわちデツドロツクが発生することがあるという
問題が知られている。

このデツドロツクの問題に対処するために、以下のい
ずれかの方法がとられている。

イ） データを占有する際に、デツドロツクが発生しな
いような規制を設ける。

ロ） デツドロツクが発生したことを検出し、デツドロ
ツク状態の回復を行う。

以下、具体的な従来技術について説明する（参考文献
として、共有データベースの諸問題に対する理論（上
林）情報処理Vol.24,No.8（1983−３）、データベー
ス排他制御方法（特願昭60-73817）がある。

（１） 一括ロツク方式 アクセスしようとするすべてのデータを一括して占有
し、アクセスが終了したら、占有したデータを解放する
方法である。

すなわち、この方式は、占有の回数をただ一度だけに
限定することによつて、デツドロツクの発生可能性を完
全になくしたことが特長である。

（２） 木規約に従うロツク方式 すべてのプログラムが、データを逐次占有していく際
の占有順序を、同一データが複数回出現することのな
い、ある特定の半順序集合に統一する方法である。この
半順序集合で示されたロツク規約を木規約という。

すなわち、この方式は、すべてのプログラムのデータ
の占有順序を統一化することによつて、デツドロツクの
発生可能性を完全になくしたことが特長である（参考文
献,3.1節参照）。さらにプログラムごとのデータ占有
順序を予め定義させ、この規約を用いて、プログラムが
デツドロツクを起こさないように、実行時にスケジユー
リングを行う方式もとられている（参考文献参照）。

（３） デツドロツク検出方式（ロールバツク方式） 各プログラムからは自由に必要となるデータを占有さ
せることとし、それに伴つて発生するデツドロツクを検
出し、検出した場合にプログラムの処理結果を無効とし
（ロールバツクし）、デツドロツク状態からの回復を行
うとともに、無効化されたプログラムを一定時間遅延さ
れたうえで、再実行させるといつた方式である（参考文
献,2.3節参照）。

〔発明が解決しようとする問題点〕

上記従来技術には、それぞれ次のような問題があつ
た。

（１） 一括ロツク方式 この方式の欠点は、プログラムがある意味ある処理単
位内で必要とするすべてのデータに対して、そのうちの
少なくとも１つのデータをアクセスしようとした時点
で、一括してデータを占有しなくてはばらないため、共
有データ部分をもつ複数のプログラム同士のデータ・ア
クセスは、すべてシリアルに実行されることになる。こ
のことは、プログラムの応答性に悪影響を及ぼす。

また、プログラムの記述性の面からも、占有記述の際
に、占有するデータを予め調べて列記しなくてはならな
いため、プログラム作成者に排他制御に対する意識を強
いることとなり、望ましいものではない。

（２） 木規約に従うロツク方式 一括ロツク方式に比較し、データをアクセスする時点
にて、個々にデータを占有していくため、プログラムの
応答性の面では改善されている。

しかし、プログラムをある決められた木規約に従つて
作製せねばならず、プログラムからのデータ・アクセス
の自由度を大幅に制約することにになり、結果として、
プログラム作成者に排他制御に対する意識を強いること
になり、望ましいものではない。

また、この規約は、すべてのプログラムに最適となる
ように決定すべきであるが、それを決めることが、デー
タベース管理者の非常な負担となる。

以上述べたいずれの方式を用いても、データの占有・
解放といつた特別の手続きを、プログラム作成者に強要
することとなり、プログラムの生産性を低下させるばか
りでなく、誤使用によるシステムの信頼性・応答性の低
下をひきおこす危険性を伴つている。

（３） デツドロツク検出（ロールバツク方式） 本方式は、前記２つの方式と比較すると、プログラム
やデータベース管理者に対する負担は少ない。

しかしながら、デツドロツク検出，ロールバツク，再
実行を行うに当り、以下に示すプログラムの性能面での
問題が生じるという欠点がある。

（ａ） デツドロツク検出オーバヘツド システムは、デツドロツク検出のための監視を行う必
要があり、また検出した際に、無効化するプログラムの
特定が必要となり、システムの負荷が増大する。

（ｂ） ロールバツク準備オーバヘツド ロールバツクの際には、更新されたデータを、更新前
の状態へ回復する必要があるが、そのためには、ログの
取得といつた前準備が必要となり、これは、プログラム
の応答性低下の要因となる。

（ｃ） ロールバツク実施オーバヘツド プログラムの更新したデータをすべてもとの状態へ戻
さねばならず、相当の処理時間を要する。

さらに、無効化したプログラムの更新したデータが、
デツドロツク発生時点ですでに解放されており、他のプ
ログラムがそのデータを用いて処理を行つていたりする
場合には、他のプログラムにまで無効化、ロールバツク
が波及する場合もある（ロールバツクの連鎖）。ロール
バツクの連鎖を防ぐ方法も考察されてはいるものの、い
ずれにせよ本方式を用いている限りでは、ロールバツク
実施に相当な処理時間を要する（参考文献、2.4節参
照）。

（ｄ） 再試行オーバヘツド 無効化されたプログラムは、再試行する必要があり、
これも相当な処理時間を要する。

上記オーバヘツドを勘案すると、プログラムの実質的
な平行処理効率は相当低下するものと考えられ、またプ
ログラムの応答性もデツドロツク発生有無により大きく
変化してしまうため、リアルタイム処理のような高い応
答性の要求される分野への適用は不可能である。

また、上記文献（特開昭61-233849号公報）の場
合、システム管理者が予めデータの占有順序を定義しな
ければならず、システム管理者の負担が大であり、かつ
誤りの発生する可能性もあつた。

本発明の目的は、以上述べた従来技術の問題点であ
る、 （１） 共用データの占有・解放といつた特別な手続き
や、データアクセス順序に対する制約を、データベース
利用者へ強要すること、 （２） デツドロツクの発生や、ロールバツクといつた
プログラムの実質的な処理効率の低下、 を解決することにより、プログラムの生産性，信頼性を
向上させるデータの排他制御を実現することにある。

〔問題点を解決するための手段〕

前記の目的を達成するため、本発明に係るデータベー
ス排他制御方法は、並列に動作する複数のプログラムに
よりデータベースの複数の資源を共用する際に、デツド
ロツク発生の可能性があるプログラムを同時に実行させ
ないように制御するデータベース排他制御方法におい
て、構造化プログラミング言語のブロツク構造に則り記
述されたそれぞれのプログラムの使用する資源名とその
使用開始および使用終了とのネスト関係より、それぞれ
のプログラムごとにそれぞれの資源の使用順序を当該プ
ログラムのソースプログラムの各行の記述上の順序に従
つて読み込むことにより抽出し、実行前にその抽出した
それぞれのプログラム間でそれぞれの資源の使用順序を
比較し、マージされた有向グラフ上に強連結の関係を生
じるプログラムの組をデツドロツク発生の可能性ありと
して登録する構成とする。

〔作用〕

複数の資源を共用する複数のプログラムの資源操作記
述により前記プログラムをコンパイルするコンパイラに
よつて各前記プログラムから各前記資源の使用順序を抽
出し、この抽出した情報に基づき該プログラム間のデツ
ドロツク発生の有無を該プログラム実行以前に抽出し、
この抽出した情報に基づきデツドロツクの発生を抑制す
るよう制御する。

〔実施例〕

以下、本発明による一実施例について詳述する。

第１図は、本発明を適用する計算機システムの概略構
成図である。計算機システム１は、CPU2,前処理機構3,
実行制御機構４および記憶装置上に実現されるデータベ
ース５から構成されている。

前処理機構３はユーザが作成し、本計算機システム上
でタスクとして動作するプログラムのソースプログラム
群６を読み込み、コンパイラ７を用いてこれを計算機上
で動作可能な形式に翻訳し、タスク８として生成すると
ともに、コンパイラ７にてソースプログラムからそのプ
ログラムのデータベース５中の資源９に対するアクセス
順序（占有順序）を抽出し、資源占有順序テーブル10へ
記憶する。すべてのソースプログラムのコンパイルが終
了した時点で、テーブルジエネレータ11を用いて、実行
制御機構４が実行制御のために用いるデツドロツクチエ
ツクテーブル12およびタスクグループ対応テーブル13を
生成する。このとき、テーブルジエネレータ11は、テー
ブル生成のための一時的情報格納のため、中間テーブル
14を用いる。タスクグループ対応テーブル13は、同じよ
うな占有順序をもつタスク群をグルーピングし、そのグ
ループ識別子（GID）と、タスクごとに付与されたタス
ク識別子（TID）との対応を表わすテーブルである。デ
ツドロツクチエツクテーブル12は、GIDごとに他のグル
ープのタスクとのデツドロツク発生可能性有無を記憶し
ているテーブルである。

実行制御機構４は、タスク群８が動作する際、資源を
占有・解放する通知を受け取り、受け取つた情報と、デ
ツドロツクチエツクテーブル12、タスクグループ対応テ
ーブル13およびグループ状態テーブル16に格納されてい
る情報に基づきタスク相互間でデツドロツクが発生しな
いようタスクの動作をスケジユーリングするタスクスケ
ジユーラ15と、タスク群８からの個々の資源９に対する
占有・解放要求に基づき、資源ごとに作成された資源管
理テーブル18を用いて、占有・解放を実施するロツクマ
ネージヤ17から成る。グループ状態テーブル16は、各グ
ループに属しているタスクのうち、スケジユーリング可
能（資源占有可能）状態となつているタスク数をグルー
プごとに格納している。また、タスクスケジユーラ15
は、スケジユーリング待ちとなつているタスクの待ち管
理のために、タスク待ちキユー19を使用する。資源管理
テーブル18は、現在資源を占有しているタスクのTIDを
格納しているテーブルである。

なお、本実施例では、単一計算機システムの例となつ
ているが、例えば前処理機構と、実行制御機構が別々の
CPUにより動作し、CPU間に適当な交信機能を持たせたよ
うな複合計算機システムであつても、本発明に何ら影響
を与えない。

第２図は、本計算機システム上でタスクとして動作す
るプログラムの動作内容を示したソースプログラムの一
例である。このソースプログラムは、例えばPASCALやＣ
言語等の「構造化プログラミング言語」に基づいてい
る。この言語のブロツク構造は、ブロツクの入り口から
出口に至る実行過程において、ブロツクの外のステツプ
を実行することがない。したがつて、ソースプログラム
中における資源の操作範囲、すなわち、資源の使用開始
ステツプと使用終了ステツプをこのブロツク構造の入
口、出口に対応させて記述することによつて、資源の使
用順序（占有順序）とソースプログラム上の記述順序を
一致させることができる。

本実施例では、処理の入口（使用開始ステツプ）を
「WITH 資源名 DO BIGIN」、処理の出口（使用終了ス
テツプ）を「END;」というキーワードを用いたブロツク
構造で規定している。なお、以上のような資源の操作範
囲の記述のしかたを「データベース操作言語」と、構造
化プログラミング言語を「親言語」と呼ぶことにする。

なお、ブロツク構造の規定の仕方（キーワード等）に
ついては、親言語となるプログラミング言語と区別可能
な、例えば言語処理系における字句解析，構文解析等に
おいてあいまいさが発生しないような記法であれば、い
かなるものであつてもかまわない。また、データベース
操作言語におけるブロツク構造は、親言語におけるブロ
ツク構造、例えばPASCAL言語におけるBEGIN〜END;と置
き換え可能な位置に記述されていなくてはならない。し
たがつて、データベース操作言語のブロツク構造は、親
言語におけるブロツク構造とネスト（入れ子）の関係に
なるか、あるいは連接または並置の関係になるかのいず
れかとなる。また、データベース操作言語自身のブロツ
ク構造のブロツク間の関係においても同様である。ま
た、記述する資源名称のネストの上位，下位の関係につ
いても特に制約はもたないものとする。本記述例では、
ブロツク構造を規定する部分以外の記述は省略して記し
た。

なお、図中の操作記述範囲は、そのブロツクの内側に
あるブロツク内をも含むものとする。

上記規則に従つていない場合は、ソースプログラムの
コンパイルの際チエツクアウトされ、ユーザによりソー
スプログラムの修正が実施される。

以下、第１図に示す計算機システムの各構成要素の動
作の詳細を説明する。

コンパイラ７は、第２図に示したような形式で記述さ
れたソースプログラムを読み込み、通常のプログラミン
グ言語のコンパイラと同様、ソースプログラムを解析
し、実行可能な形式に変換する。

この際、データベース操作言語のブロツク構造の最も
外側の入口、出口へ、タスクスケジユーラ15に対する資
源アクセス開始，終了通知用システムコールを、またす
べてのブロツク構造に対応する入口，出口に、ブロツク
単位に指定された資源に対する占有，解放を、ロツクマ
ネージヤ17に要求するためのシステムコールを埋め込
む。このとき、すでに外側のブロツクにて出現している
資源名に対応する資源と同一の資源が内側のブロツクに
現われた場合は、その内側のブロツクの入口，出口への
該システムコールの埋め込みは行わないものとする。す
なわち、１つの資源に対する２重占有は行わないように
する。

また、一方、そのプログラム内にあるデータベース操
作言語のプログラム構造のネスト関係から、資源の占有
順序情報を抽出する。

資源占有順序は、プログラムに対応する資源名を節
点，外側のプログラムを始点，内側のブロツクを終点と
する有向枝をもつ有向グラフの形となる。

第３図に、ソースプログラムから、上記の有向グラフ
を抽出する処理例の概略フローを示す。

本処理フローのキーワードは、第２図に示したソース
プログラム記憶に準じている。また、本プログラムは、
有向グラフを計算機上で表現しやすいように、有向枝に
対応した（終点，始点）の２つ組の集合を、結果として
出力するようにしている。

第４図に、第２図のプログラムをソースプログラムと
し、第３図の処理フローを適用した際の結果を（ａ）に
示し対応する有向グラフを（ｂ）に示す。

コンパイラ７は、各タスクごとにこの有向グラフを作
成し、資源占有順序テーブル10へ格納する。なお、通常
の場合、１つのタスクは１本のメインプログラムと複数
のサブプログラムからなり、それぞれのコンパイル単位
は別となる。このような場合は、コンパイル単位ごとに
有向グラフを作つておくとともに、ブロツク内で使用し
ているサブルーチン呼び出しを抽出しておき、その関係
からそのプログラムがリンクエデイツトされるのと同
様、有向グラフもリングエデイツト（マージ）すること
により、最終的には、タスクごとの有向グラフが抽出で
きるようになる。

第５図は、資源占有順序テーブル10の実現例（ａ）と
対応する有向グラフ（ｂ）を示す。ここでは、第４図で
示した結果に、TIDが付与された３つの組の形式で記憶
している。また、２重枝（第４図の例におけるＢからＡ
へ向う枝）は、１つの枝として記憶しているとともに、
推移枝（第４図の例におけるＣ→Ａの枝）は、他の枝
（Ｃ→B,B→Ａ）から推移可能であるので、省略して記
憶する。なお、第２図のプログラムは、TID＝１の場合
として表わされている。

テーブルジエネレータ11は、本計算機システム上でデ
ータベースのアクセスを実施するすべてのタスクについ
て資源占有順序テーブル10に占有順序情報が登録された
時点で起動され、まずタスク相互間でデツドロツク発生
可能性があるかどうかを示す中間テーブル14を生成す
る。第６図に、第５図に対応して作成される中間テーブ
ルの例を示す。

なお、第６図において、○は同時動作してもデツドロ
ツクが発生しないことを、×はデツドロツクの発生する
可能性のあることを示す。なお、計算機システム上で
は、例えば○を０、×を１などし、記憶する。

第７図は、第６図に示すような中間テーブル１つの要
素○，×を判定するための処理例の概略フローである。
デツドロツク発生可能性の有無は、基本的には、資源占
有順序を示す有向グラフを、対象とするタスク同士間で
マージ（merge）したとき、つまりタスクとして動作す
るプログラム同士間で比較又は突き合わせたとき、そこ
に有向グラフをマージしたことにより強連結成分（逆転
またはループ）が存在するか否かを判定することにより
求められる。

有向グラフの強連結成分は、グラフ上の任意の節点を
とつたときに、そこから出発して有効枝をたどり、再び
出発点へ戻ってこれるようなループする経路が１つでも
存在すれば、そのグラフ上に存在する。なお、強連結成
分の存在有無は、推移枝の存在有無により影響を受けな
い。強連結成分の存在有無は、例えば次のような処理で
求めることができる。

（１） 与えられた有向グラフに、そのグラフを構成す
る枝から推移されるすべての有向枝を付加する。

（２） 付加された推移枝から推移される推移枝も、同
様に再帰的に付加する。

（３） 得られた有向グラフのすべての枝の組み合わせ
の中に、１組でも始点と終点の関係が逆の枝が存在すれ
ば、強連結成分が存在する。

なお、この中間テーブル14は、上三角形分と下三角成
分が対称であるため、実際にはそのどちらか一方を求め
ることにより作成可能である。

なお、１つもネストしないタスクのTIDは、資源占有
順序テーブルに出現しないが、このタスクに対応する各
行，各列はすべて○とする。

テーブルジエネレータは、次にタスクのグルーピング
を実施する。第８図は、グルーピングの一処理例の概略
フローである。

第８図の処理は、実行時のオーバヘツドを減少するた
めに、デツドロツク発生可能性のないタスク同士で、他
タスクとのデツドロツク発生可能性が同一であるタスク
をグルーピングするものである。グルーピングした結果
は、デツドロツクチエツクテーブル12およびタスクグル
ープ対応テーブル13へ格納される。

第９図は、第６図の中間テーブル14をグルーピングし
た結果であるデツドロツクチエツクテーブル12（ａ）
と、タスクテーブル対応テーブル13（ｂ）の例である。

また、前処理機構３は、例えばデツドロツクチエツク
テーブル12,タスクグループ対応テーブル13の内容、お
よび資源占有順序テーブル10の内容を、例えばCRTやプ
リンタといつた出力装置にプログラムの同時実行可能性
をユーザが知るための情報として出力する。このことに
より、ユーザは、プログラムを実際に動作させることな
しにタスクの並行処理性を見積ることが可能となり、ま
た並行処理効率を悪化させる要因となる。アクセス順序
の異なるタスクを摘出し、プログラム修正を行うことも
可能となる。

前処理機構３は、以上示した処理を実際にタスクが動
作する前に行うため、タスクの実行におけるオーバヘツ
ドの増大は伴わない。

以下、タスク実行時における排他制御実施方法の一実施
例につき詳述する。

第10図は、実行制御機構４におけるタスクスケジユー
ラ15の処理例の概略フローである。

タスク８は、動作開始後、コンパイラ７によつて埋め
込まれた資源アクセス開始通知用システムコールにて、
タスクスケジユーラ15に対して資源９のアクセス開始を
通報する。タスクスケジユーラ15は、まずタスクグルー
プ対応テーブル13から、通報のあつたタスク８が所属し
ているグループのGIDを取り出し、次にグループ状態テ
ーブル16を参照し、同一グループに属しているタスク８
が動作中かどうかを判定する。グループ状態テーブル16
は、グループごとにスケジユーリング（動作）中のタス
ク８数を格納している。もし、動作中（タスクカウンタ
≠０）であるならば、当該タスク８もスケジユーリング
可能状態となるため、当該タスク８の所属するグループ
に対応するタスク８数カウンタをカウントアツプする。

もし、当該タスクの所属グループのタスクが動作中で
ない（タスクカウンタ＝０）ならば、デツドロツクチエ
ツクテーブル12から、デツドロツクの発生可能性のある
グループのGIDを取り出す。もし存在していなれば、前
記同様タスクカウンタをカウントアツプし、スケジユー
リング状態となる。存在している場合は、そのGIDを用
いグループ状態テーブル16のタスクカウンタを参照し、
１つでも動作中の場合は、タスク待ちキユー19に当該タ
スク８のTIDを登録し、待ち状態となる。１つも動作中
でない場合には、グループ状態テーブル16を参照し、動
作中グループ数（タスクカウンタが１以上となつている
グループの数）が２つ以上あれば、タスク待ちキユー19
に当該タスクのTIDを登録し、待ち状態となる。グルー
プ数が１つの場合は、グループ状態テーブル16の当該タ
スクの所属GIDのタスクカウンタをカウントアツプす
る。

一方、タスク８は、資源に対する一連のアクセスを完
了すると、資源アクセス終了通知用システムコールに
て、タスクスケジユーラ15に対して資源アクセスの完了
を通報する。タスクスケジユーラ15は、通報のあつたタ
スク８のTIDを用いて、タスクグループ対応テーブル13
から当該タスク８の所属GIDを取り出し、グループ状態
テーブル16のGIDに対応するタスクカウンタをカウント
ダウンする。さらに、アクセス完了に伴つて、待ちとな
つているタスク群が実行可能となる場合があるため、タ
スク待ちキユー19に登録され、待ちとなつているタスク
８について、要求時と同一の処理（第10図参照）を実施
し、再びデツドロツクチエツクを行い、デツドロツクが
発生しない場合は、そのタスク８を動作させる（スケジ
ユーリング可能性態とする）。

以上説明したように、タスクスケジユーラ15は、デツ
ドロツクを発生させる可能性のあるタスク８を同時に実
行させないように制御するため、タスク８間のデツドロ
ツク発生を完全に回避できる。

一方、起動され実行中のタスク８は、個々の資源の使
用開始時点において、資源ロツクのシステムコールを発
行することにより、ロツクマネージヤ17に対し、タスク
８のTIDと使用対象となる資源の識別子を渡たし、資源
ロツク要求を行う。

これに対して、ロツクマネジヤ17は、資源識別子に対
応する資源が他のタスク８によりロツク中か否かを調べ
めるために、資源管理テーブル18A,18B,18Cのうちの該
当テーブルを参照する。資源管理テーブル18A,18B,18C
は、個々の資源がロツク中か否かの情報とロツクタスク
８のTID（ロツク中の場合のみ）の格納している。ロツ
クマネージヤ17は、参照結果よりロツク要求を出したタ
スク以外のタスク８がロツク中の場合、ロツク要求を出
したタスク８の資源がアンロツクされるまで待ちとす
る。ロツク中でない場合は、該当資源管理テーブル18中
の対象資源のロツク情報をロツク中であると更新し、ロ
ツク要求を出したタスク８のロツクを認可する。

一方、タスク８は、個々の資源の使用終了時点におい
て、資源アンロツクのシステムコールを発行することに
より、ロツクマネージヤ17に対しタスク８のTIDと使用
終了する資源の識別子を渡たし、資源アンロツク要求を
行う。これに対し、ロツクマネージヤ17は、資源管理テ
ーブル18中の該当する資源のロツク状態情報をアンロツ
ク状態とし、資源のアンロツク待ちとなつているタスク
８を待ち状態から実行状態へ回復する。このことによ
り、１つの資源に対する複数タスク８からの同時操作を
排除し、データベース中のデータの完全性破壊防止でき
る。

以上説明したように、実行制御機構として、タスクグ
ループ対応テーブル13,デツドロツクチエツクテーブル1
2,グループ状態テーブル16およびタスクスケジユーラ15
を具備し、デツドロツクの発生可能性のあるタスクを待
ちにすることにより、デツドロツク発生を完全に回避
し、またデータの完全性の破壊を防止した効率のよい排
他制御が実現できる。

なお、本実施例においては、２グループ間のデツドロ
ツクチエツクしか行つていないため、２グループしか同
時にスケジユーリングできないが、同様の方法により、
ｎグループ間までのチエツクを行うことにより、ｎグル
ープ同時にスケジユーリングできるようになることはい
うまでもない。

また、ブロツクネストのないタスク（対応する有向グ
ラフ上に節点のみで枝が１つも存在しないタスク）につ
いては、デツドロツク要因とはならないため、タスクス
ケジユーラ15による管理対象外として、常にスケジユー
リングできるようになることもいうまでもない。

また、本実施例では、資源に対する占有をタスク８間
で排他的に行う排他ロツク方式につき説明したが、検索
のみ行う場合においては、同時に資源を占有できる共用
ロツク方式を可能とした場合においても、コンパイラに
よりデータのアクセス種類（更新を行うか否か）をも抽
出し、それに基づき、ロツクモード（排他共用）を決定
し、デツドロツク発生可能性のあるタスク８を決める際
に、双方とも共用ロツクモードであれば、待ちが発生し
ないことをデツドロツクチエツクの判定条件に付加する
ことなどにより、より並行性の高い排他制御が実現でき
ることも容易に類推可能である。

以上説明したように、本実施例のデータの排他制御方
式を用いると、 （１） プログラマ，データベース管理者ともに、排他
制御に対する事項（手続きの記述やデータ操作順序の制
約）を一切意識することなく、データベース操作が行え
る。

（２） デツドロツクを完全に回避した並行処理動率の
高い排他制御が実現でき、また実行時のオーバーヘツド
も小さい。このことにより、オンライン・リアルタイム
分野の適用も可能である。

（３） ユーザが介在しないため、高い信頼性を実現で
きる。

といつた効果があり、プログラムの生産性，信頼性の
向上が図れる。

〔発明の効果〕

本発明によれば、複数の資源を共用する複数のプログ
ラムのブロツク構造による記述により、各プログラムか
ら各資源の使用順序の組を抽出し、デツトロツク発生の
可能性あるプログラム関係を登録するため、プログラム
間のデツドロツクの発生の有無を該プログラムの実行以
前に抽出してデツドロツクの発生を防止できるという優
れた効果がある。

【図面の簡単な説明】 第１図は本発明の一実施例の計算機システムの概略構成
図、第２図は同計算機システムのプログラム記述例、第
３図はコンパイラの概略処理フロー、第４図（ａ），
（ｂ）はコンパイラの出力例を対応グラフ、第５図
（ａ），（ｂ）は資源占有順序テーブルの内容例と対応
グラフ、第６図は中間テーブルの例を示す図、第７図は
テーブルジエネレータの概略処理フロー、第８図はテー
ブルジネレータのグルーピング処理フロー、第９図
（ａ），（ｂ）はデツトロツクチエツクおよびタスクグ
ループ対応テーブル内容例、第10図はタスクスケジユー
ラの概略処理フローである。 １……計算機システム、２……CPU、３……前処理機
構、４……実行制御機構、５……データベース、６……
ソースプログラム、７……コンパイラ、８……タスク、
９……資源。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 昭61−233849（ＪＰ，Ａ) 「日立評論」Ｖｏｌ．68，Ｎｏ．５ （1986−５）Ｐ．59〜64

Claims (1)

【特許請求の範囲】
1. 【請求項１】並列に動作する複数のプログラムによりデ
   ータベースの複数の資源を共用する際に、デツドロツク
   発生の可能性があるプログラムを同時に実行させないよ
   うに制御するデータベース排他制御方法において、構造
   化プログラミング言語のブロツク構造に則り記述された
   それぞれのプログラムの使用する資源名とその使用開始
   および使用終了とのネスト関係より、それぞれのプログ
   ラムごとにそれぞれの資源の使用順序を当該プログラム
   のソースプログラムの各行の記述上の順序に従つて読み
   込むことにより抽出し、実行前にその抽出したそれぞれ
   のプログラム間でそれぞれの資源の使用順序を比較し、
   マージされた有向グラフ上に強連結の関係を生じるプロ
   グラムの組をデツドロツク発生の可能性ありとして登録
   することを特徴とするデータベース排他制御方法。