JPH02211546A - 資源の相互排他制御方法及びシステム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 この発明は、事象駆動型プロセスにおける逐次的利用可
能資源の相互排他制御方法及びシステムに関するもので
ある。ここで制御する逐次的利用可能資源の対象は、計
算機およびプログラマブル・ロジック・コントローラな
どが制御する資源である。

Ｂ、従来の技術及びその問題点 最近のコンピュータ技術では、マルチタスク。

マルチプロセス、分散処理が重要な課題になっている。

これらの技術を実現する為には、複数のタスクまたはプ
ロセスが並列実行される際に、資源を幾つかのタスクま
たはプロセスで共有しなくてはならない、この資源を共
有資源とよび、例えば種々の周辺装置、ディスク、メモ
リ、過信回線、プログラム、データ等が挙げられる。−
時に一つのタスクまたはプロセスでしか専有できない共
有資源を重要資源という。

事象駆動型プロセスにおける資源の相互排他制御の問題
は、事象駆動型プロセスが並列に実行され、それらのプ
ロセスが共有資源を使用するときに起きる。資源の相互
排他制御とは、高だか１つのプロセスしか共有資源を専
有しないための機構である。また並列実行のプロセスの
中で、共有資源を専有する部分を危険区間という、これ
は、複数のプロセスが並列実行される際の資源の共有問
題であり、プロセス間の通信及び同期化問題として提起
されている。これを解決するために、従来より多くの手
法が提案されモデルを用いて解析されてシステムの中で
用いられている。この同期化問題としては、相互排他問
題、生産者消費者問題、食事をする哲学者問題、読みだ
し書きこみ問題がある。

現在は、並列実行システム実現の際１重要な問題となる
複数のプロセス間の資源の相互排他制御はセマフォ等を
使いプログラマが注意して書く以外に方法がない、この
ように、プログラマが並列実行するプログラムを書くと
き、又はオペレータはその環境下でプログラムを実行す
るときに、常に資源割当を意識しなくてはならない、こ
れは、プログラマやオペレータにとって負担である。

以下に、セマフォを用いたプログラミングの１例を示す
、今、第２図に模式的に示す事象駆動型の３つのプロセ
スの流れＧｉ、Ｇ、、Ｇ、があるとしよう、第１のプロ
セスの流れＧ１では、タスクｐ１とｐ、が連続して・実
行される。タスクｐユが共有資源ＡとＣを使いながら実
行された後、統いてタスクｐ２が共有資源ＢとＣを使い
ながら実行される。

第２のプロセスの流れＧ２では、タスクＰ、が実行され
る。タスクＰ２は共有資源Ａ、Ｂ、Ｃを使いながら実行
される。第３のプロセスの流れＧ３では、タスクＰ、と
Ｐ、が並列に実行される。タスクＰ、は共有資源ＡとＣ
を使いながら実行され、タスクＰ、は共有資源ＢとＣを
使いながら同時に実行される。ｔ□〜ｔ、はタスクの始
点または終点を示している。第２図に登場する資源のう
ち１重要資源はＡとＢであり、かつ重要資源Ａはロボッ
ト２、重要資１１１（Ｂはロボット１であるとする。

現在は、はとんどの場合において、プログラミングが各
重要資源（マニファクチャリング・プロセスに於ける生
産機器のコントローラ、ネットワーク・システムに於け
るコンピュータ）上で行なわれており、各重要資源上の
プログラムと、それらを制御するプログラムが必要にな
る。この例を第３図に示す。第３Ａ図は全体を制御する
プログラム、第３Ｂ図はロボット１のプログラム、第３
Ｃ図はロボット２のプログラムである。

ここでは、並列実行を記述する構文は次のとおりである
。

ｃｏｂｅｇｉｎ Ｐｌ　； ｏｅｎｄ ここでＰｌ、Ｐ２は並列実行されるタスクである。

また、危険区間を記述する構文は次のとおりである。

ｗｉｔｈ　　Ｒｄ。

ｂｅｇｉｎ ａｎｄ ここで、Ｒは相互排除すべき重要資源に対する一意名で
あり、Ｓは相互排除すべき危険区間である。

この場合Ｒがセマフォとなる。

第３Ａ図において、Ｒ（ｐ）は第３Ｂ図、第３Ｃ図で示
す、それぞれのロボットのプログラムである。Ｒにパラ
メタｐを渡すとＲのプログラムはｐのタスクのみが実行
される。

危険区間を記述する構文およびそのメカニズム。

並列実行を記述する構文およびそのメカニズムは、−船
釣にプログラマに供給されておらず、その記述およびそ
のメカニズムの作成、そして相互排他制御のデバッグは
プログラマの責任となる。

さて、システムのモデリングに多く用いられてきた手法
の一つにペトリネットがある。ペトリネットの特徴は、
並列性あるいは同時進行性と非同期性であり、その実行
は離散的な事象の系列と考えることができ、いつ事象が
発生するかは非決定的である。この特徴及び実行形態を
利用して事象能動型の制御に利用しようとする試みがな
されている。また、ペトリネットの数学的解析性の良さ
とモデル化能力の高さに注目して、並列実行システム（
計算機モデル、マニファクチャリング・プロセス）のシ
ュミレーションに使われている。

ペトリネットの概略を説明する。

ペトリネットはプレース、トランジション、アーク、ト
ークンの４つから構成されており、プレースは事象を、
トランジションは条件、アークは経路、トークンは状態
を表わす。トークンはトランジションの条件に従ってプ
レース間の経路を移動し、プレースに対応した事象を引
き起こす。

第４図は、ペトリネットの実行例である。この例では、
トランジションＴ＝（ａ、　ｂ、ｔｃ）、プレースＰ＝
（ＰＸ、Ｐｙ、Ｐｚ）、ト−クンを用いて説明する。ま
ず、　　ａは、　　Ｘにトークンがなければ、トークン
を発生させ、　　Ｘｐ に置く（第４Ａ図）、　ｂは　Ｘにトークンがありかつ
Ｐｙ、Ｐｚにトークンがなければ、トーク、　　ｐ　　
　　ｐ　　　　　　　　　　　　　　　　　　ｔノを　
ｙ、　　ｚに移す（第４Ｂ図）、　ｃはトークンが　ｙ
、　　　ｚあれば、Ｐｙ、ＰｚよりトークＰ ンを取りだして、このトークン消滅させる。なお、ペト
リネットの詳細については、例えば（１）Ｐｅｔｅｒｓ
ｏｎ、Ｊ、Ｌ、著 ”Ｐｅｔｒｉ　Ｎｅｔ　Ｔｈｅｏｒｙ　ａｎｄ　ｔｈｅ
　Ｍｏｄｅｌｉｎｇ　ｏｆＳｙｓｔｅｍｓ”、Ｐｒｅｎ
ｔｉｃｅ−Ｈａｌｌ　Ｉｎｃ、、１９８１を参照された
い。

最近は、プログラマがグラフィック・エディタを用いて
第２図または第４図のようなプロセスの流れを記述し、
これをコードに変換して全体を制御するプログラムを作
成し、実行時には該プログラムに基づいて、タスクの開
始を命じたり終了信号を受は取ったりしつつ、これらの
信号に応じて、トークンを自動的に移動させていくシス
テムも提案されている。例えば、 （２））Ｉａｓｅｇａｔｓａ、　に、ａｎｄ　　Ｔａｋ
ａｈａｓｈｉ、　に１、　″阿ＦＧ（ＭａｒｋＦｌｏｗ
　Ｇｒａｐｈ）−Ｂａｓｅｄ　Ｐｒｏｇｒａｍｍａｂｌ
ｅ　Ｃｏｎｔｒｏｌｌｅｒａｎｄ　ｉｔｓ　Ａｐｐｌｉ
ｃａｔｉｏｎ　ｔｏ　ＦＭＳ、”Ｐｒｏｃｅｅｄｉｎｇ
ｓ　ｏｆｔｈｅ　　Ｉｎｔｅｒｎａｔｉｏｎａｌ　　Ｃ
ｏｎｆｅｒｅｎｃｅ　　ｏｎ　　ＳｙｓｔｅｍＥｎｇｉ
ｎｅｅｒｉｎｇ、ｐｐ３０６−３１１．１９８４．。

を参照されたい。

しかしながら、従来のこの種の制御システムにおいて、
相互排他制御を考慮したものはない。

また、プログラミングではなくモデル化の方面において
ではあるけれども、資源の空状態にあたるプレース（空
プレース）を作成し、その資源を使うタスクのプレース
と繋ぎ、危険区間を設定することによって、相互排他制
御のモデル化が行われている。ここでは、ペトリネット
の重要な性質である保存性を利用している。その空プレ
ースには、初期マーキングとしてトークンが入っており
、資源を使用されないときは、常にトークンが入ってい
る。あるプロセスが危険区間に入っていて、資源を使用
しているとき、空プレースにはトークンがない、他のプ
ロセスが同じ資源を使おうとして、危険区間に入ろうと
すると、空プレースにはトークンがなく、発火条件が満
たされないので。

プロセスは実行できない、資源を使用しているプロセス
が終了し、資源を解放して空プレースにトークンが戻る
まで、他のプロセスの実行は待たされる。

第５図にこのようなモデル化の１例を示す。

プレースｍは危険区間に入るための許可をあられす、あ
るプロセスが危険区間に入るには、ＰＬまたはｐ２にト
ークンを入れて危険区間に入りたいという合図を出し、
危険区間に入ってよいという合図すなわちｍのトークン
を待って危険区間にアクセスすることとなる０両方のプ
ロセスが危険区間に入りたいときには、トランジション
ｔ、とｔ２は競合となり、どちらか一方しか発火できな
い。

ｔｌの発火はｔ２を発火不能とし、プロセス１が危険区
間を終わってトークンをｍに戻すまでプロセス２は待機
するこことなる。

では、第５図のような重要資源の空プレースを含んだグ
ラフを作成してこれをコードに変換することによって、
相互排他制御を考慮した全体の制御プログラムを作成し
、上記文献（２）に示されるシステムの如く、トークン
を自動的に移動させていけば、相互排他制御が容易に実
現されるだろうか、残念ながら、答は「否」である、そ
の理由を以下に述べる。

（１）まず、空プレースをペトリネットの中に組み込ま
なければならない、プログラマが重要資源を意識してそ
の空プレースをペトリネット中の適切な場所に組み込ん
でいくとすれば、その労力はセマフォを用いたプログラ
ミングと同等のものになるであろう、第５図のような簡
単な事例ならともかく、第６図のように事例が少し複雑
になるだけで、ペトリネットの作成は大幅に困難になる
。

（２）実行時において、ユーザが、まず空プレース（資
源プレース）をタスク・プレースと区別した後、空プレ
ースのすべてに初期トークンを置かなければならない、
これはユーザーに大きな負担をかけることになる。

（３）ペトリネットの表現自体に起因してデッドロック
が生じる場合がある。

第６図を例にとって説明しよう、今、第６Ａ図のような
状態にあるとする。すなわち、タスクＰ８、Ｐ４が実行
中であり、資源Ｐｘ、Ｐｙは空いている。なお、資源Ｐ
ｘは、タスクＰ２、Ｐ３゜Ｐ６で使用される。資源Ｐｙ
は、タスクＰ３、Ｐ５、Ｐ６で使用される。

第６Ａ図の状態にあるならば、制御システムがタスクＰ
２、Ｐ、の実行を開始できることは明らかである。よっ
て、１．．１４は、トークンをそれぞれＰ２．Ｐ、に移
す、ここで注意すべきは、第５図、第６図のような表現
では危険区間の両端と資源の空プレースとを繋いでいる
ため、タスクＰ２に続いてタスクＰ３の実行が終了する
までＰｘの空きプレースにトークンが移ることはとなく
、同様に、タスクＰ５に続いてタスクＰ６の実行が終了
するまでＰｙの空きプレースにトークンが移ることはな
いことである。タスクｐ、、ｐｓの実行開始後のトーク
ンの位置を第６Ｂ図に示す、さて、タスクＰ２の実行が
終了しても、制御システムはタスクＰ３の実行を開始で
きない、Ｐｙの空きプレースにトークンがないからであ
る。タスクＰ、の実行が始まらない限りはＰｘの空きプ
レースにトークンが戻ることもない、よってタスクＰ６
の実行が開始されることもない、このように、トランジ
ションし２と１ｓが発火できずデッドロックが起こる。

ペトリネットでは、発火できないトランジッションおよ
びその集合をデッドロックという。

数学的に表現するなら、ペトリネット構造をＧとすると
、Ｇ＝　（Ｐ、Ｔ、Ｏ）である、ここで。

ｐ＝　（ｐ、、　ｐ、、・・・　ＰＭ）は、プレースの
集合であってＭｈｏである。Ｔ＝（Ｔ工、Ｔ２．・・・
、Ｔ）は、トランジッションの集合であってＬ＞１であ
る。プレースの集合とトランジッションの集合とは互い
に素であり、ＰｎＴ＝φである。Ｉ　：　Ｐ−＞Ｔは、
プレースからトランジッションへの入力関数である。ｏ
：’ｒ−＞ｐは、トランジッションからプレースへの出
力関数である。このペトリネット構造に、プレースへの
トークンを割り当てたマーキングμを加えたものをマー
クペトリネットという。

トークンはプレースのみに存在し、トランジッションの
発火が実行を制御している。トランジッションの発火は
、トークンが入力ブレースから出力ブレースへ移動する
ことである。ペトリネット構造は、グラフ理論において
は双対である。マークペトリネットにおいては双対の定
義が困難なため、双対の概念が利用されていない。

Ｃ０問題点を解決するための手段 本発明による資源の相互排他制御方法は、（ａ）プロセ
スの流れに含まれるタスク及び何れかのタスクによって
専有され得る重要資源がノードに対応され、逐次実行さ
れるタスクのノードは直列に配置されるとともに、並列
して実行されるタスクのノード同士は並列に配置され１
重要資源のノードは該重要資源を専有し得るすべてのタ
スクのノードと並列に配置されてなるグラフを記憶装置
上に作成し、 （ｂ）タスクの実行開始信号を送る度に、上記グラフ中
の該タスクのノード及び該ノードに並列に配置された重
要資源のノードにトークンを発生させ、プロセスの流れ
の中で先行するタスクの実行の終了を検知したとき、上
記グラフを参照して、直接の後続タスクのノード又は該
ノードに並列に配置された重要資源のノードの何れか１
つにトークンが存在している間は、直接の後続タスクの
実行開始信号の送出を待機する ことを特徴とする。

上記ステップ（ａ）では、上記グラフにおいて、連続し
て実行されるタスクのノード同士を連結する位置にゲー
トのノードが設けられ、 上記ステップ（ｂ）では、タスクの実行の終了を検知す
る度に、該タスクのノード及び該ノードに並列に配置さ
れた重要資源のノードに存在するトークンを消滅させ。

ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、該
後続タスクの実行開始信号を送った後に、該ゲート・ノ
ードのトークンを消滅させることが好ましい。

本発明による好ましい資源の相互排他制御システムは、
プロセスの流れに含まれるタスク及び何れかのタスクに
よって専有され得る重要資源に対応するノードを持ち、
逐次実行されるタスクのノードは直列に配置されるとと
もに、並列して実行されるタスクのノード同士は並列に
配置され、タスクのノード同士を連結する位置にゲート
のノードが配置され１重要資源のノードは該重要資源を
専有し得るすべてのタスクのノードと並列に配置されて
なるグラフを保持する記憶装置と。

タスクの実行開始信号を送る度に、上記グラフ中の該タ
スクのノード及び該ノードに並列に配置された重要資源
のノードにトークンを発生させる手段と、 タスクの実行の終了を検知する度に、該タスクのノード
及び該ノードに並列に配置された重要資源のノードに存
在するトークンを消滅させる手段と、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、該
後続タスクの実行開始信号を送った後に、該ゲート・ノ
ードのトークンを消滅させる手段、を具備する。

Ｄ、実施例 第１図は、この発明の実施例のシステム構成図である。

以下、この図のステップ８１〜Ｓ８を順に説明する。

（ａ）プロセス・フロー・グラフの作成（ステップＳ１
） ユーザは、単位プロセスをタスクとして、事象恥動型プ
ロセスを表現するプロセス・フロー・グラフを作成する
。ここで作成されるプロセス・フロー・グラフは、安全
で且つ活性の性質を持つ制限された（多重核も自己ルー
プもない）ペリトネット・グラフと等価である。プロセ
ス・フロー・グラフの定義は、［数学的な表現］の項を
参照されたい。

このプロセス・フロー・グラフの作成法としては、グラ
フィックス・エディタを用いてグラフィカル・シンボル
で記述した後、それをテキスト表現に変換する方法と、
テキスト・エディタを用いて文字コードで直接記述する
方法がある。ここで作成されたプロセス・フロー・グラ
フをプロセス・フロー・プログラムとも呼ぶ。

本実施例では、ユーザが対話的にグラフィクス・エディ
タによって記述する。第７図は、プロセス・フロー・プ
ログラムのグラフィカルな表現である。

プロセス・フロー・グラフ上の制御単位をタスクと呼び
、プログラム・ファイルに対応している（第８図参照）
。

第７図を用いて、プロセス・フロー・グラフの定義に従
った実行例を説明する。トークンがコンデイション・ゲ
イトＣｉまたはＣ４に発生する。トークンがコンデイシ
ョン・ゲイトＣ１に発生した場合は、タスク・プレース
ＴいＴ２にトークンが移動し、タスクＴユ、Ｔ２がそれ
ぞれ資源Ｒｐ、−’　Ｒｅを使いながら実行される。タ
スクＴ工、Ｔ２がどちらも終了すると、コンデイション
・ゲイトＣ２の条件により、トークンは、タスク・プレ
ースＴ、に移動する。タスクＴ３は資源Ｒ３を使いなが
ら実行される。そして、タスクＴ、が終了すると、トー
クンは、プレースＴ１からコンデイション・ゲイトＣ１
に移動し、消滅する６次に、トークンがコンデイション
・ゲイトＣ４に発生した場合は、タスク・プレースＴ、
にトークンが移動し、タスクＴ４が資源ＲＡ＆使いなが
ら実行される。タスクＴ４が終了すると、コンデイショ
ン・ゲイトＣ８の条件により、トークンは、タスク・プ
レースＴ、に移動する。タスクＴ５は資源ＲＡ−Ｒｎを
使いながら実行される。そして、タスクＴ５が終了する
と、トークンは、プレースＴ、からコンデイション・ゲ
イトＣ１に移動し、消滅する。この実行例では、資源の
相互排他制御は、含まれていない、ここで。

コンデイション・ゲイトとは、ペトリネット・モデルに
おけるトランジションに相当するものだが、それ自体に
トークンを置き得るという点でトランジションと決定的
に異なっている。この点については後で詳しく述べる。

プロセス・フロー・プログラムのテキスト表現を、プロ
セス・フロー・グラフの中間コードの形で作成する。こ
れは、グラフィカルな表現と等価であり、相互変換がで
きる。以後グラフのテキスト表現を単に中間コードとも
呼ぶ。

プロセス・フロー・グラフの中間コードの書式％式％ ： 入力ブレース（、入力ブレース・・・）／出力ブレース
（、出力ブレース・・・）第７図の実施例の中間コード
は、下記のようになる。

Ｃ１：　／Ｔい　Ｔ３ Ｃ，：　Ｔ１、Ｔ　ｌ　／　Ｔ　３ Ｃ３：　Ｔ３／ Ｃ４：／Ｔ４ Ｃ，：　Ｔ、／Ｔ。

Ｃｓ　：　Ｔｓ／ （ｂ）資源管理グラフの生成（ステップＳ２．８３）こ
のプロセス・フロｍ−グラフとタスク・プログラムより
、資源管理グラフを生成する。タスク・プログラムの中
よりタスクに必要な重要資源の資源名を抽出し、そのリ
ストを生成する。第８図に示すようにタスク・プログラ
ムがテキストで記述された場合、その中で記述される重
要資源は、資源の論理記号、資源の論理番号、資源の論
理名などで記′述される。プロセス・フロー・グラフと
資源名を抽出したリストから資源管理グラフを生成する
。第９図が、第７図のプロセス・フロー・グラフとその
タスクで必要な重要資源の資源名リストより生成された
資源管理グラフを示す。

なお、第８図に示す如く、ユーザは、タスクのつながり
を記述するプロセス・フロー・グラフにおいても、また
、個々のタスクを記述するタスク・プログラムにおいて
も、プログラム作成時にセマフォ等を使って資源管理を
意識する必要は一切ないことに注意されたい。

本実施例では、タスク・プログラムの作成は、テキスト
・エディタを用いて対象指向型言語で記述され、その書
式は下記の通りである。

資源の論理名：コマンド タスク・プログラム中の資源の論理名から、タスクの中
で用いる重要資源名を抽出したリストを作り、このリス
トとプロセス・フロー・グラフより資源管理グラフを生
成する。

資源管理グラフの中間コードの書式を、プロセス・フロ
ー・グラフの中間コードの書式と同じにすると、第９図
の実施例の中間コードは、下記のようになる。

Ｃ工：／ＲＡ、　Ｒ８ Ｃ・：　ＲＡ、　ＲＢ／ＲＢ Ｃ，：　ＲＢ／ Ｃ・：／ＲＡ Ｃ・＝　ＲＡ　／　ＲＡ　−Ｒｓ Ｃ・：　ＲＡ、　ＲＢ／ 第１０図は、資源名リストでプロセス・フロー・グラフ
からこのような中間コードを生成するためのアルゴリズ
ムを示すフロー・チャートである。

なお、すべての資源が重要である場合には、タスク・プ
ログラムに含まれるすべての資源名を自動的に抽出する
ことによって資源名リストを作成してもよい、資源名リ
ストはユーザが重要資源名を指定して作成してもよい。

（Ｃ）プロセス・リソース・グラフの生成（ステップＳ
４、Ｓ５．Ｓ６） プロセス・リソース・グラフの生成の過程を、フロー・
チャートとして第１１図に示す。このフロー・チャート
に従って説明を行う。プロセス・フロー・グラフと資源
管理グラフをロードしくステップ１１１，１１２）、そ
れらから共通結合のグラフを生成する（ステップ１１３
）。

第７図のプロセス・リソース・グラフと第９図の資源管
理グラフから生成される共通結合のグラフを、第１２図
に示す。

共通結合グラフの中間コードの書式を、プロセス・フロ
ー・グラフの中間コードの書式と同じにすると、第１２
図の共通結合グラフの中間コード表現は、下記のように
なる。

Ｃ１：／ＴいＴ、、　ＲＡ、　ＲＢ Ｃ，：　Ｔ１、Ｔ２、ＲＡ、　ＲＢ／　Ｔ　３、ＲＢＣ
，：　Ｔ□、ＲＢ／ Ｃ，：　／Ｔ、、　ＲＡ Ｃｓ：　Ｔ４．　Ｒ／Ｔ、、　ＲＡ、　ＲＢＣ，：　Ｔ
、、　ＲＡ、　ＲＢ／ 第１３図は、プロセス・フロー・グラフと資源管理グラ
フとからこのような中間コードを生成するためのアルゴ
リズムを示すフロー・チャートである。つまり、第１１
図のステップ１１３を詳述したものである。

ところで、このようにして生成された共通結合のグラフ
を無条件でそのままプロセス・リソース・グラフと見做
すと、デッドロックが生じる場合がある。

第１４図を使ってデッドロックが生じる場合を示す、初
期状態としてトークンがコンデイション・ゲイトＣ１に
ある。タスクＴ工が資源ＲＡ＆使い、タスクＴ、が資源
ＲＡ、Ｒ８を使いながら実行しなければならないので、
デッドロックが起きるゆ本実施例では、共通結合のグラ
フのデッドロックが生じないグラフを、プロセス・リソ
ース・グラフとする。これに従って実行すると、事象即
動型プロセスの制御と資源の相互排他制御が同時に行え
る。共通結合のグラフがデッドロックを生じる場合は、
それをユーザに表示する。

本実施例では、この共通結合のグラフで起こりうるデッ
ド・ロックは、プロセス・フロー・グラフと資源管理グ
ラフから共通結合のグラフが生成された時点で、デッド
ロックのチェックを行って（ステップ１１４）、表示し
ている（ステップ１１５）。

第１４図を共通結合グラフの形で表現したものが第１５
図である。第１５図に示すごとく、デッドロックの起こ
る場合とは、コンデイション・ゲートと資源プレースと
が重複してつながれる場合のことである。生成された共
通結合のグラフの中に１つのコンデイション・ゲートと
重複してつながれた資源があるか否かチェックし、あれ
ばそれをユーザに指摘してやればよい、デッドロックが
生じないならば、共通結合グラフはそのままプロセス・
リソース・グラフとされる（ステップ１１６）。

なお、ここで言うデッドロックとは、第６図に関して説
明したグラフ表現及びそれに従って制御するシステムの
責任で起こるものではない、後述するように１本発明に
よれば、第６図の如きデッド・ロックの発生は回避され
る。第１１図のステップ１１５で表示されるデッドロッ
クは、プログラムの構造自体に起因して生じるものであ
り、ユーザの責任でこれを回避しなければならない（ス
テップ１１７）。

プロセス・リソース・グラフは、イベント・プレースと
コンデイション・ゲイトをノードとし入力関数と出力関
数をアークとする二部有効グラフである。マーキングは
プロセス・リソース・グラフのタスク・プレース、資源
プレース、コンデイション・ゲイトにトークンを割り当
てることをいう、また、トークンはタスク・プレース、
資源プレース、コンディジ１ン・ゲイトに高々一つ存在
できる。従来のペトリネットでは、コンディジ３ン・ゲ
イトにはトークンは割り当てられないが。

プロセス・リソース・グラフでは割り当てがおこなわれ
る。プロセス・リソース・グラフの定義は、［数学的な
表現］の項を参照されたい。

なお、第１２図に示した共通結合グラフつまりプロセス
・リソース・グラフにおいては、すべてのタスク・ノー
ドについて、これと並列に資源ノードが配置されている
。しかしながら、タスクの中には重要資源にアクセスす
ることのないものもある。そういうタスクのノードには
当然資源ノードが並列に配置されない（第１８図参照）
。

（ｄ）プロセス・リソース・グラフの実行（ステップＳ
７．Ｓ８） プロセス・リソース・グラフは、逐次的利用可能資源の
相互排他制御と同時に事象駆動型の制御を行なうコント
ローラのコードに変換され、実行されるコントローラ（
計算機およびプログラマブル・ロジック・コントローラ
など）のメモリーＲＯＭ等にロードされる。このグラフ
を実行すると、資源の相互排他制御と事象駆動型のプロ
セスの制御が同時に行われる０例えばプロセス・リソー
ス・グラフのノード（イベント・プレース、コンデイシ
ョン・ゲート）はメモリー中にデータ構造体として実現
され、要素間のつながりはポインタによって表現される
。トークンの存在に関する情報は、データ構造体の中に
記憶される。トークンを発生または消滅させる方法自体
は上記文献（２）のシステムと同様に行われるので、こ
こでは詳細に述べない。

本発明で提唱するトークンの移動条件は後で厳密に式（
１）、（２）の形で表現するが、その意味する所を言葉
で述べると１次の通りになる。

（１）タスクの実行開始を命じると同時に該タスクのプ
レース（ノード）及び該プレースに並列な資源のプレー
スにトークンを置く、つまり、本発明においては、従来
のペトリネット・モデルと異なって、資源プレースに置
かれたトークンは、その資源が実行中のタスクによって
専有されていることを示す。

（ＩＩ）並列制御されるタスクがあるときは、そのタス
クすべての実行が終了した時点で、トークンを後続のコ
ンデイション・ゲイトに移動させる。

（ＩＩＩ）コンデイション・ゲイトに直接続くタスク・
プレースまたは該タスク・プレースに並列な資源プレー
スのうちの少なくとも１つにトークンが置かれている間
は、トークンをコンデイション・ゲイトに置き続けるこ
とによって、後続タスクの実行開始を待機させる。

第１２図のプロセス・リソース・グラフの定義に従った
実行を、実行制御の一例として第１６図に示す、第１２
図では、初めにトークンがコンデイション・ゲイトＣ工
に発生する場合とコンデイション・ゲイトＣ４に発生す
る場合がある０本実行倒では、初めにトークンがコンデ
イション・ゲイトＣ工に発生する場合を取り扱う、トー
クンがコンデイション・ゲイトＣ１に発生する（第１６
Ａ図）このように、タスク°Ｔ工、Ｔ２を実行させるこ
とが必要になっても、いきなリプレースＴ□。

Ｔ２にトークンを置くことはない、まずコンデイション
・ゲイトＣ工にトークンが置かれる。トークンは移動条
件式（１）によってコンデイション・ゲイトＣ工からタ
スク・プレースＴ工、Ｔ２と資源プレースＲＡ、Ｒ８に
移動する（第１６Ｂ図）、このとき、他のコンデイショ
ン・ゲイトにトークンが存在しても、資源プレースＲＡ
、Ｒ８にトークンが存在しているため、移動条件式（１
）が満足できない、このためにトークンの移動がおこら
ず。

Ｔ工、Ｔ２以外の新しいタスクの実行はおこなわれない
、タスクＴ工、Ｔ２がどちらも終了すると、トークンは
移動条件式（２）によってタスク・プレースＴいＴ２と
資源プレースＲ＾、ＲＢからフンディジ３ン・ゲイトＣ
３に移動する（第１６ｃ図）、さらにトークンは、移動
条件式（１）によってコンデイション・ゲイトＣ２から
タスク・プレースＴ３と資源プレースＲ８に移動する（
第１６Ｄ図）。このとき、コンデイション・ゲイトＣ４
にトークンが発生したとしよう、タスクＴ４の実行は開
始できる。つまり、資源プレースＲＡにはトークンがな
いために、移動条件式（１）が満たされるので、タスク
・プレースＴ４と資源プレースＲＡへのトークンの移動
はおこなわれる（第１６Ｅ図）。したかって資源Ｒを使
うタスクＴ、の実行と、資源ＲＡ　＆使うタスクＴ４の
実行が独立におこなわれる。Ｔ４が終了すると、トーク
ンは、移動条件式（２）によってタスク・プレースＴ４
と資源プレースＲＡからコンデイション・ゲイトＣ６に
移動する（第１６Ｆ図）。

トークンがコンデイション・ゲイトＣ５に存在しても、
資源プレースＲＢにすでにトークンがあるにトークンが
あるために、コンデイション・ゲイトＣ６からタスク・
プレースＴｓと資源プレースＲＡ、Ｒ８へのトークンの
移動は、移動条（１）が満たされないために、おこなわ
れない。つまりタスクＴｓは実行されない、タスクＴ、
が終了すると。

トークンは、移動条件式（２）によってタスク・プレー
スＴ、と資源プレースＲＢからコンデイション・ゲイト
Ｃ３に移動し、消滅する。したがって、タスクＴ、が実
行可能になる。

第１２図の例でも見られるようにプロセス・リソース・
グラフは資源プレースＲＡ、ＲＢに対して自己ループの
あるグラフとなる。これを安全で且つ活性の性質を持つ
制限されたペトリネットと見做すと、タスクが連続して
、すぐ同じ資源を使おうとすると、デッドロックが起こ
る。例えば第１２図では、タスクＴ、が資源ＲＡを使う
実行を終了したのち、タスクＴ５と資源ＲＡ　−Ｒｅを
使う実行をしようとした場合、資源ＲＡに対して自己ル
ープのグラフとなり、後述する移動条件式（０）が常に
満たされずデッドロックがｄこる。

この点について説明を補足する。まず第１２図のような
グラフ表現自体が新規であることに注意されたい、（従
来のペトリネットとの相違点は、後で第６図と第１８図
を対比させてさらに詳しく述べる）６次に１本発明のト
ークン移動法を採用して、資源が専有されているときに
対応する資源プレースにトークンを置くけれども、コン
デイション・ゲートにはトークンを置かない実施例を想
定してみる。この例においては、タスクＴ４の実行中に
、プレースＴ、とＲＡにトークンが置かれる。次に。

制御システムがタスクＴ、の実行を開始しようとしても
、つまり、プレースＴ４からプレースＴ、とプレースＲ
Ａ、　ＲＢにトークンを、進めようとしても、プレース
ＲＡにトークンが既に置かれているので、トークンをプ
レースＴ、に進めることができない、そして、トークン
がプレースＴ、に進まない限りは、プレースＲＡのトー
クンも消滅しないのである。

もし、プロセス・リソース・グラフで定義したごとくコ
ンデイション・ゲイトにトークンを存在させれば、上述
の実行例で示したように、安全で且つ活性の性質を持つ
制限されたペトリネットで起こるデッドロックは生じな
い、つまり、上の例でいえば、タスクＴ４の実行が終了
した時点で。

プレースＴ４とＲＡのトークンを消滅させ、コンディシ
ョン・ゲイトＣ５にトークンを発生させることによって
、プレースＲＡにトークンが存在しない状態が出現する
ので、トークンをコンディジ１ン・ゲイトＣ６からプレ
ースＴｓ、　ＲＡ、　ＲＢに移すことができる。つまり
、タスクＴ５の実行を開始することが可能になる。コン
デイション・ゲイトにトークンを置くことの意義はこの
点にある。

プロセス・リソース・グラフの実行コードは実行される
コントローラのメモリー、ＲＯＭ等にロードされる。こ
こで制御する逐次的利用可能資源の対象は、計算機およ
びプログラマブル・ロジック・コントローラ（ＰＬＣ：
）などが制御する資源である。これらの資源は、実際に
コントローラの中に含まれる資源のみならず、通信等を
介して制御可能な資源も含む６本発明では、これらの制
御対象となる逐次的利用可能資源に対して、プロセス・
リソース・グラフの実行コードに基づいて。

事象駆動型のプロセスの制御と同時に資源の相互排他制
御が行なわれる。第１７図はプロセス・リソース・グラ
フの実行コードをＰＬＣのメモリーにロードしてかかる
制御を行うシステムのハードウェア構成の１例を示す、
この例では生産機器、１゜２．３・・・が重要資源であ
り、これらの機器を用いるタスクが第８図に示すような
タスク・プログラムの形で記述される。タスク・プログ
ラムの実行開始指示信号及び該プログラムの実行が終了
したことを知らせる終了信号は、デジタル入出力インタ
ーフェイス又は通信インターフェイスを介して。

ＰＬＣと生産機器間を転送される。タスクの実行終了は
、生産機器がＰＬＣに対して信号を送ることによって検
知される。あるいは、ＰＬＯが生産機器の状態をモニタ
することによってその状態が終了状態に転じたことを検
知してもよい。

なお、タスク・プログラムは、生産機器側にて蓄積され
ていてよいし、ＰＬＣのメモリに蓄積しておいて、命令
を逐次ＰＬＣから生産機器へ転送してもよい。

最後に、まとめとして、第６図に示すようなプロセスの
流れを本発明に従って表現した結果であるプロセス・リ
ソース・グラフを第１８図に示し、その実行例を第１９
Ａ図ないし第１９Ｄ図に示す。

第１８図に示す如く、連続する２つのタスク（例えばＰ
２．Ｐ３）によっである資源（この場合はＰｘ）が使用
される場合でも、その各々と並列に資源プレースがつな
がれる点及び、第６図の場合には例えばプレースＰｘが
トランジションｔ１の入力側につながれていたのが第１
８図ではプレースＰｘがコンデイション・ゲイトＣ１の
出力側につながれているといった具合に、入出力の関係
が逆になる点において、両グラフは大きく異なっている
。

次に、本発明に従ってトークンを移動させていく実行例
を見てみる。まず、コンデイション・ゲイトＣ０とＣ４
にトークンが発生したとしよう（第１９Ａ図）、資源Ｐ
ｘ、Ｐｙのプレースの何れにもトークンがないならば、
制御システムは、コンデイション・ゲイトＣユからプレ
ースＰ、、Ｐｘにトークンを移す一方、コンデイション
・ゲイトＣ４からプレースｐ、、ｐｙにトークンを移す
ことができる（第１９Ｂ図）、つまり、タスクｐ、、　
ｐｓの実行が開始される６次に、タスクＰ２の実行が終
了したとしよう、このとき、制御システムは、プレース
Ｐ２．　Ｐｘのトークンを消滅させて、コンデイション
・ゲイトＣ２にトークンを発生させる（第１９Ｃ図）、
この時点では、まだプレースｐｙにトークンがあるので
、プレースＰ、にトークンを進めることはできない、よ
って、プロセスＡにおいて、トークンはコンデイション
・ゲイトＣ３に存在し続けて、資源Ｐｙが解放されるの
を待つことになる６次に、制御システムは、タスクＰ、
の終了信号を受は取ると、プレースＰ５、Ｐｙのトーク
ンを消滅させて、トークンをコンデイション・ゲイトＣ
６にトークンを発生させる（第１９Ｄ図）。

制御システムは、プレースＰ、とＰｘ、Ｐｙにトークン
を進めることもできるし、又はプレースＰ。

とＰｘにトークンを進めることもできる。すなわち、タ
スクＰ１、又はＰ６の実行開始を命じることができる。

このように、第６図の場合に生じたデッドロックは起こ
らない。

以上、本発明を実施例に即して説明したが、他の変形例
も考えられる０例えば、前記実施例では、プロセス・フ
ロー・グラフと資源管理グラフを中間コードの形で生成
し、プロセス・リソース・グラフは一旦中間コードの形
で生成した後実行コードに変換したけれども、要するに
これらのグラフは図面に示したものと等価な表現をメモ
リ中に生成できればよいわけであるから、その表現形式
は特に制約されない。

［数学的な表現］ プロセス・フロー・グラフ理論の定義に従って以下に記
述する６プロセス・フロー・グラフＧＰＦは、 ＧＰＦ＝　（Ｔ、　Ｃ，ＩＴ、ＯＴ、μ）ここで。

Ｔ　＝　（Ｔ、、Ｔ２、・・・、　ＴＭ）、に〉０タス
ク・プレースの集合 Ｃ冨（ＣいＣよ、・・・、Ｃ）、　Ｌ＞１コンデイショ
ン・ゲイトの集合 ＴｎＣ＝φタスク・プレースの集合とコンデイション・
ゲイトの集合とは互いに素であるＩＴ：　Ｔ−＞Ｃタス
ク・プレースからコンデイション・ゲイトへの入力関数 ＯＴ：Ｃ−＞Ｔコンデイション・ゲイトからタスク・プ
レースへの出力関数 μ：Ｔ−＞（０，１）タスク・プレースのマーキング関
数 任意の時刻ｔにおける、任意のコンデイション・ゲイト
Ｃにに関するタスク・プレースＴ、からＴｏへのトーク
ンの移動条件式は、 但し、ｍｌ＞Ｏ１鵬２〉０ となる０時刻ｔ＋１における新しいマーキングは、タス
ク・プレース子工では、 ｔｔ　（Ｔｉ（ｔ＋１））二μ（Ｔｉ（ｔ））−＃（Ｔ
ｉ、　Ｔｏ）（ｔ）　ｉ＝１．、。

＋１１ タスク・プレースＴＯでは。

ｐ　（Ｔｏ（ｔ＋１））二μ（Ｔｏ（ｔ））”１（Ｔｉ
、　Ｔｏ）（ｔ）　ｏＪ、、。

となる。

トークンの発生は、コンデイション・ゲイトＣ５におい
て、入力関数１１がない場合であり、移動条件式の右辺
の項を、 隅（Ｔｉ　（ｔ））　＝　１ １廖１ としたときである。

トークンの消滅は、コンデイション・ゲイトＣＫにおい
て、出力関数ＯＴがない場合であり、移動条件式の右辺
の項を、 ｎ　ｐ　（Ｔｏ　（ｔ）　＝　１ ｍＩ としたときである。

プロセス・リソース・グラフをグラフ理論の定義に従っ
て以下に記述する。プロセス・リソース・グラフＧＰＲ
は。

ＧＰＲ＝　（ＴＵＲ，Ｃ，ＩＴＬＪＩＲ，０ＴＵＯ也、
ＴＵ）ＩＲＵＩＩＧ）ここで。

Ｔ、（ＴＩ、　Ｔ２．、、、、　ＴＭ）、　Ｍ＞０　タ
スク・プレースの集合Ｒ＝（Ｒｚ、　Ｒ２，、、、、Ｒ
Ｎ）、　Ｎ≧Ｏ責源プレースの集合Ｃ＝（Ｃ１，Ｃ２，
、、、、ＣＬ）、　Ｌ＞１コンデイシヨン、ディトの集
合ＴｎＲｎＣ＝φ　タスク・プレースの集合と資源プレ
ースの集合とコンデイション・ゲイトの集合とは互いに
素ある Ｉ　　：Ｔ−＞Ｃタスク・プレースからコンデイション
・ゲイトへの入力関数 Ｉ　　：Ｒ−＞Ｃ資源プレースからコンデイション・ゲ
イトへの入力関数 Ｉ　　ｎＩ　　＝φ　入力関数Ｉ　と入力関数工、とＴ
ＲＴ は互いに素である ＯＴ：　Ｃ−＞Ｔ　　コンデイション・ゲイトからタス
ク・プレースへの出力関数 ０　　：Ｃ−）Ｒコンデイション・ゲイトから資源プレ
ースへの出力関数 ０ＴｎＯＲ＝φ いに素である 出力関数Ｏと出力ＯＲとは互 ■ μＴ：Ｔ−＞　（０、 マーキング関数 １）タスク・プレースの μＲ：　Ｒ−＞ キング関数 （０，１）資源プレースのマー μｃ：　ｃ−＞　（ｏ、１−）コンデイション・ゲイト
のマーキング関数 −キング関数μ　とマーキング関数μ。とは互いに素で
ある 任意の時刻ｔにおける、任意のコンデイション・ゲイト
ＣＫからイベント・プレースＴおよびＲへのトークンの
移動条件式は、 但し、膳）０、ｎ）０ となる０時刻ｔ＋１における新しいマーキングは、コン
デイション・ゲイトＣＫでは。

ｐ　（ＣＫ　（ｔ＋１））＝ｕ　（ＣＫ　（ｔ）Ｅ＃（
ｃ、　ｐ）（ｔ）タスク・プレースＴでは。

ｐ　（Ｔｉ（ｔ＋１））＝ｕ　（Ｔｉ（ｔ））十＃（ｃ
、ｐ）（ｔ）　　　ｉ＝１．、、ｍ資源プレースＲでは
、 ｐ（Ｒｊ（ｔ＋１））＝ｕ（Ｒｊ（ｔ））＋＃（ｃ、ｐ
）（ｔ）　　ｊ＝１．、、ｎとなる。

任意の時刻ｔにおける、任意のコンデイション・ゲイト
ＣＫＡイベント・プレースＴおよびＲからのトークンの
移動条件式は。

＃　（Ｃ，ｐ）（ｔ）　＝　（δｐ（’ｒ鳳（ｔ））△
ｉＬ＋　）１　（Ｒｊ　（ｔ）））△ｙ　（Ｃｋ（を旧
・・（２）ｉｍｌ　　　　　　　　％１ 但し、　ｍｈｏ、　ｎｅ。

となる０時刻ｔ＋１における新しいマーキングは。

コンデイション・ゲイトＣＫでは。

ｕ　（Ｃ，（ｔ＋１））＝、ｕ　（ＣＫ（ｔ））＋ｌ（
ｐ、　ｃ）（ｔ）タスク・プレースＴでは、 μ（丁、（ｔ＋１）戸ｕ（Ｔ、（ｔ））−＃（ｐ、　　
ｃ）（ｔ）　　　ｉ＝１．、、＋ｓ１　　　　　　　　
　　　　　ｌ 資源プレースＲでは、 μ（Ｒ，（ｔ＋１））＝μ（Ｒ，（ｔ））−＃（ｐ、　
ｃ）（ｔ）　　ｊ＝１．、、ｎＪコ となる、 トークンの発生は、コンデイション・ゲイトＣＫにおい
て、入力関数工１、ＩＲがない場合であり、移動条件式
（２）の右辺の項を、 としたときである。

トークンの消滅は、コンデイション・ゲイトＣにおいて
、出力関数０．ｏがない場合であり、Ｒ 移動条件式（１）の右辺の項を、 としたときである。

Ｅ、効果 この発明により、ユーザが事象駆動型の制御（プロセス
・フロー・グラフとタスク・プログラム）を記述するだ
けで、逐次的利用可能資源相互排他制御と同時に事象駆
動型の制御を行なうことが可能になる。この発明では、
今までプログラマの責任であったプロセス中の資源管理
のプログラミングと実行を自動的に行ない、プログラマ
による資源管理プログラムのエラー及びオペレータのプ
ログラム実行の負担がなくなる。

また１本発明によれば、従来の如くペトリネット・モデ
ルで起こり得たデッドロックが、トークンをコンデイシ
ョン・ゲートのノードに置くことによって生じない、と
いう利点も得られる。

【図面の簡単な説明】

第１図は、この発明の実施例のシステム構成図である。 第２図は、プロセスの流れの概念図である。第３図は、
従来技術による相互排他制御プログラムの記述例を示す
説明図である。第４図は、ペトリネットの実行例の説明
図である。第５図は、ペトリネットを用いた相互排他制
御のモデルの説明図である。第６図は、従来のペトリネ
ットを実行させて仮に相互排他制御を行った場合に生じ
るデッドロックの説明図である。第７図はプロセス・フ
ロー・グラフの説明図である。第８図はプロセス・フロ
ー・グラフとタスク・プログラムの説明図である。第９
図は資源管理グラフの説明図である。第１０図は資源管
理グラフを生成するための処理手順のフロー・チャート
である。第１１図はプロセス・リソース・グラフを生成
するための処理手順のフロー・チャートである。第１２
図はプロセス・リソース・グラフの説明図である。第１
３図はプロセス・フロー・グラフと資源管理グラフの共
通結合グラフを生成するための処理手順のフロー・チャ
ートである。第１４図はデッドロックを生じるプロセス
の流れの説明図である。第１５図は第１４図の内容の共
通結合グラフ表現を示す図である。第１６図は第１２図
のプロセス・リソース・グラフの実行例を示す図である
。第１７図は相互排他制御システムのハードウェア構成
の１例を示す図である。第１８図は第６図に対応するプ
ロセス・リソース・グラフを示す図である。 第１９図は第１８図のプロセス・リソース・グラフの実
行例を示す図である。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　頓　　宮　　孝 ｅｎｄ ９３１図 全体を制御するプログラム ｎｄ ｎｄ ｎｄ ｎｄ ＠ｎｄ 第８Ｃ図 ロボット２のプログラム 第４Ａ図 第４Ｂ図 アロセス１ プｂセスン 〔４ 〔５ 第７図 〔１ 〔２ 〔３ 〔４ 〔５ 第９図 第６Ａ図 第６Ｂ図 第８図 藪 第１１図 〔４ Ｃ５ 第１６Ａ図 〔６ 〔４ 〔５ 第１６Ｂ図 〔６ 第１６Ｃ図 第１６Ｅｖ！Ｊ 第１６Ｄ図 第１６１”図 第１８図 第１９Ｂ図 第１９Ａ図 第１９Ｃ図

Claims (7)

【特許請求の範囲】
1. （１）（ａ）プロセスの流れに含まれるタスク及び何れ
   かのタスクによって専有され得る重要資源がノードに対
   応され、逐次実行されるタスクのノードは直列に配置さ
   れるとともに、並列して実行されるタスクのノード同士
   は並列に配置され、重要資源のノードは該重要資源を専
   有し得るすべてのタスクのノードと並列に配置されてな
   るグラフを作成して記憶装置に保持し、 （ｂ）タスクの実行開始信号を送る度に、上記グラフ中
   の該タスクのノード及び該ノードに並列に配置された重
   要資源のノードにトークンを発生させ、プロセスの流れ
   の中で先行するタスクの実行の終了を検知したとき、上
   記グラフを参照して、直接の後続タスクのノード又は該
   ノードに並列に配置された重要資源のノードの何れか１
   つにトークンが置かれている間は、直接の後続タスクの
   実行開始信号の送出を待機する ことを特徴とする、資源の相互排他制御方法。
2. （２）上記ステップ（ａ）では、上記グラフにおいて、
   連続して実行されるタスクのノード同士を連結する位置
   にゲートのノードが設けられ、 上記ステップ（ｂ）では、タスクの実行の終了を検知す
   る度に、該タスクのノード及び該ノードに並列に配置さ
   れた重要資源のノードに存在するトークンを消滅させ、 ゲート・ノードの直前に配置された何れのタスク・ノー
   ドに対応するタスクについても実行の終了を検知したと
   き、該ゲート・ノードにトークンを発生させ、 その後、上記グラフを参照して、該ゲート・ノードの直
   後に配置された後続タスクのノード又はこれと並列に配
   置された重要資源ノードの何れか１つにトークンが存在
   している間は、該後続タスクの実行開始信号の送出を待
   機し、 該後続タスクの実行開始信号を送った後に、該ゲート・
   ノードのトークンを消滅させることを特徴とする、特許
   請求の範囲第１項記載の方法。
3. （３）上記ステップ（ａ）は、 （ａ１）プロセスの流れに含まれるタスクのノードとゲ
   イトのノードからなるプロセス・フロー・グラフを作成
   するステップ、 （ａ２）上記タスクの何れかによって専有され得る重要
   資源のノードと上記ゲイトのノードからなる資源管理グ
   ラフを作成するステップ、 （ａ３）上記プロセス・フロー・グラフと上記資源管理
   グラフを上記ゲートのノードを共通にして重ね合わせた
   共通結合のグラフを作成して記憶装置に保持するステッ
   プ からなる特許請求の範囲第２項記載の方法。
4. （４）上記ステップ（ａ３）において、プロセス・フロ
   ー・グラフと資源管理グラフの共通結合グラフを作成し
   た後、該共通結合グラフ中のデッドロックを生じさせる
   箇所の有無をチェックし、デッドロックを生じさせる箇
   所があればこのことをユーザに表示する ことを特徴とする、特許請求の範囲第１項ないし第３項
   に記載の方法。
5. （５）上記ステップ（ａ１）では、プロセス・フロー・
   グラフを中間コードの形で出力し、 上記ステップ（ａ２）では、資源管理グラフを中間コー
   ドの形で出力し、 上記ステップ（ａ３）では、共通結合のグラフを一旦中
   間コードの形で出力した後、これを実行コードに変換し
   て記憶装置に保持し、 上記ステップ（ｂ）、では、上記実行コードに基づいて
   相互排他制御を行う ことを特徴とする、特許請求の範囲第３項又は第４項記
   載の方法。
6. （６）プロセスの流れに含まれるタスク及び何れかのタ
   スクによって専有され得る重要資源がノードに対応され
   、逐次実行されるタスクのノードは直列に配置されると
   ともに、並列して実行されるタスクのノード同士は並列
   に配置され、重要資源のノードは該重要資源を専有し得
   るすべてのタスクのノードと並列に配置されてなるグラ
   フを保持する記憶装置と、 タスクの実行開始信号を送る度に、上記グラフ中の該タ
   スクのノード及び該ノードに並列に配置された重要資源
   のノードにトークンを発生させる手段と、 プロセスの流れの中で先行するタスクの実行の終了を検
   知したとき、上記グラフを参照して、直接の後続タスク
   のノード又は該ノードに並列に配置された重要資源のノ
   ードの何れか１つにトークンが存在している間は、直接
   の後続タスクの実行開始信号の送出を待機する手段 を具備する、資源の相互排他制御システム。
7. （７）プロセスの流れに含まれるタスク及び何れかのタ
   スクによって専有され得る重要資源に対応するノードを
   持ち、逐次実行されるタスクのノードは直列に配置され
   るとともに、並列して実行されるタスクのノード同士は
   並列に配置され、タスクのノード同士を連結する位置に
   はゲートのノードが配置され、重要資源のノードは該重
   要資源を専有し得るすべてのタスクのノードと並列に配
   置されてなるグラフを保持する記憶装置と タスクの実行開始信号を送る度に、上記グラフ中の該タ
   スクのノード及び該ノードに並列に配置された重要資源
   のノードにトークンを発生させる手段と、 タスクの実行の終了を検知する度に、該タスクのノード
   及び該ノードに並列に配置された重要資源のノードのト
   ークンを消滅させる手段と、ゲート・ノードの直前に配
   置された何れのタスク・ノードに対応するタスクについ
   ても実行の終了を検知したとき、該ゲート・ノードにト
   ークンを発生させ、 その後、上記グラフを参照して、該ゲート・ノードの直
   後に配置された後続タスクのノード又はこれと並列に配
   置された重要資源ノードの何れか１つにトークンが存在
   している間は、該後続タスクの実行開始信号の送出を待
   機し、 該後続タスクの実行開始信号を送った後に、該ゲート・
   ノードのトークンを消滅させる手段を具備する、相互排
   他制御システム。