JPH06243105A - 任意に変化するデータ・ストライドで情報を転送する方法及び装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】任意に変化するストライドのアプリケーション
・データを、中間のデータ記憶装置を経由せずにプロセ
ッサ間で通信する。 【構成】部分データ・メッセージを含む一連のパケット
を介して転送される各部分データメッセージは、起点ア
プリケーション・データ・メモリのストライド１部分に
記憶されたデータの一部分を有し、宛先アプリケーショ
ン・データ・メモリのストライド１部分に書き込まれ
る。起点及び宛先処理エレメントでそれぞれ独立して実
行するアプリケーション・インターフェースは、それぞ
れ、起点アプリケーション・データ・メモリに記憶され
た個々のストライド１データ部分、及びアプリケーショ
ン・データを受信すべき宛先アプリケーション・プログ
ラム・メモリにおける個々のスライド１領域に対する開
始アドレス及び長さ決定する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、分散型の、詳しくは、
高度に並列のマルチプロセシング環境において、任意に
変化するストライドのデータを個々のプロセッサ相互間
で且つ中間的なデータ記憶装置を必要とすることなく通
信するためのコミュニケーション・プロトコル用装置及
びそれに付随する方法に関するものである。

【０００２】

【従来の技術】益々強力な且つ複雑なそして比較的安価
なマイクロプロセッサの絶え間ない発展及び商業的可用
性によって、分散処理、特に、大規模な並列処理は、従
来は通常のメインフレーム・コンピュータを介して処理
されたトランザクション処理のような広範囲のアプリケ
ーションを扱うための益々魅力的な手段としてその分野
では認められつつある。

【０００３】一般的には、分散処理は、すべて並列態様
で又はパイプライン態様で集合的に動作する多数の独立
したプロセッサに跨った処理負荷の拡大を伴うものであ
る。それらプロセッサ間のメッセージ受渡及びデータ共
用を促すために、すべてのプロセッサを一緒に連結する
ための或タイプの相互接続方法が使用される。過去にお
いては、多くの変形が存在する分散処理アーキテクチャ
は、伝統的なメインフレーム又はスーパー・ミニコンピ
ュータにおいて使用されるような比較的少数の相互接続
されたプロセッサ、典型的には２つの、そして屡々１０
個以下の高度に複雑な独立した中央処理装置を使用する
必要があった。これらプロセッサは、例えば、プロセッ
サ間バスを介して直接に、又は共用の直接アクセス記憶
装置のようなマルチポート共用メモリ或いは他のコミュ
ニケーション・パスを介して間接的に相互接続される。

【０００４】対照的に、大規模な並列処理システムで
は、比較的多数の、屡々数百個の或いは数千個の独立し
た比較的単純なマイクロプロセッサ・ベースの処理エレ
メントが高速度のパケット・ネットワークから形成され
たコミュニケーション組織を介して相互接続される。そ
の場合、そのような処理エレメントは、ネットワーク上
の独立したノードのように見える。動作においては、そ
の組織は、これら処理エレメントのうちの任意のものか
ら他の処理エレメントに、それらの間のコミュニケーシ
ョンを与えるよう、典型的にはデータ・パケットの形で
メッセージを伝搬する。これらエレメントの各々は、典
型的には、独立したマイクロプロセッサ及びその関連の
サポート回路を含む。後者、即ち、サポート回路は、例
えば、プログラム及びデータ記憶のためのランダム・ア
クセス・メモリ（ＲＡＭ）及び入出力（Ｉ／Ｏ）回路に
よって代表される。特定の回路の要求条件に基づいて、
各エレメントは、初期設定（ブート）ルーチン及び構成
情報を記憶するために、読み取り専用メモリ（ＲＯＭ）
又は他の回路を含むことも可能である。

【０００５】特に、大規模な並列処理システムにおける
各分散処理エレメントは、そのエレメントをコミュニケ
ーション組織にインターフェースするコミュニケーショ
ン・サブシステムも含んでいる。

【０００６】各エレメント内のこれらサブシステムは、
Ｉ／Ｏ回路におけるコミュニケーション・インターフェ
ースのような適当なハードウエア回路及び関連の制御ソ
フトウエア・ルーチンから形成される。後者のソフトウ
エア・ルーチンは、そのエレメントで実行するアプリケ
ーションによって呼び出されてシステム内の他の任意の
そのような処理エレメントと通信する。

【０００７】改良されたシステム・パフォーマンス、特
に、回路の複雑性、コスト及びシステム・サイズのこれ
に付随した減少による改良されたシステム・パフォーマ
ンスは、如何なる分散処理環境の設計においても第１次
的な目標である。大規模な並列処理の環境では、パフォ
ーマンスの改良は、なかんずく、コミュニケーション組
織におけるメッセージ通過時間の減少、及び各処理エレ
メントにおいて始められ且つプロセッサ間コミュニケー
ションの処理のようなオーバヘッド・タスクによって必
要とされる処理時間の減少によって生じさせることが可
能である。各エレメントにおいて不必要な回路を除去す
ることは、基本的な複雑性を減少させるであろうし、各
エレメント及びシステム全体の物理的サイズ及びコスト
を付随的に減少させるであろう。この種の改良を達成す
ることは、任意の時間に同時にシステム及び多数の関連
した個々の処理エレメントを通過するかなりの数のプロ
セッサ間メッセージを与えられる大規模な並列処理環境
では、特に重要である。従って、これらの改良は大規模
な並列処理システムの環境において生じるので、以下の
説明はこれらの改良の必要性に関するものである。

【０００８】明らかなように、メッセージ伝搬は、如何
なる大規模な並列処理システムにおいても不可欠な要素
を形成する。適切なシステム・パフォーマンスを生じる
ために、コミュニケーション組織は、プロセッサ間メッ
セージの予測されるピーク負荷を任意の時間に且つ競合
なしに同時に伝搬するよう、それに接続された個々の処
理エレメント数に基づいた必要な容量を与えなければな
らない。更に、各処理エレメントそのものは、例えば、
コミュニケーション組織を通してメッセージを送信及び
受信するためにコミュニケーション・タスクが必要とす
るようなオーバヘッド・タスクを処理する場合、最小量
の時間しか費やさないようにしなければならない。明ら
かに、不十分なコミュニケーション・スループット又は
各処理エレメントおいて利用可能な減少した量のアプリ
ケーション処理時間は、大規模な並列処理システムを所
与のアプリケーションで使用するという魅力をひどく減
少させるという点でシステム・スループットに不利な影
響を与えるであろう。

【０００９】幸いにして、この分野では、少なくとも現
時点では、代表的な大規模な並列処理システムにおいて
生じると考えられる必要なピーク・メッセージ・トラフ
ィックを処理するに十分高い転送速度を与えるべき種々
のアーキテクチャが提案されている。しかし、後述する
ように、この分野は、コミュニケーション・サブシステ
ムにより行われるメッセージ伝搬と関連したオーバヘッ
ド処理時間を十分には減少させていない。これを留意し
て、高速度コミュニケーション組織の帯域幅は、アプリ
ケーション・スループット、従って、システム・パフォ
ーマンス全体に関する制限を、各処理エレメントがメッ
セージを通信するに必要なオーバヘッド時間よりもずっ
と小さくする傾向がある。

【００１０】更に、各処理エレメントの物理的サイズを
縮小することは、特に、数百個又は数千個の独立したプ
ロセッサが単一のシステムで使用される場合に最も重要
なことである。そうしない場合、システムは単純に大き
くなり過ぎ、過度な量の電力を必要とし、一般には全く
非実用的になる。

【００１１】この目標を達成する助けとなる基本的な解
決法は、２つのプロセッサが益々高速であり且つその分
野で通常言われている量よりもずっと少ないメモリを使
用するという態様でそれらプロセッサ間でメッセージ、
特に、データを転送することであろう。この点では、各
処理エレメントがメッセージの送信及び受信においてか
なり少ないオーバヘッド時間しか費やさないようにでき
るならば、システム・スループットは大いに増加可能で
ある。更に、後述するようにメッセージ伝搬と関連した
中間的メモリの必要性を少なくでき、希望的には、除く
ことができれば、各処理エレメントは少ない回路しか必
要とせず、従って、少ない物理的スペースしか費やさ
ず、従来必要としたコストよりも少ないコストしか必要
としない。

【００１２】この解決に至る重要性を十分に認識するた
めには、先ず、メッセージ、特に、データが個々の処理
エレメント及びそれと関連した特殊な問題の間で通常通
信される方法を理解しなければならない。

【００１３】一般的に言って、データは多くの形式をと
る。しかし、物理的メモリは唯１つの形式しかとらな
い。これに関して、データは幅広い種々な方法のうちの
どれかで構成可能である。例えば、データ構造は、単に
直前の番号に続く各番号（１つの番号の直後に他の番号
が続く）をリスト内に持った単なる番号のリスト、即
ち、ベクトルであってもよい。この場合、データはいわ
ゆる「ストライド１」又は「リニア・マッピング」で編
成される。即ち、各データ・エレメントは前のデータエ
レメントに、それらの間のギャップなしに、連続的に後
続する。データがマトリクス形式で構成され、列方向に
記憶され、そして行に沿ってアクセスされる場合、スト
ライド１データはマトリクスの列とみなされ、移動は１
つのデータ・エレメントから各列を通して次の下方のエ
レメントに行われる。本質的には、その列における連続
した各エレメントは、直前のエレメントに対して１だけ
アドレスを増加するだけで到達可能である。リニア・マ
ッピングは各列内で生じる。そのマトリクスが「ｎ」行
を有する場合、各列は一定のストライド「ｎ」の列であ
るといえる。この例では、行中の各連続したデータ・エ
レメントをアクセスするためには、１つの完全なデータ
列、即ち、「ｎ」個のデータ・ロケーション（アドレ
ス）がスキップされなければならない。

【００１４】ここでは、ストライドは一定であり、通常
は値「ｎ」である。マトリクスは疎らなものでもよい。
即ち、比較的少数の非ゼロ値のデータ・エレメントが、
ゼロ値のエレメントを他のすべての場所に置かれた比較
的大きいマトリクス全体に分散されたものでよい。その
対角線に沿ってエレメントを有する単位行列は、１つの
そのような例である。疎らなマトリクスの場合、かつ各
非ゼロ・エレメントのマトリクス・ロケーションによっ
ては、前のエレメントのロケーションから測った時の、
各連続したエレメントをアクセスするに必要なアドレス
・インクレメントは、マトリクス全体を通して不規則的
に変化することがあり、また実際そのように変化するこ
とが多いという意味において、これらエレメント（少な
くとも、単位行列に対するものではない）は変化する
（一定でない）不規則なストライドを持つ可能性があ
る。更に、データは不規則的なストライドを持つように
編成可能であるのみならず、これらストライドは任意に
複合的であってもよい。それに関して、そのマトリクス
におけるデータのロケーションはデータそのものの関数
であってもよい。この場合、連続したデータ・エレメン
トのロケーションは、直前のデータ・エレメントが見つ
かりそしてその関数が計算されるまで、容易には決定で
きないかもしれない。便宜上、任意に変化するストライ
ドは、以下では、複合データ・ストライドを含むように
一般的に定義されることになる。

【００１５】物理的メモリはストライド１で編成される
だけであり、それは他の形式をとらない。各メモリ・ロ
ケーションは前のロケーションの直後に続き、前のロケ
ーションのメモリ・アドレスを単に１だけインクレメン
トするだけでアクセス可能である。これに関して、メモ
リ・ロケーション・ゼロは最後のメモリ・ロケーション
のアドレスを１だけインクレメントし、それによって、
メモリ・アドレスを巡回させることによって到達され
る。

【００１６】物理的メモリ内には、種々の動作の制約
（ここでは特別に関連するものはない）によって、デー
タは連続したメモリ・ロケーションにいつも単純に記憶
されるわけではない。事実、データの個々の項目はメモ
リ内の所与の領域にわたって分散されることが多い。そ
のように、データはリンクしたリストの形式で記憶され
ることが多い。更に詳しく言えば、そのようなリストに
おける各エレメントは、典型的には、２つのフィール
ド、即ち、データ・フィールドとそのリストにおける次
の連続したエレメントのメモリにおけるロケーションに
対するアドレス・ポインタとを含む。ベクトルのような
簡単な１次元のデータ構造では、対応するデータ・エレ
メントと「ヌル」値のポインタを含む最終エレメントに
到達するまで、そのリストにおける各項目は１つのデー
タ・フィールドとそのリストにおける次のエレメントに
対する単一のアドレス・ポインタとを含む。一方、２次
元のマトリクス・データ構造の場合、マトリクス・エレ
メントの順序に依存して、各リスト・エレメントは２つ
のポインタを含むことが可能である。即ち、その１つ
は、水平マトリクス方向における次の連続したデータ・
エレメントを含むリスト・エレメントを指定し、もう１
つのポインタは垂直マトリクス方向における次の連続し
たデータ・エレメントを含む異なるリスト・エレメント
を指定する。これに関して、メモリ・スペースを保全す
るために、疎らなマトリクスにおける非ゼロ・エレメン
トだけが物理的メモリにおいて効率的に記憶可能であ
る。

【００１７】残念なことには、データ構造における個々
のリスト・エレメントがメモリ内に分散可能であるの
で、その構造におけるこれら個々のエレメントの各々の
アクセスに関連したストライドは未知であってもよい。
従って、これは、１つの構造における所与のリスト・エ
レメントをアクセスするためには、所望のエレメントに
対するポインタを得るためにすべての前のエレメントが
アクセスされなければならないことを必要とする。対照
的に、データがメモリ内で一定の（規則的な）ストライ
ドで、好ましくは、ストライド１で構成される場合、各
連続したデータ・エレメントをアクセスするために一定
のアドレス・インクレメントが使用されるので、大変効
果的なデータ転送を与えるために直接メモリ・アクセス
（ＤＭＡ）が使用可能である。しかし、以下で明らかな
ように、各データ・アクセスのための適当なメモリ・イ
ンクレメントを計算する必要があるために、ＤＭＡの使
用は、任意に変化するストライドでもって記憶されたデ
ータを転送するためには非常に非効率的になる。

【００１８】物理的メモリにおける任意に変化するスト
ライドのデータの記憶及びそこからのそのデータのアク
セスと関連した特異性が与えられると、そのデータが１
つの処理エレメントと関連のメモリから他のそのような
エレメントと関連のメモリに通信されるべき時、複雑性
及び非効率性が生じる。特に、その真の性質によるデー
タ・メッセージは線形連続のデータ値を含んでいる。即
ち、１つの値が次の値に続き、従って、基本データの実
際の構造に関係なく、メッセージは単にストライド１デ
ータだけを含む。従って、その分野で通常言われている
ように、典型的なパケット交換システムにおける各ノー
ドは２つの独立したＩ／Ｏバッファ、即ち、発信メッセ
ージが送信前に完全にアセンブルされる入力（送信）バ
ッファ及び着信メッセージがその後の使用前に完全に組
み立てられる出力（受信）バッファを含む。パケット・
コミュニケーションの汎用環境におけるそのようなバッ
ファの使用は、米国特許第５１５１８９９号、同第４８
５８１１２号及び同第４５５５７７４号開示されたシス
テムによって代表される。

【００１９】従って、任意に変わるストライドのデータ
を、特に、大規模な並列処理システムにおける１つの処
理エレメントから他の処理エレメントに転送するため
に、送信及び受信処理エレメントにおけるコミュニケー
ション・サブシステムは、ストライド１Ｉ／Ｏバッファ
を介してデータを伝搬する必要があるため、データをス
トライド１に及びストライド１から変換する必要があ
る。更に詳しく言えば、例えば、任意に変化するストラ
イドｘ（但し、ｘは変化する整数である）のデータ構造
がソース処理エレメントで実行しているアプリケーショ
ン・プログラムＡによって、宛先処理エレメントで実行
しているアプリケーション・プログラムＢに送信される
べき場合を考えてみよう。通常言われているように、ア
プリケーション・プログラムＡによって発生されたコマ
ンドに応答して、ソース処理エレメント内で使用される
コミュニケーション・サブシステムは、いわゆる、「ギ
ャザ（ｇａｔｈｅｒ）」動作を介して１つのリンクされ
たリストに記憶されているデータ構造の各項目をメモリ
から連続的にアクセスし、そしてコピーするであろう。

【００２０】この動作を通して、ストライド１出力バッ
ファにおける連続した直線的なロケーションが、１対１
ベースで、このリンクしたリストにおけるデータの連続
した項目でもって満たされるであろう。一旦データ構造
全体がこのバッファ内に記憶されてしまうと、コミュニ
ケーション・サブシステムは、適当なメッセージ・ヘッ
ダ及びトレーラ情報をバッファ内容に付加して完全なパ
ケットを形成し、しかる後、コミュニケーション組織を
通して宛先処理エレメントにそのパケット全体を送信す
る。着信パケットに応答して、宛先エレメントで実行し
ているコミュニケーション・サブシステムは、受信され
た完全なメッセージでもって入力バッファを直列的に満
たす。一旦このバッファがメッセージ全体を捕捉する
と、このサブシステムは、いわゆる「スキャッタ」動
作、即ち、分散動作を行って、アプリケーション・プロ
グラムＢによるその後の使用（しかし、メモリの制約の
ため、典型的には、種々のメモリ・ロケーションにおい
て、しかも、屡々、ソース処理エレメントで使用された
ストライドではなく任意に変化するストライドで）のた
めにメモリにおいてリンクされたリストを再作成する。
詳しく言えば、この「スキャッタ」動作は、入力バッフ
ァから各データ項目を個々にコピーする必要があり、そ
してアプリケーション・プログラムＢが必要とするスト
ライドｙ（ｙは任意に変化する整数であり、一般的には
ｘに等しくない）でもって着信データがメモリ内に分配
されるように、宛先処理エレメントのメモリ内にその項
目を連続して記憶する必要がある。

【００２１】残念なことに、「ギャザ」動作及び「スキ
ャッタ」動作を行う場合、処理時間が消費される。今
や、これらオーバヘッド動作が各処理エレメント内のど
こで実際に行われるかに関係なく、即ち、コミュニケー
ション・サブシステム（上述のように）において行われ
るか、或いはこれらエレメントにおいて実行するアプリ
ケーション・プログラムそのものによって行われるかに
関係なく、これら動作が必要とする処理時間の量は、そ
のエレメントにおいて別途利用可能な処理時間を減少
し、従って、そのアプリケーション・スループットを減
少する。

【００２２】事実、ストライド１Ｉ／Ｏバッファを介し
て大量のデータを通信することに関連したオーバヘッド
処理は、全体のシステム・パフォーマンスを大きく低下
させる傾向がある。特に、データが任意に変化するスト
ライド、特に複合的なストライドで編成される送信端に
おいては、メモリから連続した各データ項目をアクセス
するために適切なアドレス・インクレメントを計算する
ことにかなりの量のオーバヘッド処理時間が消費され
る。複雑なＤＭＡ回路がない場合（それは、回路を単純
化し、コストを減少させるという理由で、一般には、大
規模な並列処理エレメントには使用されない）、このオ
ーバヘッド処理は大量のデータに対しては価値あるもの
であり、従って、大きな待ち時間をシステムに導入す
る。更に、入力バッファの有限なサイズのために、受信
端において重大な遅延が生じ得る。特に、入力バッファ
のサイズを超える大量のデータが受信されるべき場合、
如何なるメッセージにおいても、入力バッファを満たす
だけの量のデータを送信するために、いわゆる「ローリ
ング・ウインドウ」技術が使用されなければならない。
輻輳及び起こり得る上書きを防ぐために、受信処理エレ
メントは、それが受信したデータを完全に「スキャッ
タ」して、送信エレメントからそれ以上のデータを受信
する前にそれの入力バッファを完全に空にするように、
送信エレメントと関連して流れ制御を利用しなければな
らない。従って、実際には、各処理エレメントにおける
入力バッファの制限されたサイズも基本的なシステム・
スループットを制限する。

【００２３】従って、任意に変化するストライドを持っ
たデータの処理エレメント間転送を効果的に処理するた
めのプロトコル、特に、分散処理環境において使用する
ための装置及び付随する方法（特に、大規模な並列処理
システムでは唯一無二の魅力あるものではないけれど
も、）に対する必要性がその分野には存在する。そのよ
うなプロトコルは、好ましくは、各プロセッサ・エレメ
ントにおけるＩ／Ｏバッファを通して着信及び発信メッ
セージ・データを経路指定する必要をなくさなければな
らない。これらバッファの除去は送信及び受信において
データをコピーする必要をなくし、それによって、メッ
セージ伝搬を促進するに必要な処理時間、即ち、オーバ
ヘッドを大いに減少させる。更に、これは、そのような
各エレメントに対する処理時間を自由にし、それによっ
てそのエレメントのアプリケーション・スループットを
増大させ、付随的にシステム全体のスループットも増大
させる。更に、これらバッファを除去することによっ
て、各処理エレメントは、以前に必要とされたものより
も単純になり、少ない回路及びコストしか必要としな
い。従って、これは処理システム全体のコストを減少さ
せるであろう。更に、これらバッファを除くことによっ
て、各エレメントの物理的サイズは減少され、そしてそ
れは、大規模な並列処理システムにおいて使用されるそ
のようなエレメントの実際の数が与えられると、システ
ム全体のサイズを有利に且つ大いに減少させることがで
きよう。

【００２４】

【発明が解決しようとする課題】本発明の目的は、分散
処理環境において、特に、大規模な並列処理環境（これ
に限定するものではないけれども）において、任意に変
化するストライドのアプリケーション・データを処理エ
レメント相互間で転送するための、通常のコミュニケー
ション・プロトコルの使用と関連した欠陥を除去したコ
ミュニケーション・プロトコルを提供することにある。

【００２５】

【課題を解決するための手段】本発明のプロトコルは、
起点アプリケーション・プログラムと宛先アプリケーシ
ョン・プログラムとの間で、ただ１つのパケットによる
のではなく、各々が部分データ・メッセージを含む一連
のパケットによりアプリケーション・データを転送する
ことに基づくものである。各部分データ・メッセージ
は、起点アプリケーション・データ・メモリのストライ
ド１部分に記憶されるデータの一部分を含む。本発明の
一部分を形成するアプリケーション・インターフェース
は、各独立したデータ部分の開始ロケーション及び長さ
をローカル的に決定する。受信の際、各データ部分は、
宛先アプリケーション・データ・メモリのストライド１
部分に書き込まれる。起点処理エレメント及び宛先処理
エレメントの両方で独立して動作するアプリケーション
・インターフェースは、起点アプリケーション・データ
・メモリに記憶され且つアプリケーション・データを受
信すべき宛先アプリケーション・プログラム・メモリに
おける各独立したストライド１領域に対する各ストライ
ド１データ部分の開始アドレス及び長さをそれぞれ決定
する。有利なことに、これらの独立したアプリケーショ
ン・インターフェースの使用によって、アプリケーショ
ン・データは、或任意に変化するストライドの起点アプ
リケーション・データ・メモリから、異なる任意に変化
するストライドを持つ宛先アプリケーション・メモリ
に、そのデータを如何なる入出力（Ｉ／Ｏ）バッファを
も通過させる必要なく転送可能である。

【００２６】本発明の技術によれば、各データ部分の転
送を制御するために、通常のメッセージ制御ブロックに
は存在しない２つの追加のフィールド、即ち、「未完コ
ールバック（ｐｅｎｄｉｎｇ−ｃａｌｌｂａｃｋ）」及
び「未処理サイズ（ｐｅｎｄ−ｓｉｚｅ）」を含むメッ
セージ制御ブロック（ＭＣＢ）が利用される。各部分メ
ッセージに対して、未処理サイズは、そのメッセージに
含まれたデータ部分の長さを指定する。未完コールバッ
クはアプリケーション・インターフェースにおける第１
命令に対するポインタを含む。

【００２７】メッセージ送信に対しては、本発明のアプ
リケーション・インターフェースは、アプリケーション
・データに特有の送信充填関数を利用して、各部分デー
タ・メッセージが起点アプリケーション・データ・メモ
リの非連続的なストライド１部分に記憶されている時の
それら各部分データ・メッセージの開始ロケーション及
びサイズを決定する。このような各部分メッセージが１
つの独立したパケットとして構成されそして送信された
後、コミュニケーション・サブシステムは、いずれかの
データ部分が転送されずに残っているかどうか、従っ
て、更に部分メッセージを送信する必要があるかどうか
を決定する。その必要がある場合、「送信未完エグジッ
ト（ｅｘｉｔ）」の形で動作をアプリケーション・イン
ターフェースに戻すために未完コールバックが使用さ
れ、次のストライド１データ部分に対する開始ロケーシ
ョン及びデータ長を決定させ、しかる後、コミュニケー
ション・サブシステムを介して、そのデータ部分を読み
取らせ、そして最後に、そのデータ部分を含むパケット
を構成させて送信させ、残りのデータ部分すべてに対し
てもそのようにさせる。一方、最後のデータ部分を含む
部分メッセージが送信されてしまった場合、コミュニケ
ーション・サブシステムはメッセージ制御ブロックにお
いて指定された完了コールバックを呼び出し、送信完了
エグジットを設定する。

【００２８】メッセージ受信に対して、本発明のプロト
コルは、送信とは本質的に逆の態様ではあるけれども、
たいへん類似して機能する。詳しく言えば、各部分メッ
セージが受信された後、本発明のアプリケーション・イ
ンターフェースは、受信充填関数を利用して、そのデー
タ部分が記憶されるべき（メモリ領域に関するデータ部
分のサイズによって部分的に又は完全に記憶されるべ
き）宛先アプリケーション・メモリにおけるストライド
１メモリ領域の開始ロケーション及び長さを、宛先アプ
リケーションの必要条件に基づいて決定する。この情報
は宛先アプリケーション・プログラムに与えられ、この
宛先アプリケーション・プログラムが未処理サイズをこ
の長さに等しくセットし且つデータ・ポインタを開始ロ
ケーションにセットすることによって、受信動作を開始
させたメッセージ制御ブロックを更新する。そこで、そ
の更新されたＭＣＢはコミュニケーション・サブシステ
ム（宛先処理エレメント内で機能する）に与えられる。
コミュニケーション・サブシステムは、この部分メッセ
ージをその後受信するとき、そこに含まれたデータ部分
をストライド１メモリ領域にその開始アドレスで且つ指
定された長さだけ書き込むだけである。

【００２９】各部分メッセージが受信された後、コミュ
ニケーション・サブシステムは、何れかのデータ部分が
脱落しているかどうか、即ち、何れかの部分メッセージ
が受信されずに残っているかどうかを決定する。それが
残っている場合、「受信未完エグジット」の形で動作を
アプリケーション・インターフェースに戻すために、本
発明のＭＣＢにおける未完コールバックが使用されて、
次のデータ・パケットに対するストライド１メモリ領域
の開始アドレス及びデータ長を決定させ、しかる後、コ
ミュニケーション・サブシステムを介して、そのデータ
部分を次の着信パケットから取り出させて宛先アプリケ
ーション・メモリにおけるこの領域に書き込ませ、そし
て残りのデータ部分すべてに対してもこのようにさせ
る。一方、最後のデータ部分を含む部分メッセージが受
信されてしまった場合、コミュニケーション・サブシス
テムはＭＣＢにおける指定された完了コールバックを呼
び出し、受信完了エグジットを設定する。

【００３０】有利なことに、データ転送の各側で独立の
アプリケーション・インターフェースを使用することに
よって、未処理サイズ及び長さの決定は起点処理エレメ
ント及び宛先処理エレメントの両方によりこのデータに
対して独立して且つローカル的に行われる。従って、適
正な充填関数がそのインターフェースにおいて且つそれ
と関連した各異なったアプリケーション・プログラムに
対して使用される限り、対応するアプリケーション・デ
ータ・メモリの適正な領域が連続的にアドレスされて関
連の任意に変化するストライドで各データ部分を読み取
り又は書き込む。従って、本発明のプロトコルは、アプ
リケーション・データを或メモリから他のメモリに、種
々の任意に変化するストライドで且つデータの長さに関
係なく移動させるための一般化された機構を提供する。

【００３１】或任意に変化するストライドのデータを他
の任意に変化するストライドのデータに変換するために
中間Ｉ／Ｏバッファを使用する必要を除くために、本発
明のプロトコルは各処理エレメント及びシステム全体に
おける回路の複雑性、物理的サイズ、及びコストの付随
的節約を生じる。更に、これらバッファを介してアプリ
ケーション・データをコピーするために必要であった処
理オーバヘッドを除くことによって、各処理エレメント
に対する、従って、システム全体のアプリケーション処
理スループットを大いに増大させることができる。

【００３２】更に、１つの特徴として、本発明のプロト
コルはデータ・フィルタリング及び切り捨てを行うよう
容易に使用可能である。データ送信の際、アプリケーシ
ョン・データは、このデータの不要なセクションを除去
するために、そのデータのそれらセクションの各々をス
キップするよう送信充填関数の使用を通してデータ・ポ
インタをセットするだけで、フィルタ可能である。切り
捨ては、データ受信中、受信充填関数が未処理サイズを
ゼロにセットするだけで行うことが可能である。これ
は、現在のアプリケーション・データ転送に対して受信
されるべきそれ以上の部分データ・メッセージがないこ
と、従って、受信完了エグジットが生じるべきであるこ
とを宛先処理エレメントにおけるコミュニケーション・
サブシステムに信号で伝えるであろう。

【００３３】

【実施例】上記の説明を考察すれば、本発明が教示する
ことが、如何なる分散多重処理環境においても、そして
一般的に言えば、任意に変化する（複合を含む）ストラ
イドのデータを、１つの処理エレメントと関連したメモ
リから他の処理エレメントと関連したメモリに転送する
必要がある如何なる処理環境においても、容易に利用可
能であることは当業者には容易に理解できるであろう。
それにもかかわらず、以下の説明を簡単にするために、
プロセッサ間コミュニケーションを容易にするようパケ
ット・ネットワークを利用する大規模な並列処理システ
ムを使用した環境で本発明を説明する。しかし、本発明
は、如何なる特定のアプリケーションにも限定されるも
のではなく、そして、任意に変化するストライド（以下
で詳細に説明される）に記憶されたアプリケーション・
データをプロセッサ間メッセージを基本として転送する
ことに適用可能である。従って、以下の説明は如何なる
特定のアプリケーションにも関連するものではない。

【００３４】Ａ．処理環境 具体的に説明すると、図１は、本発明を利用する大規模
な並列処理システム５の非常に高レベルの簡単なブロッ
ク図を示す。一般には、このシステムは１つのアプリケ
ーションにおける別個の部分を並列に処理する比較的多
数（Ｋ個）の独立した処理エレメント１０で形成され
る。これらプロセッサの各々が個々のアプリケーション
処理タスクを遂行するために、必要に応じて、各プロセ
ッサはパケット・ネットワークを介して他のプロセッサ
と通信し、特に、パケット・メッセージを介して他のプ
ロセッサとの間でアプリケーション・データを転送す
る。各プロセッサは、他の処理エレメントから必要なデ
ータを受信した時にその関連のアプリケーション処理を
引き受け、そしてその処理の結果を他の処理エレメント
に、そこでのその後の処理のために、再びパケット・メ
ッセージによって通信する。

【００３５】関連する範囲を更に詳しく言うと、システ
ム５は高速度パケット・ネットワーク５０及びＫ個の同
じマイクロプロセッサ・ベースの処理エレメント１０か
ら形成され、それら処理エレメントはすべてパス２０を
介してそのネットワークに接続される。このネットワー
クは、任意の対の処理エレメント１０の間でパケットを
伝搬できるクロスポイント・ベースのパケット・コミュ
ニケーション組織を提供する。これに関して、ネットワ
ーク５０は、機能的には、Ｊ＊Ｋのクロスポイント・ス
イッチング・マトリックス４０から成り、そのマトリク
スは、スイッチング接点４０_1,1；４０_2,1；・・・４０
_J,K によって示された独立したクロスポイントを含む。
それらスイッチング接点は、選択的に及びパケット・ヘ
ッダに含まれた経路指定情報の方向に基づいて、対応す
る水平方向及び垂直方向のネットワーク・パス２０を接
続して任意の２つの処理エレメント間のパケット接続を
設定する。これらパスの各々は、対応するマイクロプロ
セッサ・ベースの処理エレメントにおいて終了する。こ
れに関して、処理エレメント１０₁、１０₂、１０₃、・
・・１０_J；及び１０_J+1、１０_J+2、１０_J+3、・・・１
０_Kは、それぞれのパス２０₁、２０₂、２０₃、・・・２
０_J及び２０_J+1；及び２０_J+2、２０_J+3、・・・２０_K
を介してネットワーク５０に接続される。

【００３６】例えば、処理エレメント１０₁は、パケッ
ト３３を形成することによって処理エレメント１０_J+1
にアプリケーション・データを通信できる。そのパケッ
トは、クロスポイント４０_1、1を閉成するよう付属の経
路指定情報を介してネットワーク５０に指示し、それに
よって、破線４３により示されるようにパケット接続を
設定してこれら２つの特定な処理エレメント間でこのパ
ケットを伝搬することができる。同様に、処理エレメン
ト１０_J+3は、パケット３７を形成することによって処
理エレメント１０₃にアプリケーション・データを通信
できる。その場合、そのパケット３７は、クロスポイン
ト４０_3、3を閉成するよう付属の経路指定情報を介して
ネットワーク５０に指示し、それによって、破線４７に
より示されるようにパケット接続を設定してこれら２つ
の特定な処理エレメント間でこのパケットを伝搬するこ
とができる。

【００３７】パケット・ネットワーク５０は、非同期転
送モードを使用するというような広範囲の種々なアーキ
テクチャの１つを導入することもできる。しかし、選ば
れた特定のアーキテクチャ及びその詳細は、それが内部
的なパケット経路指定を達成する態様と共に、すべて本
発明とは無関係であり、従って、以下では詳細に説明し
ない。

【００３８】それら処理エレメントはすべて同じものな
ので、この説明はエレメント１０₁に集中させる。これ
に関して、図２は、処理システム５において利用される
例示的な処理エレメント１０₁の高レベルのブロック図
である。

【００３９】高レベルでは、エレメント１０₁は、マイ
クロプロセッサ２２０、メモリ２３０及び入出力（Ｉ／
Ｏ）回路２１０から形成され、それらはすべて内部バス
２４０を介して内部接続される。システム・パフォーマ
ンス及びスループットを増加させるために、マイクロプ
ロセッサは、縮小命令セット（ＲＩＳＣ）回路を使用し
て実現するのが望ましい。しかし、本発明は、Ｉ／Ｏ回
路２１０及びメモリ２３０の実施と同様に、その選ばれ
た特定のマイクロプロセッサには無関係であるので、こ
れら回路のうち、本発明にとって重要な点だけを以下で
は説明する。

【００４０】Ｉ／Ｏ回路２１０は、パス２０₁を介して
パケット・ネットワーク５０に電気的に接続され、処理
エレメント１０₁において実行するコミュニケーション
・ソフトウエア・ルーチンと関連して、このネットワー
クを介して他の処理エレメントパケット・コミュニケー
ションを行う。コミュニケーション・サブシステム・ル
ーチン及びその関連のＩ／Ｏ回路は、処理エレメント間
パケット・コミュニケーションを処理するように処理エ
レメント内でタスクとして実行するコミュニケーション
・サブシステムを形成する。このコミュニケーション
は、送信のために次のような動作を伴う。即ち、起点の
アプリケーション・データ・メモリから必要なアプリケ
ーション・メモリをコピーし、適切なプロトコル・ヘッ
ダ（経路指定情報及びアプリケーション識別情報を有す
る）、データ及び後書き情報（例えば、メッセージ・デ
リミッタ等）を含むようにパケットを適正にアセンブル
し、これらパケットをネットワーク５０に乗せる。そし
て受信に対しては、着信パケットに関して適当な妥当性
チェック及びエラー・チェックを行い、妥当なパケット
に対しては、対応するアプリケーションにこのデータの
到着を知らせ、そのデータを宛先アプリケーション・デ
ータ・メモリにコピーする。

【００４１】ランダム・アクセス・メモリ（ＲＡＭ）を
使用して実施可能なメモリ２３０は、線形シーケンスの
物理的メモリ・ロケーションを含み、それらロケーショ
ンの一部分がメモリ・マップ２５０に示される。処理エ
レメント１０₁に対して、このメモリはアプリケーショ
ン・プログラムをメモリ・ロケーションｌ乃至ｎに、コ
ミュニケーション・サブシステム・ソフトウエア・ルー
チン２６０をロケーションｎ乃至ｏに、そしてオペレー
ティング・システム２６２をロケーションｏ乃至ｐに記
憶する。上述のように、このソフトウエア配置は、ほと
んどのマイクロプロセッサ・ベースの大規模な並列処理
システムにおいて一般的に使用される。

【００４２】本発明の教示するところによれば、及び、
詳しく後述するように、アプリケーション・ソフトウエ
アは、アプリケーション・プログラムをそのままでなく
高レベルで、例えば、ロケーションｌ乃至ｍにある高レ
ベル・アプリケーション・プログラム２５２のみなら
ず、ロケーションｍ乃至ｎに記憶された本発明関連の低
レベル・アプリケーション・インターフェースも含むよ
う修正される。高レベル・アプリケーション・プログラ
ム２５２及び低レベル・アプリケーション・インターフ
ェース２５４は共にアプリケーション層２５５を形成す
る。動作的に言えば、本発明のアプリケーション・イン
ターフェースは、後述のようにコミュニケーション・サ
ブシステム及び高レベル・アプリケーション・プログラ
ムと関連して使用される時、任意に変化するストライド
のアプリケーション・データを、コミュニケーション・
サブシステムを介して及び個々の処理エレメント相互間
で、中間のＩ／Ｏバッファを通過させる必要なく都合よ
く転送する。

【００４３】現在、上述のような通常の大規模な並列処
理システムの場合、データ転送はシステム・パフォーマ
ンス、物理的システム・サイズ及びコストにおいて大き
な不利益を強いることがある。この理由は、この分野で
通常言われているように、コミュニケーション・サブシ
ステム（又はアプリケーション・プログラムそのもの）
は所与のメッセージに対するすべての発信データをそれ
の送信前にアプリケーション・データ・メモリから入力
バッファにコピーすること及び受信の時には着信メッセ
ージにおけるすべてのデータを出力バッファからアプリ
ケーション・データ・メモリにコピーすることに依存す
ることである。これらバッファの各々はストライド１メ
モリで編成されるけれども、即ち、各データ・ロケーシ
ョンがギャップなしで前のロケーションに連続的且つ直
列的に続くけれども、送信アプリケーション・プログラ
ムによって形成され、受信アプリケーション・プログラ
ムによって使用される基本的データが、ストライド１デ
ータとして編成されることは滅多にない。事実、アプリ
ケーション・データは任意に変化するストライドでもっ
て編成され、記憶される。更に、これら任意の変化は１
つの処理エレメントにおける１つのアプリケーションか
ら異なる処理エレメントにおける他のアプリケーション
と同じものまで幅広く相違させることができる。

【００４４】その結果、送信前に、送信アプリケーショ
ンによって宛先（受信）アプリケーションまで送信され
るべきすべてのデータが先ず種々のメモリ・ロケーショ
ンから且つそのデータが記憶されるストライドが変わる
時に、「ギャザ」されなければならず、そしてコミュニ
ケーション・サブシステムに含まれた出力バッファにス
トライド１データとしてコピーされなければならない。
同様に、受信の際、パケットに含まれた受信データは先
ずそのストライド１編成から変換され、そして宛先アプ
リケーション又はそのアプリケーション・データ・メモ
リが必要とするストライドに変化する時、宛先アプリケ
ーション・データ・メモリに選択的にコピーされなけれ
ばならず、明確に言えば、分配又は「スキャッタ」され
なければならない。

【００４５】残念なことに、アプリケーション・スルー
プットの増加において費やされるのが最上の貴重な処理
時間が、これら「ギャザ」及び「スキャッタ」動作行う
場合には、代わりにオーバヘッドとして消費される。事
実、メモリ・ストライドの任意の変化という性質によっ
ては、連続した各データ項目に対する適正なメモリ・ア
ドレスを単に計算することだけに大量の処理時間が消費
されることがある。大量のデータがある場合、これら計
算に当てられる処理時間は、アプリケーション・スルー
プットを大きく減少させ、処理システム全体の処理スル
ープットにかなりの待ち時間を導くことがある。更に、
入力バッファを内蔵することは回路の複雑性を増大さ
せ、従って、各処理エレメント及びシステム全体のコス
ト及びサイズを増大させる。

【００４６】任意に変化するストライドを持ったデータ
の処理エレメントに基づく一般的な転送に付随する欠点
を十分に認識するために、先ず、データ・ストライドの
概念に関する説明を行う。しかる後、独立した処理エレ
メント間でデータを転送するために通常使用されるプロ
トコルを詳しく説明する。その後、そのような転送をＩ
／Ｏバッファを通過させる必要なしに処理するための本
発明のプロトコルを、データ・フィルタリング及びデー
タ切り捨てまでのそのプロトコルの拡張と共に説明す
る。

【００４７】Ｂ．メモリ・ストライド 暫くの間、図３に示されたＮ＊ｎマトリクス３００を考
察する。一部分しか示されてないこのマトリクス（Ｎ列
及びｎ行を有する）は、行０に例示的なマトリクス・エ
レメント３００_0、0、３００_1、0、３００_2、0・・・３０
０_N,1及び列０に３００_0、0、３００_0、1、３００_0、2、３
００_0、3・・・３００_0、nを含んでいる。データが列方向
に記憶される場合、即ち、任意の列における後続の各デ
ータ・エレメントがその列における先行データ・エレメ
ントの直後に続いて記憶される場合、エレメント３００
_0、1のような任意のデータ・エレメントが与えられる
と、次に続くエレメント３００_0、2は、前のエレメント
のアドレスを１だけインクレメントすることによって簡
単に得られる。このように、列０のような任意の列に沿
ったデータへのアクセスは、最初のデータ・エレメント
のメモリ・アドレスを１ずつ連続的にインクレメントす
ることによって生じる。このように、各列は「ストライ
ド１」であると言える。勿論、データは一定の非１スト
ライドでもって編成される。

【００４８】行方向記憶のマトリクス３００の場合、エ
レメント３００_1、0の後にエレメント３００_2、0をアクセ
スするような１つの所与の行における連続したエレメン
トのアクセスは、ｎ個の個々のメモリ・ロケーションに
わたって、即ち、１列の長さだけスキップする必要があ
る。従って、マトリクス・エレメント３００_1、0からエ
レメント３００_2、0をアクセスするためには、前者のエ
レメントのアドレスにｎ個のメモリ・アドレス・インク
レメントが加えられて後者のエレメントに到達するよう
にしなければならない。各列は同じ長さ、即ち、ｎ個の
ロケーションを持つので、Ｎ個の列の各々はストライド
ｎであると言える。

【００４９】対照的に、図４に示されたＮ＊ｎマトリク
ス４００を考察する。マトリクス４００もマトリクス３
００のように列方向に記憶される。マトリクス４００
は、非ゼロの対角方向データ・エレメントＸ_0,0、
Ｘ_1,1、Ｘ_2,2、Ｘ_3,3、・・・Ｘ_N-1,n-1及び非対角方向
の非ゼロ・エレメントＸ_N-a,n-b及びＸ_0,nから形成され
る。垂直方向及び水平方向において１又はｎの一定の及
び規則的なストライドをを有するマトリクス３００とは
対照的に、マトリクス４００は変化するストライドを有
する。エレメントＸ_1,1からエレメントＸ_2,2へのアクセ
ス及びエレメントＸ_0,0からエレメントＸ_1、1へのアクセ
スと関連したアドレス・インクレメント、従って、メモ
リ・ストライドは一定及び規則的である。しかし、エレ
メントＸ_2,2からエレメントＸ_N-a,n-bへのアクセスと関
連したアドレス・インクレメントはエレメントＸ_1,1か
らエレメントＸ_2,2へのアクセスと関連したそれとは必
ずしも等しくない。同様に、エレメントＸ_N-a,n-bから
Ｘ_0,nへのアクセスと関連したストライドは、このマト
リクスにおける如何なる前のエレメントと関連したスト
ライドとも異なることがある。従って、マトリクス４０
０における連続したエレメントがアクセスされる時、こ
れらエレメントと関連したストライドは、どのエレメン
トがアクセスされようとしているかによって変化する。

【００５０】更に、事態を複雑にするが、データは、い
わゆる、「複合」ストライド（マトリクス４００には明
瞭には示されてないけれども）を持つことができる。複
合ストライドでは、そのストライドは記憶されたデータ
値又は対応するメモリ・アドレスそのものの関数であ
る。従って、複合ストライドを持ったデータをアクセス
するためには、次に続くデータ・エレメントに対するメ
モリ・インクレメントは、直前のデータ・エレメントの
それに対するメモリ・アドレス又は実際のデータ値の関
数として決定される必要があるかもしれない。明らか
に、適正なアドレス・インクレメントの決定における処
理時間は拡大される。特に、複合ストライドの場合又は
大きなデータ転送に対する場合、それは大量のオーバヘ
ッドを生じさせることがある。任意に変化するストライ
ド及び複合ストライドの両方とも、通常のデータ・メッ
セージ処理では同じ欠点を与える。しかし、これらスト
ライドの何れかを持ったデータの転送と関連した欠点
は、本発明によって都合よく除かれるので、参照の便宜
上、これらストライドの両方とも、以下では、単純に任
意に変化するストライドとして集合的に参照される。

【００５１】Ｃ．通常の処理エレメント間データ・コミ
ュニケーション・プロトコル 本質的には、上述のように、大規模な並列処理システム
における通常のデータ転送は、起点処理エレメントにお
けるアプリケーション・データ記憶装置から宛先処理エ
レメントにおけるアプリケーション・データ記憶装置に
転送されるべきすべてのアプリケーション・データを前
者のエレメントにおけるストライド１出力バッファにコ
ピーするためにコミュニケーション・サブシステムに依
存する。このコピー動作は、このデータの個々の部分す
べてを、各部分が記憶されるストライドに関係なくこの
ストライド１バッファに、１つの部分が他の部分の直後
に続くように、連続的に「ギャザリング」する必要があ
る。そのような各部分をアクセスするための開始アドレ
ス及び長さは起点エレメントにおけるアプリケーション
・プログラムによって決定され、供給される。しかる
後、起点エレメントにおけるコミュニケーション・サブ
システムは、このデータすべてを含む単一のパケットを
形成し、パケット・ネットワークを介して宛先処理エレ
メントにこのパケットを送信する。

【００５２】同様に、基本的には逆であるけれども、通
常、着信データを受信する場合、宛先処理エレメントに
おけるコミュニケーション・サブシステムは、このデー
タをすべてストライド１入力バッファにコピーする。一
旦このコピーが完了すると、コミュニケーション・サブ
システムは、このデータの連続部分をそのバッファから
ローカル・アプリケーション・データ・メモリに任意に
変化するストライドで分散（スキャッタ）する。宛先エ
レメントで実行するアプリケーション・プログラムは、
ローカル的に記憶されるべきそのような各部分に対する
開始メモリ・アドレス及び長さを供給する。起点エレメ
ント及び宛先エレメントは、通常は、同じデータを種々
の任意に変化するストライドで記憶する。それら部分の
各々のサイズも、起点エレメントと宛先エレメントとの
間では異なることがある。

【００５３】図５は、通常のメッセージ制御ブロック
（ＭＣＢ）、例えば、ＭＣＢ５００及びそれの構成フィ
ールドを示す。図示のように、ＭＣＢ５００は３つの独
立したフィールド、即ち、プロトコル・ヘッダ５１０、
データ・ポインタ５３０、及び完了コールバック５４０
を含む。プロトコル・ヘッダ５１０は長さフィールド５
２０及び他のフィールド（図を簡単にするためにすべて
図示されてない）を含む。その長さフィールド５２０
は、送信されるべき又は受信されるべきデータすべての
合計バイト長を指定する。上記他のフィールドは、この
データが送られる特定の処理エレメント、このデータを
得るべき実行中の特定のアプリケーション、及びこのデ
ータの起点となる処理エレメント及びアプリケーション
指定する（代表的には、経路指定ヘッダによる）。送信
に対しては、データ・ポインタ５３０は、送信されるべ
きデータの第１メモリ・ロケーションの起点アプリケー
ション・データ・メモリにおけるアドレスを含む。受信
に対しては、このデータ・ポインタは、このデータが記
憶されるべき宛先アプリケーション・データ・メモリに
おける第１メモリ・ロケーションのアドレスを含む。

【００５４】完了コールバック・フィールド５４０は、
実行が終わった時、一般に「エグジット（ｅｘｉｔ）」
と呼ばれているものを実装する命令に対するポインタを
持っており、パケット・コミュニケーション動作の完了
時に直ちに読み出しプログラムに戻す。特に、データ・
パケットが送信されるべき場合、この終了は、いわゆる
「送信完了エグジット」であり、それはコミュニケーシ
ョン・サブシステムがこのパケットを正常に送信したこ
とを起点アプリケーション・プログラムに効果的に知ら
せる。一方、データパケットが受信されるべき場合、こ
のエグジットは、いわゆる「受信完了エグジット」であ
り、それはデータ・パケット全体が正常に受信されたこ
とを宛先アプリケーション・プログラムに効果的に知ら
せる。実行が何れかのエグジットを通過する時、これ
は、アプリケーション・プログラムにより呼び出された
現在のコミュニケーション・タスクが正常に終了し、そ
れによって、そのアプリケーション・プログラムが他の
タスクを呼び出すのを可能にする。

【００５５】図６は、処理エレメント間データ転送を処
理するための各処理エレメント、例えば、エレメント１
０₁において通常の、即ち、従来のプロトコルを実施す
るために利用されるプロセスを高レベルのブロック形式
で示す。図示のように、これらプロセスは、コミュニケ
ーション・サブシステム６２０と関連したアプリケーシ
ョン・プログラム６１０を含み、そしてコミュニケーシ
ョン・サブシステムはＩ／Ｏバッファ６３０を含む。独
立の入力バッファ及び出力バッファ（両方ともこの図に
は明確には示されていない）は、着信メッセージ・デー
タ及び発信メッセージ・データのコピーを保持するため
に使用される。メモリ２３０（図２参照）における負担
を軽減し、従って、各処理エレメントの処理スループッ
トを増大させるために、通常これらバッファは、各処理
エレメントにおける関連の物理的メモリ２３０内にある
プログラム及びデータ記憶領域とは別個の高速度ハード
ウエア・バッファを占有する。図６に示された線６１５
で表わされるように及び上述のように、通常のコミュニ
ケーション・プロトコルは、アプリケーション・プログ
ラム６１０及びコミュニケーション・サブシステム６２
０の間の双方向対話に依存する。この対話は、アプリケ
ーション・プログラムによってＭＣＢ５００（図５参
照）をコミュニケーション・サブシステムに発生するこ
と、アプリケーション・プログラムによって開始アドレ
ス及び長さ情報をコミュニケーション・サブシステムに
与えること、及びコミュニケーション動作の正常な終了
時に、アプリケーション・プログラムにおける適当なエ
グジット動作を呼び出すためにコミュニケーション・サ
ブシステムによって完了コールバックを発生することに
よって例証される。

【００５６】上記のことを留意して図７を参照すると、
これらの図は、システム５において１つの処理エレメン
ト、例えば、エレメント１０₁からパケット・コミュニ
ケーションを介して他のエレメント、例えば、エレメン
ト１０_J+1に、任意に変化するストライドの例示的デー
タを通常どうりに転送する方法の高レベルのシステム・
ブロック図を示す。

【００５７】説明の便宜上、処理エレメント１０₁にお
いて実行するアプリケーション・プログラムＡは、アプ
リケーション・プログラムＡのデータ・メモリ７００に
おける５つの異なるメモリ領域、即ち、記憶領域７００
Ａ、７００Ｂ、７００Ｃ、７００Ｄ、及び７００Ｅに現
在記憶されているデータ、即ち、部分Ａ、Ｂ、Ｃ、Ｄ及
びＥを、アプリケーション・プログラムＢによるその後
の使用のために処理エレメント１０_J+1にあるアプリケ
ーション・プログラムＢのデータ・メモリ７６０に転送
しようとしていると仮定する。明瞭には示されていない
けれども、各処理エレメントに対するアプリケーション
・データ・メモリはそのエレメント内にある物理的メモ
リ、即ち、図２に示されたメモリ２３０内に含まれる。
図７に示されるように、これらのデータ部分は任意に変
化するストライド、従って、非一定且つ不規則的なスト
ライド（例えば、ストライドｘ）を記憶される。このデ
ータを処理エレメント１０₁から転送するために、アプ
リケーション・プログラムＡは、このデータの各部分が
記憶されている開始アドレス及びこのような各部分の長
さを決定する。このアドレス及び長さ情報はコミュニケ
ーション・サブシステム６２０に送られる。このコミュ
ニケーション・サブシステムは、このデータの各部分
（リンクされたリストとして集合的に記憶されることが
多い）をアクセスし、そしてその部分を、コミュニケー
ション・サブシステム６２０にあるストライド１出力バ
ッファ６３２内の連続したロケーションに読み込む。

【００５８】メモリ開始アドレス及びデータ長を先ず決
定しそして各データ部分をメモリ７００から出力バッフ
ァ６３２の対応部分に１対１でコピーするというこの動
作全体は、線７１０により示される、いわゆる「ギャ
ザ」動作を遂行することである。その結果、これら５つ
の無関係に置かれたデータ部分が、ストライド１データ
として集合的に構成されるように、出力バッファ６３２
相互に連続してコピーされる。処理エレメント１０_J+1
に送信されるべきすべてのデータ（ここでは、データ部
分Ａ乃至Ｅより成る）がストライド１データとして出力
バッファ６３２に一旦コピーされると、コミュニケーシ
ョン・サブシステム６２０は、線７１５により示される
ように、このサブシステムの一部分を形成する周知のパ
ケット・アセンブリ及び送信プロセス７２０を介してデ
ータを取り出し、このデータすべて及び適当なヘッダ及
びトレイラ情報を含む適当なメッセージ・パケットを構
成し、しかる後、パス２０₁を介してコミュニケーショ
ン組織５０にそのパケットを送信する。

【００５９】コミュニケーション組織を介して送られる
メッセージ・パケットの一般的形式がパケット７７０に
よって示される。このパケットは、３つの基本的フィー
ルド、即ち、ヘッダ・フィールド７７２、データ・フィ
ールド７７４、及びトレイラ・フィールド７７６を含
む。ヘッダ・フィールド７７２は種々のフィールド（す
べて通常のものであり、図示されてない）を含んでお
り、なかんずく、パケットに含まれたデータが送られる
宛先処理エレメント及びそこで実行するアプリケーショ
ン、並びにこのデータを発生する処理エレメント及びア
プリケーション・プログラムを指定するフィールドを含
んでいる。データ・フィールド７７４は、アプリケーシ
ョン・プログラムＡ及びアプリケーション・プログラム
Ｂの間で送信されるべきすべてのデータ、ここでは、ス
トライド１構成で配置されたデータ部分Ａ乃至Ｄより成
るデータを含んでいる。トレイラ・フィールド７７６は
種々のフィールド（すべて通常のものであり、図示され
てない）を含んでおり、なかんずく、種々のデリミッタ
及びエラー訂正のために使用されるフィールドを含んで
いる。

【００６０】そこで、パケット７７０はコミュニケーシ
ョン組織５０を介して処理エレメント１０_J+1に搬送さ
れる。それの到達の時、コミュニケーション・サブシス
テム６２０の一部分を形成するパケット受信及びディス
アセンブリ・プロセス７４０がエレメント１０_J+1を処
理してそのパケットに含まれたすべてのデータを取り出
す。説明の便宜上、このデータはアプリケーション・プ
ログラムＢによって送信請求されたと仮定する。その場
合、着信パケット７７０は、そのデータがこのアプリケ
ーション・プログラムＢによって要求されるまで、コミ
ュニケーション・サブシステムによって一時的に記憶さ
れるというものではない。従って、送信請求されたデー
タに対して、パケット７７０から取り出されたデータは
コミュニケーション・サブシステム６２０によって利用
されるストライド１入力バッファ６３４にコピーされる
であろう。着信パケット内に含まれたすべてのデータ
（ここでは、データ部分Ａ乃至Ｅ）が一旦ストライド１
入力バッファ６３４にコピーされてしまうと、アプリケ
ーション・プログラムＢは、このデータの各部分に対す
る開始メモリ・アドレス及びそのような各部分の長さを
決定することによってそのデータを、このアプリケーシ
ョンが必要とするもの、ここではＡ'、Ｂ'、Ｃ'、及び
Ｄ'として示された４つの部分に効果的に区分される。

【００６１】しかる後、アプリケーション・プログラム
Ｂは、このアドレス及び長さ情報をコミュニケーション
・サブシステムに供給する。コミュニケーション・サブ
システムは、これら部分の各々を、このアプリケーショ
ンが使用しようとしているストライド（例えば、任意に
変化するストライドｙ、但し、一般にはｙはｘに等しく
ない）でもって、対応するメモリ領域７６０_A'、７６０
_B'、７６０_C'、及び７６０_D'内に１対１で記憶する（こ
のデータはリンクされたリストとして集合的に記憶され
ることが多い）。この区分化及び記憶動作は、いわゆる
「スキャッタ」動作であり、線７５０によって示され
る。同様に、ギャザ動作とは反対であるけれども、スキ
ャッタ動作は、アプリケーションＢのデータ・メモリに
おける開始メモリ・ロケーション及び個々の各データ部
分（Ａ'乃至Ｄ'）の長さの両方を計算すること及びその
部分をアプリケーションＢデータ・メモリ内の対応する
記憶領域にコピーすることを含む。

【００６２】従って、容易に明らかなように、ストライ
ド１出力バッファ及びストライド１入力バッファを使用
する２つのコピー動作を介して、起点処理エレメントに
あるどのような任意に変化するストライドのデータから
でも、宛先処理エレメントにおけるアプリケーション・
プログラムが必要とするどのような任意に変化するスト
ライドのものにでもに、データを変換するという付随的
な必要性があっても、通常のデータ転送プロトコルで
は、起点処理エレメントから宛先処理エレメントにその
データすべてを送信するために１つのパケット７７０し
か使用しない。

【００６３】理解を固めるために、図８は、データの送
信及び受信の両方に対する機能的な見地からのこの通常
のプロトコルを示す。

【００６４】特に、図８は、この従来のプロトコルの高
レベルの機能的ブロック図を示し、特にその部分８００
は、処理エレメント１０₁において実行するアプリケー
ション・プログラムＡから処理エレメント１０_J+1にお
いて実行するアプリケーション・プログラムＢにアプリ
ケーション・データを送信するためのものである。

【００６５】図示のように、データを送信するために、
アプリケーション・プログラムＡ（一般的には、図６に
示されたアプリケーション・プログラム６１０とみなす
ことができる）は、ブロック８１０によって示されるよ
うに、通常のメッセージ制御ブロック（ＭＣＢ）５００
を発生する。アプリケーション・プログラムＡは、プロ
トコル・ヘッダ・フィールド、長さフィールド、及び完
了コールバック・フィールド（図５参照）に適当なエン
トリを挿入する。長さフィールドは、送信されるべきデ
ータ全体の長さのバイト・カウントを与えられる。プロ
トコル・ヘッダの残り部分は、なかんずく、起点処理エ
レメント及び宛先処理エレメント、この場合、エレメン
ト１０₁及び１０_J+1、並びにそのデータを発生するアプ
リケーション・プログラム及びそのデータを供給される
アプリケーション・プログラム、この場合、アプリケー
ション・プログラムＡ及びＢ、を識別するために与えら
れる。しかる後、図８に示されるように、アプリケーシ
ョン・プログラムＡは線８１５によってＭＣＢ５００を
コミュニケーション・サブシステム６２０に与える。更
に、アプリケーション・プログラムＡは、それぞれバラ
バラに記憶されたそのデータのストライド１部分に対す
る開始ロケーション及び長さをすべて決定する。

【００６６】それに応答して、コミュニケーション・サ
ブシステム６２０はそのデータ部分をすべてアプリケー
ションＡのデータ・メモリからストライド１出力バッフ
ァ６３２にコピーする。しかる後、コミュニケーション
・サブシステムは、図８のブロック８３０によって示さ
れるように、そのデータを含むデータ・パケットを構成
し、コミュニケーション組織を介して宛先処理エレメン
ト１０_J+1にそのパケットを送信する。一旦パケットが
正常に送信されると、コミュニケーション・サブシステ
ムはアプリケーション・プログラムＡに完了コールバッ
クを与える（ブロック８４０）。即ち、実行は、ＭＣＢ
５００の完了コールバック・フィールドで指定されたア
ドレスにあるこのアプリケーション・プログラム内の命
令に戻される。このように及び線８４５によって示され
るように、完了コールバックの結果、プロトコルから送
信完了エグジットを生じる。

【００６７】図９は、処理エレメント１０_J+1において
行われるこの従来のプロトコルの高レベルの機能的ブロ
ック図を示す。特に、このプロトコルの部分９００は、
処理エレメント１０₁において実行されるアプリケーシ
ョン・プログラムＡによって送信されそしてエレメント
１０_J+1において実行されるアプリケーション・プログ
ラムＢに与えられるアプリケーション・データを受信す
るためのものである。

【００６８】図示のように、データを送信請求するため
に、アプリケーション・プログラムＢ（一般には、図６
に示されたアプリケーション・プログラム６１０とみな
すことができる）は、ブロック８１０で示されるよう
に、先ずメッセージ制御ブロック（ＭＣＢ）５００を発
生する。アプリケーション・プログラムＢは、プロトコ
ル・ヘッダ・フィールド、長さフィールド、データ・ポ
インタ・フィールド、及び完了コールバック・フィール
ド（図５参照）に適当なエントリを挿入する。長さフィ
ールドは、受信されるべきデータ全体の長さのバイト・
カウントを与えられる。プロトコル・ヘッダ・フィール
ドの残りの部分は、なかんずく、起点処理エレメント及
び宛先処理エレメント、この場合、エレメント１０₁及
び１０_J+1、及びデータを発生するアプリケーション・
プログラム及びそのデータを受信するアプリケーション
・プログラム、この場合、アプリケーション・プログラ
ムＡ及びＢを識別するために与えられる。しかる後、図
９に示されるように、アプリケーション・プログラムＢ
は、線９１５によってコミュニケーション・サブシステ
ムにＭＣＢ５００を与える。更に、アプリケーション・
プログラムＢは、このデータの対応する部分が書き込ま
れるべきそれぞれ独立のストライド１メモリ領域に対す
るすべての開始アドレス及び長さを先ず決定することに
よって、そのアプリケーションが必要とする任意に変化
するストライドに着信データを効果的に区分する。

【００６９】しかる後、コミュニケーション・サブシス
テムは、ブロック９２０によって示されるようにデータ
・パケットを受信し、図９のブロック９３０によって示
されるように、ストライド１入力バッファ６３４からア
プリケーションＢデータ・メモリにおける分散した且つ
対応するストライド１記憶領域に、アプリケーション・
プログラムＢにより指定されるように部分ごとにコピー
する。パケット全体が完全に受信されてしまい、そして
そのデータがすべてアプリケーションＢデータ・メモリ
にコピーされてしまうと、コミュニケーション・サブシ
ステム６２０は、ブロック９４０によって示されるよう
にアプリケーション・プログラムＢに完了コールバック
を与える。即ち、実行は、ＭＣＢ５００の完了コールバ
ック・フィールド５４０において指定されたアドレスに
あるこのアプリケーション・プログラムにおける命令に
戻される。このようにそして図９の線９４５によって示
されるように、完了コールバックの結果、受信完了エグ
ジットがそのプロトコルから生じる。

【００７０】Ｄ．本発明の処理エレメント間データ・コ
ミュニケーション・プロトコル 上述のように、通常のプロトコルは、本来、２つの処理
エレメント間で通信されるべきすべてのアプリケーショ
ン・データを単一のパケットを介して転送されるように
制限する。これは、データがこの単一のパケットで通信
可能となるように、このデータすべてが２つの独立した
ストライド１Ｉ／Ｏバッファ（送信用の出力バッファ及
び受信用の入力バッファ）を通過することを必要とす
る。このように、このデータはすべて、送信に対して
は、出力バッファにコピーする「ギャザ」動作を介し
て、１つの任意に変化するメモリ・ストライドからスト
ライド１に変換されなければならず、そして受信の際に
は、コピー及び「スキャッタ」動作を介して、ストライ
ド１から他の任意に変化するメモリ・ストライドに変換
されなければならない。この動作によって、「ギャザ」
及び「スキャッタ」動作を行う場合、特に、そこで使用
するための開始アドレスを計算するために大量の処理時
間が消費されることがある。これは、各処理エレメント
によって与えられるアプリケーション・スループットを
減少させ、従って、処理システム全体のアプリケーショ
ン・スループットを減少させる。更に、このプロトコル
はＩ／Ｏバッファの使用を必要とし、そしてそのＩ／Ｏ
バッファは、複雑性、スペース、及びコストを各処理エ
レメントに加え、結果として、システム全体にも加える
ことになり、そしてそれらの制限された容量のために、
大量のデータが転送されるべき場合には、システム・ス
ループットを制限することがある。

【００７１】本発明によれば、特に、処理エレメント間
データ転送に有用なコミュニケーション・プロトコルが
提供され、一方、通常のプロトコルに基づく関連の欠点
はすべて除去される。

【００７２】特に、本発明は、各パケットが部分データ
・メッセージを含む場合、１つのパケットでなく、一連
のパケットでアプリケーション・データを転送すること
によるものである。各部分データ・メッセージは、起点
アプリケーション・データ・メモリに記憶されるデータ
のストライド１部分を含む。本発明のプロトコルの一部
分を形成するアプリケーション・インターフェースは、
個々のデータ部分の開始位置及び長さをローカル的に決
定する。そこで、そのインターフェースは、本発明のメ
ッセージ制御ブロック（詳細に後述される）を適当に更
新するアプリケーション・プログラムにこの情報を与え
る。

【００７３】一般的に言えば、本発明のメッセージ制御
ブロックは２つの付加フィールド、即ち、「未完コール
バック」フィールド及び「未処理サイズ」フィールドを
含み、これらは共に通常のメッセージ制御ブロックには
存在しない。各部分メッセージに対して、未処理サイズ
はそのメッセージ内に含まれたデータの長さを指定す
る。未完コールバックはアプリケーション・インターフ
ェースにおける最初の命令に対するポインタを含む。

【００７４】メッセージ送信に対して、本発明のインタ
ーフェースは、起点アプリケーション・データ・メモリ
の対応するストライド１領域に記憶された各データ部分
の開始ロケーション及びサイズを決定するために、アプ
リケーション・データに特有な送信充填関数（以下で
は、Φ_Sと記す）を利用する。各部分メッセージが１つ
の独立のパケットとして構成されそして送信された後、
コミュニケーション・サブシステムは、送信されないで
残っているデータ部分があるかどうか、従って、更に部
分メッセージを送信する必要があるかどうかを決定す
る。その必要がある場合、「送信未完エグジット」の形
で実行をアプリケーション・インターフェースに戻すた
めに未完コールバックが使用されて、次のデータ部分に
対する開始ロケーション及びデータ長を決定し、しかる
後、コミュニケーション・サブシステムを介してそのデ
ータ部分を読み出し、そして最後に、そのデータ部分を
含むパケットを構成して送信し、そして残りのデータ部
分すべてに対してそのようにする。一方、最後のデータ
部分を含む部分メッセージが送信されてしまった場合、
コミュニケーション・サブシステムは完了コールバック
を呼び出して送信完了エグジットを設定する。

【００７５】メッセージ受信に対して、本発明のプロト
コルは、本質的には逆の態様であるけれども、全く同様
に機能する。詳しく言えば、本発明のアプリケーション
・インターフェースは、着信の部分データ・メッセージ
におけるデータ部分が記憶されるべき宛先アプリケーシ
ョン・メモリにおける対応するメモリ領域の開始アドレ
ス及び長さを、宛先アプリケーションの必要性に基づい
て決定するために受信充填関数（以下では、Φ_Rと記
す）を利用する。この情報は、未処理サイズをその長さ
に等しく設定し且つデータ・ポインタを開始ロケーショ
ンに設定することによって、本発明のメッセージ制御ブ
ロックを更新する受信動作を開始した宛先アプリケーシ
ョン・プログラムにより与えられる。更新されたＭＣＢ
はコミュニケーション・サブシステム６２０に与えられ
る。コミュニケーション・サブシステムは、その後、こ
の部分データ・メッセージを受信した時、そこに含まれ
たデータ部分を、開始アドレスで且つ指定された長さだ
けメモリ領域に書き込むだけである。各部分メッセージ
が受信された後、コミュニケーション・サブシステム
は、データ部分の脱落があるかどうか、即ち、受信され
ずに残っているメッセージ部分があるかどうかを決定す
る。そのようなメッセージがある場合、本発明のＭＣＢ
における未完コールバックが実行をアプリケーション・
インターフェースに「受信未完エグジット」という形で
戻すために使用されて、次のデータ・パケットに対する
開始ロケーション及びデータ長を決定し、しかる後、コ
ミュニケーション・サブシステムを介してそのデータ部
分を次の着信パケットから取り出し、そして単にそのデ
ータ部分を宛先アプリケーション・メモリにおける適正
な領域に書き込み、そして残りのデータ部分すべてに対
してそのようにする。一方、最後のデータ部分を含む部
分メッセージが受信されされてしまった場合、コミュニ
ケーション・サブシステムは完了コールバックを呼び出
して受信完了エグジットを設定する。

【００７６】従って、本発明のコミュニケーション・プ
ロトコルは、たとえメモリ・ストライドが任意に変化す
るもの及び異なるものであっても、中間のＩ／Ｏバッフ
ァを介してデータを送ることを必要とせず、１つのアプ
リケーション・メモリから他のアプリケーション・メモ
リにアプリケーション・データを転送する。従って、こ
れらＩ／Ｏバッファは、各処理エレメント及びシステム
全体における回路の複雑性、物理的サイズ及びコストの
付随的な節約を伴って都合よく除去可能である。更に、
これらバッファを介してアプリケーション・データをコ
ピーするに必要な処理オーバヘッドを除くことによっ
て、各処理エレメントに対する、従って、システム全体
のアプリケーション処理スループットを大いに増大させ
ることができる。

【００７７】本発明のプロトコルを詳しく示すために、
以下では、先ず、各処理エレメントにおいてそのプロト
コルを実施するプロセスを説明し、続いて、本発明のメ
ッセージ制御ブロックを説明し、そして最後に、アプリ
ケーション・データの送信及び受信のためにそのプロト
コルの使用中に生じる機能的動作を個々に説明する。本
発明のプロトコルの特定の実施例、即ち、特定の低レベ
ル・コーディングと、それと共に使用される特殊なソフ
トウエア・ルーチンとは実施する上で関連しており、そ
して処理エレメント間で大きく変化し得るので、そして
それは、これらの何れの環境に対しても、以下の説明か
ら当業者には容易に明らかであるので、説明を比較的高
レベルのものに限定する。

【００７８】図１０は、任意に変化するストライドの処
理エレメント間データ転送を処理するための各処理エレ
メント、例えば、エレメント１０₁において本発明のプ
ロトコルを実施するために利用されるプロセスを、高レ
ベルのブロック図形式で示す。図示のように、これらプ
ロセスは、アプリケーション・プログラム（高レベル）
２５２、及びアプリケーション・インターフェース（低
レベル）２５４（図２では、物理的メモリ２３０内にあ
るものとして示される）を含むアプリケーション層２５
５と、図１０に示されるように、コミュニケーション・
サブシステム６２０（図６）と同じであるが如何なるＩ
／Ｏバッファも含まないコミュニケーション・サブシス
テム１０３０とを含む。図１０の線１０１５及び１０２
５によって示されるように、本発明のコミュニケーショ
ン・プロトコルは、アプリケーション・プログラム２５
２、アプリケーション・インターフェース２５４、及び
コミュニケーション・サブシステム１０３０の間の双方
向的な対話に依存する。この対話は、コミュニケーショ
ン・サブシステムに対するアプリケーション・プログラ
ムによるＭＣＢ１１００（図１１参照）の発生及び連続
的更新によって、各データ部分に対してアプリケーショ
ン・インターフェース開始アドレス及び長さ情報を介し
てコミュニケーション・サブシステムに供給することに
よって、及び、コミュニケーション動作の正常な完了の
際、アプリケーション・プログラム内の適当なエグジッ
ト動作呼び出すためのコミュニケーション・サブシステ
ムによる完了コールバックの発生によって例示される。

【００７９】図１１は、本発明のメッセージ制御ブロッ
ク（ＭＣＢ）１１００及びその構成フィールドを示す。
図示のように、ＭＣＢ１１００は、５つの独立のフィー
ルド、即ち、長さフィールド５２０を内蔵したプロトコ
ル・ヘッダ・フィールド５１０、データ・ポインタ・フ
ィールド５３０、完了コールバック・フィールド５４
０、未完コールバック・フィールド１１１０、及び未処
理サイズ・フィールド１１２０を含む。フィールド５１
０、５２０、５３０、及び５４０すべて十分に上述され
そしてそこに述べたものと同じ機能を与えるので、付加
的なフィールド１１１０及び１１２０だけを説明する。

【００８０】全体的な機能では、完了コールバック・フ
ィールド５４０と同様の未完コールバック・フィールド
１１１０は、実行された時に呼び出しプログラムに戻る
ように「エグジット」を実施するポインタを含む。未完
コールバックの場合、エグジット（図１２乃至図１６と
関連して詳しく後述する）は部分データ・メッセージを
介して送信又は受信されるべき次のデータ部分に対する
開始アドレス及び長さを計算するためのアプリケーショ
ン・インターフェースに対するものである。未処理サイ
ズ・フィールド１１２０は、部分メッセージとして送信
又は受信されるべき次のデータ部分のバイト長を含む。

【００８１】図１２ないし図１３は、処理エレメント１
０₁において動作し、任意に変化するストライドのアプ
リケーション・データをそのエレメントから他のそのよ
うなエレメント、例えば、エレメント１０_J+1に送信す
るための本発明のプロトコルの部分１２００の高レベル
の機能的ブロック図を示す。

【００８２】図示のように、データを送信するために
は、アプリケーション・プログラムＡ（一般的には、図
１２及び図１３に示された高レベルのアプリケーション
・プログラム２５２とみなすことができる）は、先ず、
ブロック１２１０によって示されるように、送信される
べきデータの第１ストライド１データ部分に対するメッ
セージ制御ブロック１１００を発生する。これに関し
て、アプリケーション・プログラムＡは、メッセージ全
体に対する内蔵の長さフィールドを含むプロトコル・ヘ
ッダを完成する。即ち、プロトコル・ヘッダは起点処理
エレメント、宛先処理エレメント及びそれらにおけるア
プリケーション・プログラムを指定するように適当にセ
ットされる。長さフィールドは、送信されるべきデータ
すべてのバイト長を指定するようにセットされる。デー
タ・ポインタは、送信されるべき第１データ部分に対す
るアプリケーションＡデータ・メモリにおける開始メモ
リ・アドレスを指すようにセットされる。特に、任意に
変化するストライドでもって構成されるデータ全体は一
連のいわゆる「データ・パーシャル（ｄａｔａ ｐａｒ
ｔｉａｌｓ）」として記憶される。ここでは、そのよう
な各データ・パーシャルはそのデータのストライド１部
分である。完了コールバック・フィールドは、送信完了
エグジットを呼び出すために適正にセットされる。

【００８３】コミュニケーション・サブシステムを介し
て連続的な各ストライド１データ部分を送るために連続
的な各部分データ・メッセージを生成する過程を通し
て、、同じプロトコル・ヘッダをコミュニケーション・
サブシステム１０３０が繰り返し使用して関連のデータ
・パケット、特に、これらパケットの各々のヘッダ部分
を構成することが可能である。第１の部分データ・メッ
セージに関して、未完コールバック・フィールドは、ア
プリケーション・インターフェースにおける開始の命令
を指すようにセットされる。未処理サイズ・フィールド
は、第１ストライド１データ部分のバイト長を指定する
ようにセットされる。明らかなように、未完コールバッ
ク・フィールドも連続した各部分データ・メッセージに
対して変化しないであろう。しかし、長さフィールド
は、アプリケーションＡデータ・メモリにおける対応す
るストライド１データ部分のサイズに基づいて変化する
であろう。

【００８４】線１２１５により示されるように一旦ＭＣ
Ｂが発生されると、コミュニケーション・サブシステム
１０３０は、ブロック１２２０に示されるように、アプ
リケーションＡデータ・メモリから現在のデータ・パー
シャル、この場合は、第１データ・パーシャルに対する
適当なストライド１データ部分（即ち、第１部分データ
・メッセージを構成する）を読み出す。しかる後、この
サブシステム１０３０は、ブロック１２３０（図１２）
に示されるように、部分データ・メッセージ・パケット
を構成し、それを、プロトコル・ヘッダに基づいた経路
指定情報と共にコミュニケーション組織を介して送信す
る。その送信動作は、線１２３５によって示される。一
旦このパケットが送信されると、そのサブシステムは、
ブロック１２４０に示されるように、送信されるべきデ
ータ全体を形成する連続的なストライド１データ部分す
べてが宛先処理エレメントに送信されてしまったかどう
かを決定する。

【００８５】この機能を達成するために、コミュニケー
ション・サブシステムは、現在のデータに関してそれま
でに送信された個々のストライド１データ部分すべての
長さの累計を保持している。そのような各部分の長さ
は、未処理サイズ・フィールドの値を通して与えられ
る。その累計は、現在の部分メッセージ・パケットがコ
ミュニケーション組織へ送信された後、この値でインク
レメントされる。送信されたストライド１データ部分す
べての和がプロトコル・ヘッダにおける長さフィールド
のバイト値に等しい場合、コミュニケーション・サブシ
ステムは線１２４７をによって完了コールバックを発生
して、送信完了エグジットをアプリケーション・プログ
ラムＡにおける適当なポイントに呼び出す。

【００８６】一方、未処理サイズ・フィールドの和がプ
ロトコル・ヘッダにおける長さフィールドの値よりも小
さく、それにより、転送されるべき追加のストライド１
データ部分が残っていることを示す場合、コミュニケー
ション・サブシステム線は、１２４３によって示されよ
うに未完コールバックを発生する。その未完コールバッ
クはアプリケーション・インターフェースに実行を転送
する。この場合、アプリケーション・インターフェース
は、図１３のブロック１２５０によって示されるよう
に、送信充填関数Φ_Sを計算して、次のストライド１デ
ータ部分に対するアプリケーションＡデータ・メモリに
おける開始ロケーション及びその部分のバイト長を決定
する。この関数及び受信充填関数Φ_Rは、アプリケーシ
ョン・データ・メモリに記憶された基本的なデータ・エ
レメントのストライドにおけるロケーション、連係、変
動と同様、転送されるデータ構造にたいへん特有なもの
である。これらの関数は共に当業者には容易に明らかで
あり且つ本発明は何れの例で使用される特殊な関数に存
在するものでもないので、使用される特殊な関数をあま
り詳細に説明することはしない。

【００８７】これに関して、次のストライド１データ部
分に対する開始ロケーション及び長さが一旦決定される
と、ブロック１２６０及び線１２６５によって示される
ように、アプリケーション・インターフェースはこの開
始ロケーション及び長さ情報を線１２６５を介してアプ
リケーション・プログラムＡに与える。しかる後、アプ
リケーション・プログラムＡは、ブロック１２７０によ
って示されるように、次の部分データ・メッセージに対
するストライド１データの長さにセットされた未処理サ
イズ・フィールド１１２０及びこのデータ部分に対する
開始ロケーションにセットされそしてアプリケーション
・インターフェースによって供給されたデータ・ポイン
タ・フィールド５３０でもってＭＣＢ１１００を更新す
る。しかる後、ブロック１２８０によって示されるよう
に、アプリケーション・プログラムＡは、その更新され
たＭＣＢをコミュニケーション・サブシステムに発生し
てこの次のストライド１データ部分をアプリケーション
Ａデータ・メモリから読み取り、そして、このデータ・
メモリから宛先処理エレメント１０_J+1におけるアプリ
ケーションＢデータ・メモリに転送されずに残っている
アプリケーションＡデータ・メモリにおける連続した各
ストライド１データ部分に対して、このデータ部分を含
む対応する部分メッセージ・パケットを構成して送信す
る。

【００８８】従って、明らかなように、ブロック１２２
０、１２３０、１２４０、１２５０、１２６０、１２７
０、及び１２８０の繰り返し実行を通して、コミュニケ
ーション・サブシステム、アプリケーション・インター
フェース及びアプリケーション・プログラムＡの間で機
能的対話が生じ、データ全体を宛先処理エレメントに一
連の部分データ・パケットとして送信する。その場合、
これらパケットの各々は、アプリケーションＡデータ・
メモリからの連続したストライド１データ部分を含んで
いる。

【００８９】図１４乃至図１６は、処理エレメント１０
_J+1において動作し、任意に変化するストライドで記憶
するためのアプリケーション・データを、他のそのよう
な処理エレメント、例えば、エレメント１０₁から受信
するための本発明のプロトコルの部分１３００を高レベ
ルの機能的ブロック図で集合的に示す。このアプリケー
ション・データの受信と関連した動作は、アプリケーシ
ョン・データを送信するための図１２乃至図１３に示さ
れたものとは本質的に逆ではあるけれども同様である。

【００９０】詳しく言えば、起点処理エレメントからア
プリケーション・データを受信するためには、コミュニ
ケーション・サブシステム１０３０は、ブロック１３０
５によって示されるように、先ず、線１３０１によっ
て、パケット・ネットワーク５０から着信部分データ・
パケットの始めの部分を受信する。この特定のパケット
は、起点処理エレメントからの一連のデータ・パケット
における第１パケットである。各部分データ・パケット
及び対応するデータ部分の間の１対１の対応によって、
この一連のデータ・パケットは、一般的には、２つ以上
のデータ・パケットを含み得るものである。これらパケ
ットは、２つの処理エレメントの間でアプリケーション
・データをすべて集合的に転送する。第１着信部分デー
タ・パケットの始めの部分の受信に応答して、コミュニ
ケーション・サブシステムは、ブロック１３０５に示さ
れるように、これまでに受信したパケットのこの部分か
らプロトコル・ヘッダを取り出す。前述のように、この
ヘッダは、起点処理エレメント、宛先処理エレメント及
び対応するアプリケーションを指定する種々のサブフィ
ールドとともに、長さフィールドを含んでいる。一旦そ
のプロトコル・ヘッダが取り出されると、コミュニケー
ション・サブシステムはブロック１３１０に示されるよ
うに、メッセージ制御ブロック１１００の不完全バージ
ョン（スタブともいう）を構成する。これまでに受信さ
れたこのＭＣＢに対する唯一の情報がプロトコル・ヘッ
ダであるので、このフィールドだけがそのスタブで完成
される。他のすべてのフィールドはゼロのままである。
そこで、コミュニケーション・サブシステムはＭＣＢス
タブをそのまま線１３１３によってアプリケーション・
プログラムＢ（一般的には、図２及び図１３に示された
高レベルのアプリケーション・プログラム２５２とみな
すこともできる）に発生する。

【００９１】この時点で、後述のように、未完コールバ
ックがまだ生じてない場合、ブロック１３１５に示され
るように、アプリケーション自体がアプリケーション・
インターフェース２５４を呼び出し、着信データ部分の
ためのメモリにおける第１ストライド１領域に対する開
始メモリ・ロケーション及び未処理サイズを決定する。
このように、アプリケーション・インターフェース２５
４は、ブロック１３２０に示されるように、先ず受信充
填関数Φ_Rを計算して、着信データが記憶されるべきア
プリケーションＢデータ・メモリにおける第１ストライ
ド領域の始め及び利用可能なこの領域のサイズを指定す
る。この領域のサイズ及びロケーションは、このデータ
の起点となるアプリケーションＡデータ・メモリにおけ
るストライド１データ領域のサイズ及びロケーションと
は総体的には無関係であることに注意してほしい。一旦
この開始ロケーション及びサイズが決定されると、ブロ
ック１３２５によって示されるように、これらの両方と
もアプリケーション・プログラムＢに、特に、サイズは
未処理サイズとして、送られる。この情報に応答して、
アプリケーション・プログラムＢは、ブロック１３３０
に示された機能を通して、完了コールバック、未処理サ
イズ及びデータ・ポインタ・フィールドをそこに挿入す
ることによってＭＣＢスタブを完成する。データ・ポイ
ンタは、アプリケーション・インターフェースによって
今与えられた開始アドレス値にセットされる。しかる
後、アプリケーション・プログラムＢは今完成したＭＣ
Ｂ１１００を線１３３３によってコミュニケーション・
サブシステムに発生して、アプリケーションＢデータ・
メモリへの第１データ部分の転送を制御させる。

【００９２】その完成したＭＣＢに応答して、コミュニ
ケーション・サブシステム１０３０は、ブロック１３３
５に示されるように、第１着信部分データ・メッセージ
・パケットの残りから第１データ部分を取り出す。その
データが取り出されている時、コミュニケーション・サ
ブシステムは、中間コピーを形成することなく、データ
・ポインタ及び未処理サイズによって定義されたアプリ
ケーションＢデータ・メモリ内のストライド１メモリ領
域にこのデータを単に書き込むだけである。勿論、受信
される特定のデータ部分の長さによっては、このデータ
は利用可能なストライド１データ領域全体を十分には満
たさないこともある。従って、次のデータ部分からの
（必要に応じて、連続した他の部分からも）着信データ
が、受信充填関数によって指定されるように、このスト
ライド１領域の残り部分を連続して満たすために使用さ
れるであろう。いずれにしても、一旦現在のデータ部分
がアプリケーションＢデータ・メモリのこのストライド
１領域に書き込まれてしまうと、コミュニケーション・
サブシステムは、ブロック１３４３によって示されるよ
うに、すべての着信アプリケーション・データが、この
場合は単一のストライド１部分として、アプリケーショ
ンＢデータ・メモリに書き込まれたかどうかを決定す
る。

【００９３】この機能を達成するために及び部分メッセ
ージ送信中に生じるものと同様に、コミュニケーション
・サブシステムは、現在のデータに対するこれまでに受
信した個々のストライド１データ部分すべての長さの累
計を保持する。このような各部分の長さは未処理サイズ
・フィールドの値を通して与えられる。その累計は、現
在の部分メッセージ・パケットがアプリケーションＢデ
ータ・メモリに書き込まれた後、この値でもってインク
レメントされる。転送されたすべてのストライド１デー
タ部分の長さの和がプロトコル・ヘッダにおける長さフ
ィールドのバイト値に等しい場合、コミュニケーション
・サブシステムは、線１３４３及び１３７５で示される
ように完了コールバック信号を発生して受信完了エグジ
ットを呼び出し、アプリケーション・プログラムＢにお
ける適当なポイントまで戻る。

【００９４】一方、未処理サイズ・フィールドの和がプ
ロトコル・ヘッダにおける長さフィールドよりも小さ
く、それによって、追加のストライド１データ部分がア
プリケーションＢデータ・メモリに書き込まれずに残っ
ていることが示される場合、コミュニケーション・サブ
システムは線１３４１によって示されるように未完コー
ルバックを発生する。一方、その未完コールバックは、
アプリケーション・インターフェース２５４に実行を転
送する。それに応答して、そのアプリケーション・イン
ターフェースは、ブロック１３４５によって示されるよ
うに、受信充填関数Φ_Rを計算してアプリケーションＢ
データ・メモリにおける次のストライド１データ領域の
開始ロケーション及びその領域のバイト長を決定する。

【００９５】次のストライド１データ領域に対する開始
ロケーション及び長さが決定されてしまうと、アプリケ
ーション・インターフェースは、ブロック１３５０及び
線１３５３によって示されるように、この開始ロケーシ
ョン及び長さ情報をアプリケーション・プログラムＢに
与える。しかる後、ブロック１３５５によって示される
ように、アプリケーション・プログラムＢは、次の部分
データ・メッセージを記憶すべきこのストライド１領域
の長さにセットされた未処理サイズ・フィールド１１２
０及びこのデータ部分に対する開始ロケーションにセッ
トされたデータ・ポインタ・フィールド５３０でもって
ＭＣＢ１１００を更新する。勿論、前のストライド１デ
ータ領域が今受信されたデータ部分によって満たされな
かった場合、データ・ポインタ及び未処理サイズは、こ
の領域の残り部分における開始ロケーションを指すよう
に及びこの領域の残りのサイズを反映するように受信充
填関数によってセットされるであろう。いずれにして
も、アプリケーション・プログラムＢがＭＣＢ１１００
を適当に更新すると、その更新されたＭＣＢは、線１３
５７によって示されるように、コミュニケーション・サ
ブシステムに与えられる。

【００９６】その更新されたＭＣＢに応答して、コミュ
ニケーション・サブシステム１０３０は、ブロック１３
６０によって示されるように、次の着信部分データ・メ
ッセージ・パケットから次のデータ部分を取り出す。そ
のデータが取り出されている時、コミュニケーション・
サブシステムは、中間コピーを形成することなく、デー
タ・ポインタ及び未処理サイズの現在値によって定義さ
れたアプリケーションＢデータ・メモリ内のストライド
１メモリ領域にこのデータを書き込むだけである。しか
る後、コミュニケーション・サブシステムは、ブロック
１３６５に示されるように、転送されるすべての着信デ
ータがアプリケーションＢデータ・メモリにおける適当
な連続的ストライド１データ部分に書き込まれてしまっ
たかどうかを決定する。これを達成するために、コミュ
ニケーション・サブシステムは、今書き込まれた現在の
部分に対する未処理サイズでもって累計をインクレメン
トする。現在のデータ転送に対して書き込まれたストラ
イド１データ部分すべての和がプロトコル・ヘッダにお
ける長さフィールドのバイト値に等しい場合、コミュニ
ケーション・サブシステムは、線１３６９及び１３７５
によって示されるように、受信完了エグジットを呼び出
してアプリケーション・プログラムＢにおける適当なポ
イントに戻る。

【００９７】一方、書き込まれるべき追加のデータ部分
が残っている場合、ブロック１３６５は、線１３６７に
よって示されるように、アプリケーション・インターフ
ェース２５４に未完コールバックを発生して、ブロック
１３４５によって示されるように、アプリケーションＡ
データ・メモリから生じた着信ストライド１データ部分
が書き込まれるべきアプリケーションＢデータ・メモリ
における次のストライド１データ領域の開始ロケーショ
ン及び長さを計算させ、それをそのような連続した着信
データ部分に対しても行う。従って、明らかのように、
宛先処理エレメントにおいてデータ全体を一連の部分デ
ータ・パケットとして受信するために、コミュニケーシ
ョン・サブシステム、アプリケーション・インターフェ
ース、及びアプリケーション・プログラムＢの間で機能
的対話が生じる。その場合、これらパケットの各々にお
けるデータ部分はアプリケーションＢデータ・メモリに
おける対応するストライド１領域に書き込まれる。

【００９８】従って、２つのアプリケーション・プログ
ラムＡ及びＢの間で同じデータが転送されるけれども、
このデータが書き込まれるアプリケーションＢデータ・
メモリにおける各ストライド１データ領域の長さ及びそ
のような領域の数はそのデータが読み取られるアプリケ
ーションＡデータ・メモリにおいて使用されたものとは
総体的には無関係であることは容易に認識できることで
ある。このように、本発明のプロトコルは、そのデータ
すべてのサイズ及び起点アプリケーション・データ・メ
モリにそのデータを集合的に記憶するストライドに関係
なく、必要に応じてデータ・パーシャルを宛先アプリケ
ーション・データ・メモリにステア（ｓｔｅｅｒ）する
ように使用することができる。

【００９９】本発明のコミュニケーション・プロトコル
は、アプリケーション・データの不要な部分をその送信
前にフィルタ・アウトする（取り除く）ために、又は着
信アプリケーション・データをその受信時に切り捨てる
ために容易に使用できる。データ切り捨て及びデータ・
フィルタリングは共に、データベース・トランザクショ
ン、文献照会、実時間データ、その他のような情報の着
信ストリームを管理する非常に高性能の情報フィルタリ
ング・プロセスに対する重要なアプリケーションを持つ
ことが期待できる。従って、本発明のプロトコルは、こ
れらのアプリケーションにおいて特に有用となろう。

【０１００】詳しく言えば、図１７は、発信データ１４
００をその送信前にフィルタするために本発明のプロト
コルが使用される例示的態様を示す。これは、不要な各
ストライド１データ部分をスキップするように単に送信
充填関数を修正することによって達成される。詳しく
は、データ１４００は、データ部分１、２、及び３（部
分１４１０、１４２０及び１４３０としても指定され
る）含むものとして、単純化して見ることが可能であ
る。メモリ・ロケーションＤ₁及びＤ₃で開始し且つ長さ
１およびながさ３の対応するストライド１長を有するデ
ータ部分１４１０及び１４３０は宛先アプリケーション
・プログラムによって要求され、一方、Ｄ₂の開始アド
レス及び長さ２のストライド１長を有するデータ部分１
４２０は不要であるとする。データ部分１４２０が送信
されないようにするために、送信充填関数Φ_Sは、デー
タ部分１４１０の開始ロケーション及びサイズが計算さ
れた後、次のデータ部分の開始ロケーションがロケーシ
ョンＤ₂ではなくＤ₃にセットされそしてこの部分の長さ
が長さ２ではなく長さ３にセットされるように適当に修
正され、それによって、不要なデータ部分１４２０を効
果的にスキップし、それを含む部分データ・メッセージ
・パケットを送信しないようにする。

【０１０１】切り捨てに関して、図１８は、着信データ
１５００をその受信時に切り捨てるために本発明のプロ
トコルを使用する方法を示す。本質的には、切り捨ては
単に未処理サイズをゼロに設定することにより、受信充
填関数を通して達成される。そのようにすることは、後
続するそれ以上のデータがなく、従って、受信動作を停
止し、完了コールバックを宛先アプリケーション・プロ
グラムに発生することをコミュニケーション・サブシス
テムに知らせる。詳しくは、この場合、転送されるべき
アプリケーション・データ１５００はデータ部分１及び
２（部分１５１０及び１５２０としても指定される）を
含むものとして、単純化して見ることもできる。宛先ア
プリケーション・プログラムはデータ部分１５１０を必
要とするだけであり、データ部分１５２０を使用しない
と仮定する。従って、データ部分１５１０が宛先処理エ
レメントで受信されそしてそこの対応するアプリケーシ
ョン・データ・メモリに記憶されてしまうと、受信充填
関数Φ_Rは、次のストライド１メモリ領域に対するデー
タ長、従って未処理サイズ、即ち、着信データ部分１５
２０を記憶するために使用されたであろう未処理サイズ
を単にゼロにセットするように修正される。従って、デ
ータ部分１５１０が宛先アプリケーション・データ・メ
モリに書き込まれてしまうと、コミュニケーション・サ
ブシステムは完了コールバックを発生する。その完了コ
ールバックは、呼び出されると、受信完了エグジット設
定して宛先アプリケーション・プログラムに戻す。

【０１０２】独特の高レベルアプリケーション・プログ
ラム及び独特の低レベルアプリケーション・インターフ
ェースを利用するものとして本発明のプロトコルを説明
したけれども、それらの間のそのようなはっきりした境
界が必要ないことは当業者には明らかであろう。それに
関して、アプリケーション・プログラムを、それ自身の
アプリケーション・インターフェースを含むように書く
ことも可能である。更に、アプリケーション・プログラ
ムは任意の数の内部アプリケーション・インターフェー
スを持つことも可能である。更に、アプリケーション・
インターフェースは、多数の異なる送信充填関数及び多
数の異なる受信充填機能を組み込むことができ、その場
合、特殊な充填関数が、そのインターフェースを通る関
数である各特定のアプリケーション・プログラムに対応
する。これに関して、特殊な送信充填関数は、起点アプ
リケーション・データ・メモリに記憶された特殊なアプ
リケーション・データの編成、ストライド及びロケーシ
ョンに基づいて選択されるであろう。特殊な受信充填関
数は、同じ特性に基づいて、しかし宛先アプリケーショ
ン・データ・メモリ及びそこに書き込まれるべきアプリ
ケーション・データと関連して選択されるであろう。

【０１０３】更に、アプリケーション・データを転送す
ることによって本発明のプロトコルを説明したけれど
も、このプロトコルは、任意の形のディジタル情報、例
えば、プログラム又はデータを１つのメモリから、使用
されるべき任意に変化するストライドを持った他のメモ
リに転送するために使用可能である。それに関して、こ
れらメモリは、物理的に独特のメモリ・ユニットである
必要はなく、むしろ、普通の物理的メモリ・ユニット内
にある単に２つの論理的に独立した記憶領域であればよ
い。

【０１０４】更に、各々が対応するデータ部分を含む複
数のパケットを転送することによって本発明のプロトコ
ルを明瞭に説明したかもしれないけれども、一般的言っ
て、このプロトコルは、メッセージがパケットの形を取
るかどうかに関係なく、そのメッセージ内の任意のタイ
プのデータ部分を転送するために使用し得るものなので
ある。それに関して、当業者は、必ずしもパケットに基
づかない任意のタイプのメッセージを搬送する広範囲の
コミュニケーション組織のうちの何れかで使用するため
に、本発明のプロトコル及びここで開示した実施例を容
易に適応させることができるであろう。

【０１０５】

【発明の効果】本発明によれば、任意に変化するストラ
イドのアプリケーション・データを、中間のデータ記憶
装置を必要とすることなく独立の処理装置間で転送する
ことができる。

【図面の簡単な説明】

【図１】本発明を利用する代表的な大規模並列処理シス
テム、即ち、システム５の非常に高レベルの簡単化した
ブロック図を示す。

【図２】処理エレメント５において利用された処理エレ
メント１０₁及びメモリ２３０の、特に、ソフトウエア
記憶されたメモリ・マップ２５０の高レベル・ブロック
図を示す。

【図３】連続的に水平方向及び垂直方向に配置されたデ
ータ・エレメントの間に一定のストライドを有するマト
リクス４００を示す。

【図４】連続したデータエレメントの間に変化するスト
ライドを有するマトリクス４００を示す。

【図５】通常の、即ち、従来のメッセージ制御ブロック
５００及びそれの構成フィールドを示す。

【図６】処理エレメント間データ転送を処理するための
各処理エレメント内で従来のプロトコルを実施するため
に利用されるプロセスを高レベルのブロック図形式で示
す。

【図７】図１に示されたシステム５において、任意に変
化する例示データが１つの処理エレメント、例えばエレ
メント１０₁からパケット・コミュニケーションを介し
て他のエレメント、例えば１０_J+1に通常転送される従
来方法の高レベルのシステム・ブロック図の一部分を示
す。

【図８】プロセッサ間データ・コミュニケーションのた
めの通常のプロトコルの高レベルの機能的ブロック図の
一部分を示し、特に、システム５において、任意に変化
するストライドのアプリケーション・データを処理エレ
メント１０₁から他の処理エレメント１０_J+1に送信する
ためのその処理エレメント１０₁おいて動作する通常の
プロトコルの部分８００の一部分を示す。

【図９】プロセッサ間データ・コミュニケーションのた
めの通常のプロトコルの高レベルの機能的ブロック図の
一部分を示し、特に、システム５において、処理エレメ
ント１０₁からアプリケーション・データを受信して任
意に変化するストライドで記憶するための他の処理エレ
メント１０_J+1において動作する通常のプロトコルの部
分９００の一部分を示す。

【図１０】任意に変化するストライドの処理エレメント
間データ転送を処理するための本発明のプロトコルを各
処理エレメント、例えば、エレメント１０₁において実
施するために利用されるプロセスを高レベルのブロック
図形式で示す。

【図１１】本発明のメッセージ制御ブロック１１００及
びその構成フィールドを示す。

【図１２】プロセッサ間データ・コミュニケーションの
ための本発明のプロトコルの高レベルの機能的ブロック
図の一部分を示し、特に、システム５において、任意に
変化するストライドのアプリケーション・データを処理
エレメント１０₁から他の処理エレメント１０_J+1に送信
するためのその処理エレメント１０₁おいて動作する本
発明のプロトコルの部分１２００の一部分を示す。

【図１３】プロセッサ間データ・コミュニケーションの
ための本発明のプロトコルの高レベルの機能的ブロック
図の一部分を示し、特に、システム５において、処理エ
レメント１０₁からアプリケーション・データを受信し
て任意に変化するストライドで記憶するための他の処理
エレメント１０_J+1において動作する通常のプロトコル
の部分１３００の一部分を示す。

【図１４】図１９に示されたプロセッサ間データ・コミ
ュニケーションのための本発明のプロトコルの高レベル
の機能的ブロック図の他の一部分を示す。

【図１５】図１９に示されたプロセッサ間データ・コミ
ュニケーションのための本発明のプロトコルの高レベル
の機能的ブロック図の更に他の一部分を示す。

【図１６】図１９に示されたプロセッサ間データ・コミ
ュニケーションのための本発明のプロトコルの高レベル
の機能的ブロック図の更に他の一部分を示す。

【図１７】発信データ１４００を、その送信前に本発明
のプロトコルの使用を通してフィルタする例示的方法を
示す。

【図１８】着信データ１５００を、その受信時に本発明
のプロトコルの使用を通して切り捨てる例示的方法を示
す。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ディーパック・モーハン・アドバニ アメリカ合衆国ニューヨーク州、ポート・ イーウェン、レイクショア・ビラズ、ナン バー２ディー (72)発明者 オーウェン・キース・モンロー アメリカ合衆国ニューヨーク州、キングス トン、セカンド・アベニュー 59番地 ア パートメント・ナンバー２ (72)発明者 ロバート・マイケル・ストラウブ アメリカ合衆国ニューヨーク州、キングス トン、ミラーズ・レイン 21ビー番地 (72)発明者 マイナー・ホルダー・グリーソン・ザ・サ ード アメリカ合衆国ニューヨーク州、ウエス ト・ハーレイ、フランダース・レイン 325番地 (72)発明者 ユンーポン・ファン アメリカ合衆国ニューヨーク州、ハーレ イ、フェアウェイ・ドライブ 112番地

Claims (12)

【特許請求の範囲】
1. 【請求項１】第１メモリにおける起点ポイント及び第２
   メモリにおける宛先ポイントがコミュニケーション組織
   に接続されているものにおいて、前記起点ポイントに第
   １の任意に変化するストライドで記憶されたディジタル
   情報を前記宛先ポイントに第２の任意に変化するストラ
   イドで転送するための方法にして、（ａ）前記起点ポイ
   ントにおいて、 第１の所定関数に応答して、前記第１メモリに記憶され
   たディジタル情報の一部分の第１開始ロケーション及び
   第１サイズを決定するステップであって、前記ディジタ
   ル情報のすべては前記第１メモリ内に前記第１の任意に
   変化するストライドで記憶され、前記一部分はストライ
   ド１編成で記憶されることと、 前記第１開始ロケーション及び第１サイズに応答して、
   ディジタル情報部分を得るように前記第１メモリの対応
   するストライド１セクションを読み取るステップと、 前記読み取りステップに応答して、読み取られた部分を
   含むメッセージを形成し、該メッセージを前記コミュニ
   ケーション組織に送信するステップと、 ディジタル情報の連続した各部分に対して前記決定ステ
   ップ、読み取りステップ、及び形成・送信ステップを繰
   り返すステップであって、該ディジタル情報の前記一部
   分は複数のメッセージを形成するように前記第１メモリ
   の別の対応するセクションにストライド１編成で記憶さ
   れ、前記メッセージの各々は前記コミュニケーション組
   織を介して前記ディジタル情報部分のうちの対応する１
   つを転送し、前記メッセージのすべては前記ディジタル
   情報のすべてを集合的に転送することと、（ｂ）前記宛
   先ポイントにおいて、 前記コミュニケーション組織から前記メッセージの１つ
   を受信するステップと、 第２の所定関数に応答して、前記コミュニケーション組
   織から受信した前記１つのメッセージに含まれた前記デ
   ィジタル情報部分のうちの対応する１つが記憶されるべ
   き前記第２メモリのストライド１セクションの第２開始
   ロケーション及び第２サイズを確認するステップと、 前記受信ステップと前記第２開始ロケーション及び第２
   サイズとに応答して、前記対応する１つのディジタル情
   報部分を前記１つのメッセージから前記第２のメモリの
   前記セクションに書き込むステップと、 前記ディジタル情報のすべてを前記第２の任意に変化す
   るストライドで前記第２メモリ内に集合的に編成するた
   めに、前記メッセージのうちの他の各メッセージに含ま
   れたディジタル情報の部分の各々を前記第２メモリの個
   々の対応するストライド１セクションに連続して書き込
   むよう前記他の各メッセージに対して前記受信ステッ
   プ、確認ステップ、及び書き込みステップを繰り返すス
   テップと、 より成る方法。
2. 【請求項２】前記第１及び第２の任意に変化するストラ
   イドは等しくないことを特徴とする請求項１に記載の方
   法。
3. 【請求項３】前記第１及び第２の任意に変化するストラ
   イドは複合変化ストライドであることを特徴とする請求
   項２に記載の方法。
4. 【請求項４】前記第１及び第２の所定関数はそれぞれ所
   定の送信及び受信充填関数であり、前記第１の所定関数
   は前記第１メモリ内に前記第１の任意に変化するストラ
   イドで記憶されたディジタル情報の各部分の第１開始ロ
   ケーション及び第１サイズを連続的に決定し、前記第２
   の所定関数は前記部分のうち各対応する１つが記憶され
   るべき前記第２メモリにおける各ストライド１セクショ
   ンの第２開始ロケーション及び第２サイズを連続的に決
   定することを特徴とする請求項２に記載の方法。
5. 【請求項５】前記起点ポイントは第１及び第２の所定プ
   ロセス及び所定コミュニケーション・プロセスを組み込
   むこと及び、 前記方法は、（ｃ）前記第１所定プロセスにおいて、 前記ディジタル情報部分のうちの初期部分を前記コミュ
   ニケーション組織を介して送信するよう前記コミュニケ
   ーション・プロセスに命令するためのメッセージ制御ブ
   ロック（ＭＣＢ）を発生するステップであって、該ＭＣ
   Ｂはプロトコル・ヘッダ・フィールド、開始ロケーショ
   ン・フィールド、長さフィールド、完了コールバック・
   フィールド、未処理サイズ・フィールド、及び未完コー
   ルバック・フィールドを含み、該長さフィールドは転送
   されるべきすべてのディジタル情報のサイズを指定し、
   該未処理サイズ・フィールドは前記各メッセージに含ま
   れたディジタル情報部分の対応する部分の長さを含むこ
   とと、 前記開始ロケーション・フィールド及び未処理サイズ・
   フィールドが前記第２所定プロセスにより確認された開
   始ロケーション及び長さの値に等しくセットされるよう
   に前記ディジタル情報部分の次に続く部分に対してＭＣ
   Ｂを更新し、それに応答して更新されたＭＣＢを前記Ｍ
   ＣＢとして発生するステップと、（ｄ）前記コミュニケ
   ーション・プロセスにおいて、 前記ＭＣＢに応答して、前記第１メモリの対応するスト
   ライド１セクションから前記ディジタル情報部分のうち
   の関連した１つを読み取るステップと、 前記プロトコル・ヘッダに応答して、前記関連した１つ
   のディジタル情報部分を含むように前記メッセージうち
   の対応する１つを形成し、前記コミュニケーション組織
   を介して前記宛先ポイントに前記メッセージのうちの前
   記対応する１つを送信するステップと、 前記ディジタル情報部分が前記メッセージのうちの対応
   するものを介して未だ送信されてない追加のデータ部分
   を含む場合、未完コールバック・フィールドにおいて定
   義された未完コールバックを前記第２所定プロセスに発
   生し、又は、前記ディジタル情報すべてが送信されてし
   まった場合、完了コールバック・フィールドにおいて定
   義された完了コールバックを前記第１所定プロセスに発
   生するステップと、（ｅ）前記第２所定プロセスにおい
   て、 前記未完コールバック及び前記第１の所定関数の発生に
   応答して、ストライド１編成をを有し且つ前記第１メモ
   リ内にある前記ディジタル情報部分のうちの次に続く部
   分に対する開始ロケーション及び未処理サイズを確認す
   るステップと、 より成ることを特徴とする請求項２に記載の方法。
6. 【請求項６】前記宛先ポイントは第１及び第２所定プロ
   セス及び所定コミュニケーションプロセスを組み込むこ
   と及び、 前記方法は、（ｆ）前記コミュニケーション・プロセス
   において、 前記コミュニケーション組織から受信したメッセージの
   うちの初期の１つのメッセージの一部分に応答して、前
   記初期の１つのメッセージに含まれたディジタル情報の
   初期部分に対する開始アドレス及びサイズを決定するよ
   う前記第１所定プロセスに命令するためのメッセージ制
   御ブロック（ＭＣＢ）スタブを発生するステップであっ
   て、該ＭＣＢスタブは前記初期の１つのメッセージの部
   分によって供給されたプロトコル・ヘッダ・フィールド
   及び長さフィールドに対して非ゼロ値を含み且つ開始ロ
   ケーション・フィールド、完了コールバック・フィール
   ド、未完コールバック・フィールド及び未処理サイズ・
   フィールドに対してゼロ値を含むことと、 完成したＭＣＢに応答して、初期の１つのメッセージか
   ら前記ディジタル情報部分の初期の１つを取り出す第１
   取り出しステップと、 前記第１取り出しステップに応答して、前記初期の１つ
   のメッセージに含まれた前記初期の１つのディジタル情
   報部分を前記完成したＭＣＢにおける前記開始ロケーシ
   ョン・フィールド及び未処理サイズ・フィールドにより
   定義された前記第２メモリの初期ストライド１セクショ
   ンに書き込む第１書き込みステップと、 更新されたＭＣＢに応答して、前記ディジタル情報部分
   のうちの次に続く部分を前記メッセージのうちの対応す
   る次のものから取り出す第２取り出しステップと、 前記第２取り出しステップに応答して、前記ディジタル
   情報部分のうちの前記次に続く部分を前記更新されたＭ
   ＣＢにおける前記開始ロケーション・フィールド及び未
   処理サイズ・フィールドにより定義された前記第２メモ
   リの対応する次に続くストライド１セクションに書き込
   む第２書き込みステップと、 前記ディジタル情報が前記メッセージのうちの対応する
   ものを介して未だ受信されてない追加のディジタル情報
   部分を含む場合、未完コールバック・フィールドにおい
   て定義された未完コールバックを前記第２所定プロセス
   に発生するか、又は前記ディジタル情報のすべてが受信
   され且つ前記第２メモリに書き込まれてしまった場合、
   完了コールバック・フィールドにおいて定義された完了
   コールバックを前記第１所定プロセスに発生するステッ
   プと、（ｇ）前記第１所定プロセスにおいて、 前記ディジタル情報の初期部分が書き込まれるべき前記
   第２メモリの初期ストライド１セクションの開始ロケー
   ション及びサイズを確認するために前記第２所定プロセ
   スを呼び出すステップと、 前記第２所定プロセスによって確認された前記ディジタ
   ル情報部分の初期部分に対する開始ロケーション及びサ
   イズに応答して、ゼロ値のフィールドを非ゼロ値にセッ
   トすることによってＭＣＢスタブを１つの完成したＭＣ
   Ｂに変換するステップであって、前記開始ロケーション
   ・フィールドは前記第２所定プロセスによって確認され
   た開始ロケーションを含むようにセットされ、前記未処
   理サイズ・フィールドは前記第２所定プロセスによって
   確認されたサイズにセットされることと、 前記ディジタル情報部分の次に続く各部分に対する前記
   第２所定プロセスにより確認された前記開始ロケーショ
   ン及び未処理サイズの値でもって前記完成したＭＣＢを
   更新して更新済みＭＣＢを形成し、それに応答して、該
   更新済みＭＣＢを発生するステップと、（ｈ）前記第２
   所定プロセスにおいて、 前記第２所定関数及び前記第１所定プロセスからの呼び
   出し又は前記未完コールバックの発生に応答して次に続
   くディジタル情報部分が書き込まれるべき前記第２メモ
   リにおける対応する次に続くストライド１セクションの
   開始ロケーション及びサイズを確認するステップと、 より成ることを特徴とする請求項２に記載の方法。
7. 【請求項７】第１メモリにおける起点ポイント及び第２
   メモリにおける宛先ポイントがコミュニケーション組織
   悦属されているものにおいて、前記起点ポイントに且つ
   第１の任意に変化するストライドで記憶されたディジタ
   ル情報を前記宛先ポイントに且つ第２の任意に変化する
   ストライドで転送するための装置にして、 前記起点ポイントにおける、（ａ）第１の所定関数に応
   答して、前記第１メモリに記憶されたディジタル情報の
   一部分の第１開始ロケーション及び第１サイズを決定す
   るための手段であって、前記ディジタル情報のすべては
   前記第１メモリ内に前記第１の任意に変化するストライ
   ドで記憶され、前記一部分はストライド１編成で記憶さ
   れることと、 前記第１開始ロケーション及び第１サイズに応答して、
   ディジタル情報部分を得るように前記第１メモリの対応
   するストライド１セクションを読み取るための手段と、 前記読み取りステップに応答して、読み取られた部分を
   含むメッセージを形成し、該メッセージを前記コミュニ
   ケーション組織に送信するための手段と、 ディジタル情報の連続した各部分に対して前記決定手
   段、読み取り手段、及び形成・送信手段を呼び出すため
   の手段であって、該ディジタル情報の前記一部分は複数
   のメッセージを形成するように前記第１メモリの別の対
   応するセクションにストライド１編成で記憶され、前記
   メッセージの各々は前記コミュニケーション組織を介し
   て前記ディジタル情報部分のうちの対応する１つを転送
   し、前記メッセージのすべては前記ディジタル情報のす
   べてを集合的に転送することと、（ｂ）前記宛先ポイン
   トにおける、 前記コミュニケーション組織から前記メッセージの１つ
   を受信するための手段と、 第２の所定関数に応答して、前記コミュニケーション組
   織から受信した前記１つのメッセージに含まれた前記デ
   ィジタル情報部分のうちの対応する１つが記憶されるべ
   き前記第２メモリのストライド１セクションの第２開始
   ロケーション及び第２サイズを確認するための手段と、 前記受信ステップと前記第２開始ロケーション及び第２
   サイズとに応答して、前記対応する１つのディジタル情
   報部分を前記１つのメッセージから前記第２のメモリの
   前記セクションに書き込むための手段と、 前記ディジタル情報のすべてを前記第２の任意に変化す
   るストライドで前記第２メモリ内に集合的に編成するた
   めに、前記メッセージのうちの他の各メッセージに含ま
   れたディジタル情報の部分の各々を前記第２メモリの個
   々の対応するストライド１セクションに連続して書き込
   むよう前記他の各メッセージに対して前記受信手段、確
   認手段、及び書き込み手段を呼び出すための手段と、 より成る装置。
8. 【請求項８】前記第１及び第２の任意に変化するストラ
   イドは等しくないことを特徴とする請求項７に記載の装
   置。
9. 【請求項９】前記第１及び第２の任意に変化するストラ
   イドは複合変化ストライドであることを特徴とする請求
   項８に記載の装置。
10. 【請求項１０】前記第１及び第２の所定関数はそれぞれ
    所定の送信及び受信充填関数であり、前記第１の所定関
    数は前記第１メモリ内に前記第１の任意に変化するスト
    ライドで記憶されたディジタル情報の各部分の第１開始
    ロケーション及び第１サイズを連続的に決定し、前記第
    ２の所定関数は前記部分のうち各対応する１つが記憶さ
    れるべき前記第２メモリにおける各ストライド１セクシ
    ョンの第２開始ロケーション及び第２サイズを連続的に
    決定することを特徴とする請求項８に記載の装置。
11. 【請求項１１】（ｃ）前記ディジタル情報部分のうちの
    初期部分を前記コミュニケーション組織を介して送信す
    るよう前記コミュニケーション・システムに命令するた
    めのメッセージ制御ブロック（ＭＣＢ）を発生するため
    の手段であって、該ＭＣＢはプロトコル・ヘッダ・フィ
    ールド、開始ロケーション・フィールド、長さフィール
    ド、完了コールバック・フィールド、未処理サイズ・フ
    ィールド、及び未完コールバック・フィールドを含み、
    該長さフィールドは転送されるべきすべてのディジタル
    情報のサイズを指定し、該未処理サイズ・フィールドは
    前記各メッセージに含まれたディジタル情報部分の対応
    する部分の長さを含むことと、 前記開始ロケーション・フィールド及び未処理サイズ・
    フィールドが第２プログラムにより確認された開始ロケ
    ーション及び長さの値に等しくセットされるように前記
    ディジタル情報部分の次に続く部分に対してＭＣＢを更
    新し、それに応答して更新されたＭＣＢを前記ＭＣＢと
    して発生するための手段と、 を有する第１プログラムを含み、（ｄ）前記コミュニケ
    ーション・システムは、 前記ＭＣＢに応答して、前記第１メモリの対応するスト
    ライド１セクションから前記ディジタル情報部分のうち
    の関連した１つを読み取るための手段と、 前記プロトコル・ヘッダに応答して、前記関連した１つ
    のディジタル情報部分を含むように前記メッセージうち
    の対応する１つを形成し、前記コミュニケーション組織
    を介して前記宛先ポイントに前記メッセージのうちの前
    記対応する１つを送信するための手段と、 前記ディジタル情報部分が前記メッセージのうちの対応
    するものを介して未だ送信されてない追加のデータ部分
    を含む場合、未完コールバック・フィールドにおいて定
    義された未完コールバックを前記第２プログラムに発生
    し、又は、前記ディジタル情報すべてが送信されてしま
    った場合、完了コールバック・フィールドにおいて定義
    された完了コールバックを前記第１プログラムに発生す
    るための手段と、 を有し、（ｅ）前記第２プログラムは、前記未完コール
    バック及び前記第１所定関数の発生に応答して、ストラ
    イド１編成をを有し且つ前記第１メモリ内にある前記デ
    ィジタル情報部分のうちの次に続く部分に対する開始ロ
    ケーション及び未処理サイズを確認するための手段より
    成ること、 を特徴とする請求項８に記載の装置。
12. 【請求項１２】前記宛先ポイントにおける、（ｆ）前記
    コミュニケーション組織から受信したメッセージのうち
    の初期の１つのメッセージの一部分に応答して、前記初
    期の１つのメッセージに含まれたディジタル情報の初期
    部分に対する開始アドレス及びサイズを決定するよう第
    １プログラムに命令するためのメッセージ制御ブロック
    （ＭＣＢ）スタブを発生するための手段であって、該Ｍ
    ＣＢスタブは前記初期の１つのメッセージの部分によっ
    て供給されたプロトコル・ヘッダ・フィールド及び長さ
    フィールドに対して非ゼロ値を含み且つ開始ロケーショ
    ン・フィールド、完了コールバック・フィールド、未完
    コールバック・フィールド及び未処理サイズ・フィール
    ドに対してゼロ値を含むことと、 完成したＭＣＢに応答して、初期の１つのメッセージか
    ら前記ディジタル情報部分の初期の１つを取り出すため
    の第１取り出し手段と、 前記第１取り出しステップに応答して、前記初期の１つ
    のメッセージに含まれた前記初期の１つのディジタル情
    報部分を前記完成したＭＣＢにおける前記開始ロケーシ
    ョン・フィールド及び未処理サイズ・フィールドにより
    定義された前記第２メモリの初期ストライド１セクショ
    ンに書き込むための第１書き込み手段と、 更新されたＭＣＢに応答して、前記ディジタル情報部分
    のうちの次に続く部分を前記メッセージのうちの対応す
    る次のものから取り出すための第２取り出し手段と、 前記第２取り出しステップに応答して、前記ディジタル
    情報部分のうちの前記次に続く部分を前記更新されたＭ
    ＣＢにおける前記開始ロケーション・フィールド及び未
    処理サイズ・フィールドにより定義された前記第２メモ
    リの対応する次に続くストライド１セクションに書き込
    むための第２書き込み手段と、 前記ディジタル情報が前記メッセージのうちの対応する
    ものを介して未だ受信されてない追加のディジタル情報
    部分を含む場合、未完コールバック・フィールドにおい
    て定義された未完コールバックを第２プログラムに発生
    するか、又は前記ディジタル情報のすべてが受信され且
    つ前記第２メモリに書き込まれてしまった場合、完了コ
    ールバック・フィールドにおいて定義された完了コール
    バックを前記第１プログラムに発生するための手段と、 を有するコミュニケーション・システムより成り、
    （ｇ）前記第１プログラムは、 前記ディジタル情報の初期部分が書き込まれるべき前記
    第２メモリの初期ストライド１セクションの開始ロケー
    ション及びサイズを確認するために前記第２プログラム
    を呼び出すための手段と、 前記第２プログラムによって確認された前記ディジタル
    情報部分の初期部分に対する開始ロケーション及びサイ
    ズに応答して、ゼロ値のフィールドを非ゼロ値にセット
    することによってＭＣＢスタブを１つの完成したＭＣＢ
    に変換するための手段であって、前記開始ロケーション
    ・フィールドは前記第２プログラムによって確認された
    開始ロケーションを含むようにセットされ、前記未処理
    サイズ・フィールドは前記第２プログラムによって確認
    されたサイズにセットされることと、 前記ディジタル情報部分の次に続く各部分に対する前記
    第２プログラムにより確認された前記開始ロケーション
    及び未処理サイズの値でもって前記完成したＭＣＢを更
    新して更新済みＭＣＢを形成し、それに応答して、該更
    新済みＭＣＢを発生するための手段と、 を有し、（ｈ）前記第２プログラムは、前記第２所定関
    数及び前記第１プログラムからの呼び出し又は前記未完
    コールバックの発生に応答して次に続くディジタル情報
    部分が書き込まれるべき前記第２メモリにおける対応す
    る次に続くストライド１セクションの開始ロケーション
    及びサイズを確認するための手段を有する、 ことを特徴とする請求項８に記載の装置。