JP3697148B2

JP3697148B2 - 分散コンピュータ環境において、複数のマルチスレッド化プロセスに渡ってコミュニケータを設定する方法およびシステム

Info

Publication number: JP3697148B2
Application number: JP2000283872A
Authority: JP
Inventors: ロバート・ブラックモア; リチャード・アール・トリューマン; アリスン・ビー・ホワイト
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-09-23
Filing date: 2000-09-19
Publication date: 2005-09-21
Anticipated expiration: 2020-09-19
Also published as: KR100390611B1; US6782537B1; CN1133925C; CN1289962A; KR20010050426A; JP2001142726A

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータシステムにおける共用リソースの管理機能に関し、特に、例えば、メッセージ伝達インターフェース（ｍｅｓｓａｇｅｐａｓｓｉｎｇｉｎｔｅｒｆａｃｅ；ＭＰＩ）ライブラリ内部での実行のための、スレッド−セーフ分散コンセンサス技術に関する。
【０００２】
【従来の技術】
本発明の背景のより良い理解のために、特定の用語の説明を最初に行う。対称型マルチプロセッサ（ＳＭＰ）として、技術上よく知られている用語は、コンピュータ・システムにおけるハードウェアの態様に関し、特に、プロセッサ・プレーナー自身の物理的なレイアウトおよびデザインに関する。このような複数のプロセッサ・ユニットは、一つの特徴として、グローバルメモリの共用と、ＳＭＰシステムの入出力（Ｉ／Ｏ）への等しいアクセスとを有する。
【０００３】
現在の計算システムに一般的に関連する他の用語は、“スレッド”である。“スレッド”という用語は、一般的な意味において、コンピュータで実行されるアプリケーションソフトウェアおよびオペレーティング・システムのカーネルにおける単純な実行パスを意味する。技術上よく理解されているように、単一のプロセス・イメージ当たり、複数のこのようなスレッドが許容されることは、普通のことである。
【０００４】
現在、スレッド規格は、ＰＯＳＩＸ規格に組み入れられている。ＰＯＳＩＸ規格の下での、基本的なスレッド・マネージメントについては、例えば、Ｋ．ＲｏｂｂｉｎｓａｎｄＳ．Ｒｏｂｂｉｎｓによる刊行物「ＰｒａｃｔｉｃａｌＵＮＩＸＰｒｏｇｒａｍｉｎｇ − ＡＧｕｉｄｅｔｏＣｏｎｃｕｒｒｅｎｃｙ，ＣｏｍｍｕｎｉｃａｔｉｏｎａｎｄＭｕｌｔｉ − Ｔｈｒｅａｄｉｎｇ，ＰｒｅｎｔｉｃｅＨａｌｌＰＴＲ（１９９６）」に述べられている。
【０００５】
発明の実施の形態を説明する際に利用される他のコンセプトは、“ロック”である。コードのクリティカル・セクション、あるいは、共用ライブラリのような、共用データ構造を有することは、現在のコンピュータ・システムにおいて典型的であり、これらの保全性は、システムの正しいオペレーションにとって極めて重要である。ロックは、一般的に、これらコードのクリティカル・セクションや共用データ構造へのアクセスを“直列化する”ために、ソフトウェア（あるいはハードウェア）において利用されるデバイスである。
【０００６】
注意すべきもう一つの用語は、マルチスレッド−セーフであるコードのコンセプトである。全てのスレッドに対してデータ保全性が確保されるように、同じリソースまたはルーチンを争っている複数の実行スレッドが直列化される場合に、コードは、スレッド／ＭＰ−セーフであると判断される。これをもたらす一つの方法は、前述のロックによる。
【０００７】
更なる背景として、メッセージ伝達インターフェース（ＭＰＩ）規格は、以下のセマンティクスを定義する。すなわち、パラレル・ジョブにおけるプロセスは、コミュニケーション・ドメイン（ここでは、“コミュニケータ”とも称される）内でメッセージを交換する。コミュニケーション・ドメインは、そのコミュニケーション・ドメイン内のメッセージの保全性を保証する。あるドメインにおいて発行されたメッセージは、他のドメインにおいて発行されたメッセージと干渉しない。パラレル・ジョブが開始すると、プロセスのサブセットは、必要に応じて、別個のコミュニケーション・ドメインを作るために協働することができる。
【０００８】
【発明が解決しようとする課題】
しかしながら、本発明者は、複数のスレッドが、同時にコミュニケーション・ドメインを得ようと試みることのできるマルチスレッド環境において、問題が発生することを認識している。この問題を処理する方法がない場合には、デッドロックが起こることとなる。したがって、マルチスレッド化処理システムにおいて、分散コンセンサスを実現するためには、非デッドロッキング技術が必要とされる。本発明は、この要求に答える一つの技術として提供される。
【０００９】
【課題を解決するための手段】
本発明の一態様においては、複数のスレッドが同時にコミュニケータを設定しようと試みることのできる分散コンピュータ環境において、複数のプロセスに渡ってコミュニケータを設定する方法であって、（ｉ）複数のプロセス上の一群の関与スレッドについてコミュニケータを設定するための一の候補コンテキスト識別子を設定するために、複数のプロセスに渡ってコミュニケーションするステップと、（ｉｉ）複数のプロセスのそれぞれの関与スレッドで、候補コンテキスト識別子がそれぞれの関与スレッドのプロセスで依然として使用可能であるか否かを確認することを通して、候補コンテキスト識別子を、それぞれの関与スレッドのプロセスで請求できるか否かをチェックし、候補コンテキスト識別子を複数のプロセスの全てのプロセスで請求できる場合には、候補コンテキスト識別子を新しい識別子として請求し、これによってコミュニケータを設定するために、複数のプロセスに渡ってコミュニケーションするステップとを含む方法を提供する。
【００１０】
本発明の他の態様においては、複数のスレッドが同時にコミュニケータを設定しようと試みることのできる分散コンピュータ環境において、複数のマルチスレッド化プロセスに渡ってコミュニケータを設定するシステムであって、（ｉ）複数のプロセス上の一群の関与スレッドについてコミュニケータを設定するための一の候補コンテキスト識別子を設定するために、複数のプロセスに渡ってコミュニケーションする手段と、（ｉｉ）複数のプロセスのそれぞれの関与スレッドで、候補コンテキスト識別子がそれぞれの関与スレッドのプロセスで依然として使用可能であるか否かを確認することを通して、候補コンテキスト識別子を、それぞれの関与スレッドのプロセスで請求できるか否かをチェックし、候補コンテキスト識別子を複数のプロセスの全てのプロセスで請求できる場合には、候補コンテキスト識別子を新しいコンテキスト識別子として請求し、これによってコミュニケータを設定するために、複数のプロセスに渡ってコミュニケーションする手段とを備えるシステムを提供する。
【００１２】
言い換えれば、ここでは、マルチスレッド化マルチプロセス・コンピュータ環境において、分散コンセンサスを実現するための技術を提供する。本技術は、決定論的である。というのは、スレッドが、制限された再試行の回数および予測可能な順序で、コミュニケータの作成に成功するからである。このため、本技術は、コミュニケータの作成に失敗したスレッドが、再試行の前にランダムな量の時間の間単に待機するのみである、いわゆる“ランダム化”アルゴリズムに対して優位であると思われる。加えて、本技術は、スレッド間のデッドロックを回避することを保証する。このため、本技術は、デッドロックの状態を検出して、デッドロックを解除させる他のアルゴリズムに対して優位である。デッドロックの検出は、スレッドが進行しないある時間が経過したことを検知することを典型的に含む。本技術の分散コンセンサス機能は、効率的である。というのは、同時にコミュニケータを作成しようとする複数のグループのスレッドの存在にもかかわらず、新しいコミュニケーション・ドメインに対する分散コンセンサスを実現するために、スレッドが再試行させられる回数に、上限が存在するからである。
【００１３】
【発明の実施の形態】
本発明の機能を組み込み、そして利用するスレッド化コンピュータ環境の一実施形態を、図１を参照して以下に説明する。
【００１４】
図１に示されるように、コンピュータ環境１００は、コネクション１０４によって、相互接続された複数の演算ノード１０２を有する。一例として、それぞれの演算ノードは、ＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎによって提供されるＲＳ／６０００ＳＰシステムのノードで構成することができる。コネクション１０４は、同様にＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎによって提供される、例えばＳＰスイッチ、あるいはハイパフォーマンス・スイッチ（ＨＰＳ）のような、パケット交換ネットワークとすることができる。再度言及しておくが、図１は、あくまで一例として示されたものである。ここで開示される技術は、図１に示したマルチプロセッサ環境に加えて、単一のマシン上で実行される、シングルスレッド化プログラムまたはマルチスレッド化プログラムの組に適用可能である。
【００１５】
コンピュータ環境１００内において、メッセージ・パケットは、パケット交換ネットワーク１０４を経て、ソース演算ノード（送信側）からレシーバ演算ノード（受信側）へ渡される。例えば、演算ユニットＮのユーザ・タスク１０６は、演算ユニット１（受信側）のユーザ・タスク１０６へ、メッセージを渡すことができる。アダプタ１１２は、演算ユニット１０２をスイッチ１０４に接続する。スイッチ１０４の一例は、「ＩＢＭＰａｒａｌｌｅｌＳｙｓｔｅｍＳｕｐｐｏｒｔＰｒｏｇｒａｍｓＦｏｒＡＩＸＡｄｍｉｎｉｓｔｒａｔｉｏｎＧｕｉｄｅ」ＰｕｂｌｉｃａｔｉｏｎＮｏ．ＧＣ２３−３８９７−０２（１９９６）に詳細に述べられている。
【００１６】
更なる説明として、演算ユニットとその演算ユニットと関連したアダプタ１１２との間のコミュニケーションは、例えば、コミュニケーション開始、コミュニケーション終了、ルート有効化、ルート無効化、ステータス戻し、およびアダプタ・リセットのような機能を含むインターフェースによって記述される。一つの実施形態において、インターフェースは、ここではＭＰＩライブラリとも称される、メッセージ伝達インターフェース（ＭＰＩ）１１０より構成される。
【００１７】
それぞれの演算ユニット１０２内で、アダプタへのアクセスは、カーネル・エクステンション／デバイス・ドライバ１０８によって管理される。エクステンション１０８は、一組の機能を含む。この一組の機能は、オペレーティング・システム自身（例えば、ＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎによって提供されるＡＩＸオペレーティング・システム）の権限を有する。カーネル・エクステンションは、ユーザ・タスク１０６（もしくはプログラム）によるアダプタ１１２の使用を許可する。そして、要求される場合には、ユーザ・タスクへの割り込みを行う機能を有する。ユーザ・タスク１０６は、ＭＰＩライブラリ１１０を通じてアダプタ１１２とコミュニケーションする。ＭＰＩライブラリは、例えば、ＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎの刊行物「ＩＢＭＰａｒａｌｌｅｌＥｎｖｉｒｏｎｍｅｎｔｆｏｒＡＩＸ：ＭＰＩＰｒｏｇｒａｍｍｉｎｇａｎｄＳｕｂｒｏｕｔｉｎｅＲｅｆｅｒｅｎｃｅ」Ｖｅｒｓｉｏｎ２，Ｒｅｌｅａｓｅ４（Ｏｃｔｏｂｅｒ，１９９８）にさらに詳細に述べられている。
【００１８】
ＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎのＭＰＩライブラリの実装は、他の様々な刊行物の中で、詳細に述べられている。例えば、ＩＢＭＳｙｓｔｅｍＪｏｕｒｎａｌ表題「ＴｈｅＣｏｍｍｕｎｉｃａｔｉｏｎＳｏｆｔｗａｒｅＩｎＰａｒａｌｌｅｌＥｎｖｉｒｏｎｍｅｎｔＯｆＴｈｅＩＢＭＳＰ２」Ｖｏｌ．３４，Ｎｏ．２，ｐｐ．２０５−２１５（１９９５）に掲載された論文を参照されたい。更なる情報が、Ｗ．ＲｉｃｈａｒｄＳｔｅｖｅｎｓ著の教本、「ＵＮＩＸＮｅｔｗｏｒｋＰｒｏｇｒａｍｍｉｎｇ」ＰｒｅｎｔｉｃｅＨａｌｌ，Ｉｎｃ発行（１９９０）において得られる。
【００１９】
既に言及したように、ここでは、コンピュータ環境は、ユーザ・タスクが複数のスレッドを含むことができるようなスレッド化コンピュータ環境で構成され、および、ライブラリがスレッド化ＭＰＩであると仮定する。スレッド化コンピュータ環境は、今日、産業上周知である。スレッド化ＭＰＩライブラリは、例えば、「ＩＢＭＰａｒａｌｌｅｌＥｎｖｉｒｏｎｍｅｎｔｆｏｒＡＩＸ」Ｖｅｒｓｉｏｎ２，Ｒｅｌｅａｓｅ４，ＩＢＭＰｒｏｄｕｃｔＮｏ．５７６５−５４３（Ｏｃｔｏｂｅｒ１９９８）のようにＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓＭａｃｈｉｎｅｓＣｏｒｐｏｒａｔｉｏｎから入手できる。このスレッド化ＭＰＩは、ＡＩＸシステム上で実行されるライセンス・プログラム製品で構成される。
【００２０】
本発明の一つの詳細な実施態様について論ずる前に、背景として以下の定義を与える。
【００２１】
“パラレル・ジョブ”とは、一群のプロセッサ上で実行される一組のタスクである。これらのタスクは、協働し、およびデータを交換して、共同で問題を解決する。
【００２２】
“タスク”もしくは“プロセス”は、アドレス空間および一つ以上の制御フローを含む実行プログラム（命令のシーケンス）の一例である。“アドレス空間”は、タスクが参照する、あるいはアクセスするメモリ・ロケーションの組である。
【００２３】
“スレッド”とは、タスク内の制御フローである。ほとんどのシステムは、今日、単一タスク内の複数の制御フローをサポートする。複数のスレッドは、同時に実行可能である。
【００２４】
“ＭＰＩコミュニケータ”とは、一群のコミュニケーション・タスクから成る論理エンティティである。一例として、コミュニケータには、コンテキストＩＤと呼ばれる識別子が付与される。
【００２５】
“コンテキストＩＤ”もしくは“コンテキスト識別子”とは、特定のＭＰＩコミュニケータを構成する複数のタスクに渡って同一であるが、他のコミュニケータとは区別される固有の数値である。
【００２６】
“コミュニケーション・ドメイン”とは、コミュニケータを構成する複数のタスクがメッセージを交換するコンテキストである。コミュニケーション・ドメインは、ドメイン内の送信メッセージが、ドメイン外のタスク（すなわち、異なるコミュニケータでは）へ送られることはないという点で、“島”の特性を有している。コミュニケーション・ドメインとコミュニケータは、ここでは、同様な意味で使用される。
【００２７】
“縮約”オペレーションとは、一組の値に対して実行されるオペレーション（例えば，ＳＵＭ，ＢＩＴＷＩＳＥＡＮＤ）であり、その各値は、パラレル・ジョブにおける一組のコミュニケーション・タスクのそれぞれのメンバーによって与えられる。オペレーションの結果は、単一のプロセス（縮約オペレーション）で、あるいは、全ての関与しているプロセス（全縮約オペレーション）に戻すことができる。
【００２８】
複数のコミュニケーション・ドメインの分離を管理するために、例えばＭＰＩライブラリが、それぞれのコミュニケーション・ドメインを、ドメイン内のジョブ・プロセスによって同意された固有の“コンテキストＩＤ”と関連づける。ＭＰＩライブラリ・ルーチン（その目的は、新しいコミュニケーション・ドメインを作成することである）は、パラレル・ジョブのプロセスのサブセット（すなわちスレッド）によってコールされ得る。このライブラリ・ルーチンは、共通のコンテキストＩＤを識別および請求することによって、新しいドメインを形成しなければならない。このコンテキストＩＤは、ドメイン内の全てのプロセスに渡って固有のものであり、サブセット内の全てのプロセスで使用可能である。新しいコミュニケーション・ドメインを作成するためのコールは、いくつかのグループのスレッドによって同時に行われ得る。それらは、同じプロセス内のものであってもよく、異なるプロセス内のものであってもよい。
【００２９】
図２は、３つのプロセス２００，２０２，２０４（プロセス１、プロセス２およびプロセス３）上のそれぞれのスレッド１が、コミュニケータＡを作成するためにＭＰＩライブラリをコールし、プロセス２００およびプロセス２０２上のスレッド２が、コミュニケータＢを作成するためにＭＰＩライブラリをコールし、プロセス２０２およびプロセス２０４上のスレッド３が、コミュニケータＣを作成するためにＭＰＩライブラリをコールする、というシナリオを示す。どのプロセスにおいても、コールは任意の順序で発生可能である。ＭＰＩセマンティックは、全てのスレッドが進行すること、およびそれぞれのライブラリ・コールが最終的には戻ることを要求する。
【００３０】
問題は、使用可能なＩＤのうちの一つを、同時に獲得しようと試みることのできる、複数のグループのスレッドの存在下で、それぞれの新しいコミュニケーション・ドメインに対して、固有のコンテキストＩＤを選択することである。例えば、コンテキストＩＤリストのような、グローバル・データへのアクセスは、マルチスレッド化ライブラリにおいて、直列化されなければならない。しかしながら、ジョブがデッドロックし得るので、共通のコンテキストＩＤを識別するためにプロセスに必要とされるコミュニケーション・フェーズの際に、どのスレッドもロックを保持することができない。
【００３１】
したがって、一般的に言えば、ここでは、マルチスレッド化コンピュータ環境において、複数のプロセスに渡ってコミュニケータを設定しながら、デッドロックを避ける方法が提供される。この環境では、複数のスレッドは、同時にコミュニケータを設定しようと試みることができる。コミュニケータは、当該コミュニケータを設定しようと試みている複数のスレッドが、関与スレッドを含む複数のプロセスに渡って固有である値（コンテキストＩＤ）について同意した時に、設定されるものと見なされる。
【００３２】
本方法は、２つのフェーズを用いる。フェーズ１においては、候補コンテキストＩＤ（ここでは、候補識別子とも称される）が、コミュニケータを作成しようと試みている複数のスレッド間に設定される。フェーズ２において、それぞれの関与スレッドは、候補コンテキストＩＤがそのプロセスにおいて請求可能か否かをチェックする。請求可能な場合には、そのコンテキストＩＤを請求することを試み、このオペレーションの結果を他の関与スレッドへ報告する。デッドロックを避けるため、コミュニケータを設定しようと試みているプロセスのスレッドは、それぞれのプロセスにおける優先キューに挿入される。この優先キューは、当該プロセス内にあるどのスレッドが、コンテキストを請求する権利を有するか否かを制御する。これらのスレッドは、一つの例として、スレッドが、そこから新しいコミュニケータを呼び出している現行のコンテキスト識別子に基づいて、優先順位付けされる。いずれかのスレッドが、フェーズ２の際の失敗を報告する場合には、本方法は、フェーズ１に戻って、新しい候補コンテキストＩＤの選択を再び開始する。
【００３３】
特に、本発明に従えば、ＭＰＩライブラリは、パラレル・ジョブ内のそれぞれのプロセスにおいて、使用可能なコンテキストＩＤのリスト（ここでは、“グローバル・コンテキスト・リストとも称される）を保持する。これらのコンテキストＩＤは、スカラーである。このコンテキストＩＤリストは、プロセスに対してグローバルである。そして、コンテキストＩＤリストへのスレッド・アクセスは、ロックによって直列化される。ＭＰＩジョブが開始されるとき、全ての関与しているプロセスは、シングル・スレッド化されており、例えば、最小のコンテキストＩＤが割り当てられている単一のコミュニケーション・ドメインに属する。初期化の後、いずれかのスレッドの組内にあり、かつ、新しいコミュニケーション・ドメインを作成するためにＭＰＩライブラリをコールするそれぞれのスレッドは、既存のドメインのコンテキストにおいて、これを行う。本発明の一つの態様において、この既存のドメインのコンテキスト識別子は、以下において詳細に述べられるように、新しいコンテキストＩＤの割当に優先順位付けを行うために使用される。
【００３４】
所与のコンテキストＩＤのもとで新しいコミュニケーション・ドメインに対する要求が既に発行されている場合、これらのコンテキストＩＤは、ソートされたリスト（“優先リスト”）内に置かれる。このリストは、プロセスに対してグローバルであり、ロックのもとでアクセスされる。最小のコンテキストＩＤのもとで要求を行ったスレッドは、優先リストの中で第１位となる。したがって、そのスレッドは、そのプロセスで、グローバル・コンテキスト・リストを更新することができるスレッドとなる。
【００３５】
最後のコンテキストＩＤ（ここでは、新コンテキストＩＤとも称される）に関するコンセンサスは、最低限２ラウンドのコミュニケーションを必要とする。コミュニケーションの第１ラウンドは、候補コンテキストＩＤ（候補識別子）を作成し、現行のドメイン内の全てのプロセスが、サブルーチン・コールに関与していることを保証する（すなわち、コールは、いくつかのプロセス上で遅れるか、または、ブロックされる可能性がある）。全てのプロセスが関与していることが分かると、それぞれのスレッドは、そのスレッドのプロセスの優先リスト（ここでは、優先キューとも称される）に自身の現行コンテキストＩＤを挿入する。どのプロセスにおいても、コミュニケーションの第１ラウンドの際に、ロックが解放されている間は、候補コンテキストＩＤは、別のスレッドによって請求され得る。よって、次のステップは、候補コンテキストＩＤが、関与している全てのプロセスで請求できるか否かチェックすることであり、請求できる場合に、コンセンサスが実現できる。候補識別子が、依然として使用可能であり、かつ、スレッドが、優先リストにおいて第１位（すなわち優先権を有する）である場合には、そのスレッドは、グローバル・コンテキスト・リストから候補識別子を更新（すなわち、削除）し、このようにして、新しい識別子として候補識別子を“請求する”。スレッドが、優先リストの第１位でない場合には、スレッドは、ロックを解放し、待機する。コミュニケーションの第２ラウンドが進行し、候補識別子が、あるプロセスで請求され得ないことを示す場合には、自身のプロセスのグローバル・コンテキスト識別子リストを更新したスレッドは、その更新をバックアウトする（すなわち、前に削除された候補識別子をリスト内へ加え戻す）。候補識別子が全てのプロセスにおいて請求された場合には、成功したスレッドは、自身の現行コンテキスト識別子を優先リストから削除し、待機している全てのスレッドをウェイクアップする。
【００３６】
優先キュー内で最高の優先順位を有さない故に待機しているスレッドは、候補識別子が依然として使用可能であるか否かを確かめるために、グローバル・コンテキスト識別子リストがチェックされるポイントで処理を再開する。関与スレッドが、自身の個々のプロセスで候補識別子を請求することができなかった故に、コンセンサスに失敗したスレッドは、コミュニケーションの第１ラウンドで、新しい候補識別子の選択を続ける。
【００３７】
図３および図４は、本発明の原理に従って、マルチスレッド化コンピュータ環境において、複数のプロセスに渡ってコミュニケータを設定する決定論的な方法の、さらに詳細な実施の態様を示す。これと同じ制御フロー（図３，図４）は、計算ドメイン内の全てのプロセス上で実行される。ローカルｃｏｎｔｅｘｔ＿ｌｉｓｔは、ローカル・プロセス上で使用可能なフリー・コンテキスト識別子のリストである。ｆｉｎｄ＿ｃａｎｄｉｄａｔｅ＿ｃｏｎｔｅｘｔ（ｔｅｍｐ＿ｌｉｓｔ）機能は、全てのプロセス上で使用可能なコンテキストＩＤを検索する。ｕｐｄａｔｅ＿ｒｅｓｕｌｔｓ（値）機能は、全てのプロセス上で値が真の場合には、ＴＲＵＥ（真）を戻し、そうでない場合には、ＦＡＬＳＥ（偽）が戻される。２つのスレッドが同時に、新しいコンテキスト識別子を得ようと試みる場合には、一方のスレッドが、待機状態で終了することとなる。
【００３８】
図３を参照すると、処理は、そこから新しいコミュニケータに対してコールが行われる現行コミュニケータのコンテキスト識別子であるｃｕｒｒｅｎｔ＿ｃｏｎｔｅｘｔを入力として受け取る（ステップ３００）。次に、ロックが獲得され、ｎｅｗ＿ｃｏｎｔｅｘｔ＿ｃｏｍｍｉｔフラグがＦＡＬＳＥにセットされ、ｃｕｒｒｅｎｔ＿ｃｏｎｔｅｘｔ識別子が、ｇｅｔ＿ｃｏｎｔｅｘｔキュー（すなわち優先キュー）へ加えられる（ステップ３１０）。
【００３９】
処理は、次に、ｎｅｗ＿ｃｏｎｔｅｘｔ＿ｃｏｍｍｉｔフラグがＴＲＵＥか否かを問い合わせ（ステップ３２０）、ＴＲＵＥである場合には、ロックを解放し、候補識別子を、新コンテキスト識別子として戻し、これにより、コミュニケータを設定し、処理を終了する（ステップ３３０）。ｎｅｗ＿ｃｏｎｔｅｘｔ＿ｃｏｍｍｉｔフラグがＴＲＵＥでない場合には、有効コンテキストＩＤのリスト（ｔｅｍｐ＿ｃｏｎｔｅｘｔ＿ｌｉｓｔ）が設定され、ロックが解放され、新コンテキスト識別子が検索され（ｆｉｎｄ＿ｃａｎｄｉｄａｔｅ＿ｃｏｎｔｅｘｔ（ｔｅｍｐ＿ｌｉｓｔ））、その後、ロックが再度獲得され、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥにセットされる（ステップ３４０）。ｆｉｎｄ＿ｃａｎｄｉｄａｔｅ＿ｃｏｎｔｅｘｔ（ｔｅｍｐ＿ｌｉｓｔ）はサブルーチンであり、このサブルーチンは、この特定のコミュニケータを経る全てのプロセス上で有効である新しいコンテキスト識別子を検索する、全縮約オペレーションを実行する。次に、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥか否かの問い合わせがなされる（ステップ３５０）。このフラグがＴＲＵＥでない場合には、処理は、ｎｅｗ＿ｃｏｎｔｅｘｔ＿ｃｏｍｍｉｔフラグがＴＲＵＥであるか否かの問い合わせ（ステップ３２０）へ戻る。ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥである場合には、ｎｅｗ＿ｃｏｎｔｅｘｔ（すなわち候補識別子）がローカル・コンテキスト・リスト（プロセスの使用可能なコンテキスト・リスト）内に存在するか否かの問い合わせがなされる（ステップ３６０）。ｎｅｗ＿ｃｏｎｔｅｘｔが、ローカル・コンテキスト・リスト内に存在しない場合には、ロックが解放され、ｕｐｄａｔｅ＿ｒｅｓｕｌｔｓルーチンがＦＡＬＳＥの値を戻し、ロックが再度獲得され、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＦＡＬＳＥにセットされる（ステップ３７０）。次に、処理は、図示されるように、問い合わせ（ステップ３５０）に戻る。
【００４０】
図４を参照すると、ｎｅｗ＿ｃｏｎｔｅｘｔが、ローカル・コンテキスト・リスト内に存在する場合には、処理は、スレッドが優先キュー内で優先権を有する（すなわち、ｇｅｔ＿ｃｏｎｔｅｘｔキュー内において第１位である）か否か問い合わせる（ステップ４００）。優先権を有さない場合には、ロックは解放され、スレッドはコンテキスト条件を待ち、その後にロックが再び獲得される（ステップ４４０）。コンテキスト条件待ちとは、キュー内でより高い優先順位を有するスレッドからの信号を待つことである。その後、処理は、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥであるか否かを確認するステップ（ステップ３５０）へ戻る（図３）。
【００４１】
スレッドが、ｇｅｔ＿ｃｏｎｔｅｘｔキュー内で優先権を有する場合には、処理は、プロセスの使用可能なコンテキスト識別子リストを更新し（すなわち、リストから候補コンテキストＩＤを削除し）、ロックを解放し、ｕｐｄａｔｅ＿ｒｅｓｕｌｔｓ（ＴＲＵＥ）信号をその他の関与スレッドへ送り、ロックを再度獲得し、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグをＦＡＬＳＥにセットする（ステップ４１０）。次に、処理は、ｕｐｄａｔｅ＿ｒｅｓｕｌｔｓが、全てのプロセス上でＴＲＵＥか否か問い合わせる（ステップ４２０）。この問い合わせは、全てのプロセスが、候補コンテキスト識別子を削除することにより、自身のローカル・コンテキスト識別子キューを首尾よく更新したか否かを判別する。首尾よく更新しなかった場合には、自身のローカル・コンテキスト識別子リストを更新したそれぞれのプロセスは、ローカル・コンテキスト・リストへの変更を取り消し（ステップ４３０）、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥであるか否かの問い合わせ（ステップ３５０）（図３）へ戻らなければならない。全てのプロセスが、自身の使用可能なコンテキスト識別子リストを更新した場合には、次に、ｃｕｒｒｅｎｔ＿ｃｏｎｔｅｘｔが優先キュー（すなわち、ｇｅｔ＿ｃｏｎｔｅｘｔ＿ｑｕｅｕｅ）から削除され、コンテキスト条件が知らされ、ｎｅｗ＿ｃｏｎｔｅｘｔ＿ｃｏｍｍｉｔフラグがＴＲＵＥにセットされる（ステップ４５０）。コンテキスト条件が知らされると、優先キュー内で待機しているスレッド（ステップ４４０）がウェイクアップされる。処理は、ｔｒｙ＿ｔｏ＿ｃｏｍｍｉｔフラグがＴＲＵＥか否かの問い合わせ（ステップ３５０）へ戻り、上述したように進行する。
【００４２】
更なる説明として、本発明の原理に従った処理の、一実施態様に関する疑似コードを以下に提供する。
【００４３】
この疑似コードにおいて、ｍｐｉ＿ａｌｌｒｅｄｕｃｅ（Ｘ）はライブラリ・ルーチンであり、このルーチンは、コールに関与しているプロセスによって与えられるＸ値の組に、縮約オペレーション（例えば、ＳＵＭ，ＢＩＴＷＩＳＥ）を実行し、その結果を、その組内の全てのプロセスへ配布する。これは、以下のアルゴリズムのコミュニケーション・フェーズを実行するために用いられる既存のライブラリ関数である。
【００４４】
【表１】

【００４７】
ここに示された流れ図は、例示として提供されたものである。本発明の趣旨に反することなしに、ここで述べられたこれらの図もしくはステップ（またはオペレーション）に対するバリエーションが存在し得る。例えば、ある場合においては、ステップは、異なる順番で実行可能であり、また、ステップは、付加、削除、もしくは修正可能である。これらのバリエーションの全ては、請求の範囲に記載された本発明の一部を含むと判断される。
【００４８】
いくつかの好ましい実施の形態に従って、本発明を詳細に述べてきが、当業者によれば、多くの修正や変更を行うことができる。従って、本発明の範囲および本発明の真の趣旨に含まれるそのような修正や変更の全てをカバーすることが、請求の範囲によって意図されている。
【図面の簡単な説明】
【図１】本発明に従って、コミュニケーション・ドメイン・コンセンサス機能を具体化するスレッド化コンピュータ環境の一例を示す図である。
【図２】本発明の原理に従って、複数のプロセスの複数のスレッドに渡って複数のコミュニケーション・ドメインが設定されるような、複数のスレッドを有する複数のプロセスの簡略図である。
【図３】本発明の原理に従って、コミュニケーション・ドメイン・コンセンサス技術の実施形態を示す図である。
【図４】本発明の原理に従って、コミュニケーション・ドメイン・コンセンサス技術の実施形態を示す図である。
【符号の説明】
１００コンピュータ環境
１０２演算ユニット
１０４パケット交換ネットワーク
１０６ユーザ・タスク
１０８カーネル・エクステンション／デバイス・ドライバ
１１０ＭＰＩライブラリ
１１２アダプタ
２００，２０２，２０４プロセス

Claims

複数のスレッドが同時にコミュニケータを設定しようと試みることのできる分散コンピュータ環境において、複数のマルチスレッド化プロセスに渡ってコミュニケータを設定する方法であって、
（ｉ）前記複数のプロセス上の一群の関与スレッドについて前記コミュニケータを設定するための一の候補コンテキスト識別子を設定するために、前記複数のプロセスに渡ってコミュニケーションするステップと、
（ｉｉ）前記複数のプロセスのそれぞれの関与スレッドで、前記候補コンテキスト識別子がそれぞれの関与スレッドのプロセスで依然として使用可能であるか否かを確認することを通して、前記候補コンテキスト識別子を、それぞれの関与スレッドのプロセスで請求できるか否かをチェックし、前記候補コンテキスト識別子を前記複数のプロセスの全てのプロセスで請求できる場合には、前記候補コンテキスト識別子を新しいコンテキスト識別子として請求し、これによって前記コミュニケータを設定するために、前記複数のプロセスに渡ってコミュニケーションするステップとを含む方法。
前記コミュニケーションするステップ（ｉｉ）は、それぞれの関与スレッドでの前記チェックの結果を、前記一群の関与スレッドの他の関与スレッドへ報告することを含む、請求項１に記載の方法。
前記コミュニケーションするステップ（ｉ）は、前記候補コンテキスト識別子を設定するために、前記複数のプロセスの各プロセスで保持される、候補コンテキスト識別子のローカル識別子リストをチェックすることを含む、請求項１に記載の方法。
前記コミュニケーションするステップ（ｉｉ）が、前記候補コンテキスト識別子を前記複数のプロセスの全てのプロセスで請求できないために前記コミュニケータの設定に失敗する場合には、一の新しい候補コンテキスト識別子を設定するために、前記コミュニケーションするステップ（ｉ）を繰り返し、当該新しい候補コンテキスト識別子について前記コミュニケーションするステップ（ｉｉ）を繰り返す、請求項１に記載の方法。
前記コミュニケーションするステップ（ｉ）および前記コミュニケーションするステップ（ｉｉ）は、ＭＰＩライブラリ内のサブルーチン・コールによって実行される、請求項１に記載の方法。
前記コミュニケーションするステップ（ｉ）が、前記複数のプロセスの全てのプロセスが前記コミュニケータの設定に関与していることを保証し、前記コミュニケーションするステップ（ｉｉ）が、それぞれの関与スレッドごとに、当該関与スレッドの現行コンテキスト識別子を、当該関与スレッドのプロセスに対してグローバルである優先キューへ挿入することを含み、前記コミュニケーションするステップ（ｉｉ）が、前記優先キュー内にリストされた、最高優先順位の現行コンテキスト識別子のもとでコミュニケータの要求を行った一の関与スレッドに対し、その候補コンテキスト識別子を、前記新しいコンテキスト識別子として請求することを許可することを含む、請求項１に記載の方法。
前記コミュニケーションするステップ（ｉｉ）が、前記関与スレッドが、そのプロセスで保持される優先キューにおいて優先権を有する場合には、前記候補コンテキスト識別子を請求する際に、前記候補コンテキスト識別子を、前記プロセスで保持される候補コンテキスト識別子のローカル識別子リストから除去することを含む、請求項１に記載の方法。
複数のスレッドが同時にコミュニケータを設定しようと試みることのできる分散コンピュータ環境において、複数のマルチスレッド化プロセスに渡ってコミュニケータを設定するシステムであって、
（ｉ）前記複数のプロセス上の一群の関与スレッドについて前記コミュニケータを設定するための一の候補コンテキスト識別子を設定するために、前記複数のプロセスに渡ってコミュニケーションする手段と、
（ｉｉ）前記複数のプロセスのそれぞれの関与スレッドで、前記候補コンテキスト識別子がそれぞれの関与スレッドのプロセスで依然として使用可能であるか否かを確認することを通して、前記候補コンテキスト識別子を、それぞれの関与スレッドのプロセスで請求できるか否かをチェックし、前記候補コンテキスト識別子を前記複数のプロセスの全てのプロセスで請求できる場合には、前記候補コンテキスト識別子を新しいコンテキスト識別子として請求し、これによって前記コミュニケータを設定するために、前記複数のプロセスに渡ってコミュニケーションする手段とを備えるシステム。
前記コミュニケーションする手段（ｉｉ）は、それぞれの関与スレッドでの前記チェックの結果を、前記一群の関与スレッドの他の関与スレッドへ報告する手段をさらに有する、請求項８に記載のシステム。
前記コミュニケーションする手段（ｉ）は、前記候補コンテキスト識別子を設定するために、前記複数のプロセスの各プロセスで保持される、候補コンテキスト識別子のローカル識別子リストをチェックする手段をさらに有する、請求項８に記載のシステム。
前記コミュニケーションする手段（ｉｉ）が、前記候補コンテキスト識別子を前記複数のプロセスの全てのプロセスで請求できないために前記コミュニケータの設定に失敗する場合には、一の新しい候補コンテキスト識別子を設定するために、前記コミュニケーションする手段（ｉ）がその動作を繰り返し、当該新しい候補コンテキスト識別子について前記コミュニケーションする手段（ｉｉ）がその動作を繰り返す、請求項８に記載のシステム。
前記コミュニケーションする手段（ｉ）および前記コミュニケーションする手段（ｉｉ）は、ＭＰＩライブラリ内のサブルーチン・コールによって実行される、請求項８に記載のシステム。
前記コミュニケーションする手段（ｉ）が、前記複数のプロセスの全てのプロセスが前記コミュニケータの設定に関与していることを保証し、前記コミュニケーションする手段（ｉｉ）が、それぞれの関与スレッドごとに、当該関与スレッドの現行コンテキスト識別子を、当該関与スレッドのプロセスに対してグローバルである優先キューへ挿入する手段を有し、前記コミュニケーションする手段（ｉｉ）が、前記優先キュー内にリストされた、最高優先順位の現行コンテキスト識別子のもとで、コミュニケータの要求を行った一の関与スレッドに、その候補コンテキスト識別子を、前記新しいコンテキスト識別子として請求することを許可する手段をさらに有する、請求項８に記載のシステム。
前記コミュニケーションする手段（ｉｉ）が、前記関与スレッドが、そのプロセスで保持される優先キューにおいて優先権を有する場合には、前記候補コンテキスト識別子を請求する際に、前記候補コンテキスト識別子を、前記プロセスで保持される候補識別子のローカル識別子リストから除去する手段を、さらに有する、請求項８に記載のシステム。