(57)【要約】      （修正有）【課題】処理によるリソース占有時間を削減することができるリソース排他占有装置を提供する。【解決手段】処理手順有向グラフに、操作するリソースを追記したリソース付き処理手順有向グラフを複数入力し、リソース付き処理手順有向グラフを探索し、二つ以上のリソースにおいて、デッドロックを引き起こす逆順リソース操作を表す逆順リソース操作情報５０を生成する逆順リソース操作判定部１０と、逆順リソース操作情報５０を利用し、処理に対して、リソース毎の、占有中か否かおよびいずれの処理が占有しているかを表すリソース占有状況に応じて、逆順リソース操作によりデッドロックを起こし得るリソースについては、初回利用時に一括占有し、処理の進行により占有が不要となったリソースは、順次解放し、デッドロックを起こすおそれのないリソースについては、利用の都度、占有するリソースの排他占有の介入を実行する処理動作介入部２０とを備える。【選択図】図１
2015207160.tif 000002
【特許請求の範囲】
【請求項１】
処理を構成する処理手順の時間的な前後関係を表現する処理手順有向グラフに、前記処理手順で操作するリソースを追記したリソース付き処理手順有向グラフを複数入力し、
前記リソース付き処理手順有向グラフを探索し、二つ以上の前記リソースにおいて、複数の前記処理が異なる順序で占有と操作とを行い、いずれの前記処理も進行しないデッドロックを引き起こす逆順リソース操作を表す逆順リソース操作情報を生成する逆順リソース操作判定部と、
前記逆順リソース操作情報を利用し、前記処理に対して、前記リソース毎の、占有中か否かおよびいずれの前記処理が占有しているかを表すリソース占有状況に応じて、前記逆順リソース操作によりデッドロックを起こし得る前記リソースについては、初回利用時に一括占有し、前記処理の進行により占有が不要となった前記リソースは、順次解放し、デッドロックを起こすおそれのない前記リソースについては、利用の都度、占有する前記リソースの排他占有の介入を実行する処理動作介入部とを
備えるリソース排他占有装置。
【請求項２】
処理を構成する処理手順の時間的な前後関係を表現する処理手順有向グラフに、前記処理手順で操作するリソースを追記したリソース付き処理手順有向グラフを複数入力し、
前記リソース付き処理手順有向グラフを探索し、前記処理手順を行と列に並べたマトリクスであって、行に並べた前記処理手順の後に列に並べた前記処理手順に続く可能性を表す処理手順マトリクス、
前記処理手順の操作対象となる前記リソースを行と列に並べたマトリクスであって、行に並べた前記リソースの操作後に列に並べた前記リソースの操作が続く可能性を表すリソース操作順序マトリクス、および、
前記処理手順マトリクスと前記リソース操作順序マトリクスを利用して、二つ以上の前記リソースにおいて、複数の前記処理が異なる順序で占有と操作とを行い、いずれの前記処理も進行しないデッドロックを引き起こす逆順リソース操作を表す逆順リソース操作情報を生成する逆順リソース操作判定部と、
前記逆順リソース操作情報を利用し、前記処理に対して、前記リソース毎の、占有中か否かおよびいずれの前記処理が占有しているかを表すリソース占有状況に応じて、前記逆順リソース操作によりデッドロックを起こし得る前記リソースについては、初回利用時に一括占有し、前記処理の進行により占有が不要となった前記リソースは、順次解放し、デッドロックを起こすおそれのない前記リソースについては、利用の都度、占有する前記リソースの排他占有の介入を実行する処理動作介入部とを
備えるリソース排他占有装置。
【請求項３】
前記複数の処理は、同じ処理の複数起動も含む請求項１または請求項２に記載のリソース排他占有装置。
【請求項４】
前記リソース占有状況の初期値として、全ての前記リソースについて未占有と設定する請求項１乃至請求項３のいずれか1項に記載のリソース排他占有装置。
【請求項５】
前記処理動作介入部は、前記処理の「開始」要求時には、当該前記処理に対して、特段何も動作介入しない請求項１乃至請求項４のいずれか１項に記載のリソース排他占有装置。
【請求項６】
前記処理動作介入部は、前記処理の「リソース操作」時には、当該前記処理の操作対象リソースが未占有かつ逆順操作リソースの場合、全ての逆順操作リソースを所定順にて占有し、一方、当該前記処理の操作対象リソースが未占有かつ逆順操作リソースでない場合、当該前記リソースのみを占有する請求項１乃至請求項５のいずれか1項に記載のリソース排他占有装置。
【請求項７】
前記リソースに対する操作が完了しても占有を維持する請求項６に記載のリソース排他占有装置。
【請求項８】
前記処理動作介入部は、前記処理の「処理手順遷移」時には、到達の見込みがない前記処理手順を把握し、当該前記処理において未使用で占有済みの前記リソースのうち、到達しない前記処理手順のみが利用する前記リソースを解放する請求項１乃至請求項７のいずれか1項に記載のリソース排他占有装置。
【請求項９】
前記処理動作介入部は、前記処理の「終了」時には、当該前記処理において占有していた前記リソースを全て解放すると共に、前記リソース占有状況を更新する請求項１乃至請求項８のいずれか1項に記載のリソース排他占有装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、リソース排他占有装置に関する。
【背景技術】
【０００２】
クラウドに代表されるように、計算実行環境を様々なソフトウェアが共有する状況が生まれている。しかも、単に計算だけでなく外部装置のようなリソースも共有する状況が生じている。
【０００３】
一般に、ソフトウェアの開発者は互いに無関係な人々であり、ソフトウェアのモデルベース開発が整備されつつあり、グラフ等によりソフトウェアを設計表現する機会が増加している。
【０００４】
様々なソフトウェアが共用するリソースに関わるデッドロックを防ぐために、従来は、アプリケーション開発者が互いにリソース占有ルールを決め、それぞれのアプリケーションにルールの実装を行っていた。
【０００５】
しかしながら、安全のため、必要以上にリソースの占有を行っている、との問題があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平０４−７７９３１号公報
【特許文献２】特開２００２−７１４８号公報
【特許文献３】特公平０７−６９８４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明が解決しようとする課題は、必要な時点で必要なリソース占有を行い、処理の途中において不要なリソースを自動解放し、処理によるリソース占有時間を削減することができるリソース排他占有装置を提供することである。
【課題を解決するための手段】
【０００８】
実施形態のリソース排他占有装置は、処理を構成する処理手順の時間的な前後関係を表現する処理手順有向グラフに、前記処理手順で操作するリソースを追記したリソース付き処理手順有向グラフを複数入力し、前記リソース付き処理手順有向グラフを探索し、二つ以上の前記リソースにおいて、複数の前記処理が異なる順序で占有と操作とを行い、いずれの前記処理も進行しないデッドロックを引き起こす逆順リソース操作を表す逆順リソース操作情報を生成する逆順リソース操作判定部と、前記逆順リソース操作情報を利用し、前記処理に対して、前記リソース毎の、占有中か否かおよびいずれの前記処理が占有しているかを表すリソース占有状況に応じて、前記逆順リソース操作によりデッドロックを起こし得る前記リソースについては、初回利用時に一括占有し、前記処理の進行により占有が不要となった前記リソースは、順次解放し、デッドロックを起こすおそれのない前記リソースについては、利用の都度、占有する前記リソースの排他占有の介入を実行する処理動作介入部とを備える。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に係るリソース排他占有装置の概略構成を示すブロック図である。
【図２】リソース付き処理手順有向グラフの一例を示す図である。
【図３】処理手順マトリクスの一例を示す図である。
【図４】リソース操作順序マトリクスの一例を示す図である。
【図５】逆順リソース操作判定部における特殊な取扱いを説明する図である。
【図６Ａ】逆順リソース操作情報の抽出例を説明する図である。
【図６Ｂ】逆順リソース操作情報の抽出例を説明する図である。
【図６Ｃ】逆順リソース操作情報の抽出例を説明する図である。
【図７】逆順リソース操作判定部における判定処理の流れを示すフローチャートである。
【図８】処理動作介入部における「リソース操作」時の介入処理の流れを示すフローチャートである。
【図９】処理動作介入部における「処理手順遷移」時の介入処理の流れを示すフローチャートである。
【図１０】「処理手順遷移」時の介入処理を説明する図である。
【図１１】処理動作介入部における「処理手順遷移」時の介入処理の変形例を説明する図である。
【図１２】実施例における処理Ｘの詳細を示す図である。
【図１３】実施例における処理Ｙの詳細を示す図である。
【図１４】実施例における処理Ｚの詳細を示す図である。
【図１５】実施例における逆順リソース操作情報の生成を説明する図である。
【発明を実施するための形態】
【００１０】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１１】
まず、本実施形態で用いる主要な用語について説明する。
【００１２】
「リソース」とは、ソフトウェアが操作利用するハードウェア資源等をいう。例えば、ネットワークに接続しているプリンター装置である。操作によって、リソースは状態を変化させる。操作によるリソースの状態変化が、その後も継続していることを後続の処理手順は前提とし、そのために処理はリソースを占有する。
【００１３】
「処理」とは、“開始”から“終了”に至るソフトウェアであり、“開始”と“終了”の間に、イベントとイベントの間や、割込み処理が発生するまでの「待ち」を0以上持っている。
【００１４】
「処理手順」とは、処理の構成要素で、「待ち」によって区切られる部分をいう。処理手順内にて、処理は計算やリソース操作を実行する。
【００１５】
「処理手順有向グラフ」とは、処理手順の時間的な前後関係を表現したグラフをいう。例えば、状態遷移図やフローチャートである。
【００１６】
「リソース付き処理手順有向グラフ」とは、処理手順有向グラフに、各処理手順で操作するリソースを記入したものをいう。
【００１７】
「占有」とは、リソース操作を特定処理のみに許可し、他に対して禁じることをいう。
【００１８】
「逆順リソース操作」とは、二つ以上のリソースにおいて、複数の処理（同じ処理の複数起動も含む）が異なる順序で占有と操作とを行うこと、行った状態をいう。どちらの処理も進行しない状態になると、デッドロックを引き起こす。
【００１９】
「逆順操作リソース」とは、操作順序が異なりうるリソースをいう。
【００２０】
本実施形態においては、逆順リソース操作によりデッドロックを起こし得るリソース群については、初回利用時に一括占有し、処理の進行により占有が不要となったリソースは順次解放し、デッドロックを起こすおそれのないリソースについては、利用の都度、占有するものである。
【００２１】
図１は、本発明の実施形態に係るリソース排他占有装置の概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータにおいて、処理に介入するもので、逆順リソース操作によりデッドロックを起こし得るリソース群の把握、初回利用時の一括占有、占有が不要となったリソースの解放、デッドロックを起こすおそれのないリソースについての利用の都度の占有を実行するプログラムとして実施することもできる。
【００２２】
図１に示すように、本実施形態に係るリソース排他占有装置１は、複数の処理によるリソースの占有・解放等に介入するもので、主として、逆順リソース操作判定部１０、処理動作介入部２０、処理手順マトリクス格納部３０、リソース操作順序マトリクス格納部４０、逆順リソース操作情報格納部５０、リソース占有状況格納部６０から構成されている。処理は、同じ処理の複数起動であってもよい。介入は、具体的には、処理の「開始」、「終了」、「リソース操作」、「処理手順遷移」に際して行う。
【００２３】
＜逆順リソース操作判定部の動作＞
逆順リソース操作判定部１０は、複数のリソース付き処理手順有向グラフを入力する。ユーザーは、状態遷移図等の処理手順有向グラフを作成し、処理手順有向グラフ中の、処理手順毎に操作するリソース名を追記する。
【００２４】
図２は、リソース付き処理手順有向グラフの一例を示す図である。図２に示すように、開始と終了の間に処理手順１および処理手順２が処理待ちを経て続いている。処理手順１は、リソースＡを操作し、処理手順２はリソースＢを操作する。逆順リソース操作判定部１０は、入力したリソース付き処理手順有向グラフから、各処理におけるリソース利用順序を把握し、逆順リソース操作の発生状況を抽出する。ここで、“リソース利用順序”とは、例えば、処理ＸにおいてリソースAを操作後にリソースBを操作することをいう。また、“逆順リソース操作”とは、例えば、処理ＸではリソースAを操作後にリソースBを操作するのに対し、処理ＹではリソースBを操作後にリソースA を操作する関係である。
【００２５】
逆順リソース操作判定部１０は、リソース付き処理手順有向グラフを解析し、“処理手順マトリクス”、“リソース操作順序マトリクス”、および“逆順リソース操作情報”を生成する。以下、これらについて詳述する。
【００２６】
＜処理手順マトリクス＞
処理手順マトリクスは、処理手順を行と列に並べたマトリクスであって、行に並べた処理手順（行処理手順）の後に列に並べた処理手順（列処理手順）に続く可能性があれば、“１“を記したものである。
【００２７】
図３は、処理手順マトリクスの一例を示す図である。図３に示す例では、処理手順αの後に、処理手順β、処理手順γ、処理手順δ、処理手順ζ、処理手順εの各々へ遷移しうるので、それぞれ“１”が立っている。処理手順βの後に処理手順αに遷移することはないので“０”が立ち、処理手順γ、処理手順δ、処理手順ζ、処理手順εの各々へは遷移しうるので、それぞれ“１”が立っている。
【００２８】
処理手順マトリクス格納部３０は、逆順リソース操作判定部１０で生成した処理手順マトリクスを格納する。
【００２９】
＜リソース操作順序マトリクス＞
リソース操作順序マトリクスは、処理手順の操作対象となるリソースを行と列に並べたマトリクスであって、処理手順マトリクスにおいて“１”となっているものについて、行に並べたリソース（行リソース）の後に列に並べたリソース（列リソース）が操作される可能性があれば、“１“を記したものである。行処理手順が使用しているリソースに対して、列処理手順が使用しているリソースを”１“にする。リソース操作順序マトリクスは、処理の開始から終了までに当該リソースを「使う」かの観点に基づいている。
【００３０】
図４は、リソース操作順序マトリクスの一例を示す図である。図４に示す例では、リソースＡが操作された後に、リソースＢ，リソースＣ，リソースＤ，リソースＥ，リソースＦの各々が操作されうるので、それぞれ“１”が立っている。リソースＣが操作された後に、リソースＡ，リソースＢが操作されることはないので“０”が立ち、一方、リソースＤ，リソースＥ，リソースＦの各々が操作されうるので、それぞれ“１”が立っている。
【００３１】
リソースの排他占有の精度をあげるため、逆順リソース操作判定部１０は、以下のような取扱いを行うのが好適である。図５は、逆順リソース操作判定部１０における特殊な取扱いを説明する図である。
【００３２】
（ａ）開始から処理手順γに至るまでに必ず通過する処理手順β→処理手順γについて、リソースB→リソースAは“1”を立てない（図５（ａ）参照）。図５（ａ）に示す例では、処理手順αの段階で既にリソースAを排他占有しているので、改めて占有する必要がない。
【００３３】
（ｂ）１つの処理手順内で複数リソースを用いる場合、利用する順序が設計時に決定的であればその順序のみを記し、非決定的であれば、リソースB→リソースC、リソースC→リソースB双方生じ、デッドロックするものと取り扱う（図５（ｂ）参照）。
【００３４】
（ｃ）ループについても(a)に同じく、リソースE→リソースBは立てない（図５（ｃ）参照）。
【００３５】
リソース操作順序マトリクス格納部４０は、逆順リソース操作判定部１０で生成したリソース操作順序マトリクスを格納する。
【００３６】
＜逆順リソース操作情報＞
逆順リソース操作情報は、二つ以上のリソースにおいて、複数の処理（同じ処理の複数起動も含む）が異なる順序で占有と操作とを行い、どちらの処理も進行しないデッドロックを引き起こすことを表す情報である。
【００３７】
図６Ａ乃至図６Ｃは、逆順リソース操作情報の抽出例を説明する図である。例えば、２つの処理Ｘ、処理Ｙにおける逆順リソース操作情報を抽出するには、まず、処理Ｘについてのリソース操作順序マトリクスと、処理Ｙについてのリソース操作順序マトリクスとを用意する。各リソース操作順序マトリクスにおいて、対角成分は“０”にしておく。各処理において、使用しないリソースについては、“０”にしておく。図６Ａに示す処理Ｙでは、リソースＢは、使用されないことがわかる。
【００３８】
全リソースの組合せについて、行ベクトルと列ベクトルの要素毎にANDを計算する(図６Ａ参照)。全て“0”の場合、当該リソースは逆順リソース操作によるデッドロックを起こさない。上述した計算は、2ベクトルの内積が“0”か否かとも、意味的に等しい。
【００３９】
次に、処理Ｘの行と処理Ｙの列について、要素毎にANDを計算する(図６Ｂ参照)。
【００４０】
図６Ｂに示すように、リソースB, リソースD, リソースFは、ANDの結果が“０”であり、逆順リソース操作によるデッドロックを起こさないことがわかる。
【００４１】
次に、全ての処理の組合せについて、図６Ｂに示す計算を行い、まとめる(図６Ｃ参照)。尚、図６Ｃに示す例では、処理Ｘ、処理Ｙ、処理Ｚの相互間における逆順リソース操作に加えて、同じ処理の複数起動の場合についても、逆順リソース操作の有無を判定する場合を示している。全ての組合せについて、逆順リソース操作が無いリソースはデッドロックを起こさない。図６Ｃに示す逆順リソース操作情報では、マトリクス上、“２”、および“１”は、処理手順のどこかで逆順が起こりうることを表しており、図６Ｃにおいて、結果欄“１”は、逆順リソース操作が有るリソースを示し、結果欄“０”は、逆順リソース操作が無いリソースを示している。図６Ｃに示す例では、リソースＢ、リソースＦについては、処理Ｘ、処理Ｙ、処理Ｚの相互間でも同じ処理の複数起動でも逆順リソース操作が無く、デッドロックを起こさないことがわかる。
【００４２】
逆順リソース操作情報格納部５０は、逆順リソース操作判定部１０で生成した逆順リソース操作情報を格納する。
【００４３】
＜逆順リソース操作判定部における判定処理＞
次に、以上のように構成された逆順リソース操作判定部１０における判定処理について、説明する。図７は、逆順リソース操作判定部１０における判定処理の流れを示すフローチャートである。
【００４４】
まず、リソース付き処理手順有向グラフを探索し、処理手順マトリクスを作成する（ステップＳ７０１）。作成した処理手順マトリクスは、処理手順マトリクス格納部３０へ格納する。
【００４５】
次に、処理手順マトリクスとリソース付き処理手順有向グラフから、リソース操作順序マトリクスを作成する（ステップＳ７０２）。作成したリソース操作順序マトリクスは、リソース操作順序マトリクス格納部４０へ格納する。
【００４６】
ステップＳ７０１、ステップＳ７０２を全ての処理について実行する（ステップＳ７０３）。
【００４７】
次いで、逆順リソース操作情報の抽出を行う（ステップＳ７０４）。抽出した逆順リソース操作情報は、逆順リソース操作情報格納部５０へ格納する。
【００４８】
ステップＳ７０３を全ての処理の組合せについて実行（ステップＳ７０５）して、判定処理を終了する。
【００４９】
＜処理動作介入部の動作＞
処理動作介入部２０は、それぞれ、処理による「開始／終了」の際、「リソース操作要求」の際、「処理手順遷移」の際に、リソース毎の“リソース占有状況”に応じて、リソースの排他占有の介入を以下のように実行する。ここで、リソース占有状況は、リソース毎に、占有中か否かおよびいずれの処理が占有しているかの情報である。本実施形態においては、リソース占有状況の初期値については、（１）初めに全リソースに占有状況を問い合せる、あるいは、（２）「未占有」に設定することでもよい。後者の設定が単純でしかも安全といえる。
【００５０】
本実施形態によれば、どのリソースがデッドロックするのかを把握するので、いずれの処理も、処理の先頭で利用可能性のある全てのリソースを占有する等の従来のリソース占有ルールを、まったく考慮する必要がない。
【００５１】
＜処理の「開始」要求時＞
処理動作介入部２０は、処理の「開始」要求時には、当該処理に対して、特段何も動作介入しない。従来のリソース占有ルールでは、処理の先頭で利用可能性のある全てのリソースを占有していたが、このような必要がない。
【００５２】
＜処理の「リソース操作」時＞
処理動作介入部２０は、処理の「リソース操作」時には、当該処理の操作対象リソースが未占有かつ逆順操作リソースの場合、全ての逆順操作リソースを所定順にて占有する。一方、当該処理の操作対象リソースが未占有かつ逆順操作リソースでない場合、当該リソースのみを占有する。尚、リソースに対する操作が完了しても占有を維持する。
【００５３】
図８は、処理動作介入部２０における「リソース操作」時の介入処理の流れを示すフローチャートである。まず、リソース占有状況から、操作対象リソースが未占有か否か判定する。（ステップＳ８０１）。
【００５４】
次に、操作対象リソースが未占有であれば（ステップＳ８０１でＹｅｓ）、逆順リソース操作情報に基づいて、当該操作対象リソースが逆順操作リソースか否かを判定する（ステップＳ８０２）。
【００５５】
次いで、操作対象リソースが逆順操作リソースであれば（ステップＳ８０２でＹｅｓ）、      当該処理が用いる可能性がある逆順操作リソースの全てを所定順序で占有する（ステップＳ８０３）。
【００５６】
一方、操作対象リソースが逆順操作リソースでなければ（ステップＳ８０２でＮｏ）、操作対象リソースのみ、占有を行う（ステップＳ８０４）。
【００５７】
次いで、占有した処理、リソースについてリソース占有状況を更新し（ステップＳ８０５）、「リソース操作」時の介入処理を終了する。
【００５８】
尚、ステップＳ８０１でＮｏ（操作対象リソースは未占有でない）であれば、何もせず（ステップＳ８０６）、「リソース操作」時の介入処理を終了する。
【００５９】
＜処理の「処理手順遷移」時＞
処理動作介入部２０は、処理の「処理手順遷移」時には、到達の見込みがない処理手順を把握し、当該処理において未使用で占有済みのリソースのうち、到達しない処理手順のみが利用するリソースを解放する。
【００６０】
図９は、処理動作介入部２０における「処理手順遷移」時の介入処理の流れを示すフローチャートで、図１０は、「処理手順遷移」時の介入処理を説明する図である。
【００６１】
まず、処理手順マトリクスから、遷移後の処理手順以降には到達しない処理手順を取得する。（ステップＳ９０１）。図１０に示す例では、処理手順βに遷移した場合、以後、処理手順αへも処理手順γへも遷移しない。同様に、処理手順γに遷移後は、処理手順αへも処理手順βへも遷移しない。
【００６２】
次に、それら処理手順から、遷移後の処理手順に先行する可能性があるものを削除する（ステップＳ９０２）。図１０に示す例では、処理手順αは処理手順βに先行する恐れがあるため除外する。
【００６３】
次いで、処理手順有向グラフに基づいて、それらの処理手順「のみ」が用いる逆順操作リソースを解放した後、リソース占有状況を更新し（ステップＳ９０３）、「処理手順遷移」時の介入処理を終了する。図１０に示す例では、処理手順γのみが用いる逆順操作リソースを解放する。
【００６４】
図１０に示すマトリクス上、同じ網掛け処理を施してあるものは、互いに転置関係にある成分であることを示している。転置関係にある成分が共に0である場合、一方への遷移時には、今後他方手順へは遷移することはなく、過去にも遷移していないことを示している。図１０に示す例では、一旦、処理手順γまで到達すると、それ以降は処理手順βにはいかないことを示しており、以降は、処理手順βが用いるリソースを解放しても支障がないことがわかる。
【００６５】
＜「処理手順遷移」時の介入処理の変形例＞
上記した介入処理については、リソースに着目した変形例も可能である。リソースに対する操作要求への介入にて「リソース操作順序マトリクス」を参照し、同様の解放を行うこともできる。本変形例によれば、遷移毎に介入処理をする必要がない。図１１は、処理動作介入部２０における「処理手順遷移」時の介入処理の変形例を説明する図である。図１１では、一方のリソース利用時には、今後他方は利用しない、過去にも利用していない、ことを示している。
【００６６】
＜処理の「終了」時＞
処理動作介入部２０は、処理の「終了」時には、当該処理において占有していたリソースを全て解放する。併せて、「リソース占有状況」を更新する。
【００６７】
リソース占有状況格納部６０は、処理動作介入部２０で抽出したリソース占有状況を都度更新して格納する。
【００６８】
[実施例]
ここでは、処理Ｘ、処理Ｙ、処理Ｚの３つを並行して実行した場合の実施例について説明する。同一の番号を付した処理手順、同一の符号を付したリソースは、それぞれの処理において、同一のものである。
【００６９】
図１２は、実施例における処理Ｘの詳細を示す図である。図１２（ａ）に示す処理Ｘの処理手順有向グラフについて、処理手順マトリクスは、図１２（ｂ）に示すように生成され、リソース操作順序マトリクス（Ｘ）は、図１２（ｃ）に示すように生成される。図１２（ｂ）、図１２（ｃ）の網掛けした部分は、転置関係にある成分同士がゼロのものを示している。
【００７０】
図１３は、実施例における処理Ｙの詳細を示す図である。図１３（ａ）に示す処理Ｙの処理手順有向グラフについて、処理手順マトリクスは、図１３（ｂ）に示すように生成され、リソース操作順序マトリクス（Ｙ）は、図１３（ｃ）に示すように生成される。図１３（ｂ）、図１３（ｃ）の網掛けした部分は、転置関係にある成分同士がゼロのものを示している。
【００７１】
図１４は、実施例における処理Ｚの詳細を示す図である。図１４（ａ）に示す処理Ｚの処理手順有向グラフについて、処理手順マトリクスは、図１４（ｂ）に示すように生成され、リソース操作順序マトリクス（Ｚ）は、図１４（ｃ）に示すように生成される。図１４（ｂ）、図１４（ｃ）の網掛けした部分は、転置関係にある成分同士がゼロのものを示している。
【００７２】
図１５は、実施例における逆順リソース操作情報の生成を説明する図である。処理Ｘ、処理Ｙ、処理Ｚについて生成したリソース操作順序マトリクス（Ｘ）、（Ｙ）、（Ｚ）に基づいて逆順リソース操作情報を生成したものである。図１５（ｄ）に示すように、処理Xと処理Yとは、リソースA,リソースBを逆順操作することがわかる。一方、処理Xと処理Zとは逆順操作しないことがわかる。さらに、処理Yと処理Zとは、リソースA, リソースDを逆順操作することがわかる。また、リソースCは処理X, 処理Y, 処理Zの３処理で逆順操作されないことがわかる。以上のことから、実施例では、リソースA, リソースB, リソースC, リソースDのうち、リソースA, リソースB, リソースDは逆順操作リソースであることがわかる。
【００７３】
そこで、処理Ｘに対して、リソースの排他占有の介入をまとめると、次のようになる。
【００７４】
（１）処理開始時には、従来は、この段階でリソースA, リソースB, リソースCの全てを占有していたのに対し、本実施例では、何もしない。
【００７５】
（２）処理手順１から終了への遷移時には、何もリソースを占有しない。
【００７６】
（３）処理手順２でリソースAを操作時には、逆順操作リソースであるリソースA及びリソースBを占有する(占有順序は、リソース排他占有装置が任意に決定可能である)。リソースCの占有は、この時点では行わない。
【００７７】
（４）処理手順４へ遷移時には、処理手順３へ遷移することがあり得ないため、逆順操作リソースBを解放する。
【００７８】
（５）処理手順６でリソースCを操作時には、ここでリソースCを占有するが、他処理が占有している場合は待つ。
【００７９】
（６）処理終了時には、占有済リソースを解放する。
【００８０】
以上説明したように、本実施形態によれば、必要な時点で必要なリソース占有を行い、処理の途中において不要なリソースを自動解放するため、処理によるリソース占有時間を削減することができ、リソース利用効率が良い。処理間のデッドロック発生を防止することができるので、ソフトウェア開発者は、どのリソースがデッドロックするのかを意識する必要がなく、開発者間で、互いにリソース占有順序ルールを決める必要がなく、リソース占有のためのコードを書く必要が無い。
【００８１】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００８２】
１・・・リソース排他占有装置
１０・・・逆順リソース操作判定部
２０・・・処理動作介入部
３０・・・処理手順マトリクス格納部
４０・・・リソース操作順序マトリクス格納部
５０・・・逆順リソース操作情報格納部
６０・・・リソース占有状況格納部
【図１】
2015207160.tif 000003
【図２】
2015207160.tif 000004
【図３】
2015207160.tif 000005
【図４】
2015207160.tif 000006
【図５】
2015207160.tif 000007
【図６Ａ】
2015207160.tif 000008
【図６Ｂ】
2015207160.tif 000009
【図６Ｃ】
2015207160.tif 000010
【図７】
2015207160.tif 000011
【図８】
2015207160.tif 000012
【図９】
2015207160.tif 000013
【図１０】
2015207160.tif 000014
【図１１】
2015207160.tif 000015
【図１２】
2015207160.tif 000016
【図１３】
2015207160.tif 000017
【図１４】
2015207160.tif 000018
【図１５】
2015207160.tif 000019