JP3375649B2 - 並列計算機 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は並列計算機の構成法に関
する。

【０００２】

【従来の技術】従来、ローカルメモリを持ち、独立に動
作可能な複数のプロセッサから構成されるクラスタを複
数用いて構成され、他のクラスタとの間でデータを相互
に通信する並列計算機においては、プロセス間通信をす
るときに、送信クラスタではユーザ空間からオペレーテ
ィングシステム内のカーネル空間へのデータのコピー
を、受信クラスタではオペレーティングシステム内のカ
ーネル空間からユーザ空間へのデータのコピーを行なっ
ていた。例えば、イーサネットで結合された、ＵＮＩＸ
オペレーティングシステムを搭載した複数のワークステ
ーションでの通信がこれに当たる。

【０００３】一方、ローカルメモリを持つ複数のプロセ
ッサエレメントからなり、他のプロセッサエレメントか
らローカルメモリにデータを書き込める並列計算機にお
いて、あるプロセッサエレメントが他のプロセッサエレ
メントのローカルメモリを介してデータを受け渡すとき
に、ローカルメモリの一部または全部の語にタグを設け
ておき、このタグでその語の内容が有効か無効かを表す
ようにした装置がある。例えば、特開平１−１９４０５
５において論じられている装置がこれに相当する。

【０００４】

【発明が解決しようとする課題】上記従来技術のうち前
者においては、各クラスタにオペレーティングシステム
が動作しているために複数のプロセスが同時に１つのク
ラスタで動作することができるため、並列計算機で実行
するプログラムにより生成されるユーザプロセスの数が
このプログラムを実行するために割当てられたクラスタ
の数と等しくない場合にも、各ユーザプロセスに対応し
て仮想空間を割当てることによりこのプログラムを実行
することができる。そのため、ユーザプロセス間のデー
タ転送とは、具体的には送信元のプロセスに対応する仮
想空間の中のデータを、送信先のプロセスに対応する仮
想空間の中に転送することに相当する。しかも、オペレ
ーティングシステムの保護機構等により、仮にユーザプ
ログラムに誤りがあっても、このプログラムにかかわり
のないプロセスのデータを不当に破壊することがないよ
うに制御されている。

【０００５】あるクラスタから、そのクラスタの外部の
装置、例えばクラスタ間を結合するネットワークに、デ
ータを高速に送出するためには通常ＤＭＡ転送が用いら
れる。ＤＭＡ転送は、メモリアドレスをハードウェアに
より連続的に生成し、連続的にメモリからデータを読み
だすように、あるいはメモリにデータを書き込むように
構成されたＤＭＡコントローラという回路を用いること
により実現される。ところが、送信元プロセスの仮想空
間にあるデータをＤＭＡコントローラによりネットワー
クに送出しようとする場合、仮想空間にある送出すべき
データが、クラスタの実メモリにあるという保障がな
い。そのため、送出すべきデータが実メモリにあること
を保障するために、必要に応じてページインを行ない、
その後にＤＭＡコントローラに転送させるようにする必
要がある。ページインはオペレーティングシステムにの
み許された機能であるため、従来技術のデータ送信にお
いてはオペレーティングシステムが必ず介入することに
なる。

【０００６】このような準備の後、ＤＭＡコントローラ
によって連続的にデータ送出が行なわれたとしても、送
信先プロセスに対応する仮想空間中の、送出されたデー
タを格納すべき領域が、送信先クラスタの実メモリに割
当てられている保障がない。そのため、従来技術におい
ては、送信先クラスタのオペレーティングシステムは、
送出されたデータを格納するために実メモリ上に設けた
バッファ（受信バッファ）をオペレーティングシステム
内部に準備し、この中に送出されたデータをいったん格
納し、その後に必要に応じてページイン（これもオペレ
ーティングシステムが介入して実行する必要がある）を
実行してから送信先のプロセスに対応する仮想空間中の
データ格納領域にデータを転送する。

【０００７】しかし、例え送信先クラスタにこのような
受信バッファを設けても、送信先クラスタにとっては送
信元クラスタがいつどのくらいの量のデータを送出して
くるかを知る手段がないので、必要な大きさの受信バッ
ファをあらかじめ確保することができない。そのため、
従来技術では、送出されてきたデータの量が予想より大
きく、確保しておいた受信バッファの大きさを越える場
合には、送信先クラスタにおいて送信元クラスタが送出
したデータを受け取らず、必要な受信バッファを新たに
確保した後に、送信元クラスタから送信先クラスタにデ
ータを再送するようになっている。

【０００８】この再送を可能にするため、従来技術では
送信元クラスタのオペレーティングシステムの内部に送
信バッファを持ち、送信したいデータが送信先クラスタ
に確実に受け取られたことを確認するまで、送信したい
データを格納するようになっている。

【０００９】この送信バッファを実メモリに設ければ、
送信バッファに格納された送信したいデータをＤＭＡコ
ントローラにより連続的にネットワークに送出すること
ができる。それゆえ、従来技術では送信元プロセスに対
応する仮想空間にあるデータを送信先プロセスに転送す
る際には、送信元クラスタでは、上述したように必要に
応じてページインを行ないつつ、仮想空間にある送信し
たいデータを、実メモリにある送信バッファに転送し、
その後にＤＭＡコントローラによって送信バッファに格
納されたデータをネットワークに送出するようにインプ
リメントされている。

【００１０】以上で示したように、従来技術では送信元
プロセスに対応する仮想空間から、送信先プロセスに対
応する仮想空間にデータを転送する場合には、送信した
いデータが送信元クラスタのオペレーティングシステム
の介入のもとで、その中にある送信バッファを、さらに
送信先クラスタのオペレーティングシステムの介入のも
とで、その中にある受信バッファを経由することにな
る。バッファへのコピーは、送信したいデータ長にほぼ
比例するオーバヘッドをもたらす。このオーバヘッドは
並列計算機の性能を著しく低下させる恐れがある。

【００１１】一方、上記従来技術のうちの後者において
は、上記のデータのコピーのオーバヘッドはないもの
の、１つのクラスタの中で複数のプロセスを動作させる
ときにそれらのうちの特定の受信プロセスに対して他ク
ラスタの送信プロセスがローカルメモリを介してデータ
の受け渡しをするときに、受信プロセスと同じクラスタ
上で同時に動作しているプロセスのデータを送信プロセ
スが不当に変更する恐れがある。

【００１２】本発明の目的は、同一クラスタで複数プロ
セスが同時に動作し、あるプロセスが異なるクラスタ上
で動作するプロセスとの間でデータを受け渡すときに発
生するオペレーティングシステムによるオーバヘッドを
削減することにある。

【００１３】

【課題を解決するための手段】本発明の目的は、独立に
動作可能な１台以上のプロセッサと、この１台以上のプ
ロセッサに共有されるメモリとからなるクラスタを複数
用いて構成され、複数のクラスタを接続するネットワー
クを有し、該複数のクラスタのそれぞれにおいて少なく
とも１つの仮想空間が割当てられ、その仮想空間におい
て少なくとも１つのプロセスがオペレーティングシステ
ムの制御下で実行される並列プロセッサにおいて、クラ
スタ内のメモリに常駐し、仮想空間に配置された通信領
域をプロセスが持ち、あるクラスタ（送信元クラスタ）
で実行中のプロセス（送信元プロセス）から他のクラス
タ（送信先クラスタ）に割当てられた他のプロセス（送
信先プロセス）に送信すべきデータを、送信元プロセス
に割当てられた通信領域内の、送信データ用の位置に割
当てられた、送信元クラスタのメモリ内の位置から、送
信元プロセスを制御するオペレーティングシステム内部
に設けたバッファの介在なしに読み出し、その読み出さ
れたデータと、送信元プロセスおよびそれを制御するオ
ペレーティングシステムが管理する情報から生成される
送信先プロセスに関連する情報とを送信元クラスタから
送信先クラスタに送信し、送信先クラスタでは、このデ
ータを受信したとき、上記関連する情報と送信先クラス
タのオペレーティングシステムが管理する情報とにより
定まり、送信先プロセスに割当てられた通信領域内の、
受信データ用の位置に割当てられた、送信先クラスタの
メモリ内の位置を、受信データ記憶位置として決定し、
その受信したデータをその決定された受信データ記憶位
置に、送信先クラスタを制御するオペレーティングシス
テム内部に設けたバッファの介在なしに書き込むことに
より達成される。

【００１４】

【作用】本発明に係る並列計算機においては、送信すべ
きデータを格納し、また、送信されてきたデータを格納
するための仮想空間中の通信領域が、オペレーティング
システムによってクラスタ内のメモリに常駐するように
制御されている。そのため、送信元クラスタが送信元プ
ロセスが実行される仮想空間からデータを読み出し、こ
れをネットワークを経由して送信先クラスタに転送し、
送信先クラスタが送信されたデータを格納する送信先プ
ロセスの仮想空間内の位置を決定し、そこに送信された
データを書き込む一連の動作において、ページフォルト
が発生することがない。

【００１５】それゆえ、送信元クラスタが送信したデー
タが、確実に送信先クラスタの実メモリに書き込まれる
ことが保証される。そのため、従来の技術に見られるよ
うな、送信されたデータが送信先クラスタのメモリに書
き込まれないような事態が発生しても、再度データを送
信できるようにするために、送信元クラスタのオペレー
ティングシステムの中に設ける送信バッファを、本発明
では設ける必要がない。同様にして、送信元クラスタの
受信バッファも不要になる。そのため、必要最小限であ
る送信元プロセスのメモリ領域から、送信先プロセスの
メモリ領域への１回のコピーのみで転送が終了し、その
結果として、従来技術に比べ送信元プロセスから送信先
プロセスにデータを転送する場合に発生するオーバヘッ
ドを著しく低減することが可能になる。

【００１６】さらに、上記転送においては、送信元プロ
セスが生成する情報に加え、送信元クラスタおよび送信
先クラスタのオペレーティングシステムが管理する情報
を用いてデータの読みだしおよび書きこみを行なうの
で、送信元プロセスのプログラムに誤りがあっても、デ
ータの不当な変更が生じないようにできる。

【００１７】

【実施例】

（第１実施例）以下、本発明の第１の実施例を図１を用
いて説明する。図１は本発明に係る並列計算機を示す。
本実施例では複数のクラスタ１００がネットワーク４に
より結合されている。図では、一つのクラスタ１００の
構成を示すが、他のクラスタ１００は図示されていな
い。図１において、１はＣＰＵであり、従来技術による
マイクロプロセッサと同様の構成であってよい。図１で
は簡単のためにＣＰＵは１つしか書かれていないが、各
クラスタ１００は２台以上のＣＰＵからなる密結合マル
チプロセッサである。ただし本発明は各クラスタ１００
がシングルプロセッサからなるときにも有効である。２
はクラスタ１００の主記憶として用いるメモリであり、
従来技術を用いてＣＰＵ１や外部のデバイス（図示せ
ず）からバス３を介してアクセスする。４はクラスタ１
００を接続するネットワークであり、あるクラスタから
送信先クラスタアドレスを指定されると、そのアドレス
に対応する送信先クラスタ（図示せず）にデータなどを
送信する。

【００１８】１１０は、メモリ２から送信すべきデータ
を読みだす送信データ読みだし回路、２８は読みだされ
た送信データをパケットの形にしてネットワーク４に送
出する送信回路、４２はネットワーク４からパケットを
受信する回路、１２０は受信されたパケット中の受信デ
ータをメモリ２に書き込む受信データ書き込み回路、７
は送信データの読みだしあるいは受信データ書き込みの
ためにメモリ２をアクセスするメモリアクセス回路であ
る。

【００１９】ＣＰＵ１には、米国ＵＮＩＸシステムラボ
ラトリーズ社が開発しライセンスしているオペレーティ
ングシステムであるＵＮＩＸの下で実行されるプロセス
と同様にユーザプロセスが実行される。１つのユーザプ
ロセスに対応して１つの仮想空間が存在する。図では説
明の判り易さのために、ＣＰＵ１内に一つの仮想空間１
０を図示してある。この仮想空間１０には、送信データ
および受信データ用の仮想の通信領域１１と、送信デー
タに付随する情報のための仮想のリクエスト領域１２が
設けられる。

【００２０】メモリ２には、各ユーザプロセスに対する
仮想の通信領域１１がマッピングされた実の通信領域１
３、各ユーザプロセスに対して設けられた仮想のリクエ
スト領域１２がマッピングされた実のリクエスト領域１
４と、各ユーザプロセスに対して設けられたアドレス変
換のためのページテーブル１５と、このクラスタ内の複
数の通信領域１３をアクセスするための、通信領域テー
ブル１６が設けられる。

【００２１】本実施例では、あるクラスタで実行される
ユーザプロセスが、送信データをそのクラスタ内の実の
通信領域１３に、そのクラスタを制御するオペレーティ
ングシステム（ＯＳ）の介入なしに書き込み、送信デー
タ読みだし回路１１０が、そのＯＳの介入なしにこの送
信データを読みだすこと、さらに、受信データ書き込み
回路１２０が、他のクラスタから受信したデータをこの
実の通信領域１３にそのＯＳの介入なしに書き込み、ユ
ーザプロセスがそのＯＳの介入なしにそのデータを読み
だすようになっている。

【００２２】図６に仮想の通信領域１１の構成を示す。
仮想の通信領域１１にはユーザプロセスから送信するデ
ータ（例えば配列Ａや、変数）あるいは他から受信した
データおよびデータ受信フラグが配置される。この領域
は主に他のクラスタに配置されたプロセスとのデータの
交換を目的としている領域である。

【００２３】図７に仮想のリクエスト領域１２の構成を
示す。このリクエスト領域１２はユーザプロセスが利用
するライブラリ関数がアクセスする領域である。リクエ
スト領域１２には、１つ以上のリクエスト構造体１２−
１と、ロケーションテーブル１２−２がある。リクエス
ト構造体１２−１は、このリクエスト領域１２が置かれ
ている仮想空間１０に対応するプロセスが発し、他のク
ラスタにあるプロセスへのデータ送信要求とそれに付随
するパラメータを格納する。ロケーションテーブル１２
−２は、他のクラスタで起動されたプロセスに関する情
報を保持する。図９に通信領域テーブル１６の構成を示
す。通信領域テーブル１６はそれぞれ一つの通信領域に
対応した複数のエントリからなる。各エントリには対応
する通信領域のベースアドレスＢＡＳＥとその領域のサ
イズＬＮが保持される。

【００２４】図１０にリクエストテーブル１７の構成を
示す。リクエストテーブル１７は、いずれかの仮想空間
の仮想のリクエスト領域１２ないの仮想のリクエスト構
造体１２−１（図７）の実アドレスをそれぞれ格納する
複数のエントリを持つ。

【００２５】図８にページテーブル１５の構成を示す。
ページテーブル１５の各エントリには、実ページアドレ
スフィールド、ページ固定フラグフィールド、その他の
制御情報がある。ページ固定フラグフィールドにページ
固定を示すフラグＦが格納されている場合には、そのエ
ントリに対応する実ページはページアウトされないよう
にオペレーティングシステムによって制御される。その
他の制御情報には従来技術による動的アドレス変換と同
様の情報が格納される。

【００２６】続いて本実施例に係る並列計算機の動作を
説明する。まず、並列計算機の初期化について説明す
る。各クラスタは簡単のために図では省略されている
が、起動に必要な装置、例えば磁気ディスク装置を備え
ている。システムの電源投入後、各クラスタは従来技術
による密結合マルチプロセッサと同様に初期プログラム
ロードし、オペレーティングシステムがそれぞれのクラ
スタで独立に起動する。起動後各クラスタのオペレーテ
ィングシステムは、従来技術、例えばＴＣＰ／ＩＰプロ
トコルを用いて任意のクラスタのオペレーティングシス
テムとネットワーク４あるいは図示されていない従来技
術によるネットワークを介してデータのやり取りを行な
うことができる。

【００２７】本実施例では、オペレーティングシステム
の起動時にさらに次のことを行なう。各クラスタのオペ
レーティングシステムはメモリ２上に通信領域テーブル
１６を作成し、その先頭アドレスを通信領域テーブルオ
リジンレジスタ６にバス３を介してセットする。次にメ
モリ２上にリクエストテーブル１７を作成し、その先頭
アドレスをリクエストテーブルオリジンレジスタ５にセ
ットする。ただし、このテーブル１７の内容はまだ書き
込まれていない。

【００２８】続いて、ユーザプロセスの初期化について
説明する。

【００２９】まず、ユーザが各クラスタのオペレーティ
ングシステムにプロセス起動を指示する。続いて、プロ
セス起動を指示されたオペレーティングシステムは、そ
の指示の対象となったプロセスに対応する仮想空間１０
を作るために、メモリ２上にページテーブル１５を作成
する。これは、従来技術と同様である。次に仮想の通信
領域１１を以下のように初期化する。まず、プログラマ
またはコンパイラによって指定された大きさの連続する
実アドレス領域をメモリ２上に確保し、これを実の通信
領域１３とする。続いて仮想空間１０上の通信領域１１
の仮想アドレスに対応するページテーブル１５のエント
リの実ページアドレスフィールド（図８参照）に、この
実の通信領域１３のアドレスを先頭から順に書き込み、
かつその領域がページアウトされないようにそのテーブ
ル１５内の対応するページ固定フラグフィールドにペー
ジ固定フラグＦを設定する。ここで、仮想の通信領域１
１の先頭アドレスはあらかじめ定められた値に設定さ
れ、この値は全クラスタの全てのユーザプロセスで共通
であるとする。また、仮想の通信領域１１と実の通信領
域１３の大きさについても同じであるとする。

【００３０】続いて、オペレーティングシステムはこの
実の通信領域１３にそのクラスタ内で一意な通信領域識
別子を割り当て、その通信領域識別子をエントリ番号と
する通信領域テーブル１６のエントリ（図９参照）にこ
の実の通信領域１３のベースアドレス（先頭アドレス）
と、その大きさをセットする。仮想の通信領域１１はペ
ージテーブルのページ固定フラグによって固定的に実の
通信領域１３に割り当てられているため、この実の通信
領域１３につけた、クラスタ内で一意の通信領域識別子
によって仮想の通信領域１１もクラスタ内で一意に識別
されうる。

【００３１】さらにメモリ２上の連続領域に実のリクエ
スト領域１４を確保し、仮想空間１０のリクエスト領域
１２の仮想アドレスに対応するページテーブル１５のエ
ントリの実ページアドレスフィールドに、確保した実の
リクエスト領域１４のアドレスを順次書き込み、その領
域がページアウトされないようにページ固定フラグフィ
ールド（図８参照）にページ固定フラグＦを設定する。
そして、図７に示すように仮想のリクエスト領域１２
に、リクエスト構造体１２−１とロケーションテーブル
１２−２を作成する。上述のように仮想のリクエスト領
域１２には、対応する実のリクエスト領域１４が確保さ
れ、かつその領域はページアウトされないように、すな
わち、メモリ２に常駐するようにされている。したがっ
て、リクエスト構造体１２−１およびロケーションテー
ブル１２−２には、必ず実メモリが対応していることに
なる。ただし、それらにはまだ情報が格納されていな
い。

【００３２】続いて、オペレーティングシステムは起動
するプロセスのあらかじめ定められた領域（図示せず）
にページテーブル１５のアドレスを設定し、そのプロセ
スがページテーブル１５を参照できるようにする。

【００３３】続いて、オペレーティングシステムは、実
のリクエストテーブル１７中の未使用エントリに、上記
で作成したリクエスト構造体１２−１に対応する実のリ
クエスト領域１４の中の領域の先頭の実アドレスを書き
込む。

【００３４】オペレーティングシステムによる以上の初
期化によって、実の通信領域１３はユーザプロセスから
仮想の通信領域１１の仮想アドレスを用いてアクセスで
き、オペレーティングシステムや外部デバイスからは実
の通信領域テーブル１６を介して実アドレスを用いてア
クセスできるようになる。また、仮想のリクエスト構造
体１２−１に対応する実領域はユーザプロセスから仮想
のリクエスト領域１２−１の仮想アドレスを用いてアク
セスでき、オペレーティングシステムや外部デバイスか
らはリクエストテーブル１７を介して実アドレスを用い
て直接アクセスできるようになる。

【００３５】続いて、オペレーティングシステムは、起
動したプロセスにプログラマまたはコンパイラがあらか
じめ与えてあるプロセスの名前と、そのプロセスが利用
する実の通信領域１３の通信領域識別子と、そのクラス
タのネットワーク内のアドレスを組にして、他の全ての
クラスタに転送する。このプロセス名前と通信領域識別
子とクラスタのネットワーク内のアドレスを受け取っ
た、他のクラスタのオペレーティングシステムは、予め
プログラマまたはコンパイラによってこのプロセス名を
参照することが決められているユーザプロセスに対して
そのクラスタ内に設けられている実のリクエスト領域１
４にあるロケーションテーブル（図７の１２−２に対応
する相当する実メモリ上の領域）の空きエントリに、受
け取ったプロセスの名前、通信領域識別子とクラスタの
ネットワーク内のアドレスを書き込む。上記のユーザプ
ロセスを起動するクラスタにおいても、このクラスタ内
のプロセスを送信先のユーザプロセスとするユーザプロ
セスが他のクラスタにおいて起動されたとき、上記と同
じ処理をする。これによって、後述するように、仮想空
間１０で実行されるプロセスが、その送信先ユーザプロ
セスの名前を指定すればそのプロセスの存在するクラス
タのアドレスとその送信先ユーザプロセスが利用する通
信領域１１の通信領域識別子をオペレーティングシステ
ムを用いずに求めることができるようになる。

【００３６】以上のようにして起動されたユーザプロセ
スは、それぞれ交互にデータを送信しあいながら並列に
動作しする。

【００３７】次に、本実施例に係るプロセス間のデータ
通信について図１１を用いて説明する。ユーザプロセス
間のデータ通信を行なう手順を送信元ユーザプロセスと
送信先ユーザプロセスの動作に分けて説明する。さら
に、送信元ユーザプロセスの動作の説明では、送信元ユ
ーザプロセスの動作と送信元クラスタの動作と送信先ク
ラスタ（図示せず）の動作に分けて説明する。以下にお
いて、特に明示しないかぎり処理はＣＰＵ１によりなさ
れる。

【００３８】ステップ５０：ライブラリ関数ｓｅｎｄの
ｃａｌｌ 送信元プロセスが、その仮想の通信領域１１中の送信デ
ータ、例えば配列Ａを送信先プロセスに送信するとき、
あらかじめ準備されたライブラリ関数ｓｅｎｄ（図示せ
ず）を次の形式で呼び出す。

【００３９】 Ｓｅｎｄ（”送信先プロセス名”，Ｘ，Ｙ，Ｚ，Ｌ） ここで、第１引数の送信先プロセスの名前は、ユーザが
一意に定める。第２引数のＸは送信データの送信元プロ
セスの仮想空間１０での先頭の仮想アドレスである。第
３引数のＹは送信先プロセスの仮想空間（図示せず）中
の、そのデータを格納したい領域の先頭の仮想アドレス
である。第４引数のＺは、そのデータを受信したときに
送信先クラスタで記憶すべきデータ受信フラグに割当て
られている仮想アドレスである。第５引数のＬは、送信
すべきデータ量である。本実施例では、送信元プロセス
は送信先プロセスの仮想の通信領域の位置と大きさをあ
らかじめ知っている。したがって、上記第３，第４引数
で指定される仮想アドレスは、この通信領域に属するよ
うにプログラムされている。さらに、第５引数で指定さ
れるデータ量は、この仮想の通信領域の大きさより小さ
くなるようにプログラムされている。

【００４０】ステップ５１：引数の変換 呼び出されたライブラリ関数ｓｅｎｄは、ユーザプロセ
スの一部として仮想空間１０の中で以下のように動作す
る。まず、送信先プロセスの名前に基づいて、仮想のリ
クエスト領域１２（対応する実のリクエスト領域１４が
メモリ２に常駐している）にあるロケーションテーブル
１２−２から、送信先プロセスのクラスタアドレスと通
信領域識別子を読みだす。さらに、ライブラリ関数ｓｅ
ｎｄは送信データの先頭の仮想アドレスを、ページテー
ブル１５を用いてメモリ２上の実の通信領域１３にある
送信データの実アドレスに変換する。また、ライブラリ
関数ｓｅｎｄはデータ受信領域とデータ受信フラグの仮
想アドレスから、送信元クラスタの仮想の通信領域１１
の先頭アドレスを減じ、送信先の実の通信領域１３内で
のオフセットをそれぞれ求める。この動作の正当性は、
全クラスタにおいてユーザプロセス内の仮想の通信領域
１１の先頭アドレスが同一にセットされていることと、
仮想の通信領域１１がメモリ２上の連続領域にある実の
通信領域１３に領域の先頭から順次割等当てられている
ことにより保障される。

【００４１】なお、先に求めたオフセット量が負になる
のは、ユーザプロセスにプログラムエラーがあるときで
あり、プログラム割り込みをＯＳに発生する。

【００４２】ステップ５２：リクエスト領域へのセット 次に、ライブラリ関数ｓｅｎｄは、先に読み出した送信
先クラスタのアドレスＣＬと、通信領域識別子ＩＤと、
先に求めたデータ受信領域のオフセットＳＯと、データ
受信フラグのオフセットＦＯと、送信データのデータ長
と実アドレスを仮想のリクエスト領域１２にあるリクエ
スト構造体１２−１（図７）にそれぞれ書き込む。さら
に、その中のリクエストフラグフィールドにリクエスト
フラグをセットする。仮想のリクエスト領域１２は実の
リクエスト領域１４に常駐しているため、これらのパラ
メータは実のリクエスト領域１４に書き込まれる。

【００４３】ステップ５３：次命令の実行 これらの処理を終了するとライブラリ関数ｓｅｎｄはユ
ーザプロセスに制御を戻す。ユーザプロセスは送信要求
の次の命令を、以下の動作と並行して実行する。

【００４４】 ステップ５４：パラメータのレジスタへのセット リクエスト選択回路２１は常時以下の動作を繰り返して
いる。

【００４５】まず、ＯＳ起動時にＯＳが値を設定したリ
クエストテーブルオリジンレジスタ５の値をその回路２
１内のリクエストテーブルエントリアドレス生成回路２
１−１（図２）に読み込み、メモリ２上のリクエストテ
ーブル１７の先頭のエントリの実アドレスを生成し、こ
のエントリの内容であるリクエスト構造体（図示せず）
の実アドレスを、メモリアクセス回路７とバス３を介し
てメモリ２からリクエストフラグアドレス生成回路２１
−２に読み込む。回路２１−２は読み込んだリクエクト
構造体の実アドレスからリクエストフラグフィールドの
実アドレスを求め、その内容をメモリアクセス回路７と
バス３を介してメモリ２からリクエストフラグ判定回路
２１−３に読み込む。２１−３はリクエストフラグフィ
ールドにリクエストフラグが書き込まれているか否かを
判定し、書き込まれていなければ上記のリクエストテー
ブルエントリアドレス生成回路２１−１に信号を送る。
この回路２１−１は、リクエストテーブル１７の次のエ
ントリのアドレスを生成し、以下回路リクエストフラグ
アドレス生成回路２１−２、リクエストフラグ判定回路
２１−３が上と同じように動作する。リクエストフラグ
判定回路２１−３は、リクエストフラグフィールドにリ
クエストフラグが書き込まれていれば、さらに送信回路
状態判定回路２１−４に信号を送り、当該クラスタの送
信回路２８の状態を判定させる。この送信回路２８がビ
ジーのときには回路２１−４は再度状態の判定をする。
回路２８がビジーでないときには、リクエスト構造体エ
ントリアドレス生成回路２１−５を起動する。この回路
２１−５は、リクエストテーブルエントリアドレス生成
回路２１−１により先に読み出されたリクエスト構造体
１２−１のアドレスに基づいて、仮想のリクエスト構造
体１２−１に対応する実アドレス領域にあるリクエスト
構造体（図示せず）を読み出し、その内のクラスタアド
レスＣＬをレジスタ２２に、通信領域識別子ＩＤをレジ
スタ２３に、データ受信領域のオフセットＳＯをレジス
タ２４に、データの受信フラグのオフセットＦＯをレジ
スタ２５に、データ長ＬＥＮをレジスタ２６にコピーす
る。さらに、読み出された実のリクエスト構造体（図示
せず）内の、送信データの実アドレスを用いて、送信す
べきデータを実の通信領域１３からバッファ２７にコピ
ーする。さらに、送信すべきデータの読みだしが終了し
たため、送信すべきデータを格納した領域の内容を変更
してもよいことを当該送信要求をしたユーザプロセスが
認識できるようにするため、リクエストフラグフィール
ドをリセットするため、リクエストフラグアドレスとリ
セット指示を送る。

【００４６】以上の処理の終了時にリクエストテーブル
エントリアドレス生成回路２１−１にそのことを線１０
００を介し、通知する。

【００４７】その後の他のリクエスト構造体について同
様の処理がなされる。

【００４８】ステップ５５：データの転送 続いて、送信回路２８がレジスタ２２ないし２６の内容
をバッファ２７の内容と共にパケットとしてネットワー
ク４に送信する。

【００４９】このように、送信元クラスタでは送信元プ
ロセスからの要求に応答して、ライブラリ関数ｓｅｎｄ
と送信データ読み出し回路１１０および送信回路２８
が、ＯＳの介入なしにデータをネットワーク４に送信す
る。以下、送信先クラスタでの動作を説明する。

【００５０】 ステップ５６：通信領域への収納可能性検査 ネットワーク４から送信先クラスタにパケットが到着す
ると、これをまず受信回路４２が受け取り、通信領域識
別子（ＩＤ）をレジスタ３７に、データ受信領域のオフ
セット（ＳＯ）をレジスタ３８に、データ受信フラグの
オフセット（ＦＯ）をレジスタ３９に、データ長（ＬＥ
Ｎ）をレジスタ４０に、データをバッファ４１にそれぞ
れコピーする。

【００５１】続いて、通信領域テーブルアドレス生成回
路３１（図３）がレジスタ３７に格納された通信領域識
別子ＩＤをもとにオフセット計算回路３１−１により、
通信領域テーブル内１６（図９）内のこのＩＤに対応す
るエントリのオフセットを計算する。これと通信領域テ
ーブルオリジンレジスタ６が指すメモリ２上の通信領域
テーブル１６の先頭アドレスを加算回路３１−２で加算
することによって、通信領域テーブル１６の、この通信
領域識別子に対応するエントリアドレス（実アドレス）
を計算し、メモリアクセス回路７とバス３を介して、こ
のエントリの通信領域ベースアドレスＢＡＳＥをレジス
タ３２に、その通信領域のサイズＬＮをレジスタ３３に
それぞれコピーする。

【００５２】続いて、送信元プロセスが正常にプログラ
ムされていれば、受信したデータを格納すべきアドレス
とデータ受信フラグを格納すべきアドレスが実の通信領
域１３に収まる。本実施例では、送信元プロセスのプロ
グラムエラーを検出するために、これらのアドレスが実
の通信領域１３に収まるかを判定するようにもなってい
る。すなわち、判定回路３５（図４）では、レジスタ３
８の内容であるデータ受信領域のオフセットＳＯ、レジ
スタ３９の内容であるデータ受信フラグのオフセットＦ
Ｏ、レジスタ４０の内容であるデータ長ＬＥＮ、レジス
タ３３の内容である通信領域のサイズＬＮを用いて比較
回路３５−１、３５−２によって判定する。３５−１と
３５−２は、それぞれ図４に示した不等式で判定し、不
等式が成立すると書き込み不可信号を出力する。３５−
１と３５−２の出力信号をＯＲ回路３５−４によりＯＲ
し、ここに信号が出力された場合、通信領域１１に収ま
らないことになる。

【００５３】ステップ５９：割り込みの発生 判定によって実の通信領域１３に収まらない場合には判
定回路３５がバス３にハードウエア割込み信号を発生さ
せる。

【００５４】ステップ６０：通信の抑制 このハードウェア割り込み信号は、送信先クラスタの１
台以上のＣＰＵ１に通知される。この信号を最初に認識
したＣＰＵ１の割り込み処理ルーチンによりオペレーテ
ィングシステムが起動され、他クラスタのオペレーティ
ングシステム間との通信によって以降の送信を抑止す
る。

【００５５】ステップ５７：アドレス変換 実の通信領域１３に収まる場合には、アドレス生成回路
３４（図５）がレジスタ３８の内容である受信データ領
域のオフセットＳＯとレジスタ３２の内容である通信領
域１３のベースアドレスＢＡＳＥを用いて加算回路３４
−１により受信したデータを格納する位置の実アドレス
を生成する。さらに、レジスタ３９と３２の内容である
データ受信フラグのオフセットＦＯとベースアドレスＢ
ＡＳＥを用いて加算回路３４−２によりデータ受信フラ
グを格納する位置のの実アドレスを生成する。

【００５６】ステップ５８：データのストア ステップ５７で生成した受信データの実アドレスとレジ
スタ４０の内容であるデータ長ＬＥＮを用いてメモリア
クセス回路７がバッファ４１にある受信データを実の通
信領域１３に転送する。さらにステップ５７で生成した
データ受信フラグの実アドレスの位置に、メモリアクセ
ス回路７がデータ受信フラグをセットする。

【００５７】以上のごとく、ＯＳの介入なしに受信デー
タが実の通信領域に書き込まれる。以上において、送信
元プロセスでは受信データおよびデータ受信フラグの位
置を仮想の通信領域１１の仮想アドレスで指定している
が、仮想の通信領域１１は実の通信領域１３に常駐して
いるので、ページフォルトにより書き込みが不成功に終
わることはない。つまり、送信元クラスタから送信先ク
ラスタにパケットを再送することがない。そのため、本
実施例では、従来技術のようにパケットの再送に備える
ためにパケットの写しを格納する領域を用意する必要が
ない。

【００５８】次に、送信先プロセスの動作について説明
する。

【００５９】送信先プロセスは、そのデータを使用した
い時点で、データの到着確認のためのライブラリ関数ｃ
ｈｅｃｋを実行すると、仮想の通信領域１１にあるデー
タ受信フラグを、その仮想アドレスを用いて読み、受信
完了か否かをデータ受信フラグの値から判断する。送信
先プロセスはデータが送信される前に予めプログラマま
たはコンパイラの指定により、このデータ受信フラグを
リセットする。前述のようにデータの受信が完了すると
このフラグがセットされるため、送信先プロセスが受信
完了このフラグから判断できる。送信先プロセスは受信
完了を確認したあと、その受信データを仮想アドレスを
用いてアクセスする。フラグがリセットされたままの場
合には、送信先プロセスが仮想の通信領域１１内のデー
タをアクセスしないようにプログラムされてにる。

【００６０】次に、プロセスの終了について説明する。
オペレーティングシステムはプロセスを終了するとき
に、そのプロセスに対応するページテーブル１５を削除
し、そのプロセスに対応するメモリ領域などのリソース
を開放するなど従来技術のＵＮＩＸと同様の動作をする
が、本実施例ではではさらに、通信領域テーブル１６中
の、終了するプロセスに割当てられた実の通信領域１３
に対応するエントリを削除する。さらに、終了するプロ
セスの名前をネットワークを介して他のクラスタのオペ
レーティングシステムに通知する。プロセスが終了した
ことを通知されたクラスタのオペレーティングシステム
は、ロケーションテーブル１２−２から終了したプロセ
ス名に対応する項を削除する。以上が本発明の第１の実
施例である。

【００６１】（第１実施例の変形例）以上に示した実施
例では、仮想の通信領域１１を各仮想空間で同一のアド
レスに置くとしたが、ロケーションテーブル１２−２
（図７）の各エントリに第４のフィールドを設け、ここ
に対応するプロセスの仮想の通信領域１１の先頭の仮想
アドレスを格納し、さらに上記のステップ５１において
送信元プロセスの仮想の通信領域１１の先頭アドレスを
用いてデータ受信領域のオフセットを計算している部分
を、上記第４のフィールドの内容を用いるようにすれ
ば、各仮想空間の中の仮想の通信領域１１の先頭の仮想
のアドレスを同一にしなくてもよい。

【００６２】さらに、上記のステップ５６では、受信し
たパケットに含まれており、レジスタ３７に格納される
通信領域識別子ＩＤを用いて実の通信領域１３の先頭ア
ドレスと長さを得ているが、通信領域識別子ＩＤのかわ
りにデータを受信するプロセスを一意に識別することが
可能な識別子を用い、この識別子から実の通信領域１３
の先頭アドレスと長さを得る回路を受信データ書き込み
回路内に用意するようにしてもよい。

【００６３】本発明の第２の実施例を図１２を用いて説
明する。第２の実施例は、第１の実施例の変形であるた
め、相違点を中心に説明する。本実施例では、送信先プ
ロセスはオペレーティングシステムを介さずにデータを
受信するが、送信元プロセスのみ送信するときにオペレ
ーティングシステムを介してネットワークへデータを転
送する点で、第１の実施例と異なる。したがって、デー
タの送受信に関するオペレーティングシステムの介入は
第１の実施例より多いが、公知の技術よりは少ないとい
うメリットがある。図１２はこの第２の実施例によるク
ラスタ１００Ｂを示す。図において、図１と同一の番号
をもつ要素の構成は、第１の実施例の要素と同一であ
る。

【００６４】本実施例では第１の実施例と異なり、各ク
ラスタ１００Ａにはリクエストテーブル１７、リクエス
ト領域１２、１４、リクエストテーブルオリジンレジス
タ５がない。

【００６５】図１２において、１２２、１２３、１２
４、１２５、１２６、１２９はそれぞれ図１の２２、２
３、２４、２５、２６、２９に対応するレジスタで、バ
ス３に直接結合され、ＣＰＵ１からメモリ２と同様にデ
ータを直接書きこむことができる。１３０はバス３に結
合するレジスタで、ＣＰＵ１からメモリ２と同様にデー
タを直接読みだすことができる。１２２は送信先クラス
タのアドレスＣＬを格納するレジスタである。１２３は
送信先プロセスに割当てられた実の通信領域１３の通信
領域識別子ＩＤを格納するレジスタである。１２４は送
信先プロセスの仮想の通信領域１１に対応する実の通信
領域１３の中にあるデータ受信領域の、実の通信領域１
３の先頭の実アドレスからのオフセットＳＯを、同じく
１２５はデータ受信フラグのオフセットＦＯを格納する
レジスタである。１２６は送信するデータのデータ長Ｌ
ＥＮを格納するレジスタである。１２９は送信元プロセ
スが送信するデータの先頭の実アドレスＡＤＲを格納す
るレジスタである。１３０には送信回路２８がビジー状
態であるかそうでないかの状態ＣＣをこの回路２８が反
映する。１２７はバッファで、メモリ２から送信すべき
データを保持する。１０７はメモリアクセス回路でメモ
リのアドレスを与えられると、その位置に格納された値
をメモリ２から読み、指定されたレジスタやメモリ２に
書き込んだり、その逆に指定されたレジスタやメモリ２
から、メモリ２の別のアドレスに値を書き込むメモリア
クセス回路である。

【００６６】続いて、本実施例に係る並列プロセッサの
動作のうち、第１の実施例と異なる部分について図１３
を参照して説明する。

【００６７】並列計算機の初期化について説明する。本
実施例では図１のリクエストテーブル１７とリクエスト
テーブルオリジンレジスタ５がないため、これらに関す
る処理は行なわない。これ以外は、第１の実施例と同じ
である。

【００６８】続いて、プロセスの初期化を説明する。本
実施例では図１の仮想のリクエスト領域１２、実のリク
エスト領域１４がないため、これらに関する処理は行な
わない。ただし、図１の仮想のリクエスト領域１２の中
にあるロケーションテーブル１２−２と同一内容のテー
ブル（図示せず）をオペレーティングシステムの内部に
作成する。これ以外は、第１の実施例と同じである。

【００６９】次に、本発明に係るプロセス間のデータ通
信について説明する。本実施例では第１の実施例とは送
信元プロセスの動作が異なる。これ以外は同じであるた
め、これら異なる動作のみを図１３を参照して説明す
る。

【００７０】ステップ６１：Ｓｅｎｄシステムコール ユーザプログラムが、オペレーティングシステムのシス
テムコールを発行し、制御をオペレーティングシステム
に渡す。このコールは前述の第１の実施例におけるライ
ブラリ関数ｓｅｎｄのｃａｌｌ文と同じ形式を有する。

【００７１】ステップ６２：引数の変換 オペレーティングシステムはシステムコールが発行され
ると、予めプロセスの初期化の時にオペレーティングシ
ステム内部のテーブル（図示せず）に登録した内容（第
１の実施例におけるロケーションテーブル１２−２に相
当）を用いて、送信先プロセス名から送信先プロセスの
存在するクラスタのネットワーク上のアドレスと送信先
プロセスに割当てられた実の通信領域１３の通信領域識
別子を決める。また、オペレーティングシステムは送信
データの先頭の仮想アドレスからページテーブル１５を
用いてメモリ２上の実の通信領域１３にある送信データ
の先頭の実アドレスを決める。さらに、第１の実施例と
同様にしてデータ受信領域の仮想アドレス、データ受信
フラグの仮想アドレスから、送信先プロセス内にある仮
想の通信領域１１の先頭アドレスからのオフセットＳ
Ｏ、ＦＯをそれぞれ求める。

【００７２】 ステップ６３：パラメータのレジスタへのセット 続いて、オペレーティングシステムはＣＣ１３０をバス
３を介して読み、通信回路２８がビジー状態でないこと
を確認し、レジスタ１２２、１２３、１２４、１２５、
１２６、１２９にそれぞれ送信先クラスタのアドレスＣ
Ｌ、送信先プロセスに割当てられた実の通信領域１３の
通信領域識別子ＩＤ、データ受信領域のオフセットＳ
Ｏ、データ受信フラグのオフセットＦＯ、送信データの
データ長ＬＥＮ、送信データの先頭の実アドレスをセッ
トする。そして、実行の制御をユーザプログラムに渡
す。

【００７３】続いて、メモリアクセス回路１０７はレジ
スタ１２９に値が書き込まれたことでＣＰＵ１から起動
のきっかけを与えられ、メモリ２上の１２９の示す実ア
ドレスから送信データをデータバッファ１２７にバス３
を介して読みだす。

【００７４】ステップ６４：次命令の実行 読み出しが終了するとユーザプログラムに制御を戻し、
次命令を実行する。

【００７５】ステップ６５：データの転送 続いて、送信回路２８はレジスタ１２２、１２３、１２
４、１２５、１２６とデータバッファ１２７を用いてパ
ケットを構成し、ネットワーク４に送信する。ネットワ
ーク４からパケットを受信したときの動作は、第１の実
施例と同様であるため省略する。

【００７６】次にプロセスの終了について説明する。本
実施例では、第１の実施例と異なりリクエスト領域１
２、１４が無いため、プロセスの終了に伴ってリクエス
ト領域の削除を行なう必要がない。

【００７７】以上が、第２の実施例である。

【００７８】本実施例によれば、送信元クラスタにおい
てオペレーティングシステムの介入があるため、第１の
実施例に比べてオーバヘッドが若干大きくなる。しか
し、公知の技術と異なり、オペレーティングシステム内
に送信バッファおよび受信バッファを設ける必要がない
のは、第１の実施例と同じであるため、公知の技術に比
べてデータ送受信のオーバヘッドが低減できる。さらに
本実施例は、第１の実施例よりも簡単な回路で構成する
ことができる。

【００７９】（第３実施例）本発明の第３の実施例を図
１４によって説明する。第３の実施例は、第２の実施例
の変形であるため、相違点を中心に説明する。本実施例
は、送信元プロセスが送信するときにオペレーティング
システムを介してネットワークへデータを転送するが、
送信先プロセスはオペレーティングシステムを介さずに
データを受信する点では第２の実施例と同じであるが、
データ転送のために必要なパラメータをオペレーティン
グシステムがメモリ２上に置く点が異なる。図１４は、
本実施例によるクラスタ１００Ｂを示す。図において、
図１または図１２と同一の番号を持つ要素の構成は、第
１または第２の実施例の要素と同一である。図１４にお
いて、２１８はリクエスト領域であり、メモリ２上にあ
りオペレーティングシステムが管理する。２３０はリク
エスト領域オリジンレジスタであり、リクエスト領域２
１８の先頭アドレスを格納する。２２２、２２３、２２
４、２２５、２２６、２２７はレジスタであり、それぞ
れ第２の実施例の１２２、１２３、１２４、１２５、１
２６および１２７に対応する。２２２は送信先クラスタ
のネットワーク上のクラスタアドレスＣＬを格納する。
２２３は送信先プロセスに割当てられた実の通信領域１
３の通信領域識別子ＩＤを格納する。２２４は送信先プ
ロセスに割当てられた実の通信領域１３中でのデータ受
信領域のオフセットＳＯを、２２５は同じくデータ受信
フラグのオフセットＦＯを格納する。２２６は送信デー
タのデータ長ＬＥＮを格納する。２２９はレジスタで、
送信回路１２８の状態ＣＣを反映した値がセットされ
る。２２７はデータバッファで、ネットワークへ送出す
るために、送信データの内容を格納する。２０７はメモ
リアクセス回路で、アドレスを渡されるとメモリ２をア
クセスして値を指定されたレジスタに格納したり、レジ
スタの値をメモリに書き込む。

【００８０】続いて、本実施例に係る並列プロセッサの
動作を説明する。本実施例に係る動作は第２の実施例と
異なる動作についてのみ説明する。

【００８１】並列計算機の初期化について説明する。本
実施例ではオペレーティングシステムの起動時にメモリ
２上にリクエスト領域２１８を確保してその先頭の実ア
ドレスをリクエスト領域オリジンレジスタ２３０にセッ
トする。これ以外は第２の実施例と同一である。

【００８２】次に、本実施例に係るプロセス間のデータ
通信について説明する。本実施例では送信元プロセスの
動作が第２の実施例と異なるため、これらのみについて
図１５を参照して説明する。

【００８３】ステップ６１：Ｓｅｎｄシステムコール ユーザプロセスからシステムコールを発行する動作は第
２の実施例の場合と同一である。

【００８４】ステップ６２：引数の変換 第２の実施例と同様である。

【００８５】 ステップ６６：リクエスト領域へのセット 続いて、オペレーティングシステムはＣＣ２２９をバス
を介して読んで、通信回路２８がビジー状態でないこと
を確認し、メモリ２上のリクエスト領域２１８に送信先
クラスタのアドレスＣＬ、送信先プロセスに割当てられ
た実の通信領域１３の通信領域識別子ＩＤ、データ受信
領域のオフセットＳＯ、データ受信フラグのオフセット
ＦＯ、送信データのデータ長、送信データの先頭の実ア
ドレスをセットする。このセットに伴って、メモリアク
セス回路２０７が起動するが、リクエスト領域２１８に
セマフォアを設けて、セマフォアを介してメモリアクセ
ス回路２０７を起動することもできる。そして、実行の
制御をユーザプログラムに渡し、次命令を実行する（図
１５の６４）。

【００８６】 ステップ６７：パラメータのレジスタへのセット 続いて、ＯＳがリクエスト領域アクセス回路２１Ａに、
リクエスト領域２１８の読み出しをバス３を介して指示
する。この回路２１Ａはリクエスト領域オリジンレジス
タ２３０からリクエスト領域２１８の各エントリを生成
し、メモリアクセス回路２０７を介して、それらの内容
を読み出し、レジスタ２２２、２２３、２２４、２２
５、２２６にそれぞれ送信先クラスタのアドレスＣＬ、
送信先プロセスに割当てられた実の通信領域１３の通信
領域識別子ＩＤ、データ受信領域のオフセットＳＯ、デ
ータ受信フラグのオフセットＦＯ、送信データのデータ
長ＬＥＮをセットする。また、メモリアクセス回路２０
７はメモリ２から送信データの先頭の実アドレスにより
送信データをデータバッファ２２７にコピーする。

【００８７】ステップ６５：データの転送 これらのレジスタがセットされると、送信回路１２８が
レジスタ２２２、２２３、２２４、２２５、２２６とバ
ッファ２２７を用いてパケットを構成し、ネットワーク
へ送信する。

【００８８】ネットワーク４からパケットを受信したと
きの動作は、第２の実施例と同様であるため省略する。

【００８９】以上が第３の実施例である。本実施例によ
れば、第２の実施例と同様に、第１の実施例よりも簡単
な回路で、第１の実施例に匹敵する性能を得ることがで
きる。

【００９０】（第４実施例）本発明の第４の実施例を説
明する。第４の実施例は第３の実施例の変形である。第
４の実施例のクラスタの装置構成は第３の実施例と同一
であるため図１４を用いて説明するが、リクエスト領域
２１８とリクエスト領域オリジンレジスタ２３０の使い
方が異なるため、これを中心に説明する。

【００９１】まず、システムの初期化を説明する。第３
の実施例と異なり、リクエスト領域２１８はメモリ２上
に固定されていないので、システムを初期化するときに
は確保せず、データ送信時に確保する。また、システム
の初期化でリクエスト領域オリジンレジスタ２３０に値
をセットしない。

【００９２】次に、送信元プロセスのオペレーティング
システムの動作を図１６を参照して説明する。

【００９３】ステップ６１：Ｓｅｎｄシステムコール 第３の実施例と同じである。

【００９４】ステップ６２：引数の変換 第３の実施例と同じである。

【００９５】ステップ６８：リクエスト領域へのセット オペレーティングシステムはメモリ２上にリクエスト領
域２１８を確保して、２１８に送信先クラスタのアドレ
スＣＬ、送信先プロセスに割当てられた実の通信領域１
３の通信領域識別子ＩＤ、データ受信領域のオフセット
ＳＯ、データ受信フラグのオフセットＦＯ、送信データ
のデータ長ＬＥＮ、送信データの先頭の実アドレスアド
レスを書き込む。

【００９６】ステップ６９：リクエスト領域オリジンレ
ジスタのセット ＣＣ２２９を読み込んで送信回路１２８がビジー状態で
ないことを確認し、リクエスト領域２１８の先頭アドレ
スをリクエスト領域オリジンレジスタ２３０にセットす
る。２３０へのセットによって、メモリアクセス回路２
０７および送信回路１２８が起動する。そして、オペレ
ーティングシステムは実行の制御をユーザプログラムに
渡し、次命令を実行する（図１６の６４）。

【００９７】ステップ６７：パラメータのレジスタへの
セット 第３の実施例と同じである。

【００９８】ステップ６５：データの転送 第３の実施例と同じである。

【００９９】ネットワーク４からパケットを受信したと
きの動作は、第３の実施例と同じであるため、省略す
る。

【０１００】以上が第４の実施例である。

【０１０１】本実施例では、リクエスト領域２１８はデ
ータ送信のたびに確保してよい。そのため、クラスタに
含まれる各ＣＰＵ１が、メモリ２中の異なるアドレスに
リクエスト領域２１８をそれぞれ確保するように制御す
ることにより、ステップ６１、ステップ６２、およびス
テップ６８を各ＣＰＵ１で同時に並行して実行すること
ができるようになる。このようにすると、あるＣＰＵ１
が実行したステップ６９により起動された送信回路１２
８の動作と並行して、他のＣＰＵ１はステップ６１、６
２、６８を実行することができ、送信回路１２８の動作
が終了すると直ちに他のＣＰＵ１がステップ６９を実行
することができる。そのため、第３の実施例に比べてデ
ータ送信に介入するオペレーティングシステムのオーバ
ヘッドをより少なくすることができる。

【０１０２】

【発明の効果】本発明によれば、ユーザプロセス間のデ
ータ転送において、ユーザプロセスの起動時に各クラス
タのオペレーティングシステムの間での通信による初期
化処理が必要であるが、実際のユーザプロセス間のデー
タ転送においてはあるクラスタにあるユーザプロセスの
仮想空間中ののデータを他のクラスタにあるユーザプロ
セスの仮想空間に転送するときにオペレーティングシス
テムの中のバッファ領域にデータをコピーすることなし
に直接転送することができる。そのため、小さなオーバ
ヘッドで、かつ、データ転送とは無関係なユーザプロセ
スの仮想空間に不当な変更を与えずにデータ転送を行な
うことができる。

【図面の簡単な説明】

【図１】本発明の第１の実施例に係る並列計算機の構成
図。

【図２】リクエスト選択回路の構成図。

【図３】通信領域テーブルアドレス生成回路の構成図。

【図４】判定回路の構成図。

【図５】アドレス生成回路の構成図。

【図６】通信領域の構成図。

【図７】リクエスト領域の構成図。

【図８】ページテーブルの構成図。

【図９】通信領域テーブルの構成図。

【図１０】リクエストテーブルの構成図。

【図１１】本発明の第１の実施例に係る並列計算機のプ
ロセス間データ転送フローを示す図。

【図１２】本発明の第２の実施例に係る並列計算機の構
成図。

【図１３】本発明の第２の実施例に係る並列計算機のプ
ロセス間データ転送フローを示す図。

【図１４】本発明の第３の実施例に係る並列計算機の構
成図。

【図１５】本発明の第３の実施例に係る並列計算機のプ
ロセス間データ転送フローを示す図。

【図１６】本発明の第４の実施例に係る並列計算機のプ
ロセス間データ転送フローを示す図。

【符号の説明】

１…ＣＰＵ、２…メモリ、３…バス、４…ネットワー
ク、５…リスエストテーブルオリジンレジスタ、６…通
信領域テーブルオリジンレジスタ、７…メモリアクセス
回路、１０…仮想空間、１１…通信領域、１２…リクエ
スト領域、１３…通信領域、１４…リクエスト領域、１
５…ページテーブル、１６…通信領域テーブル、１７…
リクエストテーブル、２１…リクエスト選択回路、２２
〜２６…レジスタ、２７…バッファ、２８…送信回路、
３１…通信領域テーブルアドレス生成回路、３２〜３３
…レジスタ、３４…アドレス生成回路、３５…判定回
路、３７〜４０…レジスタ、４１…バッファ、４２…受
信回路、１１０…送信データ読みだし回路、１２０…受
信データ書き込み回路。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 中越 順二 東京都国分寺市東恋ケ窪１丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 千葉 寛之 東京都国分寺市東恋ケ窪１丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 首藤 信一 東京都国分寺市東恋ケ窪１丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 武内 茂雄 東京都小平市上水本町５丁目20番１号 日立超エル・エス・アイ・エンジニアリ ング株式会社内 (72)発明者 緒方 康洋 東京都小平市上水本町５丁目20番１号 日立超エル・エス・アイ・エンジニアリ ング株式会社内 (72)発明者 鳥羽 達 東京都小平市上水本町５丁目20番１号 日立超エル・エス・アイ・エンジニアリ ング株式会社内 (56)参考文献 特開 平２−311050（ＪＰ，Ａ) 特開 平２−28748（ＪＰ，Ａ) 特開 平３−18959（ＪＰ，Ａ) 特開 平４−291660（ＪＰ，Ａ) 特開 平４−151721（ＪＰ，Ａ) 特開 平４−149651（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/16 - 15/177 G06F 12/08 - 12/12

Claims (12)

(57)【特許請求の範囲】
1. 【請求項１】１台以上のプロセッサと該１台以上のプロ
   セッサにより使用される主メモリとからなる複数のクラ
   スタと、該複数のクラスタを接続するネットワークとを
   具備し、それぞれのクラスタにおいて少なくとも１つの
   仮想空間が割り当てられた少なくとも１つのプロセスが
   ＯＳの制御下で実行される並列プロセッサにおいて、 それぞれのクラスタで実行されるプロセスがそれぞれ使
   用する仮想空間内に位置し、所定の大きさを持つ仮想の
   通信領域にマッピングされるべき実の通信領域をそれぞ
   れのクラスタ内の主メモリに常駐させ、 送信元クラスタでは送信先プロセスに割り当てられた仮
   想の通信領域に属する送信先仮想アドレスに基づいて送
   信先プロセスに割り当てられた実の通信領域内のデータ
   格納位置を決定し、 送信元プロセスに割り当てた実の通信領域にある、送信
   元プロセスにより指定された送信データとともに、決定
   されたデータ格納位置を指定する位置情報を送信元クラ
   スタから送信先クラスタに送信し、 送信先クラスタでは、送信先プロセスの実の通信領域内
   の、受信した位置情報により指定される位置に、受信し
   たデータを、送信先プロセスを制御するＯＳを介さない
   で書き込むプロセッサ間通信方法。
2. 【請求項２】上記送信データの送信は、上記送信データ
   を送信元プロセスを制御するＯＳの介入なしに送信元プ
   ロセスに割り当てた実の通信領域から読み出すことによ
   り行う請求項１記載のプロセッサ間通信方法。
3. 【請求項３】上記送信データの送信は、上記送信データ
   を送信元プロセスを制御するＯＳの下で送信元プロセス
   に割り当てた実の通信領域から読み出すことにより行う
   請求項１記載のプロセッサ間通信方法。
4. 【請求項４】上記位置情報は、送信先プロセスに割り当
   てられた実の通信領域の先頭から送信データを格納する
   位置までのオフセットアドレスを含み、送信先クラスタ
   では送信先プロセスに割り当てられた実の通信領域の先
   頭アドレスと、送信された位置情報内の上記オフセット
   アドレスから受信したデータを格納する位置を決定する
   請求項１記載のプロセッサ間通信方法。
5. 【請求項５】上記送信元クラスタでは、送信先プロセス
   に割り当てられた仮想の通信領域の先頭アドレスと送信
   先仮想アドレスとの差を上記オフセットアドレスとして
   もとめる請求項４記載のプロセッサ間通信方法。
6. 【請求項６】上記位置情報は、送信先プロセスの割り当
   てられた実の通信領域の識別子をさらに含み、上記送信
   先クラスタでは、該識別子から上記実の通信領域の先頭
   アドレスを決定し、該先頭アドレスと上記オフセットア
   ドレスとから上記データを格納する位置を決定する請求
   項４記載のプロセッサ間通信方法。
7. 【請求項７】上記送信元プロセスにより上記オフセット
   アドレスとは独立に指定され、上記送信先プロセスに割
   り当てられた通信領域内のフラグ領域の、該通信領域の
   先頭アドレスからのオフセットを示すフラグオフセット
   アドレスをさらに上記送信先クラスタに送信し、 上記送信先クラスタでは、該フラグ領域の位置を送信さ
   れたフラグオフセットアドレスにより決定し、上記デー
   タの上記送信先クラスタへの書き込みが終了した後に、
   該フラグ領域の位置に予めさだめられた特定の値を書き
   込むことを特徴とする請求項４記載のプロセッサ間通信
   方法。
8. 【請求項８】１台以上のプロセッサと該１台以上のプロ
   セッサにより使用される主メモリとからなる複数のクラ
   スタと、該複数のクラスタを接続するネットワークとを
   具備し、それぞれのクラスタにおいて少なくとも１つの
   仮想空間が割り当てられた少なくとも１つのプロセスが
   ＯＳの制御下で実行される並列プロセッサにおいて、 それぞれのクラスタで実行されるプロセスがそれぞれ使
   用する仮想空間内に位置し、所定の大きさを持つ仮想の
   通信領域にマッピングされるべき実の通信領域をそれぞ
   れのクラスタ内の主メモリに常駐させ、 送信元クラスタで実行中の送信元プロセスに割り当てた
   実の通信領域から、送信先クラスタの送信先プロセスに
   割り当てた実の通信領域に送信データを転送するプロセ
   ッサ間通信方法。
9. 【請求項９】１台以上のプロセッサと該１台以上のプロ
   セッサにより使用される主メモリとからなる複数のクラ
   スタと、該複数のクラスタを接続するネットワークとを
   具備し、それぞれのクラスタにおいて少なくとも１つの
   仮想空間が割り当てられた少なくとも１つのプロセスが
   ＯＳの制御下で実行される並列プロセッサにおいて、 各クラスタに、 そのクラスタで実行されるプロセスが使用する仮想空間
   内の所定の位置に位置し、所定の大きさを有する仮想の
   通信領域にマッピングされるべき、そのクラスタの主メ
   モリに常駐された実の通信領域と、 該実の通信領域内の、送信元プロセスが指定した送信デ
   ータを読み出し、送信回路に供給する手段と、 上記送信回路により読み出されたデータを送信先クラス
   タに送信する手段と、他のクラスタから送信されたデー
   タを送信先プロセスに割り当てられた実の通信領域に格
   納する手段とを有することを特徴とする並列プロセッ
   サ。
10. 【請求項１０】各クラスタに、送信元プロセスが指定す
    る送信先プロセスに応答して、それが使用する通信領域
    を一意に識別する通信領域識別手段と、送信元プロセス
    が指定する送信先仮想アドレスから、送信先プロセスに
    割り当てられた実の通信領域内のデータ格納位置を決定
    し、上記送信回路に供給する手段と、他のクラスタから
    受信した通信領域識別子から該通信領域の先頭アドレス
    を決定する手段と、決定した上記先頭アドレスと受信し
    たデータ格納位置とからそのクラスタの主メモリ内のデ
    ータ格納位置を決定する手段とを有する請求項９記載の
    並列プロセッサ。
11. 【請求項１１】上記データ格納位置が上記送信先プロセ
    スに割り当てられた送信先プロセスに割り当てられた通
    信領域に収まるか否かを判定する手段と、該判定手段に
    よる判定結果を送信元クラスタのプロセッサに通知する
    通知手段をさらに有する請求項９記載の並列プロセッ
    サ。
12. 【請求項１２】独立に動作可能な１台以上のプロセッサ
    と、該プロッセッサにより使用されるローカルメモリと
    を有するクラスタを複数用いて構成され、さらにクラス
    タ間でデータの受け渡しをするためのネットワークを有
    する並列計算機において、 各クラスタには、 各クラスタのユーザプロセスに対応して、該クラスタの
    ローカルメモリに常駐して該プロセスの仮想アドレス空
    間にマッピングされた通信領域を備え、且つ、 該プロセスが実行するデータ送信命令で指定するデータ
    送信先である受信プロセスを識別する受信プロセス識別
    子を、該受信プロセスが存在するクラスタを識別する受
    信クラスタ識別子と該受信プロセスに対応する通信領域
    を識別する通信領域識別子との組に変換する宛先変換手
    段と、 該受信クラスタ識別子と通信領域識別子とで指定された
    通信領域の中のデータを格納すべきデータアドレスと、
    該送信命令で指定された該通信領域内の該データアドレ
    スにデータを格納し終えたことを示すフラグを格納すべ
    きフラグアドレスとを該送信命令で指定されたデータと
    共に上記ネットワークに送出する送出手段と、 該ネットワークから受信した上記通信領域識別子と上記
    データアドレスとから上記受信プロセスに対応する通信
    領域の中の上記データを格納すべきアドレスに対応する
    実アドレスを求め、かつ受信した上記通信領域識別子と
    上記フラグアドレスとから上記受信プロセスに対応する
    通信領域の中の上記フラグを格納すべきアドレスに対応
    する実アドレスを求めるアドレス変換手段とを有するこ
    とを特徴とする並列プロセッサ。