JPH02228760A - 複数プロセツサ間で通信するためのシステム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、一般に複数のプロセッサを含むデータ処理シ
ステムの通信プロトコルに関し、具体的には、クラスタ
形式の多重プロセッサ・データ処理システムにおける複
数のプロセッサのカーネル間での直接の通信を可能にす
る、新しい軽量な通信プロトコルに関する。

Ｂ、従来の技術 多重プロセッサ・データ処理システム中のプロセッサが
情報を共有するための通信プロトコルは、従来技術で多
数開示されている。どの通信プロトコルを使用するかは
、多重プロセッサ・システムの特定の設計及び動作上の
制約条件によって決まる。

多重プロセッサ・システム構成は、論理通信チャネルを
共有する複数の処理ユニットと考えることができる。論
理通信チャネルは、ある処理ユニットから別の処理ユニ
ットへのメツセージが記憶できる、処理ユニット間で共
有されるメモリの形を取ることができる。また、論理通
信チャネルは、処理ユニット間を移動するメツセージが
通過する通信ネットワークの形を取ることもできる。

通信に関して、こうした従来技術の多重プロセッサ・コ
ンピュータ・システムは、全般的に密結合（ｔｉｇｈｔ
ｌｙ−ｃｏｕｐｌｅｄ）　システム、近接結合（ｃｌｏ
ｓｅｌｙ−ｃｏｕｐｌｅｄ）システム、及び疎結合（１
ｏｏｓｅｌｙ−ｃｏｕｐｌｅｄ）または分散多重プロセ
ッサ・システムに分類できる。

密結合システムとは、物理的に互いに極めて密接し、同
じメモリにアクセスでき、同じオペレーティング・シス
テムを走らせることができる同一の処理ユニットを複数
個有するものである。処理ユニット間の通信媒体はきわ
めて高速である。処理ユニットは、共有メモリから構成
されることもあり、専用バスを介する信°号伝達や当該
のコンピュータ・システムに特有な他の方法を含むこと
もある。使用される通信プロトコルも非常に特殊な専用
プロトコルであり、そのプロトコルは、完全にハードウ
ェアで実施できることもあるが、いかなる場合でも、通
信には極めて僅かのオーバーヘッドしか加わらない。こ
うしたシステムの利点は、複数のプロセッサを一緒に使
用してシステム作業負荷を処理することができる点であ
る。

分散システムは、物理的にほんの数フィートしか離れて
いないものもあり、数百マイルも離れているものもある
。通信媒体は通常、電話線、人工衛星、イーサネット（
Ｅｔｈｅｒｎｅｔ　Ｎゼロックス（Ｘｅｒｏｘ）社の商
標）やトークン・リング（ＴｏｋｅｎＲｉｎｇｌｌ　Ｂ
Ｍ社の商標）のようなローカル・エリア・ネットワーク
など当業界で標準の媒体である。

分散システム中のプロセッサはすべて互いに異なってい
てもよい。こうしたシステムは、まったく異ナルオペレ
ーティング・システムを走らせ、互いにまった（独立し
ていることもしばしばであるが、データが共有できるよ
うに協働する。そうしたシステムを用いると、データの
増加量に応じてより多くのシステム上にデータが分散で
き、可用性を高めるため複数のシステムでデータが複製
できる。

こうした分散システムで使用される通信プロトコルは、
システム・ネットワーク・アーキテクチャ（”ＳＮＡ”
　　ＩＢＭ社の商標）や伝送制御プロトコル／Ｉｎｔｅ
ｒｎｅｔ　プロトコル（ＴＣＰ／ＩＰ″）など当業界の
標準プロトコルになっているものが多い。

近接結合または「クラスタ化」システムは、他の２つの
構成の利点を組み合わせようとしたものである。こうし
たシステムは、同じ部屋でなくても、通常少なくとも同
じビル内にあり、イーサネットなどの標準通信媒体や、
ディジタル・エクイップメント（Ｄｉｇｉｔａｌ　Ｅｑ
ｕｉｐｍｅｎｔ　Ｃｏｒｐｏｒａｔｉｏｎ）　　社のク
ラスタ相互接続バスなどの専用の媒体を使用することが
できる。これらのプロセッサは通常互いに類似しており
互換性がある。それらのプロセッサは、各マシンで同じ
オペレーティングφシステムを走らせ、分散システムよ
りもはるかに緊密に協働して、データ共有以外の機能を
可能にする。

その目標は、一般にユーザに単一のシステムと思わせる
ことである。

最近、複数の仮想メモリ・データ処理ユニットをクラス
タ式構成で相互接続する提案が、カイリ（Ｋａｉ　Ｌｉ
）及びパウル・フダク（Ｐａｕｌ　Ｈｕｄａｋ）の論文
「共有仮想記憶システムにおけるメモリ整合（Ｍｅｍｏ
ｒｙ　Ｃｏｈｅｒｅｎｃｅ　ｉｎ　５ｈａｒｅｄＶｉｒ
ｔｕａｌ　Ｓｔｏｒａｇｅ　Ｓｙｓｔｅｍｓ）　Ｊ　、
分散計算の原理に基づく計算機シンポジウム第５回年余
（ｔｈｅＦｉｆｔｈ　Ａｎｎｕａｌ　Ａｓ５ｏｃｉａｔ
ｉｏｎ　ｆｏｒ　ＣｏｍｐｕｔｉｎｇＭａｃｈｉｎｅｒ
ｙ　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｐｒ１ｎｃｉｐｌｅｓ
　ｏｆＤｉｓｔｒｉｂｕｔｅｄ　Ｃｏｍｐｕｔｉｎｇ）
　（１９８６年）に提出された。提案されたマシン・ク
ラスタでは、すべてのユニットが、同じ形式のオペレー
ティング・システムをもち、同じ仮想メモリ空間にアド
レスすることができる。

したがって、クラスタ化構成の各ユニットは、その仮想
メモリ・システム内の１組のアドレスをその構成の他の
ユニットと共有し、ページ不在処理機構が、他のユニッ
ト並びにそのプロセッサの２次記憶装置からページを取
り出すように拡張される。こうしたクラスタ式システム
のユニットがページ不在に出会うと、２次記憶装置から
ではなく他の装置からページのコピーを要求することに
より、ページ不在を処理することができる。これは、他
のユニットがそのメモリにそのページを含み、２次記憶
装置よりもはるかに迅速に応答できるという利点がある
。こうしたクラスタの複数のユニットに所与のページの
コピーがあるので、べ一ジ不在に出会ったユニットは、
ページのコピーをどこに要求するべきか知らないことが
ある。さらに、特殊な措置を講じない限り、２つのユー
ットがあるページを同時に変更するなどの異常が発生す
ることがある。また、あるページを読み取るとき、読取
り側と書込み側が物理的に別々のプロセッサにいる場合
でも、最近の書込み動作の結果が見られるように保証す
ることが重要である。この皿の共存を適切に働かせるた
め、ページ変更の許可を与える、ページの所有者を見つ
ける、ページをいつ所存者に戻すかを決定するなどのこ
とを行なう、システム・プロトコルを確立することがで
きる。この種のシステム・プロトコルは、システム間の
様々なユニット中で大量の通信を必要とする。

これまでに、ＩＢＭ社が開発したＳＮＡを含めて、遠隔
プロセッサ間で情報を伝送するための多数の標準通信プ
ロトコル、ならびに米国特許箱４６４８０８１号及び第
４５３２５８８号に記載された「ドキュメント交換プロ
トコル」など、ＳＮＡと共に使用される多数の専用プロ
トコルが開発されている。

通信プロトコルが対処しなければならない通信システム
の基本的問題は、受信側プロセッサのメモリにメツセー
ジを受信するのに十分なバッファ空間があるかどうかで
ある。従来分散システムで通常使用されていたプロトコ
ルでは、十分なバッファ空間がない場合でさえ、メツセ
ージが首尾よく受信されたことを送信側プロセッサに通
知する通信リンク・レベルでの肯定応答（ＡＣＫ）が、
受信側プロセッサから送信側プロセッサに送られてきた
。通信リンク・レベルの肯定応答″ＡＣＫ”は、通常通
信リンク・アダプタなどのハードウェアまたは比較的低
位のソフトウェアによって送られる。受信側プロセッサ
が首尾よくメツ゛セージを受信したことを送信側プロセ
ッサに通知するリンク・レベル″ＡＣＫ″が送られた場
合でさえ、受は取ったメツセージを記憶する十分なバッ
ファ空間が受信側プロセッサにない場合は、受信側プロ
セッサはそのメツセージを捨てなければならない。

すなわち、より高位のソフトウェア・レベルで、メツセ
ージを捨てなければならない。あるいは受信したメツセ
ージを記憶するバッファがないという他のメツセージを
、受信側プロセッサが送信側プロセッサに送らなければ
ならない。この基本的問題から、特に分散データ処理シ
ステムにおいて、ＳＮＡなどのハードウェア／ソフトウ
ェア複合アーキテクチャを利用する必要が生じた。

メツセージ・バス・モデルを利用する、従来技術で開示
された疎結合多重プロセッサ構成では、別々の処理ユニ
ット上で走行する個々のカーネルが、構成全体で共有さ
れる資源を管理するサービス要求を含むメツセージを、
構成内の他の処理ユニットに送信する。メツセージ・バ
スは当然のことながら処理ユニット間の基本通信接続に
対応しているので、「メツセージ・バス」モデルへの依
存は確かにあったが、それは、疎結合構成の主要な性能
上のボトルネックとなると一般に考えられる。しかし、
システム結合のモデルとしてのメツセージ・バスはいく
つかの欠点をもつ。

メツセージ・バス・システムにおいてプロセッサ間で複
雑なデータ構造（たとえば、ポインタを含む制御ブロッ
ク）を直接共有するのが困難なことはよく知られており
、Ｍ、ヘルリヒ（ｌｌｅｒｌｉｈｙ）及びＢ、リスコツ
（Ｌｉｓｋｏｖ）の論文［抽象データ・タイプの値伝送
方法（ΔＶａｌｕｅ　ＴｒａｎｓｍｉｓｓｉｏｎＭｅｔ
ｈｏｄ　Ｆｏｒ　Ａｂｓｔｒａｃｔ　Ｄａｔａ　Ｔｙｐ
ｅｓ）　Ｊ　ｚ　プログラミング言語及びシステムに関
するＡＣＭ紀要（ｔｈｅ　ＡＣＭ　Ｔｒａｎｓａｃｔｉ
ｏｎｓ　ｏｎ　ＰｒｏｇｒａｍｍｉｎｇＬａｎｇｕａｇ
ｅｓ　　ａｎｄ　　Ｓｙｓｔｅｍｓ）　　％　　Ｖｏ　
　１　　、　　４％　　Ｎ　　ｏ。

４、（１９８２年１０月）に記載されている。この論文
を引用により本明細書に合体する。この主題は、Ｂ、ネ
ルソン（Ｎｅｌｓｏｎ）の博士論文「遠隔手順呼出しく
Ｒｅｍｏｔｅ　Ｐｒｏｃｅｄｕｒｅ　Ｃａ１ｌ）　Ｊ　
ｓカーネギ−・メロン大学、１８８１年５月刊でも考察
されている。この論文を引用により本明細書に合体する
。

多重プロセッサ構成内の別々の処理ユニットで実行され
るオペレーティング・システムの２つの構成要素間で要
素のリストを共有することは、それ自体比較的−膜内な
要件であるが、そのためには、それらの要素を送信側構
成要素で送信に適した書式にバックして、送信側構成要
素から受信側構成要素に送り、受信側構成要素でバック
を解除しなければならない。この動作シーケンスはプロ
セッサの利用度の点で不十分である。

より重要なことであるが、この動作シーケンスは複雑で
扱いにくい。メツセージ自パスの主な欠点は、送信側及
び受信側構成要素が、使いにくく複雑なアーキテクチャ
になり、コストが高くつき、実施、デバッグ、機能強化
及び保守が難しくなり勝ちなことである。代表的な汎用
オペレーティング・システムのカーネルは多くの相互作
用する構成要素から構成されることが多いので、メツセ
ージ・バス・モデルの周囲の多重プロセッサｊＲ成（１
）オペレーティング−システムが複雑になる傾向にある
。

複数のユニットが密結合ユニットと同様の仮想メモリを
共有するクラスタ型構成では、通信プロトコルは、様々
なユニットにおけるオペレーティング・システムのカー
ネル間での迅速な転送を実行する必要がある。選択され
たプロトコルは、ページ不在の場合に共有仮想メモリか
らページを得ること、あるユニットがあるページから読
み取ろうとするとき、別のユニットがそのページに書き
込もうとする場合に同じページに対する同時要求を管理
する方法、及び記憶データを共有する機能に共通なその
他の様々な状況などのような問題に付随する高レベルの
通信トラフィックに対処しなければならない。前述のよ
うに、疎結合分散コンピュータ・システム用に過去に開
発された標準通信プロトコルは、ユニット間でデータを
伝送するのに必要な命令の数の点で通信に大きなオーバ
ーヘッドを課し、したがってデータ・プロセッサの共有
仮想メモリ・クラスタのもつ潜在的な利点を打ち消すこ
とがあり得る。

Ｃ１発明が解決しようとする課題 したがって、本発明は、クラスタ型多重プロセッサ・シ
ステムにおけるプロセッサのオペレーティグ・システム
のトラステッド・カーネルが、高速通信リンクを介して
制御情報及びデータを通信することができるように設計
された、新しい、軽量な通信プロトコルを対象とする。

０１課題を解決するための手段 本発明は、複数の個別プロセッサ間で通信するための新
しい改良された通信システムを開示する。

このプロトコルは、送信側プロセッサの構成要素から受
信側プロセッサの構成要素にメツセージを送るための送
信側プロセッサ内の機構、そのメツセージの受信時に、
受信側プロセッサ内の宛先構成要素でバッファ空間が利
用可能かどうかを動的に決定するための受信側プロセッ
サ内の手段、及びそのメツセージが受信側プロセッサに
よって受信され、宛先構成要素でメツセージを記憶する
のに十分なバッファ空間が利用可能であるという肯定応
答または十分なバッファ空間がないという否定応答を送
信側プロセッサに送るための受信側プロセッサの機構を
含む。このプロトコルはまた、受信側プロセッサでメツ
セージを受信するのに十分なバッファ空間が利用可能で
あるとの受信側プロセッサによる決定を、送信側構成要
素に通知するための送信側プロセッサ内のソフトウェア
を含んでいる。

送信側プロセッサによって送られるメツセージは、制御
セグメントとユーザからのデータ・セグメントとを含む
。メツセージが書式化された後、送信側プロセッサは、
送信側プロセッサから受信側プロセッサに連続してメツ
セージを送ることが好ましい。送信側プロセッサ内のプ
ロトコル機構は、肯定応答が受信側プロセッサから受信
されない場合、送信側構成要素への通知なしに、送信側
プロセッサでメツセージを待ち行列に入れるルーチンを
含む。受信側プロセッサも、バッファ空間が利用可能に
なったとき、受信側構成要素が待ち行列メツセージを受
は取るのに利用できるバッファ空間をもつことを、送信
側プロセッサに通知するための機構を含む。

受信側プロセッサ側のシステムは、受信側プロセッサに
到着するメツセージを記憶するバッファ・プールを含み
、バッファ・プールの一部が受信側プロセッサ内の複数
の構成要素のそれぞれに割り当てられる。このシステム
はまた、各構成要素に割り当てられたバッファ空間の、
到着メツセージ用に利用可能な部分の記録を保持する。

通信システムが、受信側プロセッサ内の構成要素を、第
１クラスと第２クラスに分け、第１クラスの各構成要素
には第２クラスとは別のバッフＴ・プールを割り当てる
ことが好ましい。「自由」クラスの特定の構成要素に割
り当てられた「自由」バッファ・プール内のバッファは
、宛先構成要素に割り当てられた自由バッファ・プール
の部分にメツセージ用の十分な空間がないという決定に
応えて、自由クラス内の別の構成要素に割り当てられた
バッファ空間に転送することができる。「厳格」クラス
の特定の構成要素に割り当てられた「厳格」バッファ・
プール内のバッファは、別の構成要素に割り当てられた
バッファ空間に転送できない。

受信側プロセッサでは、宛先構成要素向けの関連メツセ
ージが受信側プロセッサに到着し、その宛先構成要素に
利用可能な十分な空間があるとき、複数のサービスにア
クセスするための手段をもつ割込みハンドラが、宛先構
成要素に関連する割込みハンドラ拡張部分を呼び出す。

代替実施例では、通信プロトコルが、ネットワーク内の
中間プロセッサを介して送信側プロセッサと受信側プロ
セッサの間で通信し、送信側プロセッサ内のプロトコル
機構が第１通信リンクを介してメツセージを中間プロセ
ッサに送る。中間プロセッサはそのメツセージを受信し
、第２通信リンクを介してそのメツセージを受信側プロ
セッサに再送信する。次に受信側プロセッサは、受信側
プロセッサの宛先構成要素でメツセージ用にバッファ空
間が利用可能かどうかを決定する。十分なバッファ空間
が利用可能な場合、受信側プロセッサに十分なバッファ
空間があるという肯定応答が、受信側プロセッサから中
間プロセッサに送られる。中間プロセッサは、肯定応答
を受は取ると、受信側プロセッサで十分なバッファ空間
が利用可能であるという肯定応答を送信側プロセッサに
送る。

受信側プロセッサで十分な記憶空間が利用可能でないと
いう否定応答を、受信側プロセッサが中間プロセッサに
送る場合、中間プロセッサは、受信側プロセッサに十分
なバッファ空間がないという否定応答を送信側プロセッ
サに送る。

Ｅ、実施例 第１図は、本発明の通信システムが有利に使用できる、
多重プロセッサ・クラスタ構成データ処理システムの構
成図である。第１図では、多重プロセッサ・クラスタは
、複数のプロセッサ・ユニット１０、スイッチ１１、及
びそれぞれプロセッサ・ユニット１０をスイッチ１１に
接続する複数の通信リンク１２を含んでいる。スイッチ
１１の機能は、任意のプロセッサ・ユニット１０が他の
プロセッサ・ユニット１０と通信できるようにすること
である。プロセッサｌ０Ａ１１０８１１０Ｃ１１０Ｄだ
けが図示しであるが、ネットワーク内のプロセッサの実
際の数はもっと多い。

本明細書で開示する通信システム及び多重プロセッサ・
クラスタと共に使用するのに適した高速スイッチの特定
の詳細は、本発明を理解するのに重要であるとは考えら
れない。使用できる適切なスイッチ装置の例は、米国特
許第４６３５２５０号及び第４６０５９２８号に出てい
る。

第２図は、通信プロトコルが使用できるクラスタ構成の
多重プロセッサ中データ処理システムの代替構成を示す
。第２図では、複数のプロセッサ・ユニット１０が通信
リンク１４によって互いに接続されている。

第３図は、ユニット１０が本発明の通信システムを利用
して他の非隣接ユニツ）１０と有利に通信できる、たと
えば、後で詳しく説明するように、ユニッ）１０Ａがユ
ニット１０Ｂを介し、ユニット１０ＡからＩＯＢへの通
信りンク１６とＩＯＢからＩＯＤへの別の通信リンク１
６を介して非隣接ユニット１０Ｄと通信するという、多
重プロセッサ・クラスタ別の構成を示す。

第４図は、第１図、第２図、第３図に示すプロセッサ・
ユニット１０をより詳細に示している。

プロセッサ・ユニット１０は、高機能パーソナル・コン
ピュータまたはエンジニアリング・ワークステーション
でよく、ＩＢＭ　　ＡＩＸ（ＩＢＭ社の商標）オペレー
ティング・システムを走行させ、８０１アーキテクチヤ
をもつ。しかし、本発明を実施する際、他のアーキテク
チャとオペレーティング・システムも利用できることに
留意されたい。

プロセッサ・ユニット１０は、プロセッサ１７、主メモ
リ１８、プロセッサ１７とメモリ１８の間でのデータの
転送を制御する記憶制御ユニット１９、及び複数の入出
カポ−）２ＯＡ−２０Ｅを含む。ボー）２ＯＡと２０Ｂ
は、表示型端末２１と２２をプロセッサ・ユニット１ｏ
に接続する働きをする。ポート２０Ｃはプリンタ２３を
プロセッサ１０に接続し、ボート２０Ｄはディスク・ド
ライブ２４をプロセッサに接続する。

通信入出力アダプタ１５、好ましくは直列リンク・アダ
プタ（ＳＬＡ）は、プロセッサが他のプロセッサに直接
（第２図）、またはスイッチを介して他のプロセッサに
（第１図）、または中間プロセッサを介して非隣接プロ
セッサ（第３図）に迅速にデータを転送できるように、
プロセッサ・ユニット１０のポート２０Ｅを、第１図の
通信リンク１２、または第２図の通信リンク１４、また
は第３図の通信リンク１６に接続する。以後、通信リン
クと言うとき、便宜上、通信リンク１２を指すものとす
る。

好ましい通信リンク１２は、関連特許出願に記載されて
いる直列リンクである。直列リンク１２は、プロセッサ
１０の各ボート２０Ｅと相互接続するための、光ファイ
バ・ケーブル１３（第５図）とその両端部にある５ＬＡ
１５を含む。光ファイバ・ケーブルまたはリンク１３は
、最高６４にバイト長のメツセージを、２００Ｍビット
／秒以上の速度で転送する。リンク１３は、あるプロセ
ッサのメモリからデータを取り出して、それを他のプロ
セッサのメモリに置く。メモリ・アクセスを制御するタ
グ・ワードが、６４バイトの境界上で分散／収集機能を
実行する。直列リンク・アダプタ１６は、データ転送が
正確に行なわれるようにするためのリンク・レベル装置
プロトコルを実施したものである。リンク１３と共に使
用できるプロトコルは２つあり、中間送信要求（ＲＴＳ
Ｉ）及び送信要求／受信要求（ＲＴＳ／ＲＴＲ）と呼ば
れる。

ＲＴＳＩは、受信アダプタが前もってセットアツプされ
る場合、ソフトウェアの介入なしにデータがメモリに配
送されるという点でより効率的である。ＲＴＳ／ＲＴＲ
を用いると、データが適切なメモリ位置に配送できるが
、余分な割込み、及び受信アダプタのソフトウェア・セ
ットアツプが必要である。ＲＴＳＩは、効率がより重要
な、短いが頻度の高いメツセージに適している。ＲＴＳ
／ＲＴＲは、余分のオーバーヘッドが、比較的長いデー
タ転送の間に解消できる、比較的長いメツセージに適し
ている。

プロセッサ・ユニット１０は、米国特許出願第０６／８
１９４５８号に詳細に記載されている、仮想メモリ・デ
ータ処理システムに全般的に対応している。上記出願に
記載されているように、プロセッサは、３２ビツトの実
効アドレスをもつ。

この実効アドレスは、４つの高位ビット３１−２８を利
用して１６個のセグメント・レジスタのうちの１つを選
択することにより、４０ビツト仮想アドレスに変換され
る。各セグメント・レジスタは、４０９６個の固有セグ
メントのうちの１つを定義する、１２ビツトのセグメン
ト・アドレスを記憶する。各セグメントは、２５８メガ
バイトの記憶域を含む。１ページが２にバイトのデータ
を含む場合、セグメントは１２８にページを含む。

一方、１ページが４にバイトのデータを含む場合、セグ
メントは、６４にページ、より正確には６４にの仮想ア
ドレスをもつ。これらの仮想アドレスを使って、現在そ
のセグメントに割り当てられているデータのページを識
別することができる。ただし、本発明の通信プロトコル
は、他のタイプのプロセッサと共に動作するように適合
させることもできることに留意されたい。

第５図で、各プロセッサ１０に関連するソフトウェア資
源は、オペレーティング・システム２９中の複数のオペ
レーティング・システム・サービス２８の頂部に構築さ
れた複数のアプリケーション・ソフトウェア２６を含む
ことができる。これらのシステム・サービス２８くは、
ユニット１０のハードウェア資源を割り当てる様々な資
源マネージャ３０、ファイル・アクセスなどのサービス
に対するアプリケージ１ン・ソフトウェア２６の要求に
サービスするシステム・コール３２、及び入出力事象の
完了など非同期事象に反応する割込みハンドラ３４が含
まれる。資源マネージャ３０には、ロック・マネージャ
または仮想メモリ・マネージャ３１が含まれる。

こうした基本的システム・サービス２８は、オペレーテ
ィング・システム２８のカーネルの一部として一般に記
載されている。カーネルは、通常、それなしではオペレ
ーティング・システムが利用できない、またはすべての
ユーザまたはシステム状態に影響を及ぼし、したがって
特権を与えられている、オペレーティング・システム２
９の基本機能だけを含む。したがって、カーネルは信頼
できるものでなければならず、カーネルへのアクセスは
制御されなければならない。コンパイラやユーティリテ
ィなど他のオペレーティング・システムは、そのサービ
スを実行するのに特権が必要でない。したがって、それ
らはカーネルの一部ではない。

第５図により詳しく示した共有仮想記憶多重プロセッサ
・システムでは、ユニットＩＯＡと１０Ｂの様々な構成
要素は、ユニットＩＯＡのＶＭＭ３１Ａなど、各ユニッ
トの名称に関連する文字を使って区別しである。

ユニットＩＯＡ上のアプリケ−シロン・プログラム２８
Ａなどのクライエント・プログラムは、メモリからデー
タを要求することができる。要求されたデータがユニッ
トＩＯＡの主メモリ１８Ａにはないと５ＣＵ１９Ａが決
定した場合、ページ不在が発生し、５ＣＵ１９Ａは、仮
想メモリ・マネージャ３１Ａ内のページ不在処理機構に
、ユニット１０Ａに関連するディスク・ドライブ２４、
またはその主メモリ１８、またはそのユニット１０に関
連するディスク２４に記憶されたデータをもつ他のユニ
ット１０からデータを見つけさせ検索させる。仮想メモ
リ・マネージャ３１Ａは、米国特許出願第０７／１２７
０００号に記載されている方式でこのメモリを見つける
。

ユニットＩＯＡの仮想メモリ・マネージャ３１Ａは、他
のユニット１０の仮想メモリ・マネージャ３１との通信
を確立して、ＳＮＡやローカル・エリア・ネットワーク
・プロトコルなど高レベル通信プロトコルを使用して要
求されたデータを獲得することができるが、共有仮想記
憶装置を利用する多重プロセッサ・クラスタ型データ処
理システムを支援するのに大量のカーネル対カーネル・
トラフィックが必要だとすると、こうした高レベル通信
プロトコルの使用は複雑で遅すぎる。

本発明のシステム（第５図）では、各ユニット１０のオ
ペレーティング・システム２９は、新規なマシ：／　間
通信ソフトウェア・システム（ｌＭＣ８”）３６を含む
。ｌＭＣ８３６は、仮想メモリ・マネージャ３１などプ
ロセッサ・ユニット１０中のオペレーティング・システ
ム２９のカーネル構成要素がそれを使用して、通信ドラ
イバ３８と５ＬＡ１５を介し直列リンク１３を介してＶ
ＭＭ３１Ｂなど他のプロセッサ・ユニットＩＯＢの受信
側構成要素により迅速にデータを送信しまたはそこから
検索することができる。ｌＭＣ８３６の主な用途は、ク
ラスタ型データ処理システムの１つのユニット１０のオ
ペレーティング・システム２９のカーネル構成要素が、
そのクラスタ内の他のユニット１０のオペレーティング
・システム２９のカーネル構成要素との間でメツセージ
を送受することであるが、クラスタ内の他のシステム構
成要素は、ｌＭＣ８のサービスへのトラステッド・イン
ターフェースをもつ場合、ｌＭＣ８を使用してメツセー
ジを送受できることに留意されたい。

代表的なタイプのクラスタ開通信用のｌＭＣ８の実施に
必要なステップを、第８Ａ図、第８Ｂ図、第８Ｃ図に示
し、ｌＭＣ３と他のプロセッサ構成要素の関係を第７Ａ
図と第７Ｂ図に示す。ステップ５０（第８図）で、ユニ
ット１０Ａ内のアプリケーシヨン２６Ａがメモリからの
データとページ不在を要求し、または他のサービスを要
求する。

ステップ５２で、ＶＭＭ３１Ａのページ不在ハンドラは
、データがそのプロセッサ１０Ａに利用できず他のプロ
セッサＩＯＢによって制御されると決定する。ステップ
５４で、ページ不在ノ１ンドラは、ｌＭＣ８のクライエ
ント３９になり、ｌＭＣ８３８Ａが送信するメツセージ
を作成する。このｌＭＣ５メツセージは、クライエント
３９、すなわちページ不在ハンドラからユニット１０Ｂ
またはサーバ４２の仮想メモリ・マネージ＋３１Ｂへの
メツセージと、ユニット１０Ａ内のクライエント３９が
要求したサービスを実行するためにプロセッサ１０Ｂ内
のサーバ４２が必要とする、メツセージ及び関連子るデ
ータの転送を実行するためにｌＭＣ５３８Ａが必要とす
る情報とを含む、標準形式で作成しなければならない。

このメツセージの書式を、第８Ａ図に示し、後で詳しく
説明する。

メツセージがクライエントによって作成されると、ステ
ップ５６で、クライエント３９はｌＭＣ５３８Ａを呼び
出す。ステップ５８で、ｌＭＣ８３８Ａはメツセージの
伝送経路を選択し、選択された通信チャネルに対するプ
ログラム命令を準備する。ステップ６０で、ｌＭＣ８３
６Ａは、後で詳しく説明するように、同じサーバ４２向
けの前のメツセージの状況に応じて、メツセージを選択
された直列通信リンクの通信チャネル・ドライバ３８向
けの待ち行列に入れるか、それともメツセージを後の送
信のための待ち行列に入れるかを決定する。メツセージ
がドライバ３８向けの待ち行列に入れられた場合、ステ
ップ６４で、ドライバ３８は、「直接要求送信（ＲＴＳ
Ｉ）Ｊ直列リンク・レベル・プロトコルを用いて、通信
ポート２０Ｅ１直列りンク・アダプタ（ＳＬＡ）１５Ｂ
を介し直列リンク１３を介して受信側プロセッサ・ユニ
ット１０Ｂにメツセージを出力する。

ＲＴＳＩリンク・レベルのプロトコルには、正確なデー
タ転送が起こったとき、５ＬＡ１５が自動的に生成でき
るＡＣＫが含まれる。ｌＭＣ８３６Ｂは５ＬＡ１５Ｂに
、ＡＣＫを自動的に生成しないように指令する。その代
わりに、ユニット１０Ｂ内のｌＭＣ８３６Ｂは、サーバ
４２で受信側プロセッサＩＯＢ内のバッファ空間が利用
可能かどうかの決定に基づいて、ＡＣＫまたはＮＡＫを
生成し、それが５ＬＡＩ５Ｂによってリンク１２を介し
て伝送される。

ｌＭＣ５は、単一メツセージで制御情報と関連データの
両方を転送させることができる。これは、「帯域内」信
号伝達技術であり、受信側プロセッサＩＯＢは制御情報
とデータを区別する必要がある。こうした制御情報には
、たとえば実行すべき動作を記述し、読み取るべきまた
は書き込むべきデータを指すポインタを含む、ディスク
読取り要求、ディスク書込み要求または他の「要求」が
含まれる。

ステップ６８で、送信されたメツセージを受信側５ＬＡ
Ｉ５Ｂが受は取る。５ＬＡ１５Ｂは、メツセージをバッ
ファ４０Ｂに配送する。バッファ４０Ｂは、受信側ユニ
ットの様々なカーネル構成要素によって以前に受信側ユ
ニツ）　１０　ＨのｌＭＣ８３６Ｂに割り当てられた、
共通バッファ空間のプールを含んでいる。

メツセージが到着すると、ヘッダはバッファ４０Ｂのカ
ーネル・データ・セグメント４１Ｂの２５６バイトの区
域を占め、データは、５ＬＡ１５Ｂに属するメモリのフ
レーム４３Ｂを占める。５ＬＡ１５の分散／収集機能を
使って、受信側プロセッサ１０内でヘッダとデータが物
理的に分割される。すなわち、おそらくはページを構成
するデータが、ページ位置合せされる。

ステップ７０で、５ＬＡ１５Ｂはプロセッサ１０Ｂへの
割込みを生成する。この割込みは通常通りプロセッサＩ
ＯＢによって処理される。ステップ７２で、５ＬＡ１５
Ｂ用の第２レベル割込みハンドラ（ＳＬＩＨ）が、ｌＭ
Ｃ８３８Ｂを呼び出す。

ＶＭＭ３１Ｂなどのサーバ４２が、ｌＭＣ８３６Ｂにそ
の存在を知らせてからでないとメツセージは配送できな
い。各プロセッサ・ユニット１０内のｌＭＣ８３６は、
サーバ表を維持する。サーバ表は、各サーバごとに、そ
のヘッダ及びデータ・バラフシ・アカウント、メツセー
ジが到着するときに呼び出されるルーチンのアドレス、
及びメツセージを取り出すクライエントの範喘について
の情報を含んでいる。各ユニット内のｌＭＣ８はクラス
タ・メンバのリストも維持する。

ステップ７４で、ｌＭＣ８３６Ｂは、以前にバッファ４
０Ｂに記憶されたメツセージのヘッダを読み取って、受
信側プロセッサ１０Ｂ内のサーバ４２の識別を決定し、
そのサーバ表項目及びクラスタ・メンバ・リストを検査
して、送信側プロセッサＩＯＡが受信側プロセッサＩＯ
Ｂ内のサーバにメツセージを送信することを許されてい
るかどうかを決定する。送信側プロセッサＩＯＡが許可
を持っていない場合、ステップ７６で、ｌＭＣ８３６Ｂ
は、送信側プロセッサＩＯＡにＮＡＫを送るよう５ＬＡ
１５Ｂに指示する。許可がある場合、ステップ７８で、
ｌＭＣ８３８Ｂは、サーバ４２がそのメツセージを受は
入れるのに十分な／（ソファ記憶域をもつかどうか決定
する。十分な記憶域がない場合、ステップ７６で、ｌＭ
Ｃ８３Ｅ！Ｂは、否定応答″ＮＡＫ″を送るよう５ＬＡ
１５Ｂに指示する。サーバ４２がｌＭＣ８に割り当てら
れた十分なバッファ空間をもつ場合、ステップ８２で、
ｌＭＣ８３８Ｂ、は指定されたサーバのバッファ「アカ
ウント」を減分する。ステップ８４で、ｌＭＣ８３８Ｂ
は、送信側プロセッサ・ユニット１０ＡにＡＣＫを送る
よう５ＬＡ１５Ｂに指示する。

バッファ空間がないため、または許可がないために、受
信側プロセッサ内のｌＭＣ８３８が、ＮＡＫを送るよう
５ＬＡ１５に指示する場合、受信側プロセッサ内のバッ
ファ空間４０Ｂに記憶されたメツセージは捨てられる。

ステップ８６で、ｌＭＣ８３６Ｂは、サーバ表で指定さ
れた５ＬＩＨ拡張部分４４と呼ばれる、特定のサーバ４
２のためのルーチンを呼び出す。

要約すると、５ＬＩＨ拡張部分４４は、ｌＭＣ８３８Ｂ
のために予約されたバッファ空間４０Ｂ中で受信したメ
ツセージの予備処理を実行する、サーバ４２によって提
供される特殊ルーチンである。

この予備処理は、後で詳しく説明するように、メツセー
ジの存在及び位置をサーバ４２に知らせるためのもので
ある。

ステップ８８で、プロセッサＩＯＢから送信されたＡＣ
Ｋが、プロセッサ１０Ａの５ＬＡ１５Ａで受信される。

ステップ９０で、５ＬＡ１５Ａはプロセッサ・ユニット
ＩＯＡに割り込む。

ステップ９２で、５ＬＡ１５Ａ用の割込みハンドラがｌ
ＭＣ８３８Ａを呼び出す。ステップ９４で、ｌＭＣ８３
８Ａが送信されたメツセージ中で指定された通知ルーチ
ン４６を呼び出す。通知ルーチン４６は、ｌＭＣ８を使
ってメツセージを送る各クライエントから提供され、そ
のアドレスが各メツセージ中で指定される。各通知ルー
チンは、必要なクライエント特有の処理、たとえば、ヘ
ッダが占める空間の戻しや、以前に送信されたデータ・
ページのピン解除を実行する。

ステップ７４（第７Ｂ図も参照）に戻ると、受信側プロ
セッサ内のｌＭＣ３３Ｅ３Ｂが、送信側プロセッサＩＯ
Ａはメツセージを受信側プロセッサ１０Ｂ内のサーバ４
２に送ることを許されていないと決定した場合、ステッ
プ７６で、ｌＭＣ５３６Ｂは、送信側プロセッサＩＯＡ
にＮＡＫを送るように５ＬＡ１５Ｂに指示する。同様に
、ステップ７８で、ｌＭＣ８３Ｅ３Ｂが、サーバ４２は
メツセージを受は入れるのに十分なバッファをもたない
と決定した場合、ｌＭＣ８３ＢＢは、やはりＮＡＫを送
るよう５ＬＡ１５Ｂに指示する。

ステップ９６で、第７Ｂ図に示すように、５ＬＡ１５Ａ
はＮＡＫを受信し、プロセッサ・ユニット１０Ａに割り
込む。ステップ９８で、５ＬＡＩＳＡ用の割込みハンド
ラがｌＭＣ８３８Ａを呼び出す。ステップ１００で、ｌ
ＭＣ８３８Ａは、メツセージのヘッダにＮＡＫが受信さ
れたという指示を書き込み、後の送信のためにメツセー
ジをセーブする。

ステップ８０に戻ッテ、ｌＭＣ８３８Ａが、同じサーバ
向けのメツセージに対して以前にＮＡＫを受信したとい
う指示がメツセージ・ヘッダに含まれていると決定した
場合、ステップ６２で、１ＭＣ５３Ｅ３Ａはそのメツセ
ージを待ち行列に入れる。待機メツセージの向かうべき
サーバ４２でバッファが利用可能になった結果、受信側
プロセッサ１０Ａ内のｌＭＣ８３８Ｂから非ブロツク化
メツセージを受信するまで、待機メツセージは待ち行列
中にある。こうしたバッファがどのようにして利用可能
になるかについては、「バッファ・アカウント」の項で
説明する。

本発明では、より高いレベルのソフトウェア、すなわち
ｌＭＣ８が、バッファが利用可能かどうかを検査する機
会をもつまで、５ＬＡ１Ｈによるリンク・レベルＡＣＫ
の送信を延期する。通信リンク１２は、この検査中、使
用中に保持される。

ハードウェア・リンク−レベルＡＣＫの場合にはそうで
はない。しかし、「最後のメツセージを捨てなければな
りませんでした」または「最後のメツセージ用のバッフ
ァがありました」というメツセージを送るためにより高
いレベルを必要としないので、通信システム全体はより
効率的で簡単である。

Ｅ−１：メツセージ書式 送信側プロセッサ内のメツセージの書式を、第６Ａ図に
示し、リンク１２を介して送信中のメツセージの書式を
第６Ｂ図に示す。クライエント「要求」の書式は実行さ
れる動作に特有である。

具体的には、「要求」に含まれるデータ・ポインタの位
置と意味はクライエントとサーバしか知らない。本発明
のこの方法では、この問題は、各単一メツセージの最初
の２５６バイトまたはヘッダが制御情報を含むという書
式規約を採用することにより、部分的に解決される。「
ヘッダ」は通常、メツセージの最初の１２８バイトにク
ライエント「要求ブロック」域を含む。この要求の内容
は、クライエントとサーバに対してのみ意味をもち、し
たがって、ｌＭＣ８にとっては意味がない。ヘッダの次
の１２８バイトは、ｌＭＣ８と直列リンク・アダプタ用
の制御情報を含む。ヘッダの「クライエント要求」ブロ
ックが１２８バイトより大きい場合には、クライエント
及びサーバは、メツセージのデータ部分にオーバフロー
を入れるための規約を確立しなければならない。

この解決方法の残りの部分は、クライエントがヘッドの
Ｉ　Ｍ　ＣＳ部分とＳＬＡ部分を作成する必要があるこ
とである。ヘッダの後に、所与の送信中に４にバイトの
データ・ページが１ページ以上続くことがある。許容最
大データ・ページ数は１５ページであるが、システムの
特定の構成または用途に応じて、異なる最大ページ数が
適切なこともある。

メツセージ全体が１回の送信で送信されるので、データ
用のタグ・ワードを含めて、メツセージのすべての要素
を記述するタグ・ワードを作成し、ヘッダのＳＬＡ部分
に入れなければならない。ヘッダの諸要素は、タグ・ワ
ードが要素を記述すべく正確に作成されている限り、仮
想メモリまたはリアル・メモリ中で連続している必要は
ない。

前に説明した、メツセージの作成に関する第８図のステ
ップ５４で、「クライエント」は、「クライエント要求
」部分が以前に作成されていない場合、それを作成し、
ヘッダのｌＭＣ８部分は、クライエント供給のｒＩＭｃ
ｓ作成」ルーチンを使って作成される。ｒＩＭｃｓ作成
」ルーチンは、「要求」ブロックのデータ構造、特にデ
ータ・ポインタの所在を理解し、ヘッダ及び出力データ
用のタグ・ワード・イメージ域に記入する。クライエン
トはまた、宛先、たとえば指定された受信側プロセッサ
ＩＯＢ内の特定のサーバ、送信されるデータ・ページ（
どのページを固定しなければならないか）のリスト、及
び転送完了した時に呼び出される送信側プロセッサＩＯ
Ａ内の通知ルーチン４６などの情報を指定する、工ＭＣ
８制御域も記入する。このデータ構造は、（下記のよう
な）ｒＣＪ言語または他の適切な言語で書くことができ
る。

「要求」ブロックのデータ構造は、以下の通りである。

■１９８８　ＩＢＭ　Ｃｏｒｐｏｒａｔｉｏｎｓｔｒｕ
ｃｔ　ｔａｇ　（ ｕｎｓｉｇｎｅｄ　ｐａｇｅｎｏ：　　２１；ｕｎｓｉ
ｇｎｅｄ　ｏｆｆｓｅｔ：　　５；ｕｎｓｉｇｎｅｄ　
　　　：　　１； ｕｎｓｉｇｎｅｄ　ｃｏｕｎｔ　：　　５；）； ５ｔｒｕｃｔ　ｉｍｃｓ　ｈｅａｄｅｒ　　（／：：：
ネ：キ：＊ネ：＊ネキ寧ネ＊ネ＊ネ＊寧ネ＊ネキネキネ
＊ネ＊＊ネネ＊キネネ＊＊＊キ／／＊ユーザ区域は２つ
の通信当事者が利用する一：、／／＊プロトコルを含む
。ｌＭＣ８はこの区域をネ／／＊見ず変更もしない。Ｒ
ＴＳＩプロトコルで＊／／＊は、ユーザ域は必須であり
、最初のタグ・　＊／／＊ワードがそれを指さなければ
ならない。他＊／／＊のプロトコルでは、それは任意選
択である。ネ／／ネキネ＊＊ネ＊キ＊＊＊キ中＊ネキ＊
＊キネ＊＊ネ中キネネネ＊中キネ＊キ＊中ネネ中キ＊ネ
／ｃｈａｒ　ｕｓｅｒ　ｒｅｑｕｅｓｔ　ｂｌｏｃｋ［
１２８］；／ネ＊ネ＊ネ：：：：＊本＊キ＊ネキネ＊ネ
＊ネキ＊＊キ＊＊＊ネネネ＊ネキネネ＊ネ＊キキ＊／／
＊この区域はｉｍｃｓ要求特性である。この区ネ／／ネ
域は、実行すべき入出力動作：動作完了時：／／：に講
じるべき措置を記述する。ＲＴＳＩブネ／／ネロトコル
では、要求ブロックの前半が発送：／／：され、第２の
タグ・ワードはそれを１旨さな：／／：ければならない
。ＲＴＳＩの受信側で、キ／／ネヘッダをｕｓｅｒ　ｒ
ｅｑｕｅｓｔ　ブロック及びｉｍｃｓ：／／＊要求ブロ
ックの前半で重ね書きする。他の：／／＊プロトコルで
は、それは発送されない。　　：／／：：零ネ：中ネ：
中中＊＊：＊キネキ零ネ中中＊中中中中キキ＊零キ中中
キ＊ネ中キキ中キネ／ｃｈａｒ　ｕｓｅｒ　ｍｅｓｓａ
ｇｅ　ａｒｅａ［２０］；／：ネ＊ネ＊ネ＊＊＊ネ＊＊
＊：ネ＊宰ネ＊＊ネ零寧宰：：：：：ネ中ネネ＊＊ネ＊
キ中＊ネネ／／ネこの区域は、応答の関連づけを可能に
する＊／／中データを含む。フィールドは提案であり、
＊／／＊規定ではない。　　　　　　　　　　　　　＊
／／中：：：：ネネネネネ中ネ零ネネ零ネ＊＊ネ中ネ＊
ネネネネ中ネネネネネネ＊ネ＊ネ中零零＊／／キ帽Ｉ＊
帽モ帽■：彊Ｉキ帽モ＊ネ、：：６：＊ネ＊：＊＊キ＊
キ：：＊ネ）モ＊／／＊　ｉｍｃｓ区域は１２バイト　
　　　　　　　　ネ／／：ネ：：：：中ネ＊＊ネ＊ネキ
キ＊：：キネキキ＊＊キネ＊ネキキネネネネ＊ネネキキ
ネヰキ／５ｈｏｒｔ　　ｄｅｓｔ　　ｐｒｏｃ　　ｔｏ
ｋｅｎ；５ｈｏｒｔ　　ｄｅｓｔ　　ｆｍｃｓ　　ｑｔ
ｏｋｅｎ；５ｈｏｒｔ　　５ｅｎｄ　　５ｔａｔｕｓ：
／：　ｌＭＣ５が結果をレポートする中／５ｈｏｒｔ　
５ｅｎｄ　ｍｓｇ　ｌｅｎ；／ネバイト単位で＊／ （キｎｏｔｉｆｙ　ａｄｄｒｅｓｓ）　０；／：＠送信
終了時に呼び出される零／ ／：＊　：：掌中＊：ネ：＊：中中中キ＊＊＊キネ＊＊
＊キ＊ネ中＊中＊ネ＊ネ＊ネ＊＊ネ＊＊キ／／＊この区
域はｌＭＣ８とチャネル装置ドライ＊／／＊バが通信す
るためのデータを含む。　　　　ネ／／：＊／ ＃　ｃｈａｒ　ｉｍｃｓ　ａｄｄ　ａｒｅａ　［３２］
　　　　　　　　　＊／／：ネ：　＊　：：：：キ＊：
：：ネ＊＊ネ＊＊ネ＊＊＊＊ネ中＊中＊＊ネ＊ネネ＊ネ
ネ＊ネネネネ／５ｔｒｕｃｔ　　ｉｍｃｓ　　ｈｅａｄ
ｅｒ　　ｍ１ｘｅｓ　　ｃｈａｉｎ　　ｗｏｒｄ；／：
キューのため＊／ ５ｔｒｕｃｔ　ｉｍｃｓ　ｈｅａｄｅｒ　：ｃｄｄ　ｃ
ｈａｉｎ　ｗｏｒｄｓ／＊キューのためネ／ ５ｔｒｕｃｔ　ｉｍｃｓ　ｈｅａｄｅｒキｎｅｘｔ　ｑ
ｕｅｕｅ　ｃｈａｉｎｉ／＊キューのため：／ ５ｈｒｏｔ　　ｉｍｃｓ−ｄｅｓｔ　ｐｒｏｃ；／＊実
際のプロセッサ中／ ５ｈｒｏｔ　ｔｍｃｓ　ｄｅｓｔ　ｑｔｏｋｅｎ；／＊
実際のＱＩＤ　＊／ ５ｈｏｒｔ　ｉｍｃｓ　５ｅｎｄ　ｐｒｏｃｉ／＊送信
プロセッサネ／： ５ｈｏｒｔ　　ｉｍｃｓ　　５ｅｎｄ　　５ｕｂｃｈ；
／ネ送信すブチャネル：／ ５ｈｏｒｔ　ｉｍｃｓ　ｒａｙ　５ｕｂｃｈ；／中５ｕ
ｂｃｈ　ｔｏ　５ｅｎｄ　ｔｏネ／５ｈｏｒｔ　　ｉｍ
ｃｓ−ｒａｙ　　ｍ５ｇ１ｅｎ；／＊受信したメツセー
ジ長ネ／ ５ｈｏｒｔ　ｉｍｃｓ　ｏｐ； ／＊送信または受信キ／ ＃ｄｅｆｉｎｅ／ｌＭＣ５５ＥＮＤ　　Ｃ０ＤＥ　　　
　　　　ＩＩｄｅｆｉｎｅ／ｌＭＣ５ＲＣＶ　　Ｃ０Ｄ
Ｅ　　　　　　　３ｕｎｓｉｇｎｅｄ　５ｈｏｒｔ　　
ｉｍｃｓ　　ｇｏ：ｎｄｅｆｉｎｅ／ｌＭＣ５ＩＭＭＥ
ＤＩＡＴＥＸ８０００ １ｏｎｇ　　ｒｅｓｅｒｖｅｄ ｓｌｄｅｆｉｎｅ／ＨＵＭ　ＴＣＷＳ　　　　　　　　
　　１６ｕｎｉｏｎ　　ｔａｇｓ　　　　　（ ｌｏｎｇ　　ｔａｇｗｏｒｄｓ［ＮＵＭ　　ＴＣＶＳＩ
；５ｔｒｕｃｔ　ｔａｇ　ｔａｇ　　［ＮＵＭ　ＴＣＶ
ＳＩ。

］ｔａｇｓ； ）； ５ｔｒｕｃｔ　　ｉｍｃｓ　　ｈｅａｄｅｒ　　＊ｉｍ
ｃｓ　　ｈｅａｄｅｒ：ヘッダは（２つの非連続１２８
バイト・チャンクから構成でき）、カーネル・データ用
に割り当てられた仮想記憶セグメント４１から割り振ら
れる。８０１アドレツシング・アーキテクチャを使用し
て、短い（３２ビツト）アドレスがポインタに使用でき
るようにするとき、ヘッダはすべて同じセグメントにな
ければならない。ヘッダ（及びデータ・ページ）は、ｌ
ＭＣ８が呼び出される前に固定しなければならない。ヘ
ッダ中に以下のフィールドを設けなければならない。

ｉｍｃｓ　ｄｅｓｔ　ｐｒｏｃ　　メツセージが送られ
る先のプロセッサ。ｌＭＣ８はこの妥当性検査を行ない
、経路を選択する。プロセッサが存在するが利用できな
い場合、ｌＭＣ８はメツセージを待ち行列に入れる。

ｉｍｃｓ　ｄｅｓｔ　ｑｔｏｋｅｎ　　メツセージが送
られる先の受信側プロセッサにあるサーバを表す待ち行
列識別。ｌＭＣ８はこの妥当性検査を行なわない。

ｎｏｔｉｆｙ　ａｄｏｒｅｓｓ　　送信動作の完了時に
割込みハンドラからｌＭＣ８によって呼び出されるルー
チンのアドレス。このルーチンはカーネル・テキスト・
セグメント内にあり固定されている。

ｔａｇｓ　　これらはヘッダ及び関連するデータ・ペー
ジを表すように記入しなければならない。システム・サ
ービスは仮想アドレスと長さを取り、タグ・ワードを戻
す。

メツセージがクライエントによって作成されると、クラ
イエントはｌＭＣ８を呼び出す。メツセージが送信され
る先のプロセッサが、ｌＭＣ８が通信する相手のプロセ
ッサ・グループ中にない場合以外は、ｌＭＣ８はメツセ
ージを送信する。グループ中にない場合は、ｌＭＣ３は
「エラー」戻りコードを生成する。

メツセージを後の送信のために待ち行列に入れるべき場
合、ｌＭＣ８はハッシェ方式を利用して、送信が実際行
なわれるときに、待機メツセージが正しい順序で受信側
プロセッサ内の正しい待ち行列に送られるようにする。

この方式が必要なのは、送信側プロセッサと受信側プロ
セッサの間で２つの物理通信リンクが利用できる場合、
または受信側プロセッサが同じ待ち行列向けの前のメツ
セージを否定応答した場合に起こる、メツセージが順序
外れで到着するのを防ぐためである。

Ｅ−２バッフドアカウントの処理 名プロセッサ内のｌＭＣ８３８は、特定の受信側構成要
素がプロセッサ内のフレームを余りに多く使用しないよ
うにする、アカウント処理機構４８を含む。機構４８は
、ヘッダとデータ・ページに対して別々にアカウント処
理を行なう。

受信側プロセッサ１０内のサーバは、バッファをデータ
・バッファ・プール４３に寄付し、バッフドアカウント
は、各サーバごとにアカウント処理機構４８によって維
持される。特定のサーバ向けのメツセージが到着すると
、そのアカウントが適宜減分される。そのアカウントは
より多くのバッファを寄付することによって補充される
。

そのアカウントがメツセージを受は入れるのに十分でな
いサーバ向けのメツセージが到着すると、問題が発生す
るが、すべてのサーバによって与えられる空きバッファ
の総数は大きい。サーバの不足は一時的なので、そのサ
ーバ向けのメツセージを拒否するよりも、そのサーバに
大域ブールからの空きバッファを「貸す」方がよい。

潜在的な各受信側サーバは、クラスタ内の他のフロセッ
サ１０からの到来メツセージ用に固定ページの「アカウ
ント」をもつ。各クラスごとにバッファ方針が異なる、
「サービス・クラス」という概念がある。あるユニット
内の各サーバは１つのクラスに属する。「厳格ｊクラス
では、サーバはそれらのアカウントを超過引出しできな
い。自由クラスでは、サーバは超過引出しができる（す
なわち、互いのバッファを使用できる）。自由クラスは
、すべての参加サーバの最高のニーズに必要なほど多く
ないバッファ空間を維持しながら、変動を可能にする、
ある種の大域バッファ・プールを提供する。しかし、厳
格クラスからのバッファを自由クラスが「借りる」こと
は決してできない。

アカウントに寄付するため、サーバは、特定のサーバ待
ち行列に対するバッファ・アカウントにメモリのフレー
ムを与える、ｌＭＣ８中のルニヂンを呼び出す。このル
ーチンは、ＶＭＭの優先順位レベルで走行するＶＭＭ呼
出しである。ＶＭＭ３１によって資源制御が行なわれる
場合、ＶＭＭは、要求されたフレーム数に対する権限を
サーバが与えられるようにする。システムがフレーム外
れの場合、ｖＭＭはエラー戻りコードを与える。

非エラーの場合、ＶＭＭは空きフレームを見つけて、そ
れを再利用不能にし、ｌＭＣ８のためにそのフレームを
予約する。次いでＶＭＭは、ＳＬＡの優先順位レベルで
走行するｌＭＣ５ルーチンを呼び出し、ＳＬＡバッファ
・プールにそのフレームを追加し、サーバ待ち行列のア
カウントを増分する。

受信側プロセッサ１０内のｌＭＣ８３８は所定の待ち行
列向けにＮＡＫを送るとき、サーバ表にそうしたという
指示を保持する。その待ち行列のサーバはある時点でバ
ッファ・アカウントを補充し、それが行なわれたとき、
ｌＭＣ８３８は、ＮＡ　Ｋを送った先のプロセッサに、
送信を再開するようにとのメツセージを送信する。送信
側プロセッサ１０にあるｌＭＣ８３Ｅ３は、このメツセ
ージを受信すると、その待ち行列向けの最初のメツセー
ジを通信装置ドライバ３８への待ち行列に入れ、したが
ってその待ち行列は有効に非ブロック化される。この非
ブロツク化メツセージは、ｌＭＣ３間メツセージである
ことに留意されたい。これは到着するとすぐにｌＭＣ３
によって処理されるので、バッファ・アカウントを必要
としない。

このバッファ・アカウント処理方式の理由の１つは、資
源の涸渇を防ぐことである。それは、タライエンドが妥
当な時間で処理できないメッセージでサーバのプロセッ
サをあふれさせるのを防止するための機構である。

もう一つの理由は、デッドロックの回避に役立つことで
ある。たとえば、プロセッサ１０が自由ページ・フレー
ムも自由ヘッダももたず、したがってメツセージを受信
できないことがある。次の到来メツセージによって、プ
ロセッサ１０はページ・フレームを解放することができ
るが、新しいへ・ラダを割り振ることはできないので、
このメツセージを受信できない。このバッファ・アカウ
ント処理方式を用いると、特定のサーバがメツセージを
受信するのを妨げずに、仮想メモリ・マネージャ３１が
、ｌＭＣ８用に出力されたページ・フレームの数を制限
することができる。サーバ待ち行列の数は基本的に制限
されていないので、何らかの形でその到来メツセージを
分離するため、サーバは実際には複数の待ち行列を有す
る。たとえば、仮想メモリ・マネージャ３１は、クライ
エントからページ・イン要求を受信するための１つの待
ち行列と、それ自体のページ・アウト要求に対する応答
を受信するための他の待ち行列を有することができる。

こうしないと、ページ・アウト応答が、ブロック化され
た待ち行列中でいくつかのページ・イン要求の後に入っ
て、前記の種類のデッドロックを引き起こす可能性があ
る。

Ｅ−３ヘッダ管理 受信側プロセッサ内のサーバがｌＭＣ８３６にその存在
を知らせると、サーバはその待ち行列のに使用できるヘ
ッダの数を指定する。その数はサーバがサービスする同
時要求の数の上限を表す。長いサービス待ち行列を構成
する必要はなく、それらの要求を（すでに実メモリ資源
を使用している）送信側プロセッサ中で待機させる方が
よい。

ヘッダはｌＭＣ８によって管理される。初期設定の時に
、ｌＭＣ８は、カーネル・データ空間からのページを割
り振り、それを概念上１６個の２５６バイト・ヘッダに
分解し、ヘッダを固定する。

５ＬＡ１５が受信動作で使用するための１組のタグ・ワ
ードが作成される度に、こうしたヘッダの１つがそれに
与えられる。メツセージが到来すると、メツセージがア
ドレスされる先のサーバにそのヘッダが与えられ、サー
バのヘッダ・アカウントが減分される。最終的に、サー
バは要求を完了し、あるいは要求にサービスする前に、
ヘッダからその私用のデータ域に関連情報をコピーする
ことができる。どちらの場合も、サーバはヘッダをｌＭ
Ｃ８に戻す。この時、サーバの待ち行列のヘッダ・アカ
ウントが増分され、ヘッダはｌＭＣ８のヘッダ・プール
に戻って、別の到来メツセージ中で再使用される。

ｌＭＣ８のヘッダがなくなることがある。自由ヘッダの
数が、しきい値、たとえば４より少なくなると、ｌＭＣ
８は他のページを割り振り、こうして得られたヘッダを
そのヘッダ・プールに追加する。ヘッダ・ページの割振
りは１回の処理で行なわれなければならない。というの
はページを固定するとページ不在が起こる可能性がある
からである。

ヘッダ・アカウントがゼロである待ち行列向けのメツセ
ージが到着すると、ｌＭＣ８は「データ・バッファなし
Ｊ　ＮＡＫとは区別されるＮＡＫを送る。「ヘッダなし
Ｊ　ＮＡＫの場合は、待ち行列を非ブロック化するのに
ｌＭＣ５メツセージを待つ代わりに、送信側ｌＭＣ８は
しばらくしてから再送信できる。これは、ヘッダの不在
が一過性の現象であるかもしれないからである。ヘッダ
及びバッファには異なる方式も使用できるが、必ずしも
そうする必要はない。

Ｅ−４待ち行列トークン管理 上述のように、クライエントによってそのサービスが要
求されているサーバ４２は、メツセージ・ヘッダ中で待
ち行列トークンによって識別される。

こうしたトークンを指定する方法には様々なものがある
。たとえば、ＶＭＭなどのシステム・サービスは、すべ
てのプロセッサで同じ「周知の」トークン値をもつ。他
の値はｌＭＣ８によって指定されて、サーバとクライエ
ントの間でそれ自体の機構によって通信される。ただし
、それらの機構は本発明の一部ではない。

Ｅ−５５ＬＩＨ拡張部分 ｌＭＣ８はメツセージ・ヘッダのｄｅｓｔｑｔｏｋｅｎ
フィールドからサーバを識別し、割込みハンドラ環境で
サーバの５ＬＩＨ拡張部分４４を呼び出す。メツセージ
の存在と位置をそのサーバに通信することが、５ＬＩＨ
拡張部分４４の役割である。５ＬＩＨ拡張部分４４は、
サーバの内部状態とそのデータ構造にアクセスすること
ができ、到来メツセージをどこかで待ち行列に入れるか
どうか、処理を通知する必要があるかどうかなどを知る
。

たとえば、要求がページ・イン要求である場合、すなわ
ち、サーバからクライエントにページを送る要求である
場合、５ＬＩＨ拡張部分４４は、要求されたページがメ
モリ内にあるかどうかを調べる。メモリ中にある場合、
その送出応答メツセージ用に到来メツセージの物理空間
を使って、ただちに要求にサービスすることができる。

そのページがメモリにない場合、そのページを他のシス
テムまたはディスクから取り出さなければならないが、
どちらの動作も遅い。したがって、５ＬＩＨ拡張部分は
後の処理のためにサービスのスケジューリングを行なう
ことになる。

Ｅ−６中間ノード経路設定 スイッチ１１を備えたクラスタ構成では、スイッチ１１
に接続された任意の２つのプロセッサ１０、たとえばＩ
ＯＡと１０Ｄが、互いに直接接続できる。スイッチ１１
がない場合、またはプロセッサ１０がスイッチ１１に接
続されていない場合は、第３図に示すように、２つのプ
ロセッサＩＯＡと１０Ｄが、１つまたは複数の中間プロ
セッサ１０Ｂを・介して互いに通信することが必要にな
ることがある。これは、中間ノード経路設定（ＩＮＲ）
と呼ばれる。

通信の基本的な問題は、受信側プロセッサ１０Ｄが到来
メツセージを収容するのに十分なバッファ空間をもつか
どうかである。中間ノード経路設定の場合、中間プロセ
ッサ１０Ｂはバッファ空間をもつが、宛先プロセッサ１
０Ｄはもたないことがあり、その逆の場合もある。

プロセッサＩＯＡとＩＯＤが直接接続されている場合、
ＡＣＫとＮＡＫを使って、バッファが利用可能かどうか
通知する。これは、ＪＮＲの場合には不可能である。と
いうのは、ＡＣＫとＮＡＫは中間プロセッサ内のバッフ
ァが利用可能かどうかを通知することになるからである
。

中間プロセッサ１゛ＯＢは、それがバッファ空間をもつ
と送信側プロセッサＩＯＡに伝える場合、宛先プロセッ
サＩＯＤが空間を持たないことが°ゎかると、メツセー
ジをそれ自体のバッファに保持せざるを得なくなり、バ
ッファ空間及び管理の点でかなりの負担が生じる。

この問題を解決するために２つの代替解決方法が開発さ
れた。どちらの解決方法も、通常の場合（非ＩＮＲ）が
ＩＮＨの場合の解決方法によって損なわれるべきでない
ことを認識したものである。

１つの代替解決法では、直列リンク１２を利用して、中
間プロセッサＩＯＢを介して接続を行なう。具体的には
、メツセージが、他のプロセッサ１０Ｄに向かう中間プ
ロセッサ１０Ｂに到達すると、到来直列リンク１２は、
そのメツセージが別の直列リンク１２を介してプロセッ
サＩＯＤに配送されるまで、接続されたままに保持され
る。次に、プロセッサ１０Ｄは、適宜ＡＣＫまたはＮＡ
Ｋをりンク１２を介してプロセッサＩＯＢに送り、プロ
セッサＩＯＢはこのＮＡＫまたはＡＣＫをリンク１２を
介してプロセッサＩＯＡに転送する。

さらに具体的には、中間プロセッサＩＯＢが、（それ自
体のバッファ中でのメツセージを受信したことを意味す
る）ソフトウェアＡＣＫを送る前に、プロセッサＩＯＢ
はそのメツセージを宛先プロセッサＩＯＤに転送しよう
とする。宛先プロセッサＩＯＤは、バッファ空間を持た
ない場合、ＮＡＫをプロセッサＩＯＢに送る。したがっ
て、中間プロセッサＩＯＢはそのメツセージを捨て、Ｎ
ＡＫを発信元プロセッサＩＯＡに送る。

宛先プロセッサＩＯＤがＡＣＫを送る場合、中間プロセ
ッサ１０Ｂはそのメツセージを捨て、ＡＣＫを発信元プ
ロセッサＩＯＡに送る。どちらの場合も、中間プロセッ
サＩＯＢのバッファは解放されて、他のメツセージを受
は入れることができるようになる。

この設計では、宛先プロセッサ１００が応答するまで、
通信プロセッサ１０ＡとＩＯＢの間の通信媒体が使用中
に保たれる。しかし、これは、代わりにより複雑なソフ
トウェアを使用するが、それとも中間プロセッサ内によ
り多くのバッファ空間を設けるかを考えると、妥当なト
レードオフである。この設計を拡張して複数の中間プロ
セッサを設けることができることに留意されたい。

別法として、ｌＭＣ８間接続サービスを通常のｌＭＣ８
の上端に構築することもできる。そうすると、ＡＣＫと
ＮＡＫが、クライエントとサーバとの間の実メツセージ
であるがのように、この接続を介してメツセージとして
送られる。この実施例は、前の実施例より開発コストが
高い。

直接接続した場合、工Ｍｃｓが呼び出されて、メツセー
ジを受信側プロセッサのサービス待チ行列（宛先サービ
ス待ち行列）に送る。ＩＮＨの場合は、ｌＭＣ８が呼び
出され、メツセージをローカルｌＭＣ８接続サービスの
待ち行列に入れる。

この接続は、宛先プロセッサ上の相手方の接続と（中間
プロセッサを介して）セッシジンを行なう。

メツセージは、中間プロセッサを介して宛先プロセッサ
のｌＭＣ８接続サービスに渡される。１ＭＣ８接続サー
ビスは、それを宛先サービス待ち行列に渡す。これは、
バッファの欠如によりうまくいかないことがある。宛先
プロセッサのｌＭＣ８接続サービスは、発信元プロセッ
サのｌＭＣ３接続サービスに成否を示すメツセージを送
る。

発信元プロセッサのｌＭＣ８接続サービスは、宛先ｌＭ
Ｃ８接続サービスからＡＣＫを受信するまで、後続のメ
ツセージを宛先プロセッサ中の同じ待ち行列（「宛先待
ち行列」）には送らない。

そのｌＭＣ８接続サービスがＮＡＫを受信した場合、後
続の非ブロツク化メツセージを待ってからその宛先待ち
行列に送信する。

メツセージは接続サービス間を通過しなければならない
ので、プロセッサはそれらのメツセージ用の空間を予約
しなければならないが、こうしたメツセージは一時に１
つだけ流れる。さらに、受信側ｌＭＣ８接続サービスに
、到来メツセージを宛先待ち行列に渡す前に保持するた
めの一時的バッファが必要である。しかし、中間プロセ
ッサでバッファ空間が必要なのは、ある直列リンクから
メツセージを受信してからそれを別のリンクに送出する
までの間だけである。

この機構は、所与の宛先待ち行列向けのメツセージが一
時に１つだけ飛行できるようにすることに留意されたい
。ｌＭＣ８接続サービスが、順序番号、待ち行列ごとに
別々の順序を与える場合には、この機構が改良できる。

この場合、ＮＡＫは、受信時に特定のメツセージを指定
する。送信側プロセッサのｌＭＣ８接続サービスは、飛
行中の複数の未処理メツセージをもっことがある。すな
わち、そのｌＭＣ８接続サービスは、待ち行列が非ブロ
ック化されるときどこから再開すべきかを知っている。

受信側プロセッサの接続サービスは、それが否定応答し
たメツセージより順序番号が大きなメツセージを捨てる
。その後、その待ち行列が非ブロック化されるとき、そ
れらのメツセージが送信側プロセッサから再送信される
。

【図面の簡単な説明】

第１図は、本発明の通信プロトコルが有利に利用される
、高速スイッチを介してクラスタ構成で相互接続された
複数のプロセッサ・ユニットノ機能構成図である。 第２図は、１つのプロセッサがクラスタ構成中の他のど
のプロセッサともに直接通信するという、通信リンクに
よって互いに接続された複数のプロセッサ・ユニットの
代替構成の機能構成図である。 第３図は、あるプロセッサが中間プロセッサを介して非
隣接プロセッサに通信するという、クラスタ構成で相互
接続された複数のプロセッサ・ユニットの代替構成の機
能構成図である。 第４図は、ユニットの１つに統合された様々なハードウ
ェア機能を示す、第１図、第２図、及び第３図に示した
プロセッサ・ユニットの構成図である。 第５図は、各ユニットに組み込まれた様々なソフトウェ
ア機能とそれらの間でメツセージを送信するための通信
リンクを示す、第１図に示したプロセッサ・ユニットの
うちの２つの構成図である。 第８Ａ図は、本発明の通信プロトコルに従って送信側プ
ロセッサに記憶されるメツセージのヘッダ及び別になっ
たデータ部分のデータ構造を示す図である。 第６Ｂ図は、通信リンクを介して送信されるメツセージ
のデータ構造を示す図である。 第７Ａ図と第７Ｂ図は、遠隔ユニットの構成要素間でメ
ツセージを送信する際の通信プロトコルの諸ステップを
示す図である。 第８Ａ図、第８Ｂ図及び第８Ｃ図は、本発明の通信プロ
トコルを使用する際にプロセッサによって実行される諸
ステップを記述する流れ図である。 ＦＩＧ、　２ ＦＩＧ、　１ １へヅタ゛」 ともバイト ＦＩＧ、　６Ａ 日Ｇ、　６Ｂ Ｌ、−一一一一一＋＋＋＋＋＋＋−−ニー＋＋　　　１
プロセッサ１０Ａ プロセ・／け＋０１３ フ゛ロセゾサ　１０Ａ プロセッサ１０Ｂ

Claims (3)

【特許請求の範囲】
1. （１）受信側プロセッサの受信側構成要素宛てのメッセ
   ージを、送信側プロセッサの構成要素から受信側プロセ
   ッサに送信する手段、 前記メッセージが受信側プロセッサで受信されたとき、
   前記の宛先受信側構成要素が前記メッセージ用に利用可
   能なバッファ空間をもつかどうかを動的に決定する手段
   、 前記メッセージが受信側プロセッサで受信されたことを
   、前記送信側プロセッサに肯定応答する手段、及び メッセージを受信するのに十分なバッファ空間が受信側
   構成要素で利用可能であるという前記受信側プロセッサ
   による決定を、前記肯定応答手段を介して送信側プロセ
   ッサに通知する手段 を含む、ネットワークに接続された複数のプロセッサ間
   で通信するためのシステム。
2. （２）ネットワークに接続された複数の処理システム内
   の複数の構成要素間で通信するためのシステムであって
   、 前記構成要素のそれぞれにバッファ空間を割り振る手段
   、 構成要素の組をクラス・タイプ別に分類する手段、 前記クラス・タイプごとに前記の割り振られたバッファ
   空間をプールする手段、 受信側プロセッサの受信側構成要素宛てのメッセージを
   、送信側プロセッサの構成要素から受信側プロセッサに
   送信する手段、 前記メッセージが受信側プロセッサで受信されたとき、
   前記宛先の受信側構成要素が前記メッセージ用に利用で
   きるバッファ空間をもつかどうかを動的に決定する手段
   、及び バッファ空間が前記宛先の受信側構成要素用に利用でき
   ない場合、前記宛先の受信側構成要素の前記クラス・タ
   イプに関する、前記バッファのプールからバッファを前
   記送信されたメッセージに割り振る手段 を含む前記システム。
3. （３）ネットワークに接続された複数のプロセッサ間で
   通信するための方法であって、 受信側プロセッサの複数の構成要素の１つ宛ての所期の
   メッセージを、送信側プロセッサの構成要素から受信側
   プロセッサに送信するステップ、受信側構成要素が利用
   可能なことを動的に指定し、送信されたメッセージが前
   記所期の利用可能な構成要素に到着したとき、前記利用
   可能な構成要素によって直ちに処理するため、関連する
   処理動作を並行して識別するステップ、 前記受信側プロセッサ内の割込みハンドラにより、前記
   送信メッセージの到着時に前記関連処理動作を呼び出す
   ことにより、前記所期の受信側構成要素にアクセスする
   ステップ、及び、 前記識別された処理動作を直ちに実行すると同時に、前
   記所期の受信側構成要素によって決定される他の処理動
   作を延期するステップ、 を含む前記方法。