(57)【特許請求の範囲】
【請求項１】
複数のアプリケーションが共有リソースにアクセスする際にそれら複数のアプリケーション間で排他制御が行われる分散オブジェクト環境における排他制御方式において、
排他オブジェクトを装備し、
前記複数のアプリケーションの各々は、メインスレッドと、コールバックリストと、ディスパッチスレッドとを備え、上記メインスレッドでプログラムタスクを行うとともに、上記共有リソースに対する処理を行う際には、当該処理を上記コールバックリストに登録して、上記ディスパッチスレッドから上記排他オブジェクトへロック取得要求を送出するようにしてあり、
上記排他オブジェクトは、上記複数のアプリケーションのうちのいずれかのアプリケーションの上記ディスパッチスレッドからロック取得要求を受取ったときに、当該アプリケーションを現在ロック待ちのアプリケーションとして格納するとともに、現在ロック取得が行われているか否かの状態を格納するようにしてあり、
上記ディスパッチスレッドは、上記排他オブジェクトからロック取得応答を受取ったならば、上記コールバックリストに登録されている上記共有リソースに対する処理を実行するようにしてある、
ことを特徴とする分散オブジェクト環境における排他制御方式。
【請求項２】
上記排他オブジェクトは、上記各アプリケーションの上記ディスパッチスレッドからロック取得要求を受取ったときに、当該アプリケーションを現在ロック待ちのアプリケーションとして格納する待ちアプリケーションリストと、
上記アプリケーションの上記ディスパッチスレッドから出された要求に対するロック取得が行われているか、否かの状態を格納する状態フラグと、
を備えることを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項３】
上記メインスレッドは、次に実行しようとする処理が上記共有リソースへのアクセスを必要とする処理であると判断した場合に上記コールバックリストにこの処理を登録し、かつ上記ディスパッチスレッドに処理追加通知を送信することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項４】
上記メインスレッドは、次に実行しようとする処理が上記共有リソースへのアクセスを必要とする処理でないと判断した場合にその処理を実行することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項５】
上記ディスパッチスレッドは、上記処理追加通知を上記メインスレッドから受信したならば、以前から上記コールバックリストに登録されていた処理があるか否かを判断し、以前から上記コールバックリストに登録されていた処理がないと判断した場合には、上記排他オブジェクトに対してロックを取得するためのロック取得要求を送信することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項６】
上記ディスパッチスレッドは、上記処理追加通知を上記メインスレッドから受信したならば、以前から上記コールバックリストに登録されていた処理があるか否かを判断し、以前から上記コールバックリストに登録されていた処理があると判断した場合には、上記排他オブジェクトに対してロックを取得するためのロック取得要求を送信しないことを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項７】
上記ディスパッチスレッドは、上記排他オブジェクトからロック取得応答を受信したならば、上記共有リソースに対して上記コールバックリストに登録された処理を実行し、その実行した処理をコールバックリストから削除することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項８】
上記ディスパッチスレッドは、上記共有リソースに対して上記コールバックリストに登録された処理を実行し、その実行した処理をコールバックリストから削除したならば、上記コールバックリストにその他の処理が存在するか否かを判断し、上記コールバックリストに処理が存在しないと判断した場合には、上記排他オブジェクトのロックを解放することを通知するロック解放通知を送信することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項９】
上記排他オブジェクトは、上記ディスパッチスレッドからロック取得要求の受信時に待ちアプリケーションリストにロック取得要求を送信したアプリケーションを登録することを特徴とする請求項1記載の分散オブジェクト環境における排他制御方式。
【請求項１０】
上記排他オブジェクトは、上記ディスパッチスレッドからロック取得要求を受信して状態フラグよりロック状態でないと判断した場合、あるいは上記ディスパッチスレッドからロック解放通知を受信した場合において、待ちアプリケーションリストにロック待ちをしているアプリケーションが存在していると判断した場合に待ちアプリケーションリストの先頭のアプリケーションに対してロック取得応答を送信してそのアプリケーションを待ちアプリケーションリストから削除することを特徴とする請求項９記載の分散オブジェクト環境における排他制御方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、CORBA（Common Object Request Broker Architecture）に代表される分散オブジェクト環境において、複数のアプリケーションプログラムが共有リソースにアクセスする際に、これらのアプリケーションプログラム間で排他制御が行われるようなシステムにおいて、排他制御により行われる通信を減らし、ロック待ちの際も他の処理に影響を及ぼさないようにする排他制御を提供する分散オブジェクト環境における排他制御方式に関する。
【０００２】
【従来の技術】
従来、複数のアプリケーションで排他制御を行おうとする場合、排他する共有リソースに前置する形で排他制御を行うシステムが置かれ、アプリケーションから共有リソースにアクセスする際は排他制御を行うシステムに排他制御のみならず、共有リソースに対する処理も任せていた。
たとえば、複数のアプリケーション間で共有するファイルにログを出力するために、排他制御システムに出力するデータをも転送し、排他制御システムで排他し、受信したデータを出力するようにしていた。
【０００３】
しかし、この従来技術には以下のような課題があった。第１の課題は、通信コストの増大により性能が劣化するという点である。その理由は、共有リソースへの処理を自アプリケーション内でなく、排他制御システムに任せるため、共有リソースへの処理に必要なデータなども送信する必要が生じてしまい、通信に大きなコストのかかるCORBAに代表される分散オブジェクト環境ではさらに大きな性能劣化となってしまうためである。
【０００４】
第２の課題は、汎用性がなくなってしまうという点である。その理由は、共有リソースへの処理を自アプリケーション内でなく、排他制御システムに任せるため、排他制御システム内に共有リソースにアクセスするためのロジックを組み込む必要が出てきてしまい、異なるアクセスロジックを持つ共有リソース各々に対し異なる排他制御システムを用意する必要が生じてしまうためである。
【０００５】
一方、排他制御のみを行うシステムを用意し、共有リソースに対する処理が生じた際は、その排他制御システムから共有リソースへのアクセス権を取得し、共有リソースへの処理を行い、アクセス権を返却するという手法も取られていた。
【０００６】
【発明が解決しようとする課題】
しかし、この従来技術には以下のような課題があった。第１の課題は、アクセス権取得待ちの間、処理が止まってしまう点である。
その理由は、共有リソースへの処理は自アプリケーション内で行うため、アクセス権が取得できるまで、アプリケーション自体の処理が止まってしまうためである。
また、第２の課題は、通信コストの増大により性能が劣化するという点である。
その理由は、共有リソースへの処理が発生する度に排他制御システムにアクセス権取得要求を送信するために、共有リソースへの処理の数に比例して通信量も増大してしまうためである。
なお、このような従来技術の近似技術として、たとえば、特開平０８−２７８９５３号公報（計算機システムにおける排他制御方式）、特開平０７−５６８６４号公報（共有資源の排他制御方式）などを挙げることができる。
【０００７】
この発明は、上記従来の課題を解決するためになされたもので、共有リソースへの処理を行うために、ロック待ちをしている際も、他の処理は影響を受けずに実行可能であり、かつ排他制御に必要な通信の通信量を低減することができる分散オブジェクト環境における排他制御方式を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る分散オブジェクト環境における排他制御方式は、複数のアプリケーションが共有リソースにアクセスする際にそれら複数のアプリケーション間で排他制御が行われる分散オブジェクト環境における排他制御方式において、排他オブジェクトを装備し、前記複数のアプリケーションの各々は、メインスレッドと、コールバックリストと、ディスパッチスレッドとを備え、上記メインスレッドでプログラムタスクを行うとともに、上記共有リソースに対する処理を行う際には、当該処理を上記コールバックリストに登録して、上記ディスパッチスレッドから上記排他オブジェクトへロック取得要求を送出するようにしてあり、上記排他オブジェクトは、上記複数のアプリケーションのうちのいずれかのアプリケーションの上記ディスパッチスレッドからロック取得要求を受取ったときに、当該アプリケーションを現在ロック待ちのアプリケーションとして格納するとともに、現在ロック取得が行われているか否かの状態を格納するようにしてあり、上記ディスパッチスレッドは、上記排他オブジェクトからロック取得応答を受取ったならば、上記コールバックリストに登録されている上記共有リソースに対する処理を実行するようにしてあることを特徴とする。
【０００９】
この発明によれば、各アプリケーションは、共有リソースに対しての処理を要求する際に、当該処理をコールバックリストに登録し、ディスパッチスレッドから排他オブジェクトへロック取得要求を送出する。
この際、すでにコールバックリストに登録されている処理が存在する場合には、ディスパッチスレッドは前回出されたロック取得要求の応答待ちの状態であり、ディスパッチスレッドから改めてロック取得要求が出されず、共有リソースにアクセスする際に毎回排他オブジェクトへの通信を行わず、ディスパッチスレッドは排他オブジェクトからロック取得応答が帰ってくるまで待機し、この間メインスレッドは他の処理の実行が可能状態にある。
【００１０】
したがって、この発明では、共有リソースへの処理を行うために、ロック待ちをしている際も、他の処理は影響を受けずに実行可能であり、かつ排他制御に必要な通信の通信量を削減することができる。
【００１１】
【発明の実施の形態】
以下、この発明による分散オブジェクト環境における排他制御方式の実施の形態について、図面に基づき説明する。
図１はこの発明による第１実施の形態の構成を示すブロック図である。
この図１において、まず、この第１実施の形態の概要から説明する。アプリケーション１，２は共有リソース９にアクセスするプログラムであり、プログラムタスクはそれぞれ、アプリケーション１，２のメインスレッド３，４で行われる。アプリケーション１，２の内部は同一構成を成している。
【００１２】
ここで、アプリケーション１が、共有リソース９に対する処理を実行しようとするときには、当該処理をコールバックリスト５に登録し、ディスパッチスレッド７は排他オブジェクト１０にロック取得要求を出す。
ただし、すでにコールバックリスト５に登録されている処理が存在するときは、前回出されたロック取得要求の応答待ちの状態であるため、ディスパッチスレッド７は改めて排他オブジェクト１０にロック取得要求を出すことはない。
したがって、共有リソース９にアクセスする際に、毎回排他オブジェクト１０への通信を行う必要もないようにしている。
【００１３】
また、ディスパッチスレッド７では、排他オブジェクト１０からロックが取得できたことを意味するロック取得応答が返ってくるまで待っているが、この間もメインスレッド３ではその他の処理を行うことができ、他の処理に影響を及ぼさない排他制御が可能となるようにしている。
アプリケーション２の場合も同様に構成され、上記メインスレッド４、コールバックリスト６に加えて、ディスパッチスレッド８を備えている。
【００１４】
ここで、さらに詳細に説明すると、この第１実施の形態では、共有リソース９にアクセスするアプリケーション１，２とこれらのアプリケーション１，２の排他制御を行うオブジェクトである排他オブジェクト１０からなり、それぞれのアプリケーション１，２はタスクが実行されるメインスレッド３，４と共有リソース９への処理を登録するコールバックリスト５，６と、排他オブジェクト１０にロック取得要求を行い、コールバックリスト５，６に登録された共有リソース9への処理を行うディスパッチスレッド７，８を備えている。
また、排他オブジェクト１０は、現在ロック待ちのアプリケーションを格納する待ちアプリケーションリスト１１（以下、待ちＡＰリストと略称する）と、現在アプリケーションによりロックが取得されているか、否かの状態を格納する状態フラグ１２を備えている。
【００１５】
次に、この第１実施の形態の動作について図２ないし図４のフローチャートに沿って説明する。
最初に、図２のフローチャートに沿って説明する。図２のフローチャートはメインスレッド３の処理手順を示すフローチャートである。
アプリケーション１のメインスレッド３は、まず、ディスパッチスレッド７を生成する（ステップＡ１）。
この後、このディスパッチスレッド７はメインスレッド３に関係なく動作する。
次に、メインスレッド３はステップＡ２で次に実行しようとする処理が共有リソース９へのアクセスを必要とする処理か否かを判別し、共有リソース９へのアクセスを必要とする処理であると判断した場合には、コールバックリスト５にこの処理を登録する（ステップＡ３）。
処理が追加されたことをディスパッチスレッド７に通知するために、メインスレッド３は処理追加通知をディスパッチスレッド７に送信する（ステップＡ４）。
【００１６】
一方、ステップＡ２で次に実行しようとする処理が共有リソースへのアクセスを必要とする処理ではないと判断された場合には、メインスレッド３はその処理を実行する（ステップＡ５）。
次に、ステップＡ６で次の処理があるかを判別し、もし次の処理があれば、ステップＡ２に戻り、もし次の処理がなければ、ステップＡ１で生成したディスパッチスレッド７を終了させてからメインスレッド３の動作を終了する（ステップＡ７）。
【００１７】
次に、図３のフローチャートに沿って説明する。図３のフローチャートは、ディスパッチスレッド７の処理手順を示すフローチャートである。
この図３において、メインスレッド３により生成されたディスパッチスレッド７はまず、メインスレッド３から処理追加通知が来るまで待つ（ステップＢ１）。
メインスレッド３から処理追加通知が来たら、ディスパッチスレッド７は、以前からコールバックリスト５に登録されていた処理があるか否かを判別し（ステップＢ２）、もし以前から登録されていた処理があったならば（即ち、今回の処理通過通知に関連した処理を登録するより前に登録された処理があったならば）、ディスパッチスレッド７はロック取得要求を送信することなくステップＢ１に戻り、メインスレッド３から再び処理追加通知が来るまで待つ。
【００１８】
また、このステップＢ２おいて、判定の結果、以前からコールバックリスト５に登録されていた処理がないと判断した場合には、排他オブジェクト１０に対して、ディスパッチスレッド７は、ロックを取得するためのロック取得要求を送信する（ステップＢ３）。
ディスパッチスレッド７はロックが取得できた場合には、排他オブジェクト１０からロック取得応答が返ってくるので、これを受信する（ステップＢ５）。
【００１９】
その後、ディスパッチスレッド７はコールバックリスト５に登録されている処理があるかを判別し（ステップＢ５）、登録されている処理があると判断されたならば、共有リソース９に対しコールバックリスト５に登録された処理を実行し、その実行した処理をコールバックリスト５から削除した上で（ステップＢ６）、再びステップＢ５に戻り、コールバックリスト５にその他の実行すべき処理が存在するか（登録されているか）否かを判断する。
もし、コールバックリスト５に処理がなくなったときは、ディスパッチスレッド７は排他オブジェクト１０にロックを解放することを通知するロック解放通知を送信し（ステップＢ７）、再びメインスレッド３から処理追加通知が来るのを待つ。
【００２０】
次に、図４のフローチャートに沿って説明する。図４のフローチャートは、排他オブジェクト１０の処理手順を示すフローチャートである。
この図４において、排他オブジェクト１０は、アプリケーション１のディスパッチスレッド７、アプリケーション２のディスパッチスレッド８からロック取得要求またはロック解放通知が来るまで待ち（ステップＣ１）、ロック取得要求を受信した場合には（ステップＣ２）、待ちＡＰリスト１１にロック取得要求を送信したアプリケーションを登録しておく（ステップＣ３）。
【００２１】
次に、排他オブジェクト１０は、状態フラグ１２よりロック状態にあるか否かを判別するとともに、アプリケーション１のディスパッチスレッド７、あるいはアプリケーション２のディスパッチスレッド８から受信したものが、ロック解放通知であるか否かを判別する（ステップＣ４）。、そして、ロック状態にないか、または、アプリケーション１のディスパッチスレッド７、あるいはアプリケーション２のディスパッチスレッド８から受信したものがロック解放通知であるかの、いずれかに該当していると判断された場合には、待ちＡＰリスト１１にロック待ちをしているアプリケーションがあるかを判別し（ステップＣ５）、もし待ちＡＰリスト１１にロック待ちをしているアプリケーションがあれば、待ちＡＰリスト１１の先頭のアプリケーションに対し、ロック取得応答を送信し、そのアプリケーションを待ちＡＰリスト１１から取り除き、状態フラグ１２をロック状態とする（ステップＣ６）。そして再びディスパッチスレッド７，８からの通知を待つ。
もし、ステップＣ５で待ちＡＰリスト１１にロック待ちをしているアプリケーションがないと判断された場合には、状態フラグ１２を非ロック状態とし（ステップＣ７）、ステップＣ１へ戻って再びディスパッチスレッド７，８からの要求または通知を待つ。
【００２２】
次に、具体例を用いてこの第１実施の形態の動作を説明する。アプリケーション1が、「Ａ」、「Ｂ」、「Ｃ」という三つの処理を実行するプログラムであるとし、そのうち、プログラム「Ａ」、プログラム「Ｂ」が共有リソース９への処理であったとき、図２において、まず、ディスパッチスレッド7を生成し（ステップＡ１）、次のプログラム「Ａ」の処理は共有リソース９への処理であるので、コールバックリスト５にプログラム「Ａ」を登録し（ステップＡ３）、ディスパッチスレッド７に処理追加通知を送信する（ステップＡ４）。
【００２３】
その後、まだ次の処理があるので（ステップＡ６）、ステップＡ６からステップＡ２に戻る。これは、プログラム「Ａ」の処理が実際には処理されていないが、次の処理に進めることを意味している。
次のプログラム「Ｂ」の処理も共有リソース９への処理であるので、メインスレッド３は、プログラム「Ａ」の処理と同様コールバックリスト５にプログラム「Ｂ」を登録し、メインスレッド３はディスパッチスレッド７に処理追加通知を送信する。
【００２４】
次のプログラム「Ｃ」の処理に関しては、共有リソース９には関係のない処理であるので、メインスレッド３はプログラム「Ｃ」の処理を実行する（ステップＡ５）。
その後、処理はないので、ディスパッチスレッド７を終了させ、メインスレッド３の処理を終了する。
【００２５】
一方、図３のディスパッチスレッド7での処理は、まず、ディスパッチスレッド7は、プログラム「Ａ」の処理が追加されたことを通知する処理追加通知をメインスレッド３から受信する（ステップＢ１）。
その後、コールバックリスト５の中にはプログラム「Ａ」の処理があるので、ディスパッチスレッド７はロック取得要求を排他オブジェクト１０に送信する（ステップＢ３）。
【００２６】
ロック取得応答が排他オブジェクト１０からディスパッチスレッド７に返ってくると（ステップＢ４）、共有リソース９にアクセス可能であるので、ディスパッチスレッド７はコールバックリスト５に処理があるかを調べ（ステップＢ５）、その結果、プログラム「Ａ」の処理があるので、ディスパッチスレッド７はプログラム「Ａ」の処理を実行し、コールバックリスト５からプログラム「Ａ」の処理を削除する（ステップＢ６）。
【００２７】
ディスパッチスレッド７は再びコールバックリスト５を調べた結果、プログラム「Ｂ」の処理も追加されていたとすると、ディスパッチスレッド７はプログラム「Ｂ」の処理も実行され、コールバックリスト５から削除される。
その後には、処理は追加されていないので、ディスパッチスレッド７は排他オブジェクト１０にロック解放通知を送信し（ステップＢ７）、再びステップＢ１に戻る。
ここで、プログラム「Ｂ」の処理が追加されたときの処理追加通知が届いているが、その時点では、コールバックリスト５にプログラム「Ｂ」が登録されるより以前からプログラム「Ａ」が登録されているため（ステップＢ２）、ディスパッチスレッド７はロック取得要求を送出することなく、ステップＢ１に戻る。
【００２８】
最後に、図４のフローチャートに示す排他オブジェクト１０での処理であるが、まず、プログラム「Ａ」の処理が追加されたことにより、ディスパッチスレッド７から送信されるロック取得要求を排他オブジェクト１０が受信する（ステップＣ１）。
排他オブジェクト１０が受信したのは、ディスパッチスレッド７から送信されるロック取得要求であるので（ステップＣ２）、待ちＡＰリスト１１にアプリケーション１を登録する（ステップＣ３）。
【００２９】
次に、排他オブジェクト１０は、状態フラグ１２を調べ、ロックされていない状態であるため（ステップＣ４）、待ちＡＰリスト１１をチェックし（ステップＣ５）、アプリケーション１が追加されているので、アプリケーション１にロック取得応答を送信する（ステップＣ６）。
これと同時に、排他オブジェクト１０は、待ちＡＰリスト１１からアプリケーション１を削除し、状態フラグ１２をロック状態としておく。
その後、排他オブジェクト１０は、ステップＣ１でディスパッチスレッド７から送信されたロック解放通知を受信し、ステップＣ４からステップＣ５に処理が移り、待ちＡＰリスト１１には要素はないので、状態フラグ１２をロックされていない状態にしてステップＣ１の処理に戻る。
【００３０】
【発明の効果】
以上のように、この発明によれば、アプリケーションに通常の処理を行うメインスレッドとは別に共有リソースへの処理を行うディスパッチスレッドを用意し、これらが個々に動作できるようにしたので、共有リソースへの処理を行うためにロック待ちをしている際も、他の処理は影響を受けず実行できる。
また、アプリケーションにコールバックリストを用意して、共有リソースへの処理が発生する度にロックを取得するのではなく、複数の処理でも一回のロック取得で済むようにしたので、排他制御に必要な通信を削減できる。
【図面の簡単な説明】
【図１】この発明による分散オブジェクト環境における排他制御方式の第１実施の形態の構成を示すブロック図である。
【図２】この発明による分散オブジェクト環境における排他制御方式の第１実施の形態の動作を説明するためのアプリケーションのメインスレッドの処理手順を示すフローチャートである。
【図３】この発明による分散オブジェクト環境における排他制御方式の第１実施の形態の動作を説明するためのディスパッチスレッドの処理手順を示すフローチャートである。
【図４】この発明による分散オブジェクト環境における排他制御方式の第１実施の形態の動作を説明するための排他オブジェクトの処理手順を示すフローチャートである。
【符号の説明】
１，２……アプリケーション、３，４……メインスレッド、５，６……コールバックリスト、７、８ディスパッチスレッド、９……共有リソース、１０……排他オブジェクト、１１……待ちＡＰリスト（待ちアプリケーションリスト）、１２……状態フラグ。
【図１】
0003544140.tif 000002
【図２】
0003544140.tif 000003
【図３】
0003544140.tif 000004
【図４】
0003544140.tif 000005