JP2000259436A - 分散オブジェクト環境における排他制御方式 - Google Patents
分散オブジェクト環境における排他制御方式Info
- Publication number
- JP2000259436A JP2000259436A JP11066927A JP6692799A JP2000259436A JP 2000259436 A JP2000259436 A JP 2000259436A JP 11066927 A JP11066927 A JP 11066927A JP 6692799 A JP6692799 A JP 6692799A JP 2000259436 A JP2000259436 A JP 2000259436A
- Authority
- JP
- Japan
- Prior art keywords
- thread
- application
- lock
- exclusive
- list
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 89
- 230000005540 biological transmission Effects 0.000 claims 1
- 238000004891 communication Methods 0.000 abstract description 9
- 238000010586 diagram Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 1
Landscapes
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 共有リソースへの処理を行うために、ロック
待ちをしている際も、他の処理は影響を受けずに実行可
能、かつ排他制御に必要な通信を削除することができる
分散オブジェクト環境における排他制御方式を提供する
こと。 【解決手段】 アプリケーション１から共有リソース９
に対しての処理要求を行うと、メインスレッド３がプロ
グラムタスクを実行し、処理要求を行った処理をコール
ドバックリスト５に登録し、ディスパッチスレッド７は
排他オブジェクト１０にロック取得要求を出し、すでに
コールバックリスト５に登録されている処理が存在する
と、ディスパッチスレッド７から改めてロック取得要求
が出されず、ディスパッチスレッド７は排他オブジェク
ト１０からロック取得応答が返送されるまで待機し、こ
の間メインスレッド３は他の処理の続行が可能となる。
待ちをしている際も、他の処理は影響を受けずに実行可
能、かつ排他制御に必要な通信を削除することができる
分散オブジェクト環境における排他制御方式を提供する
こと。 【解決手段】 アプリケーション１から共有リソース９
に対しての処理要求を行うと、メインスレッド３がプロ
グラムタスクを実行し、処理要求を行った処理をコール
ドバックリスト５に登録し、ディスパッチスレッド７は
排他オブジェクト１０にロック取得要求を出し、すでに
コールバックリスト５に登録されている処理が存在する
と、ディスパッチスレッド７から改めてロック取得要求
が出されず、ディスパッチスレッド７は排他オブジェク
ト１０からロック取得応答が返送されるまで待機し、こ
の間メインスレッド３は他の処理の続行が可能となる。
Description
【０００１】
【発明の属する技術分野】この発明は、CORBA（Common
Object Request Broker Architecture）に代表さ
れる分散オブジェクト環境において、複数のアプリケー
ションプログラムが共有リソースにアクセスする際に、
これらのアプリケーションプログラム間で排他制御が行
われるようなシステムにおいて、排他制御により行われ
る通信を減らし、ロック待ちの際も他の処理に影響を及
ぼさないようにする排他制御を提供する分散オブジェク
ト環境における排他制御方式に関する。
Object Request Broker Architecture）に代表さ
れる分散オブジェクト環境において、複数のアプリケー
ションプログラムが共有リソースにアクセスする際に、
これらのアプリケーションプログラム間で排他制御が行
われるようなシステムにおいて、排他制御により行われ
る通信を減らし、ロック待ちの際も他の処理に影響を及
ぼさないようにする排他制御を提供する分散オブジェク
ト環境における排他制御方式に関する。
【０００２】
【従来の技術】従来、複数のアプリケーションで排他制
御を行おうとする場合、排他する共有リソースに前置す
る形で排他制御を行うシステムが置かれ、アプリケーシ
ョンから共有リソースにアクセスする際は排他制御を行
うシステムに排他制御のみならず、共有リソースに対す
る処理も任せていた。たとえば、複数のアプリケーショ
ン間で共有するファイルにログを出力するために、排他
制御システムに出力するデータをも転送し、排他制御シ
ステムで排他し、受信したデータを出力するようにして
いる。
御を行おうとする場合、排他する共有リソースに前置す
る形で排他制御を行うシステムが置かれ、アプリケーシ
ョンから共有リソースにアクセスする際は排他制御を行
うシステムに排他制御のみならず、共有リソースに対す
る処理も任せていた。たとえば、複数のアプリケーショ
ン間で共有するファイルにログを出力するために、排他
制御システムに出力するデータをも転送し、排他制御シ
ステムで排他し、受信したデータを出力するようにして
いる。
【０００３】しかし、この従来技術には以下のような課
題があった。第１の課題は、通信コストの増大により性
能が劣化するという点である。その理由は、共有リソー
スへの処理を自アプリケーション内でなく、排他制御シ
ステムに任せるため、共有リソースへの処理に必要なデ
ータなども送信する必要が生じてしまい、通信に大きな
コストのかかるCORBAに代表される分散オブジェクト環
境ではさらに大きな性能劣化となってしまうためであ
る。
題があった。第１の課題は、通信コストの増大により性
能が劣化するという点である。その理由は、共有リソー
スへの処理を自アプリケーション内でなく、排他制御シ
ステムに任せるため、共有リソースへの処理に必要なデ
ータなども送信する必要が生じてしまい、通信に大きな
コストのかかるCORBAに代表される分散オブジェクト環
境ではさらに大きな性能劣化となってしまうためであ
る。
【０００４】第２の課題は、汎用性がなくなってしまう
という点である。その理由は、共有リソースへの処理を
自アプリケーション内でなく、排他制御システムに任せ
るため、排他制御システム内に共有リソースにアクセス
するためのロジックを組み込む必要が出てきてしまい、
異なるアクセスロジックを持つ共有リソース各々に対し
異なる排他制御システムを用意する必要が生じてしまう
ためである。
という点である。その理由は、共有リソースへの処理を
自アプリケーション内でなく、排他制御システムに任せ
るため、排他制御システム内に共有リソースにアクセス
するためのロジックを組み込む必要が出てきてしまい、
異なるアクセスロジックを持つ共有リソース各々に対し
異なる排他制御システムを用意する必要が生じてしまう
ためである。
【０００５】一方、排他制御のみを行うシステムを用意
し、共有リソースに対する処理が生じた際は、その排他
制御システムから共有リソースへのアクセス権を取得
し、共有リソースへの処理を行い、アクセス権を返却す
るという手法も取られていた。
し、共有リソースに対する処理が生じた際は、その排他
制御システムから共有リソースへのアクセス権を取得
し、共有リソースへの処理を行い、アクセス権を返却す
るという手法も取られていた。
【０００６】
【発明が解決しようとする課題】しかし、この従来技術
には以下のような課題があった。第１の課題は、アクセ
ス権取得待ちの間、処理が止まってしまう点である。そ
の理由は、共有リソースへの処理は自アプリケーション
内で行うため、アクセス権が取得できるまで、アプリケ
ーション自体の処理が止まってしまうためである。ま
た、第２の課題は、通信コストの増大により性能が劣化
するという点である。その理由は、共有リソースへの処
理が発生する度に排他制御システムにアクセス権取得要
求を送信するために、共有リソースへの処理の数に比例
して通信量も増大してしまうためである。なお、このよ
うな従来技術の近似技術として、たとえば、特開平０８
−２７８９５３号公報（計算機システムにおける排他制
御方式）、特開平０７−５６８６４号公報（共有資源の
排他制御方式）などを挙げることができる。
には以下のような課題があった。第１の課題は、アクセ
ス権取得待ちの間、処理が止まってしまう点である。そ
の理由は、共有リソースへの処理は自アプリケーション
内で行うため、アクセス権が取得できるまで、アプリケ
ーション自体の処理が止まってしまうためである。ま
た、第２の課題は、通信コストの増大により性能が劣化
するという点である。その理由は、共有リソースへの処
理が発生する度に排他制御システムにアクセス権取得要
求を送信するために、共有リソースへの処理の数に比例
して通信量も増大してしまうためである。なお、このよ
うな従来技術の近似技術として、たとえば、特開平０８
−２７８９５３号公報（計算機システムにおける排他制
御方式）、特開平０７−５６８６４号公報（共有資源の
排他制御方式）などを挙げることができる。
【０００７】この発明は、上記従来の課題を解決するた
めになされたもので、共有リソースへの処理を行うため
に、ロック待ちをしている際も、他の処理は影響を受け
ずに実行可能であり、かつ排他制御に必要な通信を削除
することができる分散オブジェクト環境における排他制
御方式を提供することを目的とする。
めになされたもので、共有リソースへの処理を行うため
に、ロック待ちをしている際も、他の処理は影響を受け
ずに実行可能であり、かつ排他制御に必要な通信を削除
することができる分散オブジェクト環境における排他制
御方式を提供することを目的とする。
【０００８】
【課題を解決するための手段】上記目的を達成するため
に、この発明の分散オブジェクト環境における排他制御
方式は、それぞれメインスレッドでプログラムタスクを
行い、共有リソースにアクセスし、かつ上記共有リソー
スに対しての処理要求を行う際に、この処理をコールバ
ックリストに登録されている処理が存在する場合には、
コールバックリストに登録し、ディスパッチスレッドか
らロック取得要求を行う複数のアプリケーションと、上
記各アプリケーションの上記ディスパッチスレッドから
のロック取得要求が出されるまで現在ロック待ちのアプ
リケーションを格納するとともに現在上記アプリケーシ
ョンの上記ディスパッチスレッドから出された要求に対
するロック取得が行われているか、否かの状態を格納す
る排他オブジェクトとを備えることを特徴とする。
に、この発明の分散オブジェクト環境における排他制御
方式は、それぞれメインスレッドでプログラムタスクを
行い、共有リソースにアクセスし、かつ上記共有リソー
スに対しての処理要求を行う際に、この処理をコールバ
ックリストに登録されている処理が存在する場合には、
コールバックリストに登録し、ディスパッチスレッドか
らロック取得要求を行う複数のアプリケーションと、上
記各アプリケーションの上記ディスパッチスレッドから
のロック取得要求が出されるまで現在ロック待ちのアプ
リケーションを格納するとともに現在上記アプリケーシ
ョンの上記ディスパッチスレッドから出された要求に対
するロック取得が行われているか、否かの状態を格納す
る排他オブジェクトとを備えることを特徴とする。
【０００９】この発明によれば、各アプリケーションか
ら共有リソースに対しての処理要求が行われると、メイ
ンスレッドがプログラムタスクを実行し、処理要求を行
った処理がコールドバックリストに登録し、ディスパッ
チスレッドは排他オブジェクトにロック取得要求を出
す。この際、すでにコールバックリストに登録されてい
る処理が存在する場合には、ディスパッチスレッドは前
回出されたロック取得要求の応答待ちの状態であり、デ
ィスパッチスレッドから改めてロック取得要求が出され
ず、共有リソースにアクセスする際に毎回排他オブジェ
クトへの通信を行わず、ディスパッチスレッドは排他オ
ブジェクトからロック取得応答が帰ってくるまで待機
し、この間メインスレッドは他の処理の実行が可能状態
にある。
ら共有リソースに対しての処理要求が行われると、メイ
ンスレッドがプログラムタスクを実行し、処理要求を行
った処理がコールドバックリストに登録し、ディスパッ
チスレッドは排他オブジェクトにロック取得要求を出
す。この際、すでにコールバックリストに登録されてい
る処理が存在する場合には、ディスパッチスレッドは前
回出されたロック取得要求の応答待ちの状態であり、デ
ィスパッチスレッドから改めてロック取得要求が出され
ず、共有リソースにアクセスする際に毎回排他オブジェ
クトへの通信を行わず、ディスパッチスレッドは排他オ
ブジェクトからロック取得応答が帰ってくるまで待機
し、この間メインスレッドは他の処理の実行が可能状態
にある。
【００１０】したがって、この発明では、共有リソース
への処理を行うために、ロック待ちをしている際も、他
の処理は影響を受けずに実行可能であり、かつ排他制御
に必要な通信を削除することができる。
への処理を行うために、ロック待ちをしている際も、他
の処理は影響を受けずに実行可能であり、かつ排他制御
に必要な通信を削除することができる。
【００１１】
【発明の実施の形態】以下、この発明による分散オブジ
ェクト環境における排他制御方式の実施の形態につい
て、図面に基づき説明する。図１はこの発明による第１
実施の形態の構成を示すブロック図である。この図１に
おいて、まず、この第１実施の形態の概要から説明す
る。アプリケーション１，２は共有リソース９にアクセ
スするプログラムであり、プログラムタスクはそれぞ
れ、アプリケーション１，２のメインスレッド３，４で
行われる。アプリケーション１，２の内部は同一構成を
成している。
ェクト環境における排他制御方式の実施の形態につい
て、図面に基づき説明する。図１はこの発明による第１
実施の形態の構成を示すブロック図である。この図１に
おいて、まず、この第１実施の形態の概要から説明す
る。アプリケーション１，２は共有リソース９にアクセ
スするプログラムであり、プログラムタスクはそれぞ
れ、アプリケーション１，２のメインスレッド３，４で
行われる。アプリケーション１，２の内部は同一構成を
成している。
【００１２】ここで、アプリケーション１から共有リソ
ース９に対しての処理要求があった場合は、この処理を
コールバックリスト５に登録し、ディスパッチスレッド
７は排他オブジェクト１０にロック取得要求を出す。こ
の際に、すでにコールバックリスト５に登録されている
処理が存在するときは、前回出されたロック取得要求の
応答待ちの状態であるため、ディスパッチスレッド７は
改めて排他オブジェクト１０にロック取得要求を出す必
要がない。したがって、共有リソース９にアクセスする
際に、毎回排他オブジェクト１０への通信を行う必要も
ないようにしている。
ース９に対しての処理要求があった場合は、この処理を
コールバックリスト５に登録し、ディスパッチスレッド
７は排他オブジェクト１０にロック取得要求を出す。こ
の際に、すでにコールバックリスト５に登録されている
処理が存在するときは、前回出されたロック取得要求の
応答待ちの状態であるため、ディスパッチスレッド７は
改めて排他オブジェクト１０にロック取得要求を出す必
要がない。したがって、共有リソース９にアクセスする
際に、毎回排他オブジェクト１０への通信を行う必要も
ないようにしている。
【００１３】また、ディスパッチスレッド７では、排他
オブジェクト１０からロックが取得できたことを意味す
るロック取得応答が返ってくるまで待っているが、この
間もメインスレッド３ではその他の処理を行うことがで
き、他の処理に影響を及ぼさない排他制御が可能となる
ようにしている。アプリケーション２の場合も同様に構
成され、上記メインスレッド４、コールバックリスト６
に加えて、ディスパッチスレッド８を備えている。
オブジェクト１０からロックが取得できたことを意味す
るロック取得応答が返ってくるまで待っているが、この
間もメインスレッド３ではその他の処理を行うことがで
き、他の処理に影響を及ぼさない排他制御が可能となる
ようにしている。アプリケーション２の場合も同様に構
成され、上記メインスレッド４、コールバックリスト６
に加えて、ディスパッチスレッド８を備えている。
【００１４】ここで、さらに詳細に説明すると、この第
１実施の形態では、共有リソース９にアクセスするアプ
リケーション１，２とこれらのアプリケーション１，２
の排他制御を行うオブジェクトである排他オブジェクト
１０からなり、それぞれのアプリケーション１，２はタ
スクが実行されるメインスレッド３，４と共有リソース
９への処理を登録するコールバックリスト５，６と、排
他オブジェクト１０にロック取得要求を行い、コールバ
ックリスト５，６に登録された共有リソース9への処理
を行うディスパッチスレッド７，８を備えている。ま
た、排他オブジェクト１０は、現在ロック待ちのアプリ
ケーションを格納する待ちアプリケーションリスト１１
（以下、待ちＡＰリストと略称する）と、現在アプリケ
ーションによりロックが取得されているか、否かの状態
を格納する状態フラグ１２を備えている。
１実施の形態では、共有リソース９にアクセスするアプ
リケーション１，２とこれらのアプリケーション１，２
の排他制御を行うオブジェクトである排他オブジェクト
１０からなり、それぞれのアプリケーション１，２はタ
スクが実行されるメインスレッド３，４と共有リソース
９への処理を登録するコールバックリスト５，６と、排
他オブジェクト１０にロック取得要求を行い、コールバ
ックリスト５，６に登録された共有リソース9への処理
を行うディスパッチスレッド７，８を備えている。ま
た、排他オブジェクト１０は、現在ロック待ちのアプリ
ケーションを格納する待ちアプリケーションリスト１１
（以下、待ちＡＰリストと略称する）と、現在アプリケ
ーションによりロックが取得されているか、否かの状態
を格納する状態フラグ１２を備えている。
【００１５】次に、この第１実施の形態の動作について
図２ないし図４のフローチャートに沿って説明する。最
初に、図２のフローチャートに沿って説明する。図２の
フローチャートはメインスレッド３の処理手順を示すフ
ローチャートである。アプリケーション１のメインスレ
ッド３は、まず、ディスパッチスレッド７を生成する
（ステップＡ１）。この後、このディスパッチスレッド
７はメインスレッド３に関係なく動作する。次に、メイ
ンスレッド３はステップＡ２で次に実行する処理が共有
リソース９へのアクセスか、否かを判別し、共有リソー
ス９へのアクセスであると判断した場合には、コールバ
ックリスト５にこの処理を登録する（ステップＡ３）。
処理が追加されたことをディスパッチスレッド７に通知
するために、メインスレッド３は処理追加通知をディス
パッチスレッド７に送信する（ステップＡ４）。
図２ないし図４のフローチャートに沿って説明する。最
初に、図２のフローチャートに沿って説明する。図２の
フローチャートはメインスレッド３の処理手順を示すフ
ローチャートである。アプリケーション１のメインスレ
ッド３は、まず、ディスパッチスレッド７を生成する
（ステップＡ１）。この後、このディスパッチスレッド
７はメインスレッド３に関係なく動作する。次に、メイ
ンスレッド３はステップＡ２で次に実行する処理が共有
リソース９へのアクセスか、否かを判別し、共有リソー
ス９へのアクセスであると判断した場合には、コールバ
ックリスト５にこの処理を登録する（ステップＡ３）。
処理が追加されたことをディスパッチスレッド７に通知
するために、メインスレッド３は処理追加通知をディス
パッチスレッド７に送信する（ステップＡ４）。
【００１６】一方、ステップＡ２で次に実行する処理が
共有リソースへのアクセスでない場合、メインスレッド
３はその処理を実行する（ステップＡ５）。次に、ステ
ップＡ６で次の処理があるかを判別し、もし次の処理が
あれば、ステップＡ２に戻り、もし次の処理がなけれ
ば、ステップＡ１で生成したディスパッチスレッド７を
終了させてからメインスレッド３の動作を終了する（ス
テップＡ７）。
共有リソースへのアクセスでない場合、メインスレッド
３はその処理を実行する（ステップＡ５）。次に、ステ
ップＡ６で次の処理があるかを判別し、もし次の処理が
あれば、ステップＡ２に戻り、もし次の処理がなけれ
ば、ステップＡ１で生成したディスパッチスレッド７を
終了させてからメインスレッド３の動作を終了する（ス
テップＡ７）。
【００１７】次に、図３のフローチャートに沿って説明
する。図３のフローチャートは、ディスパッチスレッド
７の処理手順を示すフローチャートである。この図３に
おいて、メインスレッド３により生成されたディスパッ
チスレッド７はまず、メインスレッド３から処理追加通
知が来るまで待つ（ステップＢ１）。メインスレッド３
から処理追加通知が来たら、ディスパッチスレッド７は
コールバックリスト５に処理が登録されているかを判別
し（ステップＢ２）、もし処理が登録されていなけれ
ば、ディスパッチスレッド７は排他オブジェクト１０に
ロック解放通知を送信し（ステップＢ７）、メインスレ
ッド３から再び処理追加通知が来るまで待つ。
する。図３のフローチャートは、ディスパッチスレッド
７の処理手順を示すフローチャートである。この図３に
おいて、メインスレッド３により生成されたディスパッ
チスレッド７はまず、メインスレッド３から処理追加通
知が来るまで待つ（ステップＢ１）。メインスレッド３
から処理追加通知が来たら、ディスパッチスレッド７は
コールバックリスト５に処理が登録されているかを判別
し（ステップＢ２）、もし処理が登録されていなけれ
ば、ディスパッチスレッド７は排他オブジェクト１０に
ロック解放通知を送信し（ステップＢ７）、メインスレ
ッド３から再び処理追加通知が来るまで待つ。
【００１８】また、このステップＢ２おいて、判定の結
果、ディスパッチスレッド７はコールバックリスト５に
処理が登録されていると判断すると、排他オブジェクト
１０に対し、ディスパッチスレッド７は排他オブジェク
ト１０にロックを取得するためのロック取得要求を送信
する（ステップＢ３）。ディスパッチスレッド７はロッ
クが取得できた場合には、排他オブジェクト１０からロ
ック取得応答が返ってくるので、これを受信する（ステ
ップＢ５）。
果、ディスパッチスレッド７はコールバックリスト５に
処理が登録されていると判断すると、排他オブジェクト
１０に対し、ディスパッチスレッド７は排他オブジェク
ト１０にロックを取得するためのロック取得要求を送信
する（ステップＢ３）。ディスパッチスレッド７はロッ
クが取得できた場合には、排他オブジェクト１０からロ
ック取得応答が返ってくるので、これを受信する（ステ
ップＢ５）。
【００１９】その後、ディスパッチスレッド７はコール
バックリスト５に処理があるかを判別し（ステップＢ
５）、もし処理があると判断すると、共有リソース９に
対しコールバックリスト５に登録された処理を実行し、
その処理をコールバックリスト５から削除し、再びコー
ルバックリスト５の判別に戻る（ステップＢ６）。も
し、コールバックリスト５に処理がなくなったときは、
ディスパッチスレッド７は排他オブジェクト１０にロッ
クを解放することを通知するロック解放通知を送信し
（ステップＢ７）、再びメインスレッド３から処理追加
通知が来るのを待つ。
バックリスト５に処理があるかを判別し（ステップＢ
５）、もし処理があると判断すると、共有リソース９に
対しコールバックリスト５に登録された処理を実行し、
その処理をコールバックリスト５から削除し、再びコー
ルバックリスト５の判別に戻る（ステップＢ６）。も
し、コールバックリスト５に処理がなくなったときは、
ディスパッチスレッド７は排他オブジェクト１０にロッ
クを解放することを通知するロック解放通知を送信し
（ステップＢ７）、再びメインスレッド３から処理追加
通知が来るのを待つ。
【００２０】次に、図４のフローチャートに沿って説明
する。図４のフローチャートは、排他オブジェクト１０
の処理手順を示すフローチャートである。この図４にお
いて、排他オブジェクト１０では、アプリケーション１
のディスパッチスレッド７、アプリケーション２のディ
スパッチスレッド８からロック取得通知やロック解放通
知が来るまで待ち（ステップＣ１）、もし、排他オブジ
ェクト１０がロック取得要求を受信した場合には（ステ
ップＣ２）、待ちＡＰリスト１１にロック取得要求を送
信したアプリケーションを登録しておく（ステップＣ
３）。
する。図４のフローチャートは、排他オブジェクト１０
の処理手順を示すフローチャートである。この図４にお
いて、排他オブジェクト１０では、アプリケーション１
のディスパッチスレッド７、アプリケーション２のディ
スパッチスレッド８からロック取得通知やロック解放通
知が来るまで待ち（ステップＣ１）、もし、排他オブジ
ェクト１０がロック取得要求を受信した場合には（ステ
ップＣ２）、待ちＡＰリスト１１にロック取得要求を送
信したアプリケーションを登録しておく（ステップＣ
３）。
【００２１】次に、排他オブジェクト１０は、状態フラ
グ１２よりロック状態か、否かを判別し、ロック状態で
ないか、アプリケーション１のディスパッチスレッド
７、あるいはアプリケーション２のディスパッチスレッ
ド８からロック解放通知を受信した場合（ステップＣ
４）、待ちＡＰリスト１１にロック待ちをしているアプ
リケーションがあるかを判別し（ステップＣ５）、もし
待ちＡＰリスト１１にロック待ちをしているアプリケー
ションがあれば、待ちＡＰリスト１１の先頭のアプリケ
ーションに対し、ロック取得応答を送信し、そのアプリ
ケーションを待ちＡＰリスト１１から取り除き、状態フ
ラグ１２をロック状態とする（ステップＣ６）。そして
再びディスパッチスレッド７，８からの通知を待つ。も
し、ステップＣ５で待ちＡＰリスト１１に要素がない場
合には、状態フラグ１２をロック状態でないようにし、
再びディスパッチスレッド７，８からの通知を待つ。
グ１２よりロック状態か、否かを判別し、ロック状態で
ないか、アプリケーション１のディスパッチスレッド
７、あるいはアプリケーション２のディスパッチスレッ
ド８からロック解放通知を受信した場合（ステップＣ
４）、待ちＡＰリスト１１にロック待ちをしているアプ
リケーションがあるかを判別し（ステップＣ５）、もし
待ちＡＰリスト１１にロック待ちをしているアプリケー
ションがあれば、待ちＡＰリスト１１の先頭のアプリケ
ーションに対し、ロック取得応答を送信し、そのアプリ
ケーションを待ちＡＰリスト１１から取り除き、状態フ
ラグ１２をロック状態とする（ステップＣ６）。そして
再びディスパッチスレッド７，８からの通知を待つ。も
し、ステップＣ５で待ちＡＰリスト１１に要素がない場
合には、状態フラグ１２をロック状態でないようにし、
再びディスパッチスレッド７，８からの通知を待つ。
【００２２】次に、具体例を用いてこの第１実施の形態
の動作を説明する。アプリケーション1が、「Ａ」、
「Ｂ」、「Ｃ」という三つの処理を実行するプログラム
であるとし、そのうち、プログラム「Ａ」、プログラム
「Ｂ」が共有リソース９への処理であったとき、図２に
おいて、まず、ディスパッチスレッド7を生成し（ステ
ップＡ１）、次のプログラム「Ａ」の処理は共有リソー
ス９への処理であるので、コールバックリスト５にプロ
グラム「Ａ」を登録し（ステップＡ３）、ディスパッチ
スレッド７に処理追加通知を送信する（ステップＡ
４）。
の動作を説明する。アプリケーション1が、「Ａ」、
「Ｂ」、「Ｃ」という三つの処理を実行するプログラム
であるとし、そのうち、プログラム「Ａ」、プログラム
「Ｂ」が共有リソース９への処理であったとき、図２に
おいて、まず、ディスパッチスレッド7を生成し（ステ
ップＡ１）、次のプログラム「Ａ」の処理は共有リソー
ス９への処理であるので、コールバックリスト５にプロ
グラム「Ａ」を登録し（ステップＡ３）、ディスパッチ
スレッド７に処理追加通知を送信する（ステップＡ
４）。
【００２３】その後、まだ次の処理があるので（ステッ
プＡ６）、ステップＡ６からステップＡ２に戻る。これ
は、プログラム「Ａ」の処理が実際には処理されていな
いが、次の処理に進めることを意味している。次のプロ
グラム「Ｂ」の処理も共有リソース９への処理であるの
で、メインスレッド３は、プログラム「Ａ」の処理と同
様コールバックリスト５にプログラム「Ｂ」を登録し、
メインスレッド３はディスパッチスレッド７に処理追加
通知を送信する。
プＡ６）、ステップＡ６からステップＡ２に戻る。これ
は、プログラム「Ａ」の処理が実際には処理されていな
いが、次の処理に進めることを意味している。次のプロ
グラム「Ｂ」の処理も共有リソース９への処理であるの
で、メインスレッド３は、プログラム「Ａ」の処理と同
様コールバックリスト５にプログラム「Ｂ」を登録し、
メインスレッド３はディスパッチスレッド７に処理追加
通知を送信する。
【００２４】次のプログラム「Ｃ」の処理に関しては、
共有リソース９には関係のない処理であるので、メイン
スレッド３はプログラム「Ｃ」の処理を実行する（ステ
ップＡ５）。その後、処理はないので、ディスパッチス
レッド７を終了させ、メインスレッド３の処理を終了す
る。
共有リソース９には関係のない処理であるので、メイン
スレッド３はプログラム「Ｃ」の処理を実行する（ステ
ップＡ５）。その後、処理はないので、ディスパッチス
レッド７を終了させ、メインスレッド３の処理を終了す
る。
【００２５】一方、図３のディスパッチスレッド7での
処理は、まず、ディスパッチスレッド7は、プログラム
「Ａ」の処理が追加されたことを通知する処理追加通知
をメインスレッド３から受信する（ステップＢ１）。そ
の後、コールバックリスト５の中にはプログラム「Ａ」
の処理があるので、ディスパッチスレッド７はロック取
得要求を排他オブジェクト１０に送信する（ステップＢ
３）。
処理は、まず、ディスパッチスレッド7は、プログラム
「Ａ」の処理が追加されたことを通知する処理追加通知
をメインスレッド３から受信する（ステップＢ１）。そ
の後、コールバックリスト５の中にはプログラム「Ａ」
の処理があるので、ディスパッチスレッド７はロック取
得要求を排他オブジェクト１０に送信する（ステップＢ
３）。
【００２６】ロック取得応答が排他オブジェクト１０か
らディスパッチスレッド７に返ってくると（ステップＢ
４）、共有リソース９にアクセス可能であるので、ディ
スパッチスレッド７はコールバックリスト５に処理があ
るかを調べ（ステップＢ５）、その結果、プログラム
「Ａ」の処理があるので、ディスパッチスレッド７はプ
ログラム「Ａ」の処理を実行し、コールバックリスト５
からプログラム「Ａ」の処理を削除する（ステップＢ
６）。
らディスパッチスレッド７に返ってくると（ステップＢ
４）、共有リソース９にアクセス可能であるので、ディ
スパッチスレッド７はコールバックリスト５に処理があ
るかを調べ（ステップＢ５）、その結果、プログラム
「Ａ」の処理があるので、ディスパッチスレッド７はプ
ログラム「Ａ」の処理を実行し、コールバックリスト５
からプログラム「Ａ」の処理を削除する（ステップＢ
６）。
【００２７】ディスパッチスレッド７は再びコールバッ
クリスト５を調べた結果、プログラム「Ｂ」の処理も追
加されていたとすると、ディスパッチスレッド７はプロ
グラム「Ｂ」の処理も実行され、コールバックリスト５
から削除される。その後には、処理は追加されていない
ので、ディスパッチスレッド７は排他オブジェクト１０
にロック解放通知を送信し（ステップＢ７）、再びステ
ップＢ１に戻る。ここで、プログラム「Ｂ」の処理が追
加されたときの処理追加通知が届いているが、コールバ
ックリスト５には何も処理がないので（ステップＢ
２）、再びステップＢ１に戻る。
クリスト５を調べた結果、プログラム「Ｂ」の処理も追
加されていたとすると、ディスパッチスレッド７はプロ
グラム「Ｂ」の処理も実行され、コールバックリスト５
から削除される。その後には、処理は追加されていない
ので、ディスパッチスレッド７は排他オブジェクト１０
にロック解放通知を送信し（ステップＢ７）、再びステ
ップＢ１に戻る。ここで、プログラム「Ｂ」の処理が追
加されたときの処理追加通知が届いているが、コールバ
ックリスト５には何も処理がないので（ステップＢ
２）、再びステップＢ１に戻る。
【００２８】最後に、図４のフローチャートに示す排他
オブジェクト１０での処理であるが、まず、プログラム
「Ａ」の処理が追加されたことにより、ディスパッチス
レッド７から送信されるロック取得要求を排他オブジェ
クト１０が受信する（ステップＣ１）。排他オブジェク
ト１０が受信したのは、ディスパッチスレッド７から送
信されるロック取得要求であるので（ステップＣ２）、
待ちＡＰリスト１１にアプリケーション１を登録する
（ステップＣ３）。
オブジェクト１０での処理であるが、まず、プログラム
「Ａ」の処理が追加されたことにより、ディスパッチス
レッド７から送信されるロック取得要求を排他オブジェ
クト１０が受信する（ステップＣ１）。排他オブジェク
ト１０が受信したのは、ディスパッチスレッド７から送
信されるロック取得要求であるので（ステップＣ２）、
待ちＡＰリスト１１にアプリケーション１を登録する
（ステップＣ３）。
【００２９】次に、排他オブジェクト１０は、状態フラ
グ１２を調べ、ロックされていない状態であるため（ス
テップＣ４）、待ちＡＰリスト１１をチェックし（ステ
ップＣ５）、アプリケーション１が追加されているの
で、排他オブジェクト１０からアプリケーション１にロ
ック取得応答を送信する（ステップＣ６）。これと同時
に、排他オブジェクト１０は、待ちＡＰリスト１１から
アプリケーション１を削除し、状態フラグ１２をロック
状態としておく。その後、排他オブジェクト１０は、ス
テップＣ１でディスパッチスレッド７から送信されたロ
ック解放通知を受信し、ステップＣ４からステップＣ５
に処理が移り、待ちＡＰリスト１１には要素はないの
で、状態フラグ１２をロックされていない状態にしてス
テップＣ１の処理に戻る。
グ１２を調べ、ロックされていない状態であるため（ス
テップＣ４）、待ちＡＰリスト１１をチェックし（ステ
ップＣ５）、アプリケーション１が追加されているの
で、排他オブジェクト１０からアプリケーション１にロ
ック取得応答を送信する（ステップＣ６）。これと同時
に、排他オブジェクト１０は、待ちＡＰリスト１１から
アプリケーション１を削除し、状態フラグ１２をロック
状態としておく。その後、排他オブジェクト１０は、ス
テップＣ１でディスパッチスレッド７から送信されたロ
ック解放通知を受信し、ステップＣ４からステップＣ５
に処理が移り、待ちＡＰリスト１１には要素はないの
で、状態フラグ１２をロックされていない状態にしてス
テップＣ１の処理に戻る。
【００３０】
【発明の効果】以上のように、この発明によれば、アプ
リケーションに通常の処理を行うメインスレッドとは別
に共有リソースへの処理を行うディスパッチスレッドを
用意し、これらが個々に動作できるようにしたので、共
有リソースへの処理を行うためにロック待ちをしている
際も、他の処理は影響を受けず実行できる。また、アプ
リケーションにコールバックリストを用意して、共有リ
ソースへの処理が発生する度にロックを取得するのでは
なく、複数の処理でも一回のロック取得で済むようにし
たので、排他制御に必要な通信を削減できる。
リケーションに通常の処理を行うメインスレッドとは別
に共有リソースへの処理を行うディスパッチスレッドを
用意し、これらが個々に動作できるようにしたので、共
有リソースへの処理を行うためにロック待ちをしている
際も、他の処理は影響を受けず実行できる。また、アプ
リケーションにコールバックリストを用意して、共有リ
ソースへの処理が発生する度にロックを取得するのでは
なく、複数の処理でも一回のロック取得で済むようにし
たので、排他制御に必要な通信を削減できる。
【図１】この発明による分散オブジェクト環境における
排他制御方式の第１実施の形態の構成を示すブロック図
である。
排他制御方式の第１実施の形態の構成を示すブロック図
である。
【図２】この発明による分散オブジェクト環境における
排他制御方式の第１実施の形態の動作を説明するための
アプリケーションのメインスレッドの処理手順を示すフ
ローチャートである。
排他制御方式の第１実施の形態の動作を説明するための
アプリケーションのメインスレッドの処理手順を示すフ
ローチャートである。
【図３】この発明による分散オブジェクト環境における
排他制御方式の第１実施の形態の動作を説明するための
ディスパッチスレッドの処理手順を示すフローチャート
である。
排他制御方式の第１実施の形態の動作を説明するための
ディスパッチスレッドの処理手順を示すフローチャート
である。
【図４】この発明による分散オブジェクト環境における
排他制御方式の第１実施の形態の動作を説明するための
排他オブジェクトの処理手順を示すフローチャートであ
る。
排他制御方式の第１実施の形態の動作を説明するための
排他オブジェクトの処理手順を示すフローチャートであ
る。
１，２……アプリケーション、３，４……メインスレッ
ド、５，６……コールドバックリスト、７、８ディスパ
ッチスレッド、９……共有リソース、１０……排他オブ
ジェクト、１１……待ちＡＰリスト（待ちアプリケーシ
ョンリスト）、１２……状態フラグ。
ド、５，６……コールドバックリスト、７、８ディスパ
ッチスレッド、９……共有リソース、１０……排他オブ
ジェクト、１１……待ちＡＰリスト（待ちアプリケーシ
ョンリスト）、１２……状態フラグ。
Claims (10)
- 【請求項１】 それぞれメインスレッドでプログラムタ
スクを行い、共有リソースにアクセスし、かつ上記共有
リソースに対しての処理要求を行う際に、この処理をコ
ールバックリストに登録されている処理が存在する場合
には、コールバックリストに登録し、ディスパッチスレ
ッドからロック取得要求を行う複数のアプリケーション
と、 上記各アプリケーションの上記ディスパッチスレッドか
らのロック取得要求が出されるまで現在ロック待ちのア
プリケーションを格納するとともに、現在上記アプリケ
ーションの上記ディスパッチスレッドから出された要求
に対するロック取得が行われているか、否かの状態を格
納する排他オブジェクトと、 を備えることを特徴とする分散オブジェクト環境におけ
る排他制御方式。 - 【請求項２】 上記排他オブジェクトは、上記各アプリ
ケーションの上記ディスパッチスレッドからのロック取
得要求が出されるまで現在ロック待ちのアプリケーショ
ンを格納する待ちアプリケーションリストと、 上記アプリケーションの上記ディスパッチスレッドから
出された要求に対するロック取得が行われているか、否
かの状態を格納する状態フラグと、 を備えることを特徴とする請求項1記載の分散オブジェ
クト環境における排他制御方式。 - 【請求項３】 上記メインスレッドは、次に実行する処
理が上記共有リソースへのアクセスであると判断した場
合に上記コールバックリストにこの処理を登録し、かつ
上記ディスパッチスレッドに処理追加通知を送信するこ
とを特徴とする請求項1記載の分散オブジェクト環境に
おける排他制御方式。 - 【請求項４】 上記メインスレッドは、次に実行する処
理が上記共有リソースへのアクセスでないと判断した場
合にその処理を実行することを特徴とする請求項1記載
の分散オブジェクト環境における排他制御方式。 - 【請求項５】 上記ディスパッチスレッドは、上記処理
追加通知を上記メインスレッドから受信すると、上記コ
ールバックリストに処理が登録されていると判断した場
合には上記排他オブジェクトに対してロックを取得する
ためのロック取得要求を送信することを特徴とする請求
項1記載の分散オブジェクト環境における排他制御方
式。 - 【請求項６】 上記ディスパッチスレッドは、上記処理
追加通知を上記メインスレッドから受信すると、上記コ
ールバックリストに処理が登録されていないと判断した
場合には、上記排他オブジェクトに対してロック解放通
知を送信して上記メインスレッドから再度処理追加通知
の送信を待機することを特徴とする請求項1記載の分散
オブジェクト環境における排他制御方式。 - 【請求項７】 上記ディスパッチスレッドは、上記コー
ルバックリストに処理があると判断した場合には、上記
共有リソースに対して上記コールバックリストに登録さ
れた処理を実行し、その処理をコールバックリストから
削除することを特徴とする請求項1記載の分散オブジェ
クト環境における排他制御方式。 - 【請求項８】 上記ディスパッチスレッドは、上記コー
ルバックリストに処理が存在しないと判断した場合に
は、上記排他オブジェクトのロックを解放することを通
知するロック解放通知を送信することを特徴とする請求
項1記載の分散オブジェクト環境における排他制御方
式。 - 【請求項９】 上記排他オブジェクトは、上記ディスパ
ッチスレッドからロック取得要求の受信時に待ちアプリ
ケーションリストにロック取得要求を送信したアプリケ
ーションを登録することを特徴とする請求項1記載の分
散オブジェクト環境における排他制御方式。 - 【請求項１０】 上記排他オブジェクトは、状態フラグ
よりロック状態でないと判断し場合、あるいは上記ディ
スパッチスレッドからロック解放通知を受信した場合に
おいて、待ちアプリケーションリストにロック待ちをし
ているアプリケーションが存在していると判断した場合
に待ちアプリケーションリストの先頭のアプリケーショ
ンに対してロック取得応答を送信してそのアプリケーシ
ョンを待ちアプリケーションリストから削除することを
特徴とする請求項1記載の分散オブジェクト環境におけ
る排他制御方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06692799A JP3544140B2 (ja) | 1999-03-12 | 1999-03-12 | 分散オブジェクト環境における排他制御方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06692799A JP3544140B2 (ja) | 1999-03-12 | 1999-03-12 | 分散オブジェクト環境における排他制御方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000259436A true JP2000259436A (ja) | 2000-09-22 |
| JP3544140B2 JP3544140B2 (ja) | 2004-07-21 |
Family
ID=13330117
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06692799A Expired - Fee Related JP3544140B2 (ja) | 1999-03-12 | 1999-03-12 | 分散オブジェクト環境における排他制御方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3544140B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2414830A (en) * | 2004-06-04 | 2005-12-07 | Sun Microsystems Inc | Method for accessing a shared resource by the thread requesting the lock making the operations of a second thread visible in the correct order |
| CN111897646A (zh) * | 2020-08-13 | 2020-11-06 | 银联商务股份有限公司 | 异步分布式锁实现方法及其装置、存储介质以及电子设备 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5635760B2 (ja) | 2009-10-16 | 2014-12-03 | キヤノン株式会社 | 情報処理システム、情報処理方法、およびコンピュータプログラム |
-
1999
- 1999-03-12 JP JP06692799A patent/JP3544140B2/ja not_active Expired - Fee Related
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2414830A (en) * | 2004-06-04 | 2005-12-07 | Sun Microsystems Inc | Method for accessing a shared resource by the thread requesting the lock making the operations of a second thread visible in the correct order |
| GB2414830B (en) * | 2004-06-04 | 2008-10-15 | Sun Microsystems Inc | Techniques for accessing a shared resource using an improved synchronization mechanism |
| US7644409B2 (en) | 2004-06-04 | 2010-01-05 | Sun Microsystems, Inc. | Techniques for accessing a shared resource using an improved synchronization mechanism |
| CN111897646A (zh) * | 2020-08-13 | 2020-11-06 | 银联商务股份有限公司 | 异步分布式锁实现方法及其装置、存储介质以及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3544140B2 (ja) | 2004-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8181183B2 (en) | Method, system and program products for managing thread pools of a computing environment to avoid deadlock situations | |
| US6412034B1 (en) | Transaction-based locking approach | |
| US7500037B2 (en) | System, method and program for managing locks | |
| US7065765B2 (en) | Serializing event handling in a threaded system with no wait states | |
| US7281050B2 (en) | Distributed token manager with transactional properties | |
| JP5516398B2 (ja) | マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法 | |
| US20040002974A1 (en) | Thread based lock manager | |
| US7386864B2 (en) | Automatic serialization for event driven multi-threaded programs in an object structured system | |
| US8499298B2 (en) | Multiprocessing transaction recovery manager | |
| JPH1165863A (ja) | 共有資源管理方法 | |
| US9164799B2 (en) | Multiprocessor system | |
| US7844782B2 (en) | Data processing system with memory access | |
| JPH04271453A (ja) | 複合電子計算機 | |
| CN112749020A (zh) | 一种物联网操作系统的微内核优化方法 | |
| US20070285993A1 (en) | Systems and methods for common instance handling of providers in a plurality of frameworks | |
| CN119487493A (zh) | 进程间通信的同步机制 | |
| US20040059563A1 (en) | Emulatd atomic instruction sequences in a multiprocessor system | |
| US7765548B2 (en) | System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock | |
| JP2000259436A (ja) | 分散オブジェクト環境における排他制御方式 | |
| JP7054688B2 (ja) | 同期制御システムおよび同期制御方法 | |
| CN113448710A (zh) | 基于业务资源的分布式应用系统 | |
| JP2008544371A (ja) | ロック関連の一貫性欠如を処理する方法 | |
| JPS6320634A (ja) | 計算機資源排他制御方式 | |
| JP2010026575A (ja) | スケジューリング方法およびスケジューリング装置並びにマルチプロセッサシステム | |
| JPH09330241A (ja) | デッドロック防止排他制御方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20031210 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040206 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040318 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040331 |
|
| 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: 20080416 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |