(57)【要約】【課題】クラスタコンピュータにおいて、個々のコンピュータからの通知が非同期的にアプリケーションに送られてくることに起因する、アプリケーションの可読性の低下やデバッグの難しさを避ける。【解決手段】クラスタコンピュータミドルウェアの状態を「セッション」を使って記述する。「セッション」とは、まとまった一連の処理であって、次の二つの条件を満たすもののことを指す。（ａ）セッションの開始・終了の際には、それぞれアプリケーションに通知が送られる。（ｂ）二つのセッションの間には、前後関係・包含関係・無関係のいずれかの関係が規定されている。【選択図】図３
2006228192.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークで接続された複数のコンピュータによって構成されるクラスタコンピュータの上で動作し、前記複数のコンピュータを協調動作させる機能をアプリケーションに提供するクラスタコンピュータミドルウェアであり、
前記複数のコンピュータのうちの、１台あるいは複数のコンピュータで動作する前記アプリケーションから指示を受ける機能と、前記アプリケーションに通知を送る機能と、
前記コンピュータが行うべき処理を所定の位相構造に分割してなるセッションを公開する機能と、
個々の前記セッションに対し、開始を示す前記通知と終了を示す前記通知とを一つずつ、前記アプリケーションに送る機能とを有することを特徴とするクラスタコンピュータミドルウェア。
【請求項２】
請求項１のクラスタコンピュータミドルウェアにおいて、
現在の前記セッションを保持する機能と、
前記コンピュータから非同期的に送られる通知をトリガとし、前記セッションを更新する機能を有することを特徴とするクラスタコンピュータミドルウェア。
【請求項３】
請求項１のクラスタコンピュータミドルウェアにおいて、
複数の前記セッションに対して前後関係、あるいは包含関係が規定されることを特徴とするクラスタコンピュータミドルウェア。
【請求項４】
請求項１のクラスタコンピュータミドルウェアにおいて、
処理の途中でエラーが発生した際に、前記エラーを発生させた前記セッションを特定するための情報を、前記アプリケーションに送る機能を有することを特徴とするクラスタコンピュータミドルウェア。
【請求項５】
請求項１のクラスタコンピュータミドルウェアにおいて、
マスタノードにあるデータをスレーブノードにコピーする前記セッションと、
スレーブノードにあるデータを削除する前記セッションと、
マスタノードにあるデータをすべてのスレーブノードに一括してコピーする前記セッションと、
すべてのノードにあるデータを一括して削除する前記セッションとを含むことを特徴とするクラスタコンピュータミドルウェア。
【請求項６】
請求項１に記載のクラスタコンピュータの動作を模擬する機能をアプリケーションに提供するクラスタコンピュータシミュレータであり、
１台のコンピュータで動作する前記アプリケーションから指示を受ける機能と、前記アプリケーションに通知を送る機能と、
前記コンピュータが行うべき処理を所定の位相構造に分割してなるセッションを公開する機能と、
個々の前記セッションに対し、開始を示す前記通知と終了を示す前記通知とを一つずつ、前記アプリケーションに送る機能とを有することを特徴とするクラスタコンピュータシミュレータ。
【請求項７】
請求項６のクラスタコンピュータシミュレータにおいて、
現在の前記セッションを保持する機能と、
前記コンピュータの動作を模擬するシミュレータから非同期的に送られる通知をトリガとし、前記セッションを更新する機能を有することを特徴とするクラスタコンピュータシミュレータ。
【請求項８】
請求項６のクラスタコンピュータシミュレータにおいて、
複数の前記セッションに対して前後関係、あるいは包含関係が規定されることを特徴とするクラスタコンピュータシミュレータ。
【請求項９】
請求項６のクラスタコンピュータシミュレータにおいて、
処理の途中でエラーが発生した際に、前記エラーを発生させた前記セッションを特定するための情報を、前記アプリケーションに送る機能を有することを特徴とするクラスタコンピュータシミュレータ。
【請求項１０】
請求項６のクラスタコンピュータシミュレータにおいて、
マスタノードにあるデータをスレーブノードにコピーする前記セッションと、
スレーブノードにあるデータを削除する前記セッションと、
マスタノードにあるデータをすべてのスレーブノードに一括してコピーする前記セッションと、
すべてのノードにあるデータを一括して削除する前記セッションとを含むことを特徴とするクラスタコンピュータシミュレータ。
【請求項１１】
通信ネットワークで接続された複数のコンピュータによって構成されるクラスタコンピュータのうちの、１台あるいは複数のコンピュータで動作するアプリケーションであって、
前記アプリケーションは、前記複数のコンピュータを協調動作させる機能を、前記クラスタコンピュータの上で動作するクラスタコンピュータミドルウェアにより提供されるものであり、
前記アプリケーションは、
前記クラスタコンピュータミドルウェアに指示を送る機能と、
前記クラスタコンピュータミドルウェアから通知を受け取る機能と、
前記クラスタコンピュータミドルウェアから、前記コンピュータが行うべき処理を所定の位相構造に分割してなる個々のセッションに対し、開始を示す前記通知と終了を示す前記通知とを一つずつ、受け取る機能と、
前記セッションの開始によって送られる前記通知に対する処理を行うルーチンを保持する機能と、
前記クラスタコンピュータミドルウェアに、前記ルーチンを実行させるために必要な情報を送る機能と、前記セッションの開始を求める指示を送る機能とを備えた、ことを特徴とするアプリケーション。
【請求項１２】
通信ネットワークで接続された複数のコンピュータによって構成されるクラスタコンピュータの構成を記憶保持するコンピュータで動作するアプリケーションであって、
前記アプリケーションは、前記クラスタコンピュータの動作を模擬する機能をクラスタコンピュータシミュレータにより提供されるものであり、
前記アプリケーションは、
前記クラスタコンピュータシミュレータに指示を送る機能と、
前記クラスタコンピュータシミュレータから通知を受け取る機能と、
前記コンピュータが行うべき処理を所定の位相構造に分割してなる個々のセッションに対し、開始を示す前記通知と終了を示す前記通知とを一つずつ、受け取る機能と、
前記セッションの開始によって送られる前記通知に対する処理を行うルーチンを保持する機能と、
前記クラスタコンピュータシミュレータに前記ルーチンを実行させるために必要な情報を送る機能と、前記セッションの開始を求める指示を送る機能とを有する、ことを特徴とするアプリケーション。
【請求項１３】
請求項１１あるいは請求項１２のアプリケーションにおいて、
前記セッションの開始を求める前記指示を送った後、前記指示に対応する前記セッションの終了を伝える通知を受け取る機能を有することを特徴とするアプリケーション。
【請求項１４】
請求項３あるいは請求項８に記載のセッションおよびその位相構造を表示部に視覚的に表示するセッション表示方法であって、
個々の前記セッションを長方形で表し、
前記前後関係を有する複数のセッションを表す長方形を上下に配置し、
前記包含関係を有する複数のセッションを表す長方形を入れ子に配置することを特徴とするセッション表示方法。
【請求項１５】
請求項１に記載のアプリケーションを開発するために使われるアプリケーション開発支援方法であり、
前記クラスタコンピュータミドルウェアと同じ位相構造を持つ前記セッションを保持する、請求項６のクラスタコンピュータシミュレータによって動作する模擬アプリケーションを開発する工程と、
前記模擬アプリケーションを、請求項１のクラスタコンピュータミドルウェアに移植する工程とを含むことを特徴とするアプリケーション開発支援方法。
【請求項１６】
クラスタコンピュータで動作するクラスタコンピュータミドルウェアであって、前記クラスタコンピュータが、一つのマスタコンピュータと、一つ以上のスレーブコンピュータと、前記マスタコンピュータおよび前記スレーブコンピュータを相互に接続するネットワークとを含むものにおいて、
前記クラスタコンピュータミドルウェアが少なくとも、
前記マスタコンピュータで動作するマスタアプリケーションとのリンクが可能なマスタモジュールと、
前記スレーブコンピュータで動作するスレーブアプリケーションとのリンクが可能なスレーブモジュールとによって構成され、
前記マスタモジュールが、
前記クラスタコンピュータで実行されるべき並行処理手順を作成するスケジューラを備え、
前記スケジューラが、
動作を開始する前に、前記マスタアプリケーションの処理を一時停止させ、
前記動作を終了した後に、前記マスタアプリケーションの処理を再開させ、かつ、
前記マスタモジュールおよび前記スレーブモジュールが、
前記スケジューラから受け取った指示に基づき、他の前記マスタモジュールあるいは前記スレーブモジュールと相互に通信する手段と、
前記スケジューラから受け取った指示に基づき、前記マスタアプリケーション、あるいは前記スレーブアプリケーションによって事前に設定されたイベントハンドラを実行する手段とを備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項１７】
請求項１６に記載のクラスタコンピュータミドルウェアであって、
逐次的にルーチンを実行する処理系からの呼び出しによって動作し、
前記スケジューラの動作を開始させ、かつ前記スケジューラの終了を待つ機能を有する前記ルーチンを前記処理系に公開する、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項１８】
請求項１６に記載のクラスタコンピュータミドルウェアであって、
前記マスタモジュール、あるいは前記スレーブモジュールが、
データのコピーを行うデータコピー手段と、
データの消去を行うデータ消去手段とを備え、かつ
前記スケジューラが、
前記データコピー手段、および前記データ消去手段を動作させる手段を備える、ことを特徴とするクラスタコンピュータミドルウェア。
【請求項１９】
請求項１８に記載のクラスタコンピュータミドルウェアであって、
前記マスタモジュールおよび前記スレーブモジュールが、
前記イベントハンドラの実行、前記データのコピー、前記データの消去のうち、少なくとも一つの終了を知らせる通知を前記スケジューラに送る手段を備え、
前記スケジューラが
前記マスタモジュールおよび前記スレーブモジュールから送られる前記通知を時系列的に並べ替える手段を備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２０】
請求項１８に記載のクラスタコンピュータミドルウェアであって、
前記イベントハンドラが、
コピーあるいは消去の対象となる前記データをリストに追加する手段、あるいはリストから削除する手段を備え、かつ
前記スケジューラが、前記リストに基づいて前記データコピー手段、および前記データ消去手段を動作させる手段を備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２１】
請求項１８に記載のクラスタコンピュータミドルウェアであって、
前記マスタモジュールが、
前記マスタアプリケーションから処理中断要求を受け取る手段を備え、かつ
前記スケジューラが、
コピーあるいは消去された前記データの配置を管理する手段と、
前記処理中断要求を受け取った時に、前記データ消去手段に対し、前記データの配置に基づいて、中間的な前記データを消去させる指示を送る手段とを備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２２】
請求項１６に記載のクラスタコンピュータミドルウェアであって、
前記スケジューラが、
前記マスタコンピュータおよび前記スレーブコンピュータの状態を管理する手段と、
前記状態に基づき、
前記マスタモジュールあるいは前記スレーブモジュールに、
前記イベントハンドラの複数回の実行を振り分ける手段とを備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２３】
請求項２２に記載のクラスタコンピュータミドルウェアであって、
前記スケジューラが、
前記マスタコンピュータおよび前記スレーブコンピュータの処理速度を把握する手段と、
前記イベントハンドラの複数回の実行を、その順番に基づき、
複数の前記マスタコンピュータあるいは前記スレーブコンピュータのうち、処理速度の速いものに優先的に振り分ける手段とを、備えることを特徴とするクラスタコンピュータミドルウェア。
【請求項２４】
請求項２２に記載のクラスタコンピュータミドルウェアであって、
前記スケジューラが
前記マスタモジュールおよび前記スレーブモジュールに振り分けられた前記イベントハンドラを実行させる際、
前記マスタコンピュータおよび前記スレーブコンピュータを一意に識別する情報、もしくは前記イベントハンドラの個々の実行を一意に識別する情報を前記イベントハンドラに渡す、ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２５】
請求項１６に記載のクラスタコンピュータミドルウェアであって、
前記スケジューラが、
前記スレーブコンピュータの故障を検知する手段と、
前記故障を検知した後、
故障した前記スレーブモジュールに対して送った指示の複製を他の故障していない前記スレーブモジュールに対して送り直す手段とを備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２６】
請求項１８に記載のクラスタコンピュータミドルウェアであって、
前記スケジューラが、
少なくとも一つの前記スレーブモジュールの前記データコピー手段に対し、他の前記スレーブモジュールにデータをコピーさせる手段を備える、
ことを特徴とするクラスタコンピュータミドルウェア。
【請求項２７】
請求項２６に記載のクラスタコンピュータミドルウェアであって、
前記ネットワークのトポロジが複数のハブを含む木構造であり、
前記スケジューラが、
前記ネットワークの前記トポロジを把握する手段と、
コピー元になる前記マスタモジュールあるいは前記スレーブモジュールと、
コピー先になる他の前記スレーブモジュールが、異なる前記ハブに接続されているかどうかを判定し、
前記判定の結果に基づいて
前記コピー先になる他の前記スレーブモジュールを選定する手段とを、備えることを特徴とするクラスタコンピュータミドルウェア。
【請求項２８】
請求項１あるいは請求項１６のクラスタコンピュータミドルウェアを記録している、コンピュータ読み取り可能な記録媒体。
【請求項２９】
請求項６のクラスタコンピュータシミュレータを記録している、コンピュータ読み取り可能な記録媒体。
【請求項３０】
請求項１１あるいは請求項１２のアプリケーションを記録している、コンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はクラスタコンピュータミドルウェアに関し、特にアプリケーションを容易に移植・開発することのできるクラスタコンピュータミドルウェアに関する。
【背景技術】
【０００２】
複数のコンピュータをネットワークで接続し、協調動作するようにしたものを「クラスタコンピュータ」と呼ぶ。クラスタコンピュータは並列コンピュータの一種で、パーソナルコンピュータの急激な高性能化・低価格化を背景に、比較的低コストで超高速計算を実現する手段として注目されている。
【０００３】
特許文献１には、クラスタコンピュータの一例が記載されている。しかしクラスタコンピュータには、物理的な構成や運用形態の異なる多くの種類があり、それぞれ解決するべき課題も異なっている。この例のクラスタコンピュータは、地理的に離れたコンピュータを比較的伝送速度の遅い広域ネットワークで結合するもので、前記の公報にはシステム全体の処理性能を高めるため、広域ネットワークの中に配置されているルータの負荷を分散させる手法が提示されている。すなわち他のクラスタ装置にアプリケーションジョブを振り分ける際に、各クラスタ装置のリソース管理情報、およびネットワーク制御情報に基づき、アプリケーションジョブを振り分ける構成が示されている。なお本発明の対象とするクラスタコンピュータは、後で述べるように上記公知例のクラスタコンピュータとは物理的な構成や運用形態が異なる。したがって本発明の解決するべき課題も、システム全体の処理性能を高めるという上記公知例の課題とは異なる。
【０００４】
一般的なクラスタコンピュータは、「マスタコンピュータ」と呼ばれる１台のコンピュータと、「スレーブコンピュータ」と呼ばれる多数のコンピュータから構成されている。アプリケーションは普段、マスタコンピュータで動作している。並列処理が必要となる部分にさしかかると、マスタコンピュータは素材データを個々のスレーブコンピュータに分配した上、それぞれのスレーブコンピュータが担当する処理の範囲を決定し、処理の開始をそれぞれのスレーブコンピュータに指示する。処理を終えたスレーブコンピュータは、部分的な結果データをマスタコンピュータに送り、マスタコンピュータはそれらを統合して一つのまとまった結果データを得る。このように並列処理を実現するために行われる一連の動作のことを「処理手順」と呼ぶ。実際のアプリケーションでは、処理に要する時間を短縮したり、必要なメモリ容量を小さくしたりする目的で、上記のような単純な処理手順だけでなく、より複雑な処理手順が使われることも多い。
【０００５】
コンピュータとクラスタコンピュータは、その構成が大きく異なっているので、通常のアプリケーションを、そのままクラスタコンピュータで動作させることはできない。クラスタコンピュータで動作するアプリケーションを作成するには、あらかじめアプリケーションをクラスタコンピュータ用として設計し、データの分配・回収、処理開始の指示の送信、処理終了の通知の受信といった、基本的な機能を盛り込む必要がある。
【０００６】
こうした基本的な機能を集め、アプリケーションから簡単に使うことができるようにしたソフトウェアは「クラスタコンピュータミドルウェア」と呼ばれる。クラスタコンピュータミドルウェアは、アプリケーションとコンピュータの間に位置するネットワークソフトウェアであり、個々のコンピュータの接続・動作の状態を監視・変更したり、アプリケーションからの指示を個々のコンピュータに分配したり、個々のコンピュータからの通知を取りまとめてアプリケーションに伝えたりする機能を持っている。クラスタコンピュータミドルウェアを使うと、アプリケーションがコンピュータ間のデータ通信を意識する必要性が軽減され、クラスタコンピュータ用のアプリケーションを簡単に書くことができる。このようなクラスタコンピュータミドルウェアの例は、たとえば特許文献２に記載されている。
【０００７】
【特許文献１】特開２００２−２５９３５号公報
【特許文献２】特開２００４−３８２２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら前記従来技術では、並列アプリケーションを開発するために多大な費用・労力、高度な知識・技術が必要とされた。また開発する並列アプリケーションに、高い拡張性と上位互換性を与えることが難しかった。
【０００９】
たとえば従来の一般的なクラスタコンピュータミドルウェアでは、アプリケーションやコンピュータから送られる指示・通知を加工せず、そのまま相手先に送っていた。そのため一般的なアプリケーションは、個々のコンピュータに処理の開始を指示した後、それらからの処理終了の通知を待つループに入るように作らなければならなかった。
【００１０】
図２３に、クラスタコンピュータ１００において、上記の並列処理手順を実現するために、アプリケーションとクラスタコンピュータミドルウェアが行う情報交換の内容を示す。普段マスタモジュールで実行されているアプリケーションは、並列処理が必要な部分にさしかかると、個々のスレーブモジュールに、部分的な処理の開始を要求する指示３１０（３１０Ａ・３１０Ｂ・３１０Ｃ）を送る。これを受けたスレーブモジュールは、それぞれの担当する処理を行い、それが終わったら、処理の完了を知らせる通知３２０（３２０Ａ・３２０Ｂ・３２０Ｃ）をマスタモジュールに送る。スレーブモジュールが処理を行っている間、マスタモジュールは、スレーブモジュールからの通知３２０を待っている。
【００１１】
ここで従来のクラスタコンピュータミドルウェアの問題点を明確にするため、簡単なアプリケーションを例に取り上げ、これをクラスタコンピュータ１００に移植することを考える。並列化する前のソースコードを図２４に模式的に示す。このアプリケーションは、前処理に相当するＰｒｏｃｅｓｓＡと、本処理に相当するＰｒｏｃｅｓｓＢと、後処理に相当するＰｒｏｃｅｓｓＣを順番に実行するものである。ＰｒｏｃｅｓｓＢは繰り返し処理であり、実行するのに長い時間がかかるので、ここではＰｒｏｃｅｓｓＢを並列化することを考える。
【００１２】
図２４のアプリケーションを従来のクラスタコンピュータミドルウェアを使用して並列化した、新しいアプリケーションのマスタモジュールのソースコードを図２５に模式的に示す。並列化される前のソースコードと比較すると、並列化された後のソースコードはきわめて読みにくくなっていることがわかる。たとえばこのソースコードには、マスタモジュールでの特定の処理をトリガとして実行される処理ブロック４３０と、スレーブモジュールから送られる通知３２０をトリガとして実行される処理ブロック４２０が混在している。処理ブロック４３０には、スレーブモジュールの処理終了を待つためのループを置く必要がある。また処理ブロック４２０と処理ブロック４３０は、異なるトリガによって非同期的に実行されるので、これらが使用する変数は、すべてグローバル変数４１０として定義する必要がある。オブジェクト指向に基づく近代的なプログラミングにおいては、グローバル変数はなるべく使うべきではないとされており、これは望ましくないことである。また図２４では実行される順番に置かれていたＰｒｏｃｅｓｓＡとＰｒｏｃｅｓｓＣは、新しいソースコードではまったく異なる部位に記述されており、その順番も逆になっている。また図２５には書かれていないが、実際には非同期的に実行される処理ブロックの間の干渉を防ぐため、再入（処理が終わる前に、再び同じ処理が始められること）を防止するための仕組みが不可欠であり、スレーブコンピュータ１１０ｂ〜１１０ｉや、通信ネットワーク１２０の障害を想定したエラー対策も考慮すると、従来のクラスタコンピュータミドルウェアを使用したアプリケーションの並列化は非常に難しいことがわかる。
【００１３】
このように従来技術では、個々のコンピュータから通知が非同期的に送られることによる、アプリケーションの可読性の低下やデバッグの困難を避けることができなかった。通知が「非同期的に送られる」とは、マスタコンピュータで実行される「メイン処理」とは無関係に、スレーブコンピュータで実行される「サブ処理」をトリガとする通知が送られるということである。その結果、次のような問題が生じていた。
（１）エラーが発生した場合、そのエラーがメイン処理によって発生したのか、サブ処理によって発生したのかを特定することが困難である。そのため体系的なデバッグがしにくい。
（２）メイン処理の実行される順番と、ソースコードに記述される順番が一致しない。そのため並列化の前と後では、ソースコードの構造がまったく異なったものとなる。またメイン処理の中に、通知を待つループ処理が多く現れ、ソースコードの可読性を損なう。
（３）メイン処理がサブ処理の実行順序に依存する。そのためミドルウェアが改良されたりしてサブ処理の実行順序が変わると、それを使用しているアプリケーションも作り直さなければならない。
（４）並列処理の手順によってメイン処理が変化する。そのためライブラリのように並列化するべき処理が多くある場合、それぞれの処理がまったく異なった構造で書かれることになり、ソースコードの管理が難しくなる。
（５）独立に動作しているスレーブコンピュータの動作タイミングを模擬することが難しいので、確実に動作するアプリケーションを開発するには、実際にクラスタコンピュータを用意する必要がある。
（６）メイン処理からの指示に対し、即座にサブ処理が実行される。そのためメイン処理には、サブ処理を実行するタイミングを管理する責任が発生する。
【００１４】
本発明は、それぞれのコンピュータから通知が非同期的に送られることに起因する、従来のクラスタコンピュータミドルウェアが抱える問題を解決するためのものである。
【００１５】
本発明の第１の解決課題は、並列アプリケーションを開発するために多大な費用・労力、高度な知識・技術を必要としないクラスタコンピュータミドルウェアを提供することにある。
【００１６】
本発明の第２の解決課題は、開発する並列アプリケーションに、高い拡張性と上位互換性を与えることが容易なクラスタコンピュータミドルウェアを提供することにある。
【００１７】
本発明のその他の解決課題と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すると以下のとおりである。
【００１９】
（１）通信ネットワークで接続された複数のコンピュータによって構成されるクラスタコンピュータの上で動作し、前記複数のコンピュータを協調動作させる機能をアプリケーションに提供するクラスタコンピュータミドルウェアであり、前記複数のコンピュータのうちの、１台あるいは複数のコンピュータで動作する前記アプリケーションから指示を受ける機能と、前記アプリケーションに通知を送る機能と、前記コンピュータが行うべき処理を所定の位相構造に分割してなるセッションを公開する機能と、個々の前記セッションに対し開始を示す前記通知と終了を示す前記通知とを一つずつ前記アプリケーションに送る機能とを有するクラスタコンピュータミドルウェア。
【００２０】
（２）マスタモジュールとスレーブモジュールから構成されるクラスタコンピュータミドルウェアに、アプリケーションの処理を一時的にブロックして動作するスケジューラと、スケジューラからの指示を受けてアプリケーションが事前に設定したイベントハンドラを実行する手段を備えたクラスタコンピュータミドルウェア。
【発明の効果】
【００２１】
本発明の一つの特徴によれば、それぞれのコンピュータからの通知が非同期的に送られなくなるので、アプリケーションの可読性が向上し、デバッグも容易になる。
【００２２】
また本発明のもう一つの特徴によれば、クラスタコンピュータの実際の構成をアプリケーションから隠すことができる。そのためクラスタコンピュータの構成に依存する処理手順をアプリケーションに実装する必要がなくなる。また同一のアプリケーションを異なる構成のクラスタコンピュータで動作させることができるようになる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施の形態について、詳細に説明する。
［クラスタコンピュータの一般論］
本発明によるクラスタコンピュータミドルウェアについて説明する前に、ここでクラスタコンピュータの一般論について簡単に述べる。一般的なクラスタコンピュータ１００のハードウェア構成例を図１に示す。クラスタコンピュータ１００は、１台のマスタコンピュータ１１０ａと、多数のスレーブコンピュータ１１０ｂ〜１１０ｉによって構成されており、これらが高速の通信ネットワーク１２０で相互に結合されている。マスタコンピュータ１１０ａは、ディスプレイ１３１と、キーボード１３２と、マウス１３３からなるコンソールを備えている。しかしスレーブコンピュータ１１０ｂ〜１１０ｉはコンソールを備えておらず、その操作はマスタコンピュータ１１０ａから通信ネットワーク１２０を経由して間接的に行われる。
【００２４】
クラスタコンピュータ１００では、複数のコンピュータ１１０が物理的に近接した場所に配置されていることを想定している。その場合、スイッチングハブとＬＡＮケーブルを使用してネットワーク１２０を構成することができる。ただし本発明は、複数のコンピュータ１１０が離れた場所に配置されており、ルータや光ファイバを使用してネットワーク１２０が構成されている場合にも応用可能である。
【００２５】
それぞれのコンピュータ１１０には、クラスタコンピュータミドルウェア５００と、それを利用するアプリケーション５１０がインストールされている。これらのクラスタコンピュータミドルウェアとアプリケーションは、それぞれが「マスタモジュール」と「スレーブモジュール」に分割されている。したがってクラスタコンピュータ１００では、以下の四種類のプログラムが動作することになる。
（１）クラスタコンピュータミドルウェア（マスタモジュール）５００Ｍ
（２）クラスタコンピュータミドルウェア（スレーブモジュール）５００Ｓ
（３）アプリケーション（マスタモジュール）５１０Ｍ
（４）アプリケーション（スレーブモジュール）５１０Ｓ
一般にアプリケーションは、マスタモジュール・スレーブモジュールとも、実行可能なプログラムとして提供される。一方クラスタコンピュータミドルウェアは通常ライブラリとして提供され、それぞれのモジュールは、アプリケーションの対応するモジュールにリンクされて動作する。
【００２６】
アプリケーションが並列処理を行うには、所定の手順でデータをコピー・削除したり、処理を実行したりする必要がある。そのような手順のことを「並列処理手順」と呼ぶ。図２に、簡単な並列処理手順の一例を示す。この並列処理手順は、次の四つのステップからなる。
【００２７】
ステップ１：マスタモジュールがスレーブモジュールに素材データ２１０をコピーしてから、処理開始を命令するステップ。
【００２８】
ステップ２：スレーブモジュールが素材データ２１０を処理し、結果データ２２０の断片である結果データ２２１を作成してから、マスタモジュールに処理終了を報告するステップ。
【００２９】
ステップ３：マスタモジュールがスレーブモジュールに結果データ２２１のコピーを命令し、スレーブモジュールから送られた結果データ２２１をマスタモジュールが統合して結果データ２２０を作成するステップ。
【００３０】
ステップ４：マスタモジュールがスレーブモジュールに素材データ２１０と結果データ２２１の削除を命令し、スレーブモジュールが素材データ２１０と結果データ２２１を削除するステップ。
【００３１】
以上のステップにより、１台のコンピュータが動作する場合と同じように、素材データ２１０から結果データ２２０が作成される。
【００３２】
以下では本発明の実施形態を、図面に示したいくつかの実施例を参照しながら、さらに詳細に説明する。
【実施例１】
【００３３】
本発明の第１の実施例になる、クラスタコンピュータミドルウェアについて説明する。
【００３４】
まず、第１の実施例によるクラスタコンピュータミドルウェア５００の構成を図３に示す。クラスタコンピュータミドルウェア５００は、アプリケーションインタフェース５０１と、分配統合制御手段５０２と、コンピュータインタフェース５０３とによって構成されている。このうち分配統合制御手段５０２には、セッション保持手段５０４と、セッション更新手段５０５が含まれており、これが本発明によるクラスタコンピュータミドルウェア５００の特徴となっている。
【００３５】
クラスタコンピュータミドルウェア５００は、通信ネットワークで結合された複数のモジュールから成り立っている分散型のソフトウェアである。それぞれのモジュールはそれぞれ別のコンピュータ１１０ａ〜１１０ｉにインストールされ、アプリケーション５１０からの指示３５０を受けて相互に通信を行い、これらのコンピュータ１１０ａ〜１１０ｉを協調動作させる。
【００３６】
アプリケーションインタフェース５０１は、アプリケーション５１０とリンクするためのインタフェースで、オペレーティングシステムごとに定められているライブラリ仕様に基づく。アプリケーション５１０から指示３５０を受けたり、アプリケーション５１０に通知３６０を送ったりするために、各種のルーチンやイベントを決まった形式でアプリケーション５１０に公開する、すなわち使用を可能にするものである。
【００３７】
分配統合制御手段５０２は、アプリケーション５１０から受けた指示３５０をコンピュータ１１０ａ〜１１０ｉに適切に分配したり、コンピュータ１１０ａ〜１１０ｉから個別に届く通知を統合して作成した通知３６０をアプリケーション５１０に送ったりするものである。
【００３８】
コンピュータインタフェース５０３は、通信ネットワーク１２０で接続された複数のコンピュータ１１０ａ〜１１０ｉに指示３３０を送ったり、コンピュータ１１０ａ〜１１０ｉから通知３４０を受けたりするためのインタフェースである。それぞれのコンピュータ１１０ａ〜１１０ｉには、オペレーティングシステムがインストールされている。オペレーティングシステムは各種のファンクションを公開しており、コンピュータインタフェース５０３はそれらを呼び出すことで、コンピュータ１１０ａ〜１１０ｉにデータを伝送させたり、処理を開始させたりすることができる。
【００３９】
セッション保持手段５０４は、クラスタコンピュータが現在どのセッションを実行しているかを記憶・保持するものである。セッションの考え方については、後で詳しく説明する。
【００４０】
セッション更新手段５０５は、アプリケーション５１０からの指示３５０や、コンピュータ１１０ａ〜１１０ｉからの通知３４０をトリガとして、セッション保持手段５０４が保持しているセッションを新しい値に遷移させるものである。
【００４１】
ここでクラスタコンピュータミドルウェア５００が導入する「セッション」について説明する。「セッション」とは、まとまった一連の処理であり、かつ次の二つの条件を満たすもののことを指す。
ａ．セッションの開始・終了の際には、それぞれアプリケーション５１０に通知３６０が送られる。
ｂ．二つのセッションの間には、前後関係・包含関係・無関係のいずれかの関係が規定されている。
【００４２】
クラスタコンピュータミドルウェア５００において、上記のように定義されたセッションは、図４に示すような性質を持つものとして扱われる。セッションはクラスタコンピュータミドルウェア５００が導入する仮想的な概念であり、その実体が存在する必要はない。しかしセッションの存在を前提にアプリケーションインタフェース５０１の仕様を規定すると、後述する新規な効果が得られる。
【００４３】
ここからは、セッションを定義している上記の二つの条件について詳述する。まずは開始通知と終了通知について説明する。開始通知とは、セッションが開始した直後に送られる通知３６０のことであり、終了通知とは、セッションが終了する直前に送られる通知３６０のことである。これらの通知３６０は、分配統合制御手段５０２から、アプリケーション５１０に送られる。終了通知は、処理によってエラーが発生しても必ず送られることが保証されている。この性質を利用すると、アプリケーション５１０は、現在どのセッションが実行されているかを確実に知ることができる。
【００４４】
これらの開始通知・終了通知は、実際には「イベント」として実装されている。イベントとは、特定の事象が発生した場合に、あらかじめ設定されたルーチンが実行される、ソフトウェアの仕組みである。クラスタコンピュータミドルウェア５００の場合には、セッションの開始と終了が事象に相当する。ルーチンであるイベントは引数を取ることができ、アプリケーション５１０はその値を調べたり変更したりすることができる。つまり開始イベント・終了イベントの引数を利用することで、アプリケーション５１０はセッションが実際に行った動作の内容を調べたり、セッションが行うべき動作の内容を変更したりすることができる。
【００４５】
次に、セッションの満たすべきもう一つの条件である、三つの関係について説明する。セッションＡがセッションＢに先行する（セッションＢがセッションＡに後続する）とは、セッションＡの終了通知が必ずセッションＢの開始通知の前に送られることを意味する。またセッションＡがセッションＢを含む（セッションＢがセッションＡに含まれる）とは、セッションＡの開始通知が必ずセッションＢの開始通知の前に送られ、セッションＡの開始通知が必ずセッションＢの開始通知の後に送られることを意味する。そしてセッションＡとセッションＢの間に関係がないとは、それらの開始通知・終了通知の送られる順番が決まっていないことを意味する。クラスタコンピュータミドルウェア５００では、任意の二つのセッションに対し、これらの三つの関係のいずれかが規定されている。すべての規定を考慮すると、クラスタコンピュータが行うべき処理は、所定の位相関係を持つ複数のセッションの組み合わせとして表される。これを「セッションの位相構造」と呼ぶ。こうしたセッションの位相構造は、個々のクラスタコンピュータミドルウェア５００に固有のものとして規定され、アプリケーション５１０にも公開される。アプリケーション５１０の設計では、セッションの位相構造のみを利用してアルゴリズムを検討する必要がある。
【００４６】
セッションの関係は、図５のように図形を使って表記することもできる。この方法ではセッション６００を長方形で示し、その位置関係によってセッション６００の関係を記述する。ここでは二つのセッションを取り上げ、それぞれ「セッションＡ（６００Ａ）」・「セッションＢ（６００Ｂ）」と呼ぶ。図形を使った表記では、前後関係を持つセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（イ）のように上下に並べて表し、包含関係を持つセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（ロ）のように入れ子にして表し、関係のないセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（ハ）のように上下にずらしながら横に並べて表す。ここでは二つのセッション６００を例に挙げたが、セッション６００が三つ以上の場合にも同様の考え方で表記することができる。
【００４７】
図形を使うセッション６００の表記では、縦軸が時間の流れ、横軸が処理の行われる場所（コンピュータ１１０、または複数のコンピュータ１１０の組み合わせ）を表すと考えると理解しやすい。セッション６００の位相構造は、クラスタコンピュータミドルウェア５００を特徴付ける重要な性質である。図形を使ってセッションを表記する方法を開発支援ツールなどに応用すると、わかりやすく誤解されにくいユーザインタフェースを提供することができる。こうした用途においては、画面レイアウトの制約などにより、縦軸と横軸を入れ替えて配置したり、関係のないセッション６００を上下にずらさずに配置したりしても差し支えない。
【００４８】
クラスタコンピュータミドルウェア５００が規定するセッション６００の位相構造を図６に示す。またそれぞれのセッション６００で行われる処理は、図７に示すとおりである。
（１）Ｃｏｐｙセッション６０１
ノードにある一つのデータを、他のノードにコピーする。
（２）Ｄｅｌｅｔｅセッション６０２
ノードにある一つのデータを削除する。
（３）Ｓｅｎｄセッション６０３
マスタノードにあるデータを、スレーブノードにコピーする。
（４）Ｅｘｅｃｕｔｅセッション６０４
スレーブノードにタスクを実行させる。
（５）Ｒｅｃｅｉｖｅセッション６０５
スレーブノードにあるデータを、マスタノードにコピーする。
（６）Ｗａｓｔｅセッション６０６
スレーブノードにあるデータを削除する。
（７）Ｂａｔｃｈセッション６０７
一つのスレーブノードに分散処理をさせる。
（８）Ｄｅｌｉｖｅｒセッション６０８
マスタノードにあるデータを、すべてのスレーブノードにコピーする。
（９）Ｒａｃｅセッション６０９
すべてのスレーブノードに分散処理をさせる。
（１０）Ｃｌｅａｎセッション６１０
すべてのノードにあるデータを削除する。
（１１）Ｏｐｅｒａｔｅセッション６１１
クラスタコンピュータを動作させる。
【００４９】
なおここでは、ディスクの上にファイルとして保存されているデータと、特定のメモリ領域に格納されているデータを総称して「データ」と呼ぶ。またクラスタコンピュータを構成するマスタコンピュータ・スレーブコンピュータを総称して「ノード」と呼ぶ。
【００５０】
これらのセッション６００を開始・終了させるトリガには二つの種類がある。一つはアプリケーション５１０からの指示３５０、もう一つはコンピュータ１１０ａ〜１１０ｉからの通知３４０である。どちらの種類のトリガによってセッション６００が開始・終了するのかは、セッション６００の種類や、セッション６００の実行の有無によって決まる。たとえばＤｅｌｉｖｅｒセッション６０８を開始させるトリガは指示３５０であり、Ｄｅｌｉｖｅｒセッション６０８を終了させるトリガは通知３４０である。またＲａｃｅセッションを開始させるトリガは、Ｄｅｌｉｖｅｒセッション６０８の実行の有無に依存する。Ｄｅｌｉｖｅｒセッション６０８が実行される場合には通知３４０、実行されない場合には指示３５０がトリガとなる。Ｏｐｅｒａｔｅセッション６１１を開始させるトリガも指示３５０である。すなわちアプリケーション５１０からの指示３５０がなければ、一連の処理手順は開始されない。
【００５１】
セッションの開始イベント・終了イベントの引数は、個々のセッション６００ごとに規定されている。たとえばＣｏｐｙセッション６０１の開始イベントでは、コピーするデータのインデックスが引数として渡される。アプリケーション５１０は、この引数を（データが存在しないことを表す）０に書き換えることにより、コピーを中断させることもできる。またＣｏｐｙセッション６０１の終了イベントでは、実際にコピーされたデータのインデックスが引数として渡される。この値が０であった場合には、エラーが発生したために実際にはデータがコピーされなかったということである。このようにしてアプリケーション５１０は、セッション６００での処理が正しく行われたことを確認することもできる。複数のデータを扱うことのできるＳｅｎｄセッション６０３・Ｅｘｅｃｕｔｅセッション６０４・Ｒｅｃｅｉｖｅセッション６０５・Ｗａｓｔｅセッション６０６・Ｄｅｌｉｖｅｒセッション６０８・Ｃｌｅａｎ６１０セッションでは、データのインデックスの代わりに、複数のインデックスを格納することのできるリストが引数として渡される。アプリケーション５１０でこのリストにデータのインデックスを追加することで、複数のデータをすべてのスレーブノードに一括してコピーしたり、複数のノードにあるデータを一括して削除したりすることが可能になる。
【００５２】
以上のようなセッション６００の性質を踏まえると、先に説明を省略したセッション保持手段５０４とセッション更新手段５０５の動作が理解しやすくなる。そこでここからは、それらの動作について説明していくことにする。
【００５３】
セッション保持手段５０４は、クラスタコンピュータが現在どのセッション６００を実行しているかを記憶・保持するものである。セッション６００は階層的な包含関係を持っているので、セッション保持手段５０４は木（ツリー）構造の変数を使い、これに現在実行されているセッション階層を記憶させる。クラスタコンピュータミドルウェア５００の初期状態では、この変数にはセッション階層が記憶されておらず、すなわちセッション６００が実行されていないことを示している。
【００５４】
セッション更新手段５０５は、アプリケーション５１０からの指示３５０や、コンピュータ１１０ａ〜１１０ｉからの通知３４０をトリガとして、セッション保持手段５０４が保持しているセッション６００を新しい値に遷移させるものである。セッション６００がどのように遷移するかは、現在のセッション６００と、トリガである指示３５０・通知３４０によって決まる。
【００５５】
たとえば現在Ｄｅｌｉｖｅｒセッション６０８が実行されており、これにいくつかのＣｏｐｙセッション６０１が含まれているものとする。そこにコンピュータ１２０から「データコピー終了」の通知が送られてきた場合、セッション更新手段５０５はこのコンピュータ１２０に対応するＣｏｐｙセッション６０１を終了させ、セッション保持手段５０４からも削除する。この動作によってＣｏｐｙセッション６０１がすべて終了した場合には、Ｄｅｌｉｖｅｒセッション６０８を終了させ、セッション保持手段５０４からも削除する。そして続くＲａｃｅセッション６０９を開始させ、セッション保持手段５０４に追加する動作を行う。セッション６００の開始・終了の際には、先に述べたとおり、開始通知や終了通知がアプリケーション５１０に送られる。なお必要に応じ、通知３６０をシリアライズする（一つの通知３６０に対する処理がアプリケーション５１０で実行されている間には、次の通知３６０を送らない）ようにしてもよい。
【００５６】
このようにクラスタコンピュータミドルウェア５００では、アプリケーション５１０からの指示３５０やコンピュータ１１０からの通知３４０をトリガとして、本発明で新規に導入したセッションの概念に基づき、アプリケーション５１０に通知３６０を送る。アプリケーション５１０のプログラミングは、これらの通知３６０に対する処理を記述することによって行われる。
【００５７】
アプリケーション５１０の構成を図８に示す。アプリケーション５１０には、開始イベントハンドラ５１１と、開始イベントハンドラ５１２と、アドレス公開手段５１３が含まれている。
【００５８】
「イベントハンドラ」とは、イベントによって動作し、決められた処理を行うルーチンである。イベントハンドラは実際には関数や手続きなので、その形式とアドレスがわかれば呼び出すことができる。そこでアプリケーション５１０は、クラスタコンピュータミドルウェア５００がＯｐｅｒａｔｅセッション６１１の実行を開始する前に、クラスタコンピュータミドルウェア５００にイベントハンドラのアドレスを公開する。アドレス公開手段５１３は、これらのイベントハンドラのアドレス５２０を取得し、実際には関数や手続きとして実装される指示３５０に引数として追加する。イベントハンドラの形式はあらかじめ決められているので、クラスタコンピュータミドルウェア５００は、セッション６００の開始・終了に合わせ、開始イベントハンドラ５１１と終了イベントハンドラ５１２を実行させることができるようになる。
【００５９】
本発明のクラスタコンピュータにおいて、アプリケーション５１０とクラスタコンピュータミドルウェア５００が行う情報交換の内容を図９に示す。セッション開始指示３５１を受けてセッション開始通知３６１が出され、それに対する返答として処理Ａ・処理Ｂ・処理Ｃの実行が指示される。この図と、図２３に示された内容を比べると、クラスタコンピュータミドルウェア５００が、スレーブモジュールが処理を実行する順番を、アプリケーション５１０から隠蔽していることがわかる。アプリケーション５１０は、スレーブモジュールが実行する処理の順番を変えたり調べたりすることができない。またそのようなことをする必要性そのものがなくなっている。セッション開始通知３６１によって開始イベントハンドラ５１１が実行され、セッション処理内容指示３５２を自動的に送るので、セッション開始指示３５１を送った後のアプリケーション５１０は、セッション６００の終了、つまりセッション終了通知３６２が送られてくるのをただ単に待っているだけでよいのである。アプリケーション５１０のこのような動作は、セッションの位相構造が複雑であっても本質的には変わらない。
【００６０】
本発明によるクラスタコンピュータミドルウェア５００を使用して並列化したアプリケーションの、マスタモジュールのソースコードを図１０に模式的に示す。この図と、図２５に示したソースコードを比べると、先に指摘されていた従来のクラスタコンピュータミドルウェアの問題点の多くが本発明によって解消されたことがわかる。新しいソースコードは大幅に単純化されており、図２４に示した並列化する前のソースコードとの対応もさせやすくなっている。
【００６１】
以上のように、クラスタコンピュータミドルウェア５００を使うことにより、次の新規な効果が得られる。
【００６２】
（１）エラーが発生した場合には、セッション保持手段５０４が保持している現在のセッション６００をアプリケーション５１０に通知することができる。そのためアプリケーション５１０から見ると、エラーの発生した部位を容易に推定することができるようになり、体系的なデバッグに役立つ。
【００６３】
（２）複数のコンピュータ１１０ａ〜１１０ｉから非同期的に発生する多数の通知３４０が統合されてアプリケーション５１０に送られる。そのためアプリケーション５１０には、それぞれのセッション６００に対して行うべき処理を記述すればよく、またセッション６００の実行される順番で書き下ろすことができる。また通知３６０を待つループを書く必要がなくなるので、ソースコードの可読性が高まる。
【００６４】
（３）セッションの前後関係・包含関係を変更せずに、並列処理の実行順序を見直し、ミドルウェアを改良していくことができる。アプリケーション５１０は、セッション６００の前後関係・包含関係のみを利用して設計されているので、ミドルウェアを改良しても正しく動作することが保証される。
【００６５】
（４）並列処理の手順が大きく変わっても、アプリケーション５１０では開始通知・終了通知に対する処理を書き換えるだけである。そのため並列化するべき処理がたくさんある場合でも、それぞれの処理を類似の構造で書くことができ、ソースコードの管理が非常に容易になる。
【００６６】
（５）個々のコンピュータの動作タイミングについて考慮する必要がないので、ミドルウェアと同じセッション６００の仕様を持つシミュレータを作ることができる。このシミュレータを使うことで、クラスタコンピュータを用意しなくても、並列処理を行うアプリケーションを開発することができる。
【００６７】
（６）メイン処理からの指示があっても、すぐにサブ処理の実行が始まるとは限らない。したがってメイン処理は、サブ処理を実行するタイミングを管理する責任から解放される。サブ処理の管理をミドルウェアに任せるようにすれば、アプリケーションがきわめて簡単なものになる。
【実施例２】
【００６８】
実施例２と実施例３では、実施例１で説明したクラスタコンピュータミドルウェア５００を活用するシステムを取り上げ、具体的なアプリケーション５１０を作成する方法について説明する。実施例２では天気図作成システム７００を、実施例３では３次元画像処理システム８００を例に取り上げる。
【００６９】
始めに本発明を天気図作成システムに応用した実施例を説明する。
【００７０】
図１１に、本発明によるクラスタコンピュータミドルウェア５００を利用する、天気図作成システム７００の構成を示す。天気図作成システム７００は、天気図作成アプリケーション７０１とクラスタコンピュータ１００によって構成されており、地形データ７１１と地方別気象データ７１２ａ〜７１２ｈをもとに全国の天気図７２０を作成する機能を持つ。クラスタコンピュータ１００は、本発明によるクラスタコンピュータミドルウェア５００を使って構成されている。
【００７１】
天気図作成システム７００では、処理に要する時間を短縮するため、地方別に天気図７２０を作成した後、それらをつなぎ合わせて全国の天気図７２０を作成する。地方別の天気図７２０を作成するには、地形データ７１１と、その地方に対応する地方別気象データ７１２が必要である。すなわちクラスタコンピュータ７０２を構成するスレーブノードには、マスタノードからこれらのデータを分配しなければならない。
【００７２】
地形データ７１１と地方別気象データ７１２ａ〜７１２ｇのうち、地形データ７１１は時間とともに変化することのないデータなので、システムを立ち上げた時にそれぞれのスレーブノードに分配しておけばよい。しかし地方別気象データ７１２ａ〜７１２ｇは、時々刻々と変化するデータなので、処理のたびに最新のデータを分配する必要がある。このように一部の素材データを削除せずに残しておくような処理手順を採用することで、この素材データをスレーブノードに分配するのに必要な時間を省くことができる。
【００７３】
以上のような処理手順を実現するには、図６や図７に示したセッション６００の開始・終了イベントに対し、アプリケーションを次のように動作させればよい。
（１）Ｄｅｌｉｖｅｒセッションの開始イベント
すでに地形データ７１１がスレーブノードに分配されているかどうかを調べ、分配されていなければ、地形データ７１１をそれぞれのスレーブノードにコピーするように指示する。
（２）Ｂａｔｃｈセッションの開始イベント
地方別気象データ７１２ａ〜７１２ｇを、それぞれのスレーブノードにコピーするように指示する。
（３）Ｒｅｃｅｉｖｅセッションの開始イベント
地方別の天気図７２０をマスタノードにコピーするように指示する。
（４）Ｒｅｃｅｉｖｅセッションの終了イベント
マスタノードにコピーされた地方別の天気図７２０から、全国の天気図７２０を作成する。
（５）Ｗａｓｔｅセッションの開始イベント
地方別気象データ７１２と地方別の天気図７２０を削除するように指示する。
【００７４】
以上のようにクラスタコンピュータミドルウェア５００を使用すると、五つのイベントに対する処理を記述するだけで、簡単に上記の並列処理手順を実装することができる。
【実施例３】
【００７５】
次に本発明を３次元画像処理システムに応用した例について説明する。
【００７６】
図１２に、本発明によるクラスタコンピュータミドルウェア５００を利用する、３次元画像処理システム８００の構成を示す。３次元画像処理システム８００は、３次元画像処理アプリケーション８０１とクラスタコンピュータ１００によって構成されており、３次元形状データ８１１にレンダリング条件８１２を適用して表示用のレンダリング画像８２０を作成する機能を持つ。クラスタコンピュータ１００は、本発明によるクラスタコンピュータミドルウェア５００を使って構成されている。
【００７７】
３次元画像処理システム８００では、処理に要する時間を短縮するため、表示領域を分割してレンダリングを行う。この処理には、３次元形状データ８１１とレンダリング条件８１２が必要である。すなわちクラスタコンピュータ８０２を構成するスレーブノードには、マスタノードから３次元形状データ８１１を分配してから、レンダリング条件８１２を伝え、さらにスレーブノードごとに異なる表示領域を指示して処理をさせることになる。すべてのスレーブノードの負荷を均一にするには、表示領域の分割を、スレーブノードの数に対して充分に細かくしておくことが望ましい。そのためスレーブノードで処理が終了したら、マスタノードはすぐ次の表示領域をスレーブノードに指示し、次の処理をさせるように動作しなければならない。
【００７８】
以上のような処理手順を実現するには、図６や図７に示したセッション６００の開始・終了イベントに対し、アプリケーションを次のように動作させればよい。
（１）Ｄｅｌｉｖｅｒセッションの開始イベント
３次元形状データ８１１をすべてのスレーブノードにコピーするように指示する。
（２）Ｅｘｅｃｕｔｅセッションの開始イベント
Ｂａｔｃｈセッションの番号に対応する表示領域を求め、レンダリング条件８１２とともにスレーブノードに伝えるよう指示する。
（３）Ｒｅｃｅｉｖｅセッションの開始イベント
分割されたレンダリング画像８２０をマスタノードにコピーするように指示する。
（４）Ｒｅｃｅｉｖｅセッションの終了イベント
マスタノードにコピーされた、分割されたレンダリング画像３２０から、一つのまとまったレンダリング画像８２０を合成する。
（５）Ｗａｓｔｅセッションの開始イベント
分割されたレンダリング画像８２０を削除するように指示する。
（６）Ｃｌｅａｎセッションの開始イベント
すべてのスレーブノードにコピーされた３次元形状データ８１１を削除するように指示する。
【００７９】
以上のようにクラスタコンピュータミドルウェア５００を使用すると、六つのイベントに対する処理を記述するだけで、簡単に上記の並列処理手順を実装することができる。
【００８０】
さらに天気図作成システム７００と３次元画像処理システム８００では、並列処理手順が異なるにもかかわらず、アプリケーション５１０はいずれも、セッションの開始・終了イベントに対する処理の集まりとして記述される。このようにソースコードの書き方が並列処理手順に依存しなくなることも、クラスタコンピュータミドルウェア５００を使用する利点である。
【実施例４】
【００８１】
次に、本発明を応用したクラスタコンピュータシミュレータについて説明する。
【００８２】
本発明によるクラスタコンピュータシミュレータ９００の構成を図１３に示す。本発明によるクラスタコンピュータシミュレータ９００を構成する要素の多くは、クラスタコンピュータミドルウェア５００と共通するものである。しかし１台のコンピュータで動作するクラスタコンピュータシミュレータ９００では、実際のコンピュータ１１０の代わりにコンピュータシミュレータ９１０ａ、９１０ｂ〜９１０ｉが使用されている。スレーブコンピュータやスレーブモジュールに関係する要素も除去されている。またコンピュータインタフェース５０３の代わりにコンピュータシミュレータインタフェース９０３が使用され、通信ネットワーク１２０を経由して送られる指示３３０と通知３４０の代わりに、通信を伴わない模擬的な指示３７０と模擬的な通知３８０が使用されている点も異なる。しかしクラスタコンピュータシミュレータ９００とクラスタコンピュータミドルウェア５００では、セッションの位相構造とアプリケーションインタフェース５１０が同一である。したがってクラスタコンピュータシミュレータ９００とリンクして正しく動作するアプリケーション５１０は、クラスタコンピュータミドルウェア５００とリンクしても正しく動作することが保証されている。
【００８３】
コンピュータシミュレータ９１０は、個々のコンピュータ１１０の動作を模擬するシミュレータで、独立に動作する複数のコンピュータ１１０の動作を正確に模擬するため、それぞれ独立したスレッド（プログラムの内部で同時に実行することのできる処理の単位）として実装されている。
【００８４】
クラスタコンピュータシミュレータ９００の画面の一例を図１４に示す。この画面には、ＩＰアドレスが表示された複数の円形が表示されており、それぞれがコンピュータシミュレータ９１０に対応している。コマンドメニュー１００１を操作すると、円形を追加・削除したりＩＰアドレスを変えたりすることができ、実際に使用するクラスタコンピュータと同じ構成を作ることができる。
【００８５】
クラスタコンピュータシミュレータ９００が動作している時には、それぞれのコンピュータシミュレータ９１０の状態によって画面がリアルタイムに変化する。細い輪郭の円形１０１０は、休止中のコンピュータシミュレータ９１０を、太い輪郭の円形１０１１は、処理実行中のコンピュータシミュレータ９１０を表している。また矢線１０１２はデータのコピーを表している。
【００８６】
円形をマウスでクリックすると、コンピュータシミュレータ９１０が保持しているデータ（ファイル・メモリ）を表示させることができる。この機能を使うと、スレーブコンピュータが処理を開始する前に必要なデータが正しく配布されたかどうか、一連の処理が終わった時点で不要なデータが残されていないかどうかを確認することができ、信頼性の高いアプリケーション５１０の開発に役立つ。
【実施例５】
【００８７】
本発明の第５の実施例になる、クラスタコンピュータミドルウェアについて説明する。
【００８８】
第５の実施例において、クラスタコンピュータ１００を構成している、マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉの内部の構成を図１５に模式的に示す。マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉには、それぞれクラスタコンピュータミドルウェア１２００とアプリケーション１３００が、マスタモジュールとスレーブモジュールに分割されてインストールされている。これらのコンピュータ１１０はそれぞれ、ネットワークインタフェース１１１と、メモリ１１２と、ディスク１１３を備えている。ディスク１１３には、クラスタコンピュータミドルウェア１２００と、アプリケーション１３００が格納されている。これらはメモリ１１２にロードされ、相互にリンクして動作する。ネットワークインタフェース１１１は、マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉを、ネットワーク１２０を介して相互に接続する。そのため任意のコンピュータ１１０の間でデータ通信が可能である。なお以下の記述では、誤解が生じないと思われる場合に限り、「マスタ」・「スレーブ」という表記を適宜省略する。
【００８９】
クラスタコンピュータミドルウェア１２００とアプリケーション１３００の内部の論理的構成を図１６に示す。クラスタコンピュータミドルウェア１２００の、マスタモジュール１２００ａとスレーブモジュール１２００ｂ〜１２００ｉは、それぞれ通信手段１２２０と、データコピー手段１２３０と、データ消去手段１２４０と、イベント発生手段１２５０を共通して備えている。またマスタモジュール１２００ａに限り、スケジューラ１２１０と、割り込み受理手段１２６０を備えている。
【００９０】
スケジューラ１２１０は、あらかじめ決められた処理手順に従い、データコピー手段１２３０や、データ消去手段１２４０や、イベント発生手段１２５０に指示を送る機能を持つ。これによって実際に、データのコピー、データの消去、イベントの発生が行われる。
【００９１】
通信手段１２２０は、スケジューラ１２１０から送られてくる指示、およびメモリ１１２やディスク１１３に格納されているメモリブロックやファイルのデータを、他のコンピュータに伝送するものである。これは通常、オペレーションシステム（ＯＳ）が提供するソケット通信の仕組みによって実装される。
【００９２】
データコピー手段１２３０は、スケジューラ１２１０から送られてくる指示を受け、メモリブロックやファイルのデータをコピーする機能を持つ。データのコピーを他のコンピュータに行う場合、通信手段１２２０を間接的に使用してデータを伝送する。これは通常、ＯＳが提供するディスク操作やメモリ操作の仕組みによって実装される。
【００９３】
データ消去手段１２４０は、スケジューラ１２１０から送られてくる指示を受け、メモリブロックやファイルのデータを消去する機能を持つ。これは通常、ＯＳが提供するディスク操作やメモリ操作の仕組みによって実装される。
【００９４】
イベント発生手段１２５０は、スケジューラ１２１０から送られてくる指示を受け、あらかじめアプリケーション１３００が設定したルーチンを実行する機能を持つ。このルーチンは「イベントハンドラ」と呼ばれる。これは通常、ＯＳが提供するルーチンコールバック（アプリケーションの機能をライブラリから使うこと）の仕組みによって実装される。イベントハンドラでは、データの作成・変換を含む任意の処理を行うことができる。またイベントハンドラの引数に、スケジューラ１２１０が備えている操作対象データリスト１２１２を渡すことも可能である。操作対象データリスト１２１２は、クラスタコンピュータミドルウェア１２００によってコピーあるいは消去されるデータ、もしくはコピーあるいは消去されたデータのリストである。アプリケーション１３００は操作対象データリスト１２１２に対し、データを識別するためのインデックス（メモリブロックのアドレス、ファイルの名前など）を追加したり、削除したりすることができる。クラスタコンピュータミドルウェア１２００では、実際にデータのコピーや消去が行われるタイミングをアプリケーション１３００から制御することができない。つまりアプリケーション１３００でデータのコピー・消去を制御・監視するには、イベントハンドラの中で操作対象データリスト１２１２を使い、操作対象となるデータを事前に設定したり、操作対象となったデータを事後に取得したりする方法を使わなければならない。イベントの発生するタイミングは、スケジューラ１２１０に任せられているが、各種のイベントが発生する順番を体系的に整理して理解しやすくするには、たとえば第１の実施例に記載したようなセッション６００の考え方を導入し、その開始と終了の際にイベントが発生するものと規定してもよい。
【００９５】
割り込み受理手段１２６０は、処理完了率の取得や処理の中断など、非同期的な処理の要求を受け付け、スケジューラ１２１０に知らせる機能を持つ。
【００９６】
アプリケーション１３００の、マスタモジュール１３００ａとスレーブモジュール１３００ｂ〜１３００ｉは、共通してイベントハンドラ設定手段１３１０を備えている。またアプリケーション１３００のマスタモジュール１３００ａに限り、割り込み要求手段１３２０を備えている。
【００９７】
イベントハンドラ設定手段１３１０は、イベント発生手段１２５０の動作によって実行される、イベントハンドラを設定する機能を持つ。これは通常、ＯＳが提供するルーチンコールバックの仕組みによって実装される。
【００９８】
割り込み要求手段１３２０は、処理完了率の取得や処理の中断など、非同期的な処理をスケジューラ１２１０に要求する機能を持つ。これは通常、ＯＳが提供するルーチンエクスポート（ライブラリの機能をアプリケーションから使うこと）の仕組みによって実装される。処理完了率の取得は通常、ＯＳが提供するタイマによって行われる。また処理の中断は通常、ユーザの操作によって行われる。
【００９９】
以上の構成により、クラスタコンピュータ１００では、スケジューラ１２１０が個々のコンピュータ１１０におけるデータのコピー、データの消去、イベントの発生を集中的に制御することができる。これらの三つの操作は、さまざまな並列処理を実現する要素となるものである。あらゆる並列処理は、これらの要素的な操作の組み合わせによって実現することができる。つまりクラスタコンピュータ１００が正しく動作するかどうかは、スケジューラ１２１０がスケジューリングを正しく行うかどうかに依存する。
【０１００】
スケジューラ１２１０の動作（スケジューリング）を支配する処理手順１４００の例を図１７に示す。処理手順１４００は、階層的にいくつかの部分に分けられている。それぞれの部分で行われる処理は次のとおりである。
（１）Ｃｏｐｙ部分１４０１
ノードにある一つのデータを、他のノードにコピーする。
（２）Ｄｅｌｅｔｅ部分１４０２
ノードにある一つのデータを削除する。
（３）Ｓｅｎｄ部分１４０３
マスタノードにあるデータを、スレーブノードにコピーする。
（４）Ｅｘｅｃｕｔｅ部分１４０４
スレーブノードにタスクを実行させる。
（５）Ｒｅｃｅｉｖｅ部分１４０５
スレーブノードにあるデータを、マスタノードにコピーする。
（６）Ｗａｓｔｅ部分１４０６
スレーブノードにあるデータを削除する。
（７）Ｂａｔｃｈ部分１４０７
一つのスレーブノードに分散処理をさせる。
（８）Ｄｅｌｉｖｅｒ部分１４０８
マスタノードにあるデータを、すべてのスレーブノードにコピーする。
（９）Ｒａｃｅ部分１４０９
すべてのスレーブノードに分散処理をさせる。
（１０）Ｃｌｅａｎ部分１４１０
すべてのノードにあるデータを削除する。
（１１）Ｏｐｅｒａｔｅ部分１４１１
クラスタコンピュータ１００を動作させる。
【０１０１】
なおここでは、スケジューラ１２１０が管理しているコンピュータ１１０のことを「ノード」と呼ぶ。スケジューラ１２１０は、マスタコンピュータ１１０ａで動作しながら、後述するノードリスト１５１０を使用することにより、マスタノードとスレーブノードの両方を一元的に管理している。
【０１０２】
スケジューラ１２１０はスケジューリングを行うにあたり、データ配置テーブル１２１２とノード属性テーブル１２１３を使用する。
【０１０３】
データ配置テーブル１２１２は、たとえば図１８に示すデータ構造により、個々のコンピュータ１１０が保持しているデータを把握・管理する機能を持つ。ノードリスト１５１０は、クラスタコンピュータ１００に含まれるコンピュータ１１０のリストであり、それぞれのコンピュータ１１０に対応する要素である、ノードを保持している。それぞれのノードはデータリスト１５２０を保持している。データリスト１５２０は、コンピュータ１１０が保持しているデータ（メモリブロック・ファイル）のリストである。
【０１０４】
データ配置テーブル１２１２は、スケジューラ１２１０がデータをコピーさせたり、消去させたりするたびに自動的に更新される。そのためスケジューラ１２１０は、データ配置テーブル１２１２を参照することで、その時点でのデータの配置状況を知ることができる。
【０１０５】
ノード属性テーブル１２１３は、たとえば図１９に示すデータ構造により、個々のコンピュータ１１０（ノード）に関する属性１５３０や、状態１５４０を把握・管理する機能を持つ。ノードの属性１５３０には、次のようなものが含まれる。
（１）ＩＰアドレス
（２）処理速度の計測値
またノードの状態１５４０には、次のようなものが含まれる。
（３）処理中かどうか（イベントハンドラを実行しているかどうか）
（４）通信中かどうか（ネットワークを使用しているかどうか）
（５）故障中かどうか
ノード属性テーブル１２１３に保持されるノードの状態１５４０も、スケジューラ１２１０の動作（スケジューリング）に伴って更新される。そのためスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、その時点でのノードの状態１５４０を知ることができる。
【０１０６】
次にスケジューラ１２１０がスケジューリングを行う際、どのようにデータ配置テーブル１２１２とノード属性テーブル１２１３を使用するかを説明する。ここでは処理手順１４００を例に、次の六つの場合について説明する。
（１）データの一括配布（Ｄｅｌｉｖｅｒ部分１４０８の実行）
（２）データの一括消去（Ｃｌｅａｎ部分１４１０の実行）
（３）分散処理（Ｒａｃｅ部分１４０９の実行）
（４）処理完了率の取得
（５）処理の中断
（６）スレーブコンピュータ１１０ｂ〜１１０ｉの故障。
【０１０７】
（１．データの一括配布）
Ｄｅｌｉｖｅｒ部分１４０８では、操作対象データリスト１２１１に含まれているデータを、マスタノードからすべてのスレーブノードにコピーする。この動作を実現するため、スケジューラ１２１０はデータ配置テーブル１２１２を参照し、そのデータを保持しているノードと保持していないノードを、それぞれ一つずつ選定する。この選定には乱数を使ってもよいし、コンピュータ１１０がネットワーク１２０に接続されているトポロジを利用してもよい。たとえば複数のハブを含む木構造のトポロジを持つネットワーク１２０では、ハブを結ぶ伝送路の通信量が他の伝送路に比べて非常に大きくなる傾向がある。そこでハブの経由数の大きい、つまり送信元のノードから位相的に離れているノードに対して優先的にデータをコピーするようにすると、ハブを結ぶ伝送路には一度だけしかデータが通さないようになるので、システムの性能が向上する。
【０１０８】
現在の状態が処理中あるいは通信中のノードは、データの送受信を行うことができない。そこでスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、これらのノードの使用を避けるようにする。データの送信元のノードと受信先のノードが決まった時点で、スケジューラ１２１０は送信元のノードに対し、受信元のノードにデータを送るように指示する。データのコピーが始まったら、ノード属性テーブル１２１３を更新し、送信元のノードと受信先のノードの状態を通信中に変える。データのコピーが終わったら、これらのノードの状態をもとに戻す。こうしてすべてのノードがそのデータを保持するようになるまで、上記の作業を繰り返す。
【０１０９】
（２．データの一括消去）
Ｃｌｅａｎ部分１４１０では、それぞれのノードに保持されているデータを消去する。この動作を実現するため、スケジューラ１２１０はノードを選定した上で、データ配置テーブル１２１２を参照し、そのノードが保持しているデータの一覧を取得する。その後ノードに対し、それぞれのデータを消去するように指示する。こうした作業をすべてのノードに対して行う。
【０１１０】
（３．分散処理）
Ｒａｃｅ部分１４０９では、本来行うべき処理の全体を細かく分割した部分的な処理（タスク）を、それぞれのスレーブノードに実行させる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、個々のタスクをイベントハンドラとしてあらかじめ設定しておく。そのためスケジューラ１２１０の動作は、現在の状態が処理中でも通信中でもないノードを見つけ、イベントを発生させるように指示する動作になる。ノードの状態を把握するには、ノード属性テーブル１２１３を参照する。使用可能なノードが見つかった場合、その中から一つを選定する。この選定には乱数を使ってもよいし、個々のノードの処理速度の計測値がわかっている場合には、最後近くのタスクに対し、処理速度の遅いノードを割り当てないような方法を採ってもよい。最後のタスクを遅いノードに実行させると、それがシステム全体を待たせてしまい、性能を低下させるからである。ノードがイベントハンドラを実行し始めたら、スケジューラ１２１０はノード属性テーブル１２１３を更新し、ノードの状態を処理中に変える。またイベントハンドラを実行し終えたら、ノードの状態をもとに戻す。こうして分割されたすべてのタスクが実行されるまで、上記の作業を繰り返す。
【０１１１】
（４．処理完了率の取得）
処理完了率の取得では、個々のタスクについて完了率を求め、それらの平均を算出する。ノード属性テーブル１２１３を参照することで、現在タスクを実行しているノードを知ることができる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、タスクの完了率を求めるイベントハンドラを用意し、あらかじめ設定しておくことができる。そのためタスクを実行しているノードを知ったスケジューラ１２１０は、そのノードに対してイベントを発生させるように指示し、タスクの完了率を知ることができる。こうしてすべてのタスクに対して同様の操作を行い、最終的に平均を求めて、アプリケーション１３００の割り込み要求手段１３２０に返す。
【０１１２】
（５．処理の中断）
処理の中断では、実行中のすべてのタスクを中断させるとともに、配布された一時的なデータを消去しなければならない。タスクの中断についてスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、現在タスクを実行しているノードを知ることができる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、タスクを中断させるイベントハンドラを用意しておくこともできる。すなわちスケジューラ１２１０は、タスクを実行しているすべてのノードに対し、イベントを発生させるように指示すればよい。
【０１１３】
また一時的なデータをすべて消去するには、データ配置テーブル１２１２を参照して一時的なデータの一覧を取得した上で、そのデータを保持しているノードに対し、それらのデータを消去させるように指示すればよい。
【０１１４】
（６．スレーブコンピュータ１１０ｂ〜１１０ｉの故障）
スレーブコンピュータ１１０ｂ〜１１０ｉのいずれかが故障した場合、ノード属性テーブル１２１３を更新し、故障したノードの状態を故障中に変える。これによってスケジューラ１２１０は、故障したノードの使用を避ける。その上で、故障したノードで実行されたタスクを、故障していない他のスレーブノードで再実行させる。タスクの再実行は、そのタスクを含むＢａｔｃｈ部分１４０７を再び実行させることで行うことができる。
【０１１５】
クラスタコンピュータミドルウェア１２００は、アプリケーション１３００に対し、スケジューラ１２１０の動作を開始させるためのルーチンをエクスポートしている。そのためアプリケーション１３００は、任意のタイミングでスケジューラ１２１０の動作を開始させることができる。しかし、ひとたびスケジューラ１２１０が動作を開始すると、制御はスケジューラ１２１０に移るので、その動作が終了するまで制御はアプリケーション１３００に戻らない。
【０１１６】
クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、時間とともに制御が移動する様子を図２０に示す。ここでは「シーケンシャル」と「イベントドリブン」という語句を使用するが、これらの語句の定義については後述することにして、まずは説明を先に述べる。初期状態ではアプリケーション１３００が制御を持っている。アプリケーション１３００は、「シーケンシャル」に前処理１６１０を実行した後、並列処理１６２０も同じく「シーケンシャル」に開始させる。これによってスケジューラ１２１０の動作（スケジューリング１６４０）が開始される。並列処理１６２０の実際の処理は、スケジューラ１２１０の動作が終了するのを待ちながら、その間にイベントが発生したら、それに対応するイベントハンドリング１６４１・１６４２・１６４３を実行する処理である。すなわちイベントハンドリング１６４１・１６４２・１６４３は、スケジューリング１６４０の進行に伴い、「イベントドリブン」に実行される。最終的に処理手順が完了し、スケジューラ１２１０の動作が終了すると、制御は再びアプリケーション１３００に戻され、並列処理１６２０に続く後処理１６３０が「シーケンシャル」に実行される。
【０１１７】
ここで「シーケンシャル」とは、プログラムに書かれたとおりのタイミングで実行される、あるいはソースコードから予測される順番で実行されることを意味する。これに対して「イベントドリブン」とは、必ずしもプログラムに書かれたとおりのタイミングで実行されない、あるいはソースコードから予測することのできない順番で実行されることを意味する。これらの区別は、アプリケーション１３００のソースコードを見るとわかりやすい。ソースコードについては後述する。
【０１１８】
実際のクラスタコンピュータミドルウェア１２００とアプリケーション１３００は、それぞれマスタモジュールとスレーブモジュールに分割されているので、制御が移動する様子は図２０よりも実際には複雑で、図２１のようになる。ここで注意する必要があるのは、複数のコンピュータ１１０で構成されるクラスタコンピュータ１００では、イベントハンドリング１６４１〜１６４７のうちのいくつかがまったく同時に終了する可能性があるということである。そこでスケジューラ１２１０には、同時に受け取った終了通知を時系列的に並べ替える（シリアライズする）手段を設ける必要がある。これはたとえば、待ち行列（キュー）やＦＩＦＯバッファを使って実現することができる。
【０１１９】
またスケジューリング１６４０の方法によっては、必ずしも分割されたタスクの順番でイベントハンドリング１６４１〜１６４７が実行されるとは限らない。そこでスレーブコンピュータ１１０ｂ〜１１０ｉに、それぞれが実行するべきタスクの内容を伝えるため、イベントハンドラにはタスクを識別するための番号を引数として渡すようになっている。
【０１２０】
アプリケーション１３００のマスタモジュール１３００ａのソースコードを図２２に示す。前処理１６１０と、並列処理１６２０と、後処理１６３０は、シーケンシャルに実行される処理なので、ソースコードの上でもメインルーチン１７１０に連続して記述されている。これに対してイベントハンドリング１６４１・１６４２・１６４３は、イベント発生をトリガとして実行されるので、必ずしもソースコードの上に記述されている、イベントハンドラ１７２１・１７２２・１７２３の順番で実行されるとは限らない。イベント発生の順番は、スケジューラ１２１０が実際に動作した結果として決まってくる。それはスケジューラ１２１０の動作を支配している処理手順、コンピュータ１１０の台数や接続方法、コンピュータ１１０の性能のばらつき、割り込み処理の要求の有無、内部で使用している乱数の偶然性など、いろいろな要因によって動的に変化するものである。
【０１２１】
このように、本実施例によるクラスタコンピュータミドルウェア１２００における並列処理は、メインルーチン１７１０をブロックして（一時停止させて）動作するスケジューリングと、メインルーチン１７１０に対して非同期的に動作する複数のイベントハンドラ１７２１・１７２２・１７２３の組み合わせとして実現されている。
【０１２２】
このことは「アプリケーション１３００が、イベントドリブンに実行される処理（イベントハンドリング）のみで、並列処理を実装しなければならない」ことを意味する。これはアプリケーション１３００に対し、一種の制約を課すことになる。しかしこの制約を遵守することで、クラスタコンピュータ１００の実際の構成がアプリケーション１３００から隠される。その結果、アプリケーション１３００の開発者は、次の効果を享受することができる。
【０１２３】
（１）アプリケーション１３００に、個々のコンピュータ１１０を管理したり、スケジューリングを行ったりする仕組みを実装する必要がなくなるので、アプリケーション１３００の移植・開発が容易になる。
【０１２４】
（２）アプリケーション１３００が、コンピュータ１１０の台数やネットワーク１２０の種類に依存しなくなる。そのためアプリケーション１３００を、不特定多数のユーザに配布して使用させることができるようになる。
【０１２５】
（３）アプリケーション１３００が行うべき並列処理を、形式の揃ったイベントハンドラの集合として記述することができるので、ソースコードが読みやすくなる。またイベントハンドラの処理内容を変えれば、さまざまな並列処理を記述することもできる。すなわちソースコードの可読性と、処理手順の自由度を両立させることができる。
【０１２６】
（４）アプリケーション１３００がスケジューラ１２１０の処理手順に依存しなくなるので、将来の上位互換性が保証される。スケジューラ１２１０が改良されても、アプリケーション１３００を修正する必要がなくなる。
【０１２７】
（５）現在イベントハンドリングを行っているコンピュータ１１０や、個々のコンピュータ１１０に保持されているデータを、スケジューラ１２１０が知ることができる。そのため処理完了率の取得や、処理の中断といった割り込み処理の要求に対し、スケジューラ１２１０が個々のコンピュータ１１０に対して適切な指示を自動的に割り振ることができる。そのためこのような仕組みをアプリケーション１３００に実装する必要がなくなる。
【０１２８】
（６）クラスタコンピュータ１００と同一の処理手順のスケジューラ１２１０を持つクラスタシミュレータを用意すれば、実際にクラスタコンピュータ１００を用意しなくても、アプリケーション１３００を動作させることができる。そのためアプリケーション１３００のチーム開発・先行開発や、マスタモジュール１３００ａとスレーブモジュール１３００ｂ〜１３００ｉのクロスデバッグが可能になる。
【０１２９】
以上のとおり、本発明の実施例５によれば、マスタモジュールとスレーブモジュールから構成されるクラスタコンピュータミドルウェアに、アプリケーションの処理を一時的にブロックして動作するスケジューラと、スケジューラからの指示を受けてアプリケーションが事前に設定したイベントハンドラを実行する手段を備えている。これにより、多大な費用・労力や高度な知識・技術を必要とせず、並列アプリケーションを開発することのできる環境を提供することができる。また高い拡張性と上位互換性を持つ並列アプリケーションを開発することのできる環境を提供することができる。
【図面の簡単な説明】
【０１３０】
【図１】クラスタコンピュータ１００のハードウェア構成例を示す図である。
【図２】簡単な並列処理手順の一例を示す図である。
【図３】本発明の一実施例になるクラスタコンピュータミドルウェア５００の構成を示す図である。
【図４】本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの性質を示す図である。
【図５】本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの関係を、図形を使って表記する方法を示す図である。
【図６】本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの位相構造を示す図である。
【図７】図６に示した各セッションで行われる処理の内容を示す図である。
【図８】本発明の一実施例になるクラスタコンピュータミドルウェア５００を使用するアプリケーションの構成を示す図である。
【図９】本発明の一実施例になるクラスタコンピュータミドルウェア５００のマスタモジュールと、アプリケーション５１０のマスタモジュールが行う、情報交換の内容を示す図である。
【図１０】本発明の一実施例になるクラスタコンピュータミドルウェア５００を使用して並列化されたアプリケーションのマスタモジュールのソースコードを模式的に示す図である。
【図１１】本発明の他の実施例になる天気図作成システム７００の構成を示す図である。
【図１２】本発明の他の実施例になる３次元画像処理システム８００の構成を示す図である。
【図１３】本発明の他の実施例になるクラスタコンピュータシミュレータ９００の構成を示す図である。
【図１４】図１３の実施例における、クラスタコンピュータシミュレータ９００の画面の一例を示す図である。
【図１５】図３の実施例における、コンピュータ１１０の内部の構成を模式的に示す図である。
【図１６】図３の実施例における、クラスタコンピュータミドルウェア１２００とアプリケーション１３００の内部の論理的構成を示す図である。
【図１７】処理手順１４００の例を示す図である。
【図１８】データ配置テーブル１２１２のデータ構造を例示する図である。
【図１９】ノード属性テーブル１２１３のデータ構造を例示する図である。
【図２０】クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、制御が移動する様子を示す図である。
【図２１】クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、制御が移動する様子を詳しく示す図である。
【図２２】アプリケーション１３００のマスタモジュール１３００ａのソースコードを示す図である。
【図２３】従来のクラスタコンピュータミドルウェアのマスタモジュールと、アプリケーションのマスタモジュールが行う、情報交換の内容を示す図である。
【図２４】アプリケーションのソースコードを模式的に示す図である。
【図２５】従来のクラスタコンピュータミドルウェアを使用して並列化されたアプリケーションのマスタモジュールのソースコードを模式的に示す図である。
【符号の説明】
【０１３１】
１００  クラスタコンピュータ
１１０  コンピュータ
１１０ａ  （マスタ）コンピュータ
１１０ｂ〜１１０ｉ  （スレーブ）コンピュータ
１１１  ネットワークインタフェース
１１２  メモリ
１１３  ディスク
１２０  通信ネットワーク
１３１  ディスプレイ
１３２  キーボード
１３３  マウス
２１０  素材データ
２２０  結果データ
２２１  結果データ（断片）
３１０  （個別に送られる、アプリケーションから分配統合制御手段への）指示
３２０  （個別に送られる、分配統合制御手段からアプリケーションへの）通知
３３０  （分配統合制御手段からコンピュータへの）指示
３４０  （コンピュータから分配統合制御手段への）通知
３５０  （アプリケーションから分配統合制御手段への）指示
３５１  セッション開始指示
３５２  セッション処理内容指示
３６０  （分配統合制御手段からアプリケーションへの）通知
３６１  セッション開始通知
３６２  セッション終了通知
３７０  （分配統合制御手段からコンピュータシミュレータへの）模擬的な指示
３８０  （コンピュータシミュレータから分配統合制御手段への）模擬的な通知４１０  グローバル変数
４２０  （通知３２０をトリガとして実行される）処理ブロック
４３０  （特定の処理をトリガとして実行される）処理ブロック
５００  クラスタコンピュータミドルウェア
５００Ｍ  クラスタコンピュータミドルウェア（マスタモジュール）
５００Ｓ  クラスタコンピュータミドルウェア（スレーブモジュール）
５０１  アプリケーションインタフェース
５０２  分配統合制御手段
５０３  コンピュータインタフェース
５０４  セッション保持手段
５０５  セッション更新手段
５１０  アプリケーション
５１０Ｍ  アプリケーション（マスタモジュール）
５１０Ｓ  アプリケーション（スレーブモジュール）
５１１  開始イベントハンドラ
５１２  終了イベントハンドラ
５１３  アドレス公開手段
５２０  アドレス
６００、６００Ａ、６００Ｂ  セッション
６０１  Ｃｏｐｙセッション
６０２  Ｄｅｌｅｔｅセッション
６０３  Ｓｅｎｄセッション
６０４  Ｅｘｅｃｕｔｅセッション
６０５  Ｒｅｃｅｉｖｅセッション
６０６  Ｗａｓｔｅセッション
６０７  Ｂａｔｃｈセッション
６０８  Ｄｅｌｉｖｅｒセッション
６０９  Ｒａｃｅセッション
６１０  Ｃｌｅａｎセッション
６１１  Ｏｐｅｒａｔｅセッション
７００  天気図作成システム
７０１  天気図作成アプリケーション
７１１  地形データ
７１２、７１２ａ〜７１２ｈ  地方別気象データ
７２０  天気図
８００  ３次元画像処理システム
８０１  ３次元画像処理アプリケーション
８１１  ３次元形状データ
８１２  レンダリング条件
８２０  レンダリング画像
９００  クラスタコンピュータシミュレータ
９０３  コンピュータシミュレータインタフェース
９１０  コンピュータシミュレータ
９１０ａ  （マスタ）コンピュータシミュレータ
９１０ｂ〜９１０ｉ  （スレーブ）コンピュータシミュレータ
１００１  コマンドメニュー
１０１０  細い輪郭の円形
１０１１  太い輪郭の円形
１０１２  矢線
１２００  クラスタコンピュータミドルウェア
１２００ａ  クラスタコンピュータミドルウェアのマスタモジュール
１２００ｂ〜１２００ｉ  クラスタコンピュータミドルウェアのスレーブモジュール
１２１０  スケジューラ
１２１１  操作対象データリスト
１２１２  データ配置テーブル
１２１３  ノード属性テーブル
１２２０  通信手段
１２３０  データコピー手段
１２４０  データ消去手段
１２５０  イベント発生手段
１２６０  割り込み受理手段
１３００  アプリケーション
１３００ａ  アプリケーションのマスタモジュール
１３００ｂ〜１３００ｉ  アプリケーションのスレーブモジュール
１３１０  イベントハンドラ設定手段
１３２０  割り込み要求手段
１４００  処理手順
１４０１  Ｃｏｐｙ部分
１４０２  Ｄｅｌｅｔｅ部分
１４０３  Ｓｅｎｄ部分
１４０４  Ｅｘｅｃｕｔｅ部分
１４０５  Ｒｅｃｅｉｖｅ部分
１４０６  Ｗａｓｔｅ部分
１４０７  Ｂａｔｃｈ部分
１４０８  Ｄｅｌｉｖｅｒ部分
１４０９  Ｒａｃｅ部分
１４１０  Ｃｌｅａｎ部分
１４１１  Ｏｐｅｒａｔｅ部分
１５１０  ノードリスト
１５２０  データリスト
１５３０  属性
１５４０  状態
１６１０  前処理
１６２０  並列処理
１６３０  後処理
１６４０  スケジューリング
１６４１〜１６４７  イベントハンドリング
１７１０  メインルーチン
１７２１、１７２２、１７２３  イベントハンドラ。
【図１】
2006228192.tif 000003
【図２】
2006228192.tif 000004
【図３】
2006228192.tif 000005
【図４】
2006228192.tif 000006
【図５】
2006228192.tif 000007
【図６】
2006228192.tif 000008
【図７】
2006228192.tif 000009
【図８】
2006228192.tif 000010
【図９】
2006228192.tif 000011
【図１０】
2006228192.tif 000012
【図１１】
2006228192.tif 000013
【図１２】
2006228192.tif 000014
【図１３】
2006228192.tif 000015
【図１４】
2006228192.tif 000016
【図１５】
2006228192.tif 000017
【図１６】
2006228192.tif 000018
【図１７】
2006228192.tif 000019
【図１８】
2006228192.tif 000020
【図１９】
2006228192.tif 000021
【図２０】
2006228192.tif 000022
【図２１】
2006228192.tif 000023
【図２２】
2006228192.tif 000024
【図２３】
2006228192.tif 000025
【図２４】
2006228192.tif 000026
【図２５】
2006228192.tif 000027