JP3312362B2 - マルチプロセッサシステム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のプロセッサモジ
ュールから構成されるマルチプロセッサシステムに関
し、特に転送遅延時間が短く、プロセッサモジュール間
のリソース競合を回避でき、処理効率の高いメッセージ
転送が可能なマルチプロセッサシステムに関するもので
ある。

【０００２】

【従来の技術】複数のプロセッサを組み合わせてマルチ
プロセッサシステムを用いて、複数のオブジェクト（並
列実行の単位となるプロセス）の間でメッセージを交信
しながら処理を進めるオブジェクト指向分散処理方式が
提案されている。例えば、Ｔ.Ｓhimizu et al.“Ｌow
-Ｌatency Ｃommunication Ｓupport for theＡＰ
1000",Ｐroceedings of the 19th Ｉnternational
Ｓymposium onＣomputer Ａrchitecture,pp.288〜29
7,1992には、上記のようなオブジェクト指向分散処理方
式が記述されている。図２および図３は、上記文献によ
る従来例を示すシステム構成図およびプロセッサ間メッ
セージ通信方法を示すシーケンスチャートである。図２
において、１−１，１−２はマルチプロセッサシステム
におけるプロセッサモジュール（ＰＭ）、２−１，２−
２はプロセッサモジュール内のプロセッサ、３−１，３
−２はそれぞれ対応するプロセッサ１−１，１−２から
読み書きアクセスが可能なローカルメモリ、４−１，４
−２はＰＭ間でメッセージ転送を行うためのＤＭＡ（Di
rect Memory Access)コントローラ、５はプロセッサ
間通信路、６はローカルメモリ３−１上に設けられたメ
ッセージバッファエリア、７は同じくローカルメモリ３
−２上に設けられたメッセージバッファエリアである。

【０００３】図２に示すマルチプロセッサシステムにお
いて、ＰＭ１−１からＰＭ１−２にメッセージを転送す
る場合のシーケンスを、図３により説明する。Ｓ１はメ
ッセージバッファ要求、Ｓ２はメッセージバッファエリ
ア６の確保、Ｓ３はメッセージバッファエリア６へメッ
セージを書込み、Ｓ４は送信要求、Ｓ５はＤＭＡコント
ローラ４−１に制御情報設定、Ｓ６はＤＭＡ起動、Ｓ７
はメッセージバッファエリア６からプロセッサ間通信路
５へ転送、Ｓ８はプロセッサ間転送、Ｓ９は受信一時バ
ッファに記憶、Ｓ１０は割込み、Ｓ１１はメッセージバ
ッファエリア７の確保、Ｓ１２はＤＭＡコントローラ４
−２に制御情報設定、Ｓ１３はＤＭＡ起動、Ｓ１４は受
信一時バッファからメッセージバッファエリア７に転
送、Ｓ１５は割込み、Ｓ１６は受信先の特定、Ｓ１７は
受信オブジェクト起動、Ｓ１８はメッセージの読出しの
各ステップを示している。図３におけるプロセッサモジ
ュール１−１の送信オブジェクト１０からメッセージバ
ッファ要求Ｓ１があると、オペレーティングシステムの
中心的プログラムであるカーネル１１−１がステップＳ
２でメッセージバッファエリア６をローカルメモリ３−
１内に確保し、送信オブジェクト１０に通知する。送信
オブジェクト１０は、ステップＳ３でメッセージバッフ
ァエリア６にメッセージを書き込む。図２においては、
太線矢印Ｌ１０で示されている。送信オブジェクト１０
はカーネル１１−１にステップＳ４で送信要求を出し、
カーネル１１−１はステップＳ５でメッセージバッファ
エリア６の先頭アドレス（図２のＡＤＲ１）とメッセー
ジサイズ（図２のｎ）、および転送先のプロセッサモジ
ュール番号等の制御情報をＤＭＡコントローラ４−１に
設定する。これは、図２においては、太線矢印Ｌ１１で
示される。カーネル１１−１は、ステップＳ６でＤＭＡ
コントローラ４−１を起動し、ＤＭＡコントローラ４−
１は設定された制御情報に従って、ステップＳ７，Ｓ８
でメッセージをメッセージバッファエリア６から順次読
み出し、プロセッサ間通信路５を経由して受信側ＰＭ１
−２のＤＭＡコントローラ４−２に転送する。これは、
図２では、太線矢印Ｌ１２で示される。

【０００４】ＤＭＡコントローラ４−２は、ステップＳ
９でメッセージを一時記憶に蓄積すると同時に、並行し
てステップＳ１０でプロセッサ２−２のカーネル１１−
２に割り込みをかける。これは、図２においては、太線
矢印Ｌ１３で示される。カーネル１１−２は、ステップ
Ｓ１１で受信側ＰＭ１−２のローカルメモリ３−２上に
メッセージバッファエリア７のアドレス（図２のＡＤＲ
２）とメッセージサイズ（図２のｎ）等の制御情報を設
定する。カーネル１１−２がステップＳ１３でＤＭＡ起
動を行うと、ＤＭＡコントローラ４−２はステップＳ１
４でメッセージをメッセージバッファエリア７に転送し
（図２の太線矢印Ｌ１４）、ステップＳ１５でカーネル
１１−２に転送終了を通知する。カーネル１１−２は、
ステップＳ１６でメッセージ内に書込まれた宛先を見
て、図２の受信オブジェクト１２を特定し、ステップＳ
１７で起動する。受信オブジェクト１２がステップＳ１
８でローカルメモリ３−２内のメッセージバッファ７か
らメッセージを読み出す（これは図２の太線矢印Ｌ１
５）。以上の手順により、ＰＭ間のメッセージ転送が行
われる。

【０００５】

【発明が解決しようとする課題】図３においては、送信
オブジェクト１０がステップＳ３でメッセージバッファ
エリア６に書き込んだ段階で、受信ＰＭ宛のメッセージ
転送をできるだけ早く開始することが望ましい。また、
受信側においても、図３のステップＳ９でメッセージを
受信した段階で、できるだけ早く受信オブジェクト１２
にメッセージを引き渡すことが望ましい。しかしなが
ら、従来の技術では、図３に示すように、ステップＳ５
とステップＳ１２のＤＭＡ起動準備処理や、ステップＳ
１１における受信側でのメッセージバッファエリアの捕
捉、ステップＳ１０，Ｓ１５における割り込み処理等が
あり、メッセージ送受信を終了させるまでには多くのカ
ーネル処理が必要である。その結果、メッセージ転送遅
延の増加とカーネルの処理オーバヘッド増加を招くとい
う問題がある。特に、プロセッサ間通信路５の転送速度
が大きい場合には、上記処理オーバヘッドによる転送遅
延の比率は相対的に増加するため、処理オーバヘッドの
削減と転送遅延時間の短縮が必須の条件となってくる。
また、ステップＳ１０，Ｓ１５では、送信ＰＭからのメ
ッセージ到着を通知する方法として割り込みを用いてい
る。しかし、割り込み要求を受け付けるためには、現在
実行中の情報を退避して、割り込み処理に切り替えるた
めのカーネルの処理オーバヘッドが一般に大である。従
って、割り込み方式を多数のＰＭを含む超並列システム
に適用した場合には、単位時間当りの割り込み回数の増
加により、処理オーバヘッドが非常に大となって、転送
遅延も増大するという問題が生じる。

【０００６】割り込みを回避する方法としては、従来よ
り、ポーリング方式と呼ばれる要求受け付け方式が用い
られている。ポーリング方式は、プロセッサ側が外部か
らの処理要求を予め決められたメモリやレジスタ等に記
憶させておき、処理が可能になると、プロセッサが処理
要求を読み出してきて処理を開始する方法である。この
ように、ポーリング方式は、割り込み方式に比較して処
理切り替えのオーバヘッドが少ないが、処理要求を記憶
する全てのメモリやレジスタを読み出す必要があるた
め、処理要求の発生頻度が少ない場合には処理要求の読
み出しが空振りに終る、つまり処理要求が発生していな
い現象となることも多い。特に、多数のＰＭを有する超
並列システムでは、処理要求の数および種類が多いた
め、それらの全てを定期的に読み出すための処理オーバ
ヘッドが大きく、空振りの回数も増加して処理効率が低
下するという問題があった。また、本出願人は本願に先
立って、『分散共有メモリシステム』（特願平６−７４
６６９号明細書および図面参照）を提案した。上記発明
においては、分散共有メモリを送信プロセッサモジュー
ルと受信プロセッサモジュールの組み合わせ毎に対応し
て分割し、各プロセッサモジュールからメッセージを送
信する場合、自プロセッサモジュールを送信元とする受
信プロセッサモジュール対応のエリアを使用する。その
結果、異なる２つの送信プロセッサモジュールから同一
受信プロセッサモジュールにメッセージ通信要求が同時
に発生しても、互いに使用するメッセージバッファが重
複することがなく、メッセージバッファ確保のための競
合処理に伴う性能低下や性能ボトルネックを回避するこ
とができる。本発明の目的は、上記のような従来の課題
を解決し、先願の発明を利用して、カーネル等のシステ
ムソフトウェアのオーバヘッドを削減するとともに、転
送遅延時間を短縮して、処理効率の高いメッセージ転送
を実現できるマルチプロセッサシステムを提供すること
にある。

【０００７】

【課題を解決するための手段】上記目的を達成するた
め、本発明のマルチプロセッサシステムは、 （イ）複数のプロセッサモジュール（１８）から構成さ
れたマルチプロセッサシステム（１７）において、上記
プロセッサモジュール（１８）には、各プロセッサモジ
ュール間で共通のアドレスを有し、送信プロセッサモジ
ュールと受信プロセッサモジュールの組み合わせで指定
される管理単位毎に分割された分散共有メモリ（２１）
と、上記送信プロセッサモジュールの分散共有メモリ
（以下、送信側分散共有メモリ２１）とアドレスを共有
する受信プロセッサモジュールの識別情報を記憶し、該
送信側分散共有メモリ（２１）への書き込みが発生する
と、上記受信プロセッサモジュールの識別情報で指定さ
れた受信プロセッサモジュールに、書き込みアドレスと
書き込みデータを送信するとともに、受信した書き込み
アドレスと書き込みデータをもとに受信プロセッサモジ
ュールの分散共有メモリ（以下、受信側分散共有メモリ
２１）の、送信側と同一のアドレスロケーションにコピ
ーを行う分散共有メモリ制御手段（２２）と、送信する
メッセージの宛先情報をもとに受信プロセッサモジュー
ルを特定し、上記分散共有メモリ上の送信プロセッサモ
ジュールと受信プロセッサモジュールの組み合わせで指
定されるメッセージバッファ（１６）を捕捉するメッセ
ージバッファ管理手段（２００）とを有し、送信プロセ
ッサモジュール（１８）から受信プロセッサモジュール
（１８）にメッセージを送信する場合に、送信プロセッ
サモジュールは、上記メッセージバッファ管理手段（２
００）により上記受信プロセッサモジュール対応の送信
メッセージバッファ（１８０）を捕捉し、該送信メッセ
ージバッファ（１８０）に上記メッセージを書き込み、
該送信プロセッサモジュール（１８）と受信プロセッサ
モジュール（１８）とが同一モジュールである場合に
は、上記受信プロセッサモジュール（１８）は、上記送
信メッセージバッファから、直接、メッセージを読み出
すことにより、同一プロセッサ内メッセージ通信を行
い、送信プロセッサモジュールと受信プロセッサモジュ
ールが異なるモジュールである場合には、送信側の分散
共有メモリ制御手段（２２）が、上記送信メッセージバ
ッファのアドレスをもとに受信プロセッサモジュール識
別情報を取り出し、該識別情報の受信プロセッサモジュ
ールに送信メッセージバッファアドレスと書き込みデー
タを転送し、受信側の分散共有メモリ制御手段は、受信
した上記送信メッセージバッファのアドレスと上記書き
込みデータをもとに受信側の分散共有メモリの、送信側
と同一アドレスの受信メッセージバッファにコピーを行
い、上記受信プロセッサモジュールでは、上記受信メッ
セージバッファからメッセージを読み出すことにより、
異なるプロセッサ間のメッセージ通信を行うことを特徴
としている。

【０００８】（ロ）上記受信側の分散共有メモリ制御手
段は、さらにアドレスを共有する送信プロセッサモジュ
ールの識別情報を記憶し、上記送信プロセッサモジュー
ルでは、該送信プロセッサモジュールと受信プロセッサ
モジュールの組み合わせで指定される分散共有メモリ上
の送信制御エリアに、メッセージ制御情報あるいはメッ
セージバッファ管理情報を含む制御データを書き込み、
送信プロセッサモジュールと受信プロセッサモジュール
とが同一モジュールである場合には、該受信プロセッサ
モジュールは、上記送信制御エリアから、直接、制御デ
ータを読み出してメッセージあるいはメッセージバッフ
ァに関する制御内容を認識し、対応する処理を実行した
後、上記送信制御エリアに返答制御データを書き込み、
上記送信プロセッサモジュールは、上記送信制御エリア
から上記返答制御データを読み出して受信側での処理結
果を認識することにより、同一プロセッサモジュール内
双方向通信を行い、送信プロセッサモジュールと受信プ
ロセッサモジュールが異なるモジュールである場合に
は、上記送信側の分散共有メモリ制御手段は、上記送信
制御エリアのアドレスをもとに受信プロセッサモジュー
ル識別情報を取り出し、該送信制御エリアアドレスと書
き込みデータを上記受信プロセッサモジュールに転送
し、上記受信側の分散共有メモリ制御手段は、受信した
上記送信制御エリアアドレスと上記書き込みデータをも
とに受信側分散共有メモリの、送信側と同一アドレスの
受信制御エリアにコピーを行い、上記受信プロセッサモ
ジュールは、上記受信制御エリアから制御データを読み
出して、メッセージあるいはメッセージバッファに関す
る制御内容を認識し、対応する処理を実行した後、上記
受信制御エリアに返答制御データを書き込むと、受信側
の分散共有メモリ制御手段は、上記受信制御エリアアド
レスをもとに、上記送信プロセッサモジュール識別情報
を取り出し、該識別情報をもとに上記受信制御エリアア
ドレスと上記返答制御データを上記送信プロセッサモジ
ュールに転送し、上記送信側の分散共有メモリ制御手段
は、受信した上記受信制御エリアアドレスと上記返答制
御データをもとに送信側分散共有メモリの、受信側と同
一アドレスの送信制御エリアにコピーを行い、上記送信
プロセッサモジュールでは、上記送信制御エリアから上
記返答制御データを読み出して、受信側での処理結果を
認識することにより、プロセッサモジュール間双方向通
信を行うことも特徴としている。

【０００９】（ハ）複数のプロセッサモジュールから構
成されたマルチプロセッサシステムにおいて、上記プロ
セッサモジュールには、各プロセッサモジュール間で共
通の同一アドレスを有し、受信プロセッサモジュール対
応の管理単位毎に分割された分散共有メモリと、送信側
分散共有メモリとアドレスを共有する受信プロセッサモ
ジュールの識別情報を記憶し、送信側分散共有メモリへ
の書き込みが発生すると、上記受信プロセッサモジュー
ル識別情報で指定された受信プロセッサモジュールに書
き込みアドレスと書き込みデータを送信するとともに、
受信した書き込みアドレスと書き込みデータをもとに受
信側分散共有メモリの、送信側と同一のアドレスロケー
ションに書き込みを行う分散共有メモリ制御手段とを有
し、上記受信側の分散共有メモリのエリアはＦＩＦＯメ
モリで構成され、複数の送信プロセッサモジュールから
１つの受信プロセッサモジュールに処理要求を通知する
際に、上記送信プロセッサモジュールと受信プロセッサ
モジュールが同一のモジュールである場合には、上記送
信プロセッサモジュールでは、送信側分散共有メモリ上
の自プロセッサモジュール宛処理要求ＦＩＦＯエリア
に、処理要求データを書き込み、上記送信プロセッサモ
ジュールと受信プロセッサモジュールが異なるモジュー
ルである場合には、上記送信プロセッサモジュールで
は、上記送信側分散共有メモリ上の受信プロセッサモジ
ュール宛処理要求ＦＩＦＯエリアに、処理要求データを
書き込み、送信側分散共有メモリ制御手段は、上記処理
要求エリアのアドレスをもとに受信プロセッサモジュー
ル識別情報を取り出し、上記処理要求エリアアドレスと
書き込みデータを受信プロセッサモジュールに転送し、
受信側分散共有メモリ制御手段は、受信した上記処理要
求ＦＩＦＯエリアアドレスと上記書き込みデータをもと
に受信側分散共有メモリの、送信側と同一アドレスの上
記処理要求ＦＩＦＯエリアに書き込むことにより、上記
処理要求ＦＩＦＯエリアに複数の処理要求データを到着
順に蓄積し、上記受信側プロセッサモジュールでは、受
信側分散共有メモリ上の上記要求ＦＩＦＯエリアから複
数の上記処理要求データを順次読み出すことにより、処
理要求を検出することも特徴としている。

【００１０】（ニ）上記送信側分散共有メモリ制御手段
は、送信側分散共有メモリの連続する複数のアドレスロ
ケーションに複数のデータが連続的に書き込まれた場
合、上記複数のデータの先頭アドレスと複数のデータと
をまとめて受信プロセッサモジュールに一括送信し、受
信側分散共有メモリ制御手段は、一括受信した上記先頭
アドレスと上記複数のデータをもとに受信側分散共有メ
モリ上の同一アドレスロケーションに連続的にコピーを
行うことも特徴としている。

【００１１】

【作用】本発明においては、送信プロセッサモジュー
ルの分散共有メモリ制御手段に、分散共有メモリアドレ
スを共有する受信プロセッサモジュール識別番号を記憶
することにより、送信側共有メモリへの書き込みが行わ
れると、分散共有メモリ制御手段からそのアドレスに対
応する受信プロセッサモジュール識別番号を読み出し、
対応する受信プロセッサモジュールに書き込み情報を送
出すると、受信側の分散共有メモリ制御手段は、受信側
分散共有メモリの同一アドレスロケーションにコピーを
行う。送信プロセッサモジュール内の分散共有メモリ
は、受信プロセッサ対応にメッセージバッファ群が分割
されており、ある受信プロセッサ対応のメッセージバッ
ファにメッセージが書き込まれると、分散共有メモリ制
御手段により、対応する送受信プロセッサモジュール内
の分散共有メモリの同一ロケーションのメッセージバッ
ファにコピーが行われる。このように、プロセッサモジ
ュール間で高速にオーバヘッドの少ないメッセージ通信
が実現できる。 また、受信側の分散共有メモリ制御手段にも、分散共
有メモリアドレスを共有する送信プロセッサモジュール
識別番号を記憶しておき、これにより受信側分散共有メ
モリのメッセージ制御エリアにメッセージ制御情報を書
き込むと、送信側分散共有メモリにコピーされることに
より、メッセージ制御に必要な双方向通信が行える。

【００１２】さらに、受信側分散共有メモリの処理要
求エリアをＦＩＦＯメモリにすることにより、送信側分
散共有メモリに書き込んだ処理要求が、受信側分散共有
メモリのＦＩＦＯに順次蓄積される。従って、複数の送
信側プロセッサモジュールが同時に各分散共有メモリの
同一ＦＩＦＯロケーションに処理要求を書き込んだ場合
でも、受信側の分散共有メモリのＦＩＦＯで自動的に順
序付けが行われるので、全ての処理要求がＦＩＦＯに順
次書き込まれる。受信側は、分散共有メモリ内の要求登
録ＦＩＦＯを順次読み出すだけで、発生した要求のみを
効率よく取り出せる。従って、従来のポーリング処理や
割り込み処理で必要とされた処理オーバヘッドを大幅に
削減することができる。 また、先願である特願平６−７４６６９号明細書およ
び図面に記載のものに比較すると、分散共有メモリが全
てのプロセッサモジュール間で共通のアドレスが付加さ
れ、送信プロセッサモジュールと受信プロセッサモジュ
ールの組み合わせで指定される管理単位毎に分割されて
いる点、および分散共有メモリを、自プロセッサモジュ
ール内のローカル転送データのための送受信用と、異な
るプロセッサモジュール間のリモート転送データのため
の送受信用のエリアに分割している点では共通してい
る。しかし、上記明細書では、送信プロセッサモジュー
ルが送信および受信メッセージバッファを捕捉し、受信
プロセッサモジュールがそれらを解放し、受信プロセッ
サモジュールで再利用するか、あるいは送信プロセッサ
モジュールに再利用を許可する方法を用いている。その
結果、２つのプロセッサモジュール間で双方向のメッセ
ージ通信のトラヒックがアンバランスな場合、メッセー
ジバッファの過不足が生じ易く、その制御手順も複雑で
処理オーバヘッドも大きい。これに対して、本発明で
は、送信および受信メッセージバッファの捕捉、解放は
送信プロセッサモジュールで一元的に行われ、送信側プ
ロセッサモジュールで常に再利用されるため、制御手順
も簡単である。また、上記明細書では、送信メッセージ
バッファから受信メッセージバッファへのコピーは、送
信メッセージバッファにメッセージが書かれた後、メッ
セージ送信要求が発せられた時点で開始される。これに
対して、本発明では、送信メッセージバッファから受信
メッセージバッファへのコピーは、送信メッセージバッ
ファにメッセージが書き込まれた瞬間から開始されるた
め、メッセージ転送遅延時間を短縮することができる。
そして、本発明では、さらに受信側の分散共有メモリ制
御手段にも、分散共有メモリアドレスを共有する送信プ
ロセッサモジュール識別番号を記憶しておき、受信側分
散共有メモリのメッセージ制御エリアにメッセージ制御
情報を書き込むと、送信側分散共有メモリにコピーされ
る点が付加されている。また、分散共有メモリの処理要
求エリアをＦＩＦＯメモリにする点も新たに追加されて
いる。さらに、分散共有メモリ制御手段に登録されるプ
ロセッサモジュール情報に応じて、一方向性通信、両方
向性通信、放送型通信等の各種の通信パターンを任意に
実現できる点でも追加されている。このように、本発明
によれば、メッセージが送信側から受信側に伝達される
までの遅延時間が大幅に削減されるとともに、一方向
性、両方向性、放送型等の各種通信パターンを選択する
ことができるので、柔軟性が高い。また、受信側プロセ
ッサモジュールは受信側分散共有メモリの同じアドレス
ロケーションから制御データを読み出すだけで、プロセ
ッサモジュール間の通信の同期を簡単にとることがで
き、かつ複数の送信プロセッサモジュールが同時に、分
散共有メモリの同一番地に書き込みされた場合でも、受
信側の分散共有メモリのＦＩＦＯに順次書き込まれるの
で、競合処理を全く必要としない。従って、受信側は、
分散共有メモリ内の要求登録ＦＩＦＯを順次読み出すの
みで、発生した要求のみを効率よく取り出すことがで
き、従来のようなサーチのための処理オーバヘッドを大
幅に削減できる。

【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図４は、本発明の一実施例を示すマルチプロ
セッサシステムの構成図であって、３台のプロセッサか
らなる場合を示している。図４において、１７はマルチ
プロセッサシステム、１８−１，１８−２，１８−３は
マルチプロセッサシステムにおけるプロセッサモジュー
ル（ＰＭ）、１９−１，１９−２，１９−３は各ＰＭ内
のプロセッサ、２０−１，２０−２，２０−３はそれぞ
れ対応するプロセッサ１９−１〜１９−３から読み書き
アクセスが可能なローカルメモリ、２１−１，２１−
２，２１−３は全プロセッサモジュール間で共通のアド
レスが付与された分散共有メモリである。ただし、プロ
セッサ１９−１からアクセスできる分散共有メモリはロ
ーカルメモリ２１−１のみであって、他のＰＭのローカ
ルメモリ２１−２，２１−３にはアクセスできない。同
じように、プロセッサ１９−２からアクセスできる分散
共有メモリは２１−２のみであり、プロセッサ１９−３
からアクセスできる分散共有メモリは２１−３のみであ
る。２２−１，２２−２，２２−３は分散メモリカップ
ラであって、これらは分散共有メモリ２１−１〜２１−
３にデータがそれぞれ書き込まれた時点で、その書き込
みデータを、予め指定された他のプロセッサモジュール
の全てないし１個に送信すると同時に、他のプロセッサ
モジュールから受信した書き込みデータを、分散共有メ
モリ２１−１〜２１−３のうちの送信側と同一のアドレ
スロケーションに書き込むための装置である。

【００１３】次に、２３−１，２３−２，２３−３は分
散メモリプロテクタであって、それぞれ、分散共有メモ
リ２１−１〜２１−３内のメッセージバッファに記憶さ
れているメッセージを不正なアクセスから保護する装置
である。２４−，２４−２，２４−３はネットワークア
ダプタであって、通信ネットワーク２６を介して他の分
散システムとメッセージ等を交換するための装置であ
る。２５はプロセッサモジュール間通信路であって、マ
ルチプロセッサシステム１７内のＰＭ間でメッセージあ
るいはそれらの制御情報を転送するための装置である。
プロセッサモジュール間通信路の具体的実現手段として
は、システムバス、ＬＡＮ、パケットスイッチングネッ
トワーク、リングネットワーク等、送信側と受信側で１
対１の通信ができるものであれば何でもよい。２６は複
数のマルチプロセッサシステム１７間を相互接続するた
めの通信ネットワークであって、ここでは転送データを
固定長のブロックに分割して、それに行き先ヘッダを付
加した５３バイトのセルにして、ネットワーク内を転送
するＡＴＭ（Ａsynchronous Ｔrasnsfer Ｍode)ネッ
トワークを想定しているが、その他の種類の通信ネット
ワークでも適用可能であることは勿論である。

【００１４】図５、図６および図７は、図４における分
散共有メモリのデータ配置例を示す図である。ここで
は、データの配置を物理アドレスレベルで示している。
分散共有メモリ内の通信領域は、ＰＭ間通信エリア、
ＰＭ内通信エリア、ＦＩＦＯ通信エリア、の３種類
に大別される。このうちＰＭ間通信エリアは、マルチ
プロセッサシステム１７内のＰＭ間通信情報を記憶する
エリアであり、ＰＭ内通信エリアは、同一ＰＭ内で送
受信される通信情報を記憶するエリアであり、またＦ
ＩＦＯ（First In First Out)通信エリアは、ＰＭ間
にまたがる処理要求をＦＩＦＯ形式で蓄積記憶するエリ
アである。ＰＭ間通信エリアおよびＰＭ内通信エリア
は、 （ｉ）メッセージを記憶するメッセージバッファ（Ｍ
Ｂ）エリア （ii）メッセージバッファの捕捉／解放状態を表示する
ＭＢ管理マップエリア （iii）メッセージバッファアドレス等の送受間引き継
ぎ制御情報（ディスクリプタ）を複数個、連続アドレス
に配置したディスクリプタリングエリア それぞれに分けられる。これらのエリアの具体的使用方
法については、追って説明する。上記ＭＢ、ＭＢ管理マ
ップ、およびディスクリプタリングは、それぞれページ
を単位として物理メモリの割り当てが行われ、これらの
ページは仮想記憶のページテーブルにより管理されてい
る。そして、ＭＢエリア用のページテーブルには、プロ
セッサのスーパバイザモード（カーネルやカーネルから
起動される各種のシステム制御プログラムが実行される
モード）と、ユーザモード（各種アプリケーションプロ
グラムが実行されるモード）との両方からアクセスが許
されるように保護情報が設定されている。その結果、各
種アプリケーションプログラムがＭＢエリアにメッセー
ジを直接読み書きすることができるので、処理の効率化
を図ることが可能となる。一方、ＭＢ管理マップ用ペー
ジと、ＭＢディスクリプタリング用ページのページテー
ブルには、プロセッサのスーパバイザモードのアクセス
のみを許すように保護情報が設定されている。その結
果、アプリケーションプログラムからＭＢ管理マップお
よびＭＢディスクリプタリングへの不正書き込みに対し
て保護が行われる。

【００１５】図５〜図７のエリア内の記述に示すよう
に、分散共有メモリ２１上の各エリアを識別するため
に、Ｍｉｊ−ｋのような識別名を用いている。ここで、
Ｍはプロセッサモジュール対応のＭＢ／ＭＢ管理マップ
／ＭＢディスクリプタリング／ＦＩＦＯ通信エリアの識
別記号であり、ＰＭ（１８−１）に対応するＭＢはＸ、
そのＭＢ管理マップはＸＭ、ＭＢディスクリプタリング
はＸＤ、ＦＩＦＯ通信エリアはＸＦと表現される。同じ
ように、ＰＭ（１８−２）に対応するＭＢはＹ、そのＭ
Ｂ管理マップはＹＭ、ＭＢディスクリプタリングはＹ
Ｄ、ＦＩＦＯ通信エリアはＹＦ、ＰＭ（１８−３）に対
応するＭＢはＺ、そのＭＢ管理マップはＺＭ、ＭＢディ
スクリプタリングはＺＤ、ＦＩＦＯ通信エリアはＺＦの
ように名称が付けられている。また、ｉ，ｊは、それぞ
れ送信ＰＭの識別番号（ＰＭ ＩＤ）と受信ＰＭの識別
番号（ＰＭ ＩＤ）を表わしており、ＰＭ＃１（１８−
１）、ＰＭ＃２（１８−２）、ＰＭ＃３（１８−３）に
対応してそれぞれ１，２，３の番号が付与されている。
ただし、例外として、ＦＩＦＯ通信エリアＸＦ，ＹＦ，
ＺＦは値ｊのみを有し、値ｉを持っていない。その理由
としては、ＦＩＦＯ通信エリアが値ｊで表わされる受信
側プロセッサモジュール対応に分割されており、値ｉで
表わされる各送信プロセッサモジュール対応に分割され
ており、値ｉで表わされる各送信プロセッサモジュール
間で共通に使用するため、エリアの指定情報として値ｉ
を必要としないためである。

【００１６】ｋは同一種類のエリア内での複数個のＭＢ
／ＭＢ管理マップ／ＭＢディスクリプタ／ＦＩＦＯ通信
エリアを識別するためのもので、１から順に値が割り振
られている。例えば、Ｚ１３−２は、分散共有メモリ２
１−３上の、ＰＭ＃１（１８−１）からＰＭ＃３（１８
−３）へのＭＢのうちの第２番目のＭＢを表わす。ま
た、ＸＤ２１−２は、分散共有メモリ２１−１上の、Ｐ
Ｍ＃２（１８−２）から１番目のＰＭ＃１（１８−１）
へのＭＢディスクリプタのうち、第２番目のＭＢディス
クリプタを表わす。図５〜図７から明らかなように、Ｐ
Ｍ間通信エリアではｉ≠ｊ、ＰＭ内通信エリアではｉ＝
ｊとなる。ただし、例外として、ＭＢディスクリプタ／
ＦＩＦＯ通信エリアで、送信処理要求情報が登録される
場合にはＳと表現され、受信処理要求情報が登録される
場合にはＲと表現される。例えば、ＸＤ１２−Ｒは、分
散共有メモリ（２１−１）上のＰＭ＃１（１８−１）か
らＰＭ＃２（１８−２）への受信ディスクリプタを表わ
し、ＺＦ２−Ｓは、分散共有メモリ（２１−３）上のＰ
Ｍ＃２（１８−２）への受信処理ＦＩＦＯ通信エリアを
表わしている。各分散共有メモリは、実効的に必要とさ
れるメモリ量、つまり自プロセッサが送受信するために
必要なエリアのみが実装されている。例えば、分散共有
メモリ２１−１では、図５、図６のハッチ部分のみが実
装されており、それ以外のエリアにはメモリが実装され
ていない。

【００１７】２つのメッセージバッファのｉ，ｊ，ｋの
値がそれぞれ一致し、Ｍの値が異なるＭＢがペアを構成
する。このペアは、異なる分散共有メモリの同一物理ア
ドレスロケーションに配置される。例えば、図５〜図７
において、メッセージバッファＸ１２−１とＹ１２−１
はペアを組んでおり、互いに同じ物理アドレスを有して
いる。各ペアは、送信側ＰＭのカーネルにより動的に捕
捉、解放が行われる。各ＭＢは固定長の大きさで構成さ
れており、図５〜図７に示すように、宛先ＰＭ−ＩＤが
同一の複数のＭＢを、分散共有メモリの連続するアドレ
スロケーションに割り付ける。これを、宛先ＰＭ対応Ｍ
Ｂプールと呼ぶ。各ＭＢプール対応にＭＢ管理マップが
存在し、ＭＢプール内のＭＢ数に応じたＭＢ管理マップ
のエントリが用意され、それらが分散共有メモリの連続
エリアに割り付けられている。例えば、図５において、
メッセージバッファＸ１２−１，Ｘ１２−２は１つのＭ
Ｂプールを構成し、Ｘ１２−１に対してＭＢ管理マップ
エントリＸＭ１２−１が、Ｘ１２−２に対してＭＢ管理
マップエントリＸＭ１２−２が対応する。『対応』とい
う意味は、ＭＢの先頭アドレス（以下、単にＭＢアドレ
スと呼ぶ）が付与されると、そのＭＢ管理マップエント
リアドレスを求めることができ、逆にＭＢ管理マップエ
ントリアドレスからＭＢアドレスも求めることができる
ことを意味している。ＭＢ管理マップの各エントリは、
対応するＭＢが『未使用』か／『使用中』かの状態を表
示し、カーネルにより値が設定される。ＭＢの場合と同
じ考え方により、送信側分散共有メモリＭＢ管理マップ
エントリと、受信側分散共有メモリの同一アドレスのＭ
Ｂ管理マップエントリがペアを構成している。例えば、
ＭＢ管理マップエントリＸＭ１２−２とＹＭ１２−２が
ペアを組んでいる。

【００１８】ディスクリプタリングエリアも、ＭＢと同
じように、宛先ＰＭ−ＩＤが同一の複数のＭＢディスク
リプタを分散共有メモリの連続するアドレスロケーショ
ンに割り付けており、割り付けた全体をディスクリプタ
リングと呼ぶ。『リング』と呼ばれている理由は、ディ
スクリプタリングに含まれる複数のディスクリプタを若
いアドレス順にサイクリックに使用していくからであ
る。送信側の各ディスクリプタリングと同一アドレスの
エリアが、受信プロセッサモジュールの分散共有メモリ
にも配置される。ディスクリプタリングは、送信オブジ
ェクトからのメッセージ制御情報を他のＰＭあるいは他
のシステムに引き継ぐための『送信ディスクリプタリン
グ』と、他のＰＭあるいは他のシストムから受信したメ
ッセージ制御情報を受信オブジェクトに引き継ぐための
『受信ディスクリプタリング』に分けられる。ディスク
リプタリングもＭＢやＭＢ管理マップの場合と同じよう
に、送信側と受信側の同一アドレス間でペアを構成す
る。ディスクリプタリング内のディスクリプタとＭＢと
の対応は、実行時にカーネルにより動的に決定される。
具体的には、例えばＰＭ＃１（１８−１）からＰＭ＃２
（１８−２）にメッセージを送信する場合に、ＰＭ（１
８−１）のカーネルが空きのＭＢプールの中から適当な
ＭＢ（例えばＸ１２−２）を捕捉し、次に対応する送信
ディスクリプタリング（例えばＸ１２−Ｓ）を選択し、
その中の『未使用』の最若アドレスのディスクリプタに
ＭＢアドレスを登録する。このような方法でディスクリ
プタとＭＢとの対応が動的に決定される。なお、送信デ
ィスクリプタリングＸＤ１２−Ｓとペアを組む送信ディ
スクリプタリングはＹＤ１２−Ｓである。

【００１９】図７におけるＦＩＦＯ通信エリアは、送信
オブジェクトからのメッセージ受信処理要求を他のＰＭ
または他のシステムに通知するための『送信処理ＦＩＦ
Ｏエリア』と、他のＰＭまたは他のシステムから受信し
たメッセージ受信処理要求を受信オブジェクトに通知す
るための『受信処理ＦＩＦＯエリア』に分けられる。こ
のうち、メッセージ処理要求送信側の分散共有メモリ
は、通常のＲＡＭ（ランダムアクセスメモリ）で構成さ
れるが、メッセージ処理要求受信側の分散共有メモリ
は、ＦＩＦＯで構成されている。例えば、ＰＭ＃１（１
８−１）上のＰＭ＃１（１８−１）宛受信処理ＦＩＦＯ
エリアＸＦ１−Ｒは、他のＰＭからのメッセージ受信処
理要求を記憶するためにＦＩＦＯメモリで構成されてい
るが、ＰＭ＃２上のＰＭ＃１（１８−１）宛受信処理Ｆ
ＩＦＯエリアＹＦ１−Ｒおよび、ＰＭ＃３上のＰＭ＃１
（１８−１）宛受信処理ＦＩＦＯエリアＺＦ１−Ｒは、
いずれもＲＡＭで構成されている。この理由としては、
受信処理要求を書き込む側のＰＭ（ＰＭ＃２とＰＭ＃
３）が受信処理要求をそれぞれ受信処理ＦＩＦＯエリア
ＹＦ１−ＲとＺＦ１−Ｒに同時に書き込んだ場合、それ
らが同時に受信処理要求を読み出す側のＰＭ（ＰＭ＃
１）の受信処理ＦＩＦＯエリアＸＦ１−Ｒに到着するの
で、これらの受信処理要求を全て蓄積するためにＦＩＦ
Ｏメモリを使用するからである。

【００２０】図１は、本発明の一実施例を示すプロセッ
サモジュールの内部構成図である。図１のプロセッサモ
ジュールは、図４におけるＰＭ１８−１〜１８−３に該
当している。なお、以下の説明では、３つのＰＭ内に存
在する構成要素の各々を識別する必要がないときには、
−１，−２，−３の各識別符号を省略する。例えば、個
々の分散共有メモリを指定しないときには、分散共有メ
モリ２１−１，２１−２，２１−３と記述することな
く、単に分散共有メモリ２１と記述することにする。図
１において、１６は分散共有メモリ２１上に配置された
メッセージバッファ（ＭＢ）、３０はプロセッサモジュ
ール（ＰＭ）１８内の各種装置を結合するためのプロセ
ッサバス、２２は分散メモリカップラで、分散共有メモ
リ２１に実装されているエリアへの書き込みアクセスが
あったとき、他のＰＭの分散共有メモリの同じアドレス
ロケーションにも書き替えデータを送信する機能、およ
び他のＰＭから書き替えデータを受信して、自ＰＭの分
散共有メモリへの書き込みを行う機能を有する。分散メ
モリカップラ２２は、以下の構成要素を含んでいる。先
ずバス信号デコーダ３１であり、これはプロセッサバス
３０の信号線上の信号を解読し、所属する分散共有メモ
リ２１への書き込みアクセスがあれば、信号線３２に
‘１’を出力して、転送制御部３３を起動する。転送制
御部３３は、分散メモリカップラ２２全体の制御を司る
部分であり、ここから内部ロジックに各種制御信号（図
示省略）を供給する。３４はモジュールＩＤ管理部であ
り、分散共有メモリ２１への書き込みデータをＰＭ間で
送受する際に必要な宛先プロセッサモジュールＩＤ（Ｐ
Ｍ ＩＤ）を記憶している。モジュールＩＤ管理部３４
の詳細については図６に示している。

【００２１】図１において、３５はパケット送信レジス
タであって、他のＰＭに転送する分散共有メモリアドレ
スや書き込みデータ等、または他のＰＭへの割り込み情
報等を記憶する。３６はパケット送信バッファであり、
パケット送信レジスタ３５からのデータを受け取り、他
のＰＭに転送するまでの一時待ち合わせ機能を有してい
る。３７はパケット受信バッファであり、他のＰＭから
転送されてきたデータを受け取り、パケット受信レジス
タ３８に渡すまでの一時待ち合わせの機能を有する。パ
ケット受信レジスタ３８は、他のＰＭから転送されてき
た情報を記憶するレジスタであり、パケット送信レジス
タ３５が送り出した内容と同じデータが記憶される。３
９はパケットデコーダであり、パケット受信レジスタ３
８内のデータをデコードして、分散共有メモリ２１内の
アドレスロケーションへの書き込み要求であれば、信号
線４０を介して転送制御部３３に分散共有メモリ書き込
みの実行を依頼する。また、デコードの結果が、他のＰ
Ｍからの割り込みであれば、信号線４１を介して割込み
制御部４２に割込み処理を依頼する。割込み制御部４２
は、信号線４３を経由してプロセッサ１９に割り込み要
求を行う。

【００２２】図１において、２３は分散メモリプロテク
タであって、分散共有メモリ２１に配置されたＭＢ（１
６）内のメッセージを不正なアクセスから保護するハー
ドウェア機構である。分散メモリプロテクタ２３は、カ
レントケーパビリティレジスタ（ＣＣＲ：Ｃurent Ｃa
pability Ｒegister)５１、ＭＣＲメモリ（ＭemoryＣa
pability Ｒegister Ｍemory)５０、比較器５２を含
んでいる。ＣＣＲ５１は、カレントケーパビリティを記
憶するレジスタである。カレントケーパビリティは、具
体的には、プロセッサ１９で実行中のアプリケーション
オブジェクト（プロセッサのユーザモードで実行される
オブジェクト）のＩＤを意味している。ＭＣＲメモリ５
０は、複数のＭＣＲ５３から構成され、各ＭＣＲ５３は
分散共有メモリ２１上の各ＭＢ１６対応に、メモリケー
パビリティを記憶する。メモリケーパビリティは、具体
的には、対応するＭＢ１６へのメモリアクセスが生じる
と、ＭＢアドレスを基に対応するＭＣＲ５３をＭＣＲメ
モリ５０の中から選択し、これを取り出す。比較器５２
は、選択されたＭＣＲ５３とＣＣＲ５１とを比較してメ
ッセージバッファへの正しいアクセスであるか否かを判
定し、不一致であれば不正アクセスであると判定する。
不正アクセスを検出した場合には、並行して行われてい
るＭＢ１６へのアクセスを中継し、信号線５４を介して
プロセッサ１９に緊急通通する。

【００２３】以下、分散メモリプロテクタ２３を、ＰＭ
１８−１内の送信オブジェクトからＰＭ１８−２内の受
信オブジェクトへのメッセージ通信に適用した場合の制
御手順について述べる。 （ａ）送信ＰＭ１８−１のカーネルは、送信オブジェク
トの実行を開始する前に、カレントケーパビリティレジ
スタＣＣＲ５１−１にカレントケーパビリティつまり送
信オブジェクトＩＤを設定する。 （ｂ）送信ＰＭ１８−１のカーネルは、分散共有メモリ
２１−１上に送信ＭＢ１６−１を捕捉した後、送信ＭＢ
１６−１対応のＭＣＲ５３−１にメモリケーパビリティ
を設定する。この時点のメモリケーパビリティは、ＭＢ
の捕捉を要求したオブジェクトのＩＤつまり送信オブジ
ェクトＩＤである。 （ｃ）送信プロセッサ１９−１から送信ＭＢ１６−１へ
のメモリアクセスがある度毎に、ＭＣＲ５３−１の中か
らＭＢアドレスを基に対応するＭＣＲ５３−１を１個選
択して、それをＣＣＲ５１−１と比較する。ＭＣＲ５３
−１とＣＣＲ５１−１のオブジェクトＩＤの値が等しい
ときには正しいアクセスであり、等しくないときには不
正アクセスであると判定する。 （ｄ）メッセージが受信ＰＭ１８−２の受信ＭＢ１６−
２に到着したと仮定する。受信ＰＭ１８−２のカーネル
は、受信オブジェクトの実行を開始する前に、ＣＣＲ５
１−２にカレントケーパビリティつまり受信オブジェク
トＩＤを設定する。 （ｅ）受信ＰＭ１８−２のカーネルは、受信ＭＢ１６−
２に対応するＭＣＲ５３−２に、メモリケーパビリティ
を設定する。この時点のメモリケーパビリティは、メッ
セージの宛先であるオブジェクトのＩＤつまり受信オブ
ジェクトＩＤである。

【００２４】（ｆ）受信プロセッサ１９−２から受信Ｍ
Ｂ１６−２へのメモリアクセスがある度毎に、比較器５
２−２によりＭＣＲ５３−２とカレントケーパビリティ
レジスタＣＣＲ５１−２内のオブジェクトＩＤの値を比
較し、等しければ正しいアクセス、等しくなければ不正
アクセスと判定する。 上記動作において、ＭＣＲ５３とＣＣＲ５１に、それぞ
れメモリケーパビリティとカレントケーパビリティが設
定されている期間（プロテクションウィンドウ開放期
間）は、ＭＢの所有権が付与された送信または受信オブ
ジェクトのみがそのＭＢをアクセスできる。プロテクシ
ョンウィンドウ開放期間中に、もし無関係のオブジェク
トがＭＢアクセスを行うと、ＭＣＲとＣＣＲのケーパビ
リティの不一致が生じて、不正アクセスであることが検
出される。プロテクションウィンドウ開放期間以外で
は、送信、受信オブジェクトも含めた全てのアプリケー
ションオブジェクトは、このＭＢにアクセスすることが
できないので、強固なメモリ保護が実現されることにな
る。なお、分散メモリプロテクタ２３は、プロセッサの
アプリケーションモード（またはユーザモード）でのＭ
Ｂアクセスで動作するが、カーネルモード（またはスー
パバイザモード）でのメモリアクセスは動作せず、無条
件にメモリアクセスを許容する。この理由としては、一
般にカーネルモードで実行されるプログラム（例えばカ
ーネル）は、アプリケーションオブジェクトに比較して
潜在バグの含有率が小さく、不正なメモリアクセスをす
る可能性が少ないからである。

【００２５】図８は、図１におけるモジュールＩＤ管理
部の内部構成図である。図８において、６０はモジュー
ルＩＤディレクトリであり、ＣＡＭ（ＣontentＡddress
able Ｍemory)セル部６１とデータメモリ部６２から構
成される。ＣＡＭとは、検索キーデータを入力して、こ
れと各ワード（ＣＡＭセル）の記憶データの内容を一斉
に比較照合して、指定された検索条件に合致した内容の
ＣＡＭセルを選択表示するメモリである。ＣＡＭセルの
各々には、『分散共有メモリページアドレス６３』が記
憶されている。分散共有メモリページアドレス６３は、
他のプロセッサモジュールと共用されているアドレスの
ページである。例えば、分散共有メモリ２１の連続エリ
アに配置された宛先ＰＭ対応のＭＢプールのページアド
レス、そのＭＢ管理マップのページアドレス、ディスク
リプタリングのページアドレス、宛先ＰＭ対応のＦＩＦ
Ｏ通信エリアのページアドレス等が設定される。図５〜
図７で説明したように、ＭＢ、ＭＢ管理マップ、ディス
クリプタリング、ＦＩＦＯ通信エリアは、それぞれ宛先
ＰＭ毎に異なるページに割り付けられている。一方、デ
ータメモリ部６２は、各ＣＡＭセルのワードに対応する
補助データを記憶するＲＡＭであり、分散共有メモリペ
ージアドレス６３を共有している宛先プロセッサモジュ
ールのＩＤ（宛先ＰＭ ＩＤ）６４を記憶している。

【００２６】ここで、ＭＢ管理マップ、ディスクリプタ
リングは、送信ＰＭ、受信ＰＭの両方から書き込みが行
えるようにするため、送信ＰＭのモジュールＩＤディレ
クトリ６０には、〔共有ページアドレス、受信ＰＭ Ｉ
Ｄ〕のペアが記憶され、受信ＰＭＭのモジュールＩＤデ
ィレクトリ６０には、〔送信側と同じ共有ページアドレ
ス、送信ＰＭ ＩＤ〕のペアが記憶される。このよう
に、各ＰＭのモジュールＩＤディレクトリ６０には、コ
ピーをしたい全てのＰＭのＰＭ ＩＤが登録されてい
る。図８の６５はキーレジスタであり、これはＣＡＭセ
ル部６１の内容と比較照合するための検索キーデータを
記憶する。６６はマスクレジスタであり、これはキーレ
ジスタ６５内の検索キーデータとＣＡＭセル部６１との
比較を行う場合に、比較しないビット位置を指定するた
めのレジスタである。６７はＣＡＭコマンドレジスタで
あり、ＣＡＭセル部６１に関する各種指令を記憶する。
６８は結果レジスタであり、これは検索した結果、一致
したＣＡＭセルの有無の表示、複数セル一致の有無の表
示、空きセルの有無の表示等を行う部分である。キーレ
ジスタ６５とＣＡＭセル部６１との比較照合の結果、一
致したＣＡＭを使用しなくても、よく知られているよう
にハッシングの技術とＲＡＭとを組み合わせて、ＣＡＭ
と同じような機能を実現することができる。

【００２７】図８に示すモジュールＩＤ管理部３４は、
以下のように動作する。分散共有メモリ２１への書き込
みアクセスがあると、そのアドレスがキーレジスタ６５
に格納され、そのページアドレスとＣＡＭセル部６１と
が比較される。一致したセルが検出されると、そのアド
レスが他のＰＭにより共用されていることを意味するの
で、データメモリ部６２から対応する宛先ＰＭ ＩＤ６
４を読み出し、これを分散共有メモリアドレスに付与し
た後、書き込みデータと合わせて送信パケットを作成
し、図１に示すパケット送信レジスタ３５に設定する。
パケット送信レジスタ３５からパケット送信バッファ３
６を経由してパケットを宛先ＰＭに送出する。受信側の
分散メモリカップラ２２では、パケット受信バッファ３
７で、他のＰＭから転送されてきたデータを受け取り、
パケット受信レジスタ３８に引き渡す。パケット受信レ
ジスタ３８では、受信したデータをデコードし、指定さ
れた分散共有メモリアドレスロケーションにデータを書
き込む。このようにして、送信側分散共有メモリから受
信側分散共有メモリにコピーが行われる。なお、送信側
分散共有メモリへの書き込みアクセスでは、受信側分散
共有メモリへのコピーアクセスの完了を待たずにアクセ
スを完了する。

【００２８】本実施例においては、あるＰＭから他のＰ
Ｍにポイントツーポイントでコピーを行う構成を基本と
して説明しているが、ポイントツーマルチポイントでコ
ピーを行うことも可能である。その場合には、モジュー
ルＩＤディレクトリ６０には１つの分散共有メモリペー
ジアドレス６３に対して、複数の宛先ＰＭ ＩＤ６４を
登録しておく。その結果、分散共有メモリへの１回の書
き込みに対して複数のパケットが生成され、それぞれ指
定されたＰＭにパケットが送信されるので、複数のＰＭ
の分散共有メモリにコピーを行うことができる。また、
同一の分散共有メモリページアドレス６３に対して、送
信側ＰＭのモジュールＩＤディレクトリ６０には、受信
側ＰＭ ＩＤを登録し、受信側ＰＭのモジュールＩＤデ
ィレクトリ６０には、送信側ＰＭ ＩＤを登録しておく
ことにより、分散共有メモリのエリアに送信側、受信側
のどちらから書き込んでも、互いに相手側の分散共有メ
モリにコピーを行う、つまり双方向通信を行うことがで
きる。

【００２９】図９は、図１におけるパケット送信レジス
タおよびパケット受信レジスタに共通のデータフォーマ
ット図である。ここでは、分散共有メモリアクセスタイ
プと割込みデータタイプの２種類のフォーマットを示し
ている。図９において、８０，９０は属性識別フィール
ドであり、‘０’ならば分散共有メモリアクセスタイプ
であることを示し、‘１’ならば割込みデータタイプで
あることを示す。分散共有メモリアクセスタイプの場合
には、モジュールＩＤ管理部３４が出力する『宛先ＰＭ
ＩＤ８１』，『分散共有メモリアドレス８２』，『書
込みデータ８３』，『書込み単位８４』の各フィールド
を含む。『書込み単位８４』フィールドは、書込みのデ
ータ幅、例えばバイト、ハーフワード（１６ビット）、
ロングワード（３２ビット）等を指定するものである。
一方、割込みデータタイプの場合には、モジュールＩＤ
管理部３４が出力する『宛先ＰＭ ＩＤ９１』，割込み
発生源を示す『送信モジュールＩＤ９２』，割込みの種
別を示す『割込み識別データ９３』，『書込み単位９
４』の各フィールドを含む。なお、宛先ＰＭ ＩＤ８
１，９１がある特定の値の場合には、放送型パケットと
して全てのＰＭでパケットを受信するように構成するこ
とが可能である。

【００３０】図１０、図１１、図１２は、本発明におい
て使用される各種のメッセージ通信のパターンと、その
処理の流れを示す説明図である。図１０はシステム内メ
ッセージ通信の場合である。図１０において、１２０は
送信オブジェクト、１２１は受信オブジェクト、１２２
はメッセージキュー、１２３は送信オブジェクト、１２
４は受信ディスクリプタリング、１２５はＩＯＣ配信オ
ブジェクト、１２６はメッセージキュー、１２７は受信
オブジェクトである。メッセージパターンは、以下のよ
うに分類される。 （ａ）システム内メッセージ通信・・・送信オブジェク
トと受信オブジェクトが同一マルチプロセッサシステム
（図１の１７）内に存在する場合である。システム内メ
ッセージ通信には、次の２通りのケースが存在する。 （ａ１）ＰＭ内通信・・送信オブジェクト１２０と受信
オブジェクト１２１が同一ＰＭ内に存在する場合であ
る。ＰＭ内通信の場合、カーネルは受信オブジェクト１
２１のメッセージキュー１２２のアドレスを知っている
ので、カーネルは、送信オブジェクト１２０から受信オ
ブジェクト１２１のメッセージキュー１２２に直接、メ
ッセージを登録することができる。受信オブジェクト１
２７はメッセージキュー１２６からメッセージを取り出
し、対応する処理を行う。 （ａ２）ＰＭ間通信・・送信オブジェクト１２３と受信
オブジェクト１２７が同一マルチプロセッサシステム１
７内の異なるＰＭに存在する場合である。ＰＭ間通信の
場合、送信オブジェクト１２３の存在するＰＭ（送信Ｐ
Ｍ）のカーネルからは、受信ＰＭ内の受信オブジェクト
１２７の制御情報（例えばメッセージキュー１２６のア
ドレス）が見えないので、直接、受信オブジェクト１２
７のメッセージキュー１２６にメッセージを登録するこ
とができない。そこで、送信ＰＭでは、送信カーネル
が、事前に知っている受信ディスクリプタリング１２４
にメッセージを登録し、受信ＰＭではＩＯＣ（Ｉnterob
ject Ｃommunication)配信オブジェクト１２５が、受
信ディスクリプタリング１２４を読出し、受信オブジェ
クト１２７のメッセージキュー１２６にメッセージを登
録する。

【００３１】図１１は、システム間メッセージ通信の場
合である。図１１において、１４０は送信オブジェク
ト、１４１は送信ディスクリプタリング、１４２はＩＮ
Ｃ送信処理オブジェクト、１４３はアダプタ送信ディス
クリプタリング、１４４はアダプタ受信ディスクリプタ
リング、１４６はメッセージキュー、１４７は受信オブ
ジェクト、１５０は送信オブジェクト、１５１は送信デ
ィスクリプタリング、１５２はＩＮＣ送信処理オブジェ
クト、１５３はアダプタ送信ディスクリプタリング、１
５４はアダプタ受信ディスクリプタリング、１５５はＩ
ＮＣ受信処理オブジェクト、１５６は受信ディスクリプ
タリング、１５７はＩＯＣ配信オブジェクト、１５８は
メッセージキュー、１５９は受信オブジェクトである。 （ｂ）システム間メッセージ通信・・送信オブジェクト
と受信オブジェクトが異なるマルチプロセッサシステム
１７に存在する場合である。送信システムあるいは受信
システムで中継ＰＭがない場合と、ある場合の２通りが
ある。 （ｂ１）中継ＰＭがない場合・・送信システムの場合、
送信オブジェクト１４０の存在するＰＭ（送信ＰＭ）
と、受信システム宛の通信リンクを持っているＰＭ（送
信中継ＰＭ）とが一致している場合である。受信側シス
テムの場合、通信リンクを終端しているＰＭ（受信中継
ＰＭ）と受信オブジェクト１４７の存在するＰＭ（受信
ＰＭ）とが一致している場合である。送信システムで送
信中継ＰＭがない場合、送信ＰＭでは、カーネルが送信
オブジェクト１４０からのメッセージを自ＰＭ内の送信
ディスクリプタリング１４１に登録する。ＩＮＣ（Inte
r-Ｓystem Ｃommunication)送信処理オブジェクト１４
２は、送信ディスクリプタリング１４１を読み出してネ
ットワークプロトコル処理を行い、アダプタ送信ディス
クリプタリング１４３にメッセージを登録する。ネット
ワークアダプタ２４は、アダプタ送信ディスクリプタリ
ング１４３からメッセージを取り出して、通信ネットワ
ーク２６に送出する。

【００３２】一方、受信システムで受信中継ＰＭがない
場合、通信ネットワーク２６からメッセージが送り届け
られ、受信ＰＭのネットワークアダプタ２４がメッセー
ジをアダプタ受信ディスクリプタリング１４４に登録す
る。そして、ＩＮＣ受信処理オブジェクト１４５がアダ
プタ用受信ディスクリプタリング１４４を読み出して、
同一ＰＭ内の受信オブジェクト１４７のメッセージキュ
ー１４６にメッセージを登録する。 （ｂ２）中継ＰＭがある場合・・送信システムの場合、
送信オブジェクト１５０の存在するＰＭ（送信ＰＭ）
が、受信システムへの通信リンクを持ち合わせておら
ず、他のＰＭ（送信中継ＰＭ）が持ち合わせている場合
である。また、受信システムの場合、通信リンクを終端
しているＰＭ（受信中継ＰＭ）と受信オブジェクト１５
９の存在するＰＭ（受信ＰＭ）とが異なる場合である。
送信システムでは、送信中継ＰＭがある場合、送信ＰＭ
のカーネルの送信処理プログラム１７が送信オブジェク
ト１５０からのメッセージを送信中継ＰＭ宛の送信ディ
スクリプタリング１５１に登録する。送信中継ＰＭのＩ
ＮＣ送信処理オブジェクト１５２は送信ディスクリプタ
リング１５１を読み出して、ネットワークプロトコル処
理を行ってアダプタ送信ディスクリプタリング１５３に
メッセージを登録する。ネットワークアダプタ２４はア
ダプタ送信ディスクリプタリング１５３からメッセージ
を取り出して通信ネットワーク２６に送出する。

【００３３】また、受信システムで受信中継ＰＭがある
場合、通信ネットワーク２６からメッセージが送り届け
られ、受信ＰＭのネットワークアダプタ２４がメッセー
ジをアダプタ受信ディスクリプタリング１５４に登録す
る。次に、受信中継ＰＭのＩＮＣ受信処理オブジェクト
１５５がアダプタ受信ディスクリプタリング１５４を読
み出し、最終宛先の受信ＰＭ宛の受信ディスクリプタリ
ング１５６にメッセージを登録し、受信ＰＭではＩＯＣ
（Ｉnterobject Ｃommunication)配信オブジェクト１
５７が受信ディスクリプタリング１５６を読み出し、受
信オブジェクト１５９のメッセージキュー１５８にメッ
セージを登録する。なお、図１１のシステム間メッセー
ジ通信の組み合わせパターンの数は、〔送信中継あり／
なし〕，〔受信中継あり／なし〕の合計４通りである。
図１２は、各アプリケーションオブジェクトに付与され
たオブジェクトＩＤのフォーマットを示す図である。図
１２において、１７０はオブジェクトＩＤ、１７１はそ
のオブジェクトが存在するマルチプロセッサシステムの
番号で、通信ネットワーク内で一意に識別可能なように
形成される。１７２はプロセッサモジュールＩＤ（ＰＭ
ＩＤ）で、マルチプロセッサシステム内で一意に識別
可能の値をとる。１７３はローカルＩＤであり、ＰＭ内
でオブジェクトを一意に識別するための番号である。

【００３４】図１３は、本発明における送信ディスクリ
プタと送信処理要求のメモリ配置例を示す図であり、図
１４は、送信処理要求のフォーマット図である。ＰＭ＃
１（１８−１）からＰＭ＃３（１８−３）宛の送信ディ
スクリプタリングを（ＸＤ１３−Ｓ，ＺＤ１３−Ｓ）の
ペアで、ＰＭ＃２（１８−２）からＰＭ＃３（１８−
３）宛の送信ディスクリプタリングを（ＹＤ２３−Ｓ，
ＺＤ２３−Ｓ）のペアで、ＰＭ＃３内の送信ディスクリ
プタリングをＺＤ３３−Ｓで、それぞれ表わす。また、
ＰＭ＃１（１８−１）上のＰＭ＃３（１８−３）宛の送
信処理ＦＩＦＯをＸＦ３−Ｓで、ＰＭ＃２（１８−２）
上のＰＭ＃３（１８−３）宛の送信処理ＦＩＦＯをＹＦ
３−Ｓで、ＰＭ＃３（１８−３）内の送信処理ＦＩＦＯ
をＺＦ３−Ｓで、それぞれ表わす。このように、図１３
はシステム間ＰＭ中継通信の送信システムの例を示して
いる。送信オブジェクトはＰＭ＃１（１８−１）、ＰＭ
＃２（１８−２）、ＰＭ＃３（１８−３）に分散してお
り、送信中継ＰＭはＰＭ＃３（１８−３）とする。各Ｐ
Ｍの送信オブジェクトから合計５個のメッセージＭｉ
（ｉ＝１，２，・・５）がＰＭ＃３（１８−３）を経由
して通信ネットワークに送出されるものとし、各メッセ
ージの送信ディスクリプタを順にＱ１，Ｑ２，Ｑ３，Ｑ
４，Ｑ５と表わし、それらに対応する送信処理要求を順
にＱＡ１，ＱＡ２，ＱＡ３，ＱＡ４，ＱＡ５と表わす。
送信ディスクリプタの構造は、後述の図１５（ｃ）に示
されている。送信処理要求のデータ構造（フォーマッ
ト）は、図１４に示すように、要求元プロセッサモジュ
ールＩＤ（ＰＭ ＩＤ）１７５と、送信ディスクリプタ
へのポインタ１７６から構成されている。送信要求は、
次のように伝達される。先ず、ＰＭ＃１（１８−１）で
メッセージＭ１の送信要求が発生すると、ＰＭ＃１（１
８−１）ではＰＭ＃３（１８−３）宛送信ディスクリプ
タリングＸＤ１３−Ｓに送信ディスクリプタＱ１を登録
し、次にＰＭ＃３宛送信処理ＦＩＦＯエリアＸＦ３−Ｓ
に送信処理要求ＱＡ１を登録する。これらが分散メモリ
カップラ２２により、それぞれＰＭ＃３上の送信ディス
クリプタリングＺＤ１３−ＳとＰＭ＃３上の送信処理要
求ＦＩＦＯエリアＺＦ３−Ｓにコピーされる。

【００３５】次に、２番目のメッセージＭ２の送信要求
がＰＭ＃３（１８−３）内で発生したと仮定すると、Ｐ
Ｍ＃３（１８−３）内の送信ＭＢディスクリプタリング
ＺＤ３３−Ｓに送信ディスクリプタＱ２を、ＰＭ＃３
（１８−３）宛送信処理ＦＩＦＯエリアＺＦ３−Ｓに送
信処理要求ＱＡ２を登録する。この場合には、ＰＭ内通
信であるため、他のＰＭへのコピーは行われない。な
お、送信処理ＦＩＦＯエリアＺＦ３−ＳはＦＩＦＯメモ
リ構造であるため、最初に登録されたＱＡ１が保存され
たままＱＡ２が追加登録される。次に、３番目のメッセ
ージＭ３の送信要求がＰＭ＃２（１８−２）で発生した
ものとすると、ＰＭ＃２（１８−２）上のＰＭ＃３宛送
信ＭＢディスクリプタリングＹＤ２３−Ｓに送信ディス
クリプタＱ３がＰＭ＃３宛送信処理ＦＩＦＯエリアＹＦ
３にＱＡ３が登録される。それらが、それぞれＰＭ＃３
（１８−３）上の送信ＭＢディスクリプタリングＺＤ２
３−ＳとＰＭ＃３上の送信処理要求ＦＩＦＯエリアＺＦ
３−Ｓにコピーされる。送信処理ＦＩＦＯエリアＺＦ３
−ＳにはＱＡ１，ＱＡ２が保存されたまま、ＱＡ３が追
加登録される。送信ディスクリプタＱ４，Ｑ５について
も、全く同じように、Ｑ５までの要求登録が終了した段
階では、図１３のような記憶状態となる。

【００３６】この段階において、ＰＭ＃３（１８−３）
のＩＮＣ送信処理オブジェクトは、ＰＭ＃３（１８−
３）宛の送信処理ＦＩＦＯエリアＺＦ３−Ｓを読み出す
と、入力した順に送信処理要求ＱＡ１，ＱＡ２，ＱＡ
３，ＱＡ４，ＱＡ５を取り出すことができる。要求の中
に記載されている送信元ＰＭ ＩＤ１７５と送信ディス
クリプタポインタ１７６から、対応する送信ディスクリ
プタＱｉの所在位置を求め、送信ディスクリプタＱｉか
らメッセージバッファの所在位置を求めることができ
る。このようにして、メッセージＭｉを順に処理してネ
ットワークに送出していく。ここで、従来のポーリング
方式では、３つの送信ディスクリプタリングＺＤ１３−
Ｓ、ＺＤ２３−Ｓ、ＺＤ３３−Ｓを順にポーリングして
送信要求の有無をチェックしており、処理要求の有無に
かかわらず、全ての送信ディスクリプタリングを見る必
要があった。そのため、読み出しても送信要求が見つか
らない空振りが生じることがあり、その結果、処理のオ
ーバヘッドが大きかった。これに対して本実施例では、
ＰＭ＃３（１８−３）で自ＰＭ宛送信処理ＦＩＦＯエリ
アＺＦ３−Ｓを周期的に読み出すだけで発生した送信要
求を取り出すことができ、無駄な空振りが生じることが
ないので、極めて処理効率が高い。また、ＰＭ＃１（１
８−１）から送信処理ＦＩＦＯエリアＸＦ３−Ｓを経由
した送信処理ＦＩＦＯエリアＺＦ３−Ｓへの登録と、Ｐ
Ｍ＃２（１８−２）から送信処理ＦＩＦＯエリアＹＦ３
−Ｓを経由した送信処理ＦＩＦＯエリアＺＦ３−Ｓへの
登録が同時に発生しても、送信処理ＦＩＦＯエリアＺＦ
３−ＳのＦＩＦＯメモリの構造により、登録要求が直列
化されて全て蓄積されていくため、マルチプロセッサ間
の競合処理を行う必要がなく、処理オーバヘッドは極め
て軽減される。なお、図１３では、送信要求の場合を例
に説明しているが、受信要求の場合にも全く同じよう
に、自ＰＭ宛の受信要求を指定された受信処理ＦＩＦＯ
エリアから読み出すため、発生した受信要求のみを効率
よく検出できる。

【００３７】図１５および図１６は、本発明で使用され
る各種データ構造を示す図である。図１５（ａ）はメッ
セージバッファ（ＭＢ）１８０のデータ構造であり、Ｎ
ＥＸＴＭＰ１８１は受信オブジェクト宛のメッセージを
リスト構造で接続するためのポインタ、ＳＩＤ１８２は
このメッセージの送信元である送信オブジェクトのＩ
Ｄ、ＲＩＤ１８３はこのメッセージの宛先である受信オ
ブジェクトのＩＤ、ＳＩＺＥ１８４はメッセージ本体
（ＢＯＤＹ）１８６のサイズを表わしている。また、Ａ
ＴＴＲ１８５はこのメッセージの付属属性を表示したフ
ィールド、ＢＯＤＹ１８６はメッセージの中味を示すフ
ィールドである。ＭＢ１８０の先頭アドレスは、ＭＢＡ
２０２として付与される。各ＭＢは固定長であり、前述
のように宛先ＰＭ ＩＤが同じであるＭＢ群が分散共有
メモリ２１の連続するエリアに割り付けられて１つのＭ
Ｂプールを構成している。各ＭＢプール対応にＭＢ管理
マップが存在する。このＭＢ管理マップは、ＭＢプール
内のＭＢ数に応じたＭＢ管理マップエントリから構成さ
れる。

【００３８】図１５（ｂ）はＭＢ管理マップエントリＶ
１９０の構造を示しており、Ｖ＝０の場合には、対応す
るＭＢが『未使用』の状態であり、Ｖ＝１の場合には、
対応するＭＢが『使用中』の状態を表わしている。ＭＢ
が１つ与えられると、その先頭アドレスＭＢＡ２００の
値から、対応するＭＢ管理マップエントリＶ１９０のア
ドレスが簡単に計算で求められるように構成される。同
じように、各宛先ＰＭ対応ＭＢプール毎に送信ディスク
リプタリングと受信ディスクリプタリングが１つずつ存
在して、両者を合わせてディスクリプタリングと呼ぶ。
図１４で説明したように、送信ディスクリプタリングは
他のシステムへのメッセージ制御情報を記憶し、受信デ
ィスクリプタリングは他のシステムから、あるいはシス
テム内の他ＰＭからのメッセージ制御情報を記憶する。
ディスクリプタリングの各エントリ（ディスクリプタ）
はＭＢの各々に対応している。図１５（ｃ）は、ディス
クリプタ２００の構造を示したものであって、２０１は
論理リンク番号で、対応するＭＢ上のメッセージを通信
ネットワーク２６経由で他のシステムに転送する場合に
使用する通信リンクの識別番号である。２０２は対応す
るＭＢの先頭アドレスＭＢＡを記憶するフィールドで、
図１５（ａ）で示したＭＢＡ２０２と同一である。２０
３は実行権を表わす情報であり、実行権＝『ＥＮＱ』で
あるならば、ディスクリプタリングにディスクリプタを
登録できる状態（エンキュー）にあることを示してお
り、実行権＝『ＤＥＱ』であれば、ディスクリプタリン
グからそのディスクリプタを取り出せる状態（デキュ
ー）にあることを示している。

【００３９】図１５（ｄ）はアプリケーションオブジェ
クトの実行に必要な各種の制御データを記憶するオブジ
ェクトコントロールブロック（ＯＣＢ）の構造を示した
もので、ＯＣＢＡ２１１はＯＣＢの先頭アドレスを示す
ポインタ、ＮＥＸＴＯＰ２１２はＯＣＢをレディキュー
にリンクする時のポインタ、ＭＳＧＰ２１３はオブジェ
クト宛のメッセージを記憶しているＭＢのアドレスを示
す。ＳＴＡＴＵＳ２１４は、オブジェクトの実行状態を
示すフィールドであり、送受信オブジェクト間の同期制
御に使用される。その他の制御２１５は、その他の制御
フィールドである。図１６では、プロセッサ１９実行待
ちのＯＣＢを登録したレディキューの構造と、各種制御
データ構造との関係を示している。ＲＥＡＤＹＰ２２０
で示されるレディキューに２つのＯＣＢ（ＯＣＢｉ２２
１，ＯＣＢｊ２２２）が登録されており、ＯＣＢｉ２２
１は２個のメッセージを受信し、ＯＣＢｊ２２２は３個
のメッセージを受信している状態にある例を示してい
る。

【００４０】図１７は、システムルーチングテーブルと
ＰＭルーチングテーブルの構造図である。受信オブジェ
クトＩＤ（ＲＩＤ）（図１５の１８３）の値を基にし
て、メッセージをシステム内のどのＰＭを経由して送受
信するかを指定するルーチングテーブルであって、本実
施例では、システムルーチングテーブル２４９とＰＭル
ーチングテーブル２８９から構成され、それぞれ各ＰＭ
のローカルメモリ２０に記憶されている。システムルー
チングテーブル２４９の各エントリは、システムＩＤフ
ィールド２５０、システム通信モードフィールド２５
１、通信リンクフィールド２５２、送信中継ＰＭフィー
ルド２５３から構成されている。システムＩＤフィール
ド２５０に『自システムＩＤ２６０』が登録されている
エントリの場合には、そのエントリのシステム通信モー
ドフィールド２５１は、『システム内通信２６１』と表
示されている。一方、システムＩＤフィールド２５０に
『他システムＩＤ２７０』が登録されているエントリの
場合には、そのエントリのシステム通信モードフィール
ド２５１は『システム間通信２７１』と表示され、通信
リンクフィールド２５２には、他システムに結合されて
いる通信リンクの『通信リンクＩＤ２７２』が登録され
ている。また、送信中継ＰＭフィールド２５３には、通
信リンクＩＤ２７２に対応する通信リンクを収容してい
る『送信中継ＰＭのＩＤ２７３』を記憶している。ある
マルチプロセッサシステム１７が、他のＫ個のマルチプ
ロセッサシステムと接続されている場合には、システム
ルーチングテーブル２４９のエントリ総数は（１＋Ｋ）
個となる。

【００４１】ＰＭルーチングテーブル２８９は、ＰＭ
ＩＤフィールド２９０、ＰＭ通信モードフィールド２９
１、ＭＢ管理マップアドレスフィールド２９２から構成
される。ＰＭ ＩＤフィールド２９０に『自ＰＭ ＩＤ
３００』が登録されているエントリの場合には、そのエ
ントリのＰＭ通信モードフィールド２９１には『ＰＭ内
通信３０１』と記述されており、ＭＢ管理マップアドレ
スフィールド２９２には『ＰＭ内通信ＭＢ管理マップベ
ースアドレス３０２』が登録されている。また、ＰＭ
ＩＤフィールド２９０に、『他ＰＭ ＩＤ３１０』が登
録されているエントリの場合には、ＰＭ通信モードフィ
ールド２９１には『ＰＭ間通信３１１』と記述されてお
り、ＭＢ管理マップアドレスフィールド２９２には、そ
のＰＭＩＤに対応する『ＰＭ間通信ＭＢ管理マップベー
スアドレス３１２』が登録されている。各フィールドの
詳細な使用方法は後述する。なお、あるマルチプロセッ
サシステム１７がＪ個のＰＭから構成されている場合に
は、ＰＭルーチングテーブルのエントリ総数はＪ個であ
る。

【００４２】図１８は、本発明におけるシステム内ＰＭ
内通信のタイムチャートであり、図１９は同じくシステ
ム内ＰＭ間通信のタイムチャートであり、図２０はシス
テム間ＰＭ無中継通信のタイムチャートであり、図２１
はシステム間ＰＭ中継通信のタイムチャートである。な
お、図１８〜図２１のプロセッサの実行ステップのう
ち、太い罫線で示されたステップ（例えば、図１８のス
テップＳ１００）はプロセッサのスーパバイザモードで
実行している部分であり、これに対して細い罫線で示さ
れたステップ（例えば、図１８のステップＳ１０２）は
プロセッサのユーザモードで実行している部分である。
図２２〜図３２は、アプリケーション（ＡＰＬ）オブジ
ェクトからの要求により、カーネル自身のプログラムあ
るいはカーネルが起動するプログラムのフローチャート
であって、いずれも全てプロセッサのスーパバイザモー
ドで実行される。図２２は、カーネルの一部であって、
アプリケーション（ＡＰＬ）オブジェクトの起動および
終了処理を行うプログラムのフローチャートである。ま
た、図２３および図２４は、ＭＢ捕捉処理プログラムお
よびＭＢ解放処理プログラムの各フローチャートであっ
て、ＡＰＬオブジェクトからの要求により起動される。
また、図２５および図２６は、送信処理および受信処理
プログラムのフローチャートであり、これらもＡＰＬオ
ブジェクトからの要求により起動される。

【００４３】図２７および図２８は、送信ディスクリプ
タリング、受信ディスクリプタリング、アダプタ送信デ
ィスクリプタリング、アダプタ受信ディスクリプタリン
グに共通なエンキュー処理（各ディスクリプタリングに
エントリを登録する処理）およびデキュー処理（各ディ
スクリプタリングからエントリを削除する処理）のプロ
グラムのフローチャートである。図２７（ａ）はディス
クリプタリングの一般的な論理構造を示す図、図２７
（ｂ）はエンキュー処理のフローチャート、図２８はデ
キュー処理のフローチャートである。図２７（ａ）にお
いて、４００はリードポインタ（ＲＰ）であり、ディス
クリプタリングからエントリを取り出す場合（デキュー
処理）のエントリ読み出しアドレスを指定する。４０１
はライトポインタ（ＷＰ）であり、ディスクリプタリン
グにエントリを登録する場合（エンキュー処理）のエン
トリ書き込みアドレスを指定する。各エントリは実行権
フィールド４０３と、処理要求内容を記憶するディスク
リプタアイテムフィールド４０４に分割される。ディス
クリプタアイテムフィールド４０４は、ディスクリプタ
リングの種類（例えば、送信ディスクリプタリングか／
アダプタ送信ディスクリプタリングかの違い）に依存し
て内容が変わることがある。実行権フィールド４０３
は、そのエントリにアクセスする主体がエンキュー側に
あるか／デキュー側にあるかを指定するもので、『ＥＮ
Ｑ』と表わされているときには新しいエントリを登録し
てもよいことを意味し、『ＤＥＱ』の表わされていると
きには登録されているエントリを取り出してもよいこと
を意味する。エンキュー側はエントリを登録する毎にＷ
Ｐ４０１をインクリメントし、次のエンキュー位置を知
らせる。また、デキュー側はエントリを取り出す毎にＲ
Ｐ４００をインクリメントし、次のデキュー位置を知ら
せる。

【００４４】図２７にエンキュー処理，図２８にデキュ
ー処理の各フローが示される。エンキュー処理では、ス
テップ４２０で、ＷＰ４０１で示されるエントリの実行
権フィールド４０３が『ＥＮＱ』と表示されているか否
かをテストする。もし、ＥＮＱと表示されているなら
ば、新しいエントりを登録してもよいことを意味するの
で、ステップ４２１でそのディスクリプタアイテムフィ
ールド４０４に新エントリ情報を書き込み、ステップ４
２２でそのエントリの実行権フィールド４０３を『ＤＥ
Ｑ』に書き替える。ステップ４２３では、このエントリ
の登録によりディスクリプタリングの最後に到達したか
否かをテストする。到達していなければ、ステップ４２
４でＷＰ４０１をインクリメントし、次のエンキュー位
置を設定する。ディスクリプタリングの最後に到達して
いれば、ステップ４２５でＷＰ４０１の値をディスクリ
プタリングのベースアドレスにセットすることにより、
ディスクリプタリングをサイクリックに使用する。ステ
ップ４２０で実行権フィールド＝『ＤＥＱ』と表示され
ているときには、これはディスクリプタリング４０２に
前回登録したエントリがデキュー側により未だ読み出さ
れずに残っていることを示すので、ステップ４２６でデ
ィスクリプタリングオーバフローのエラー処理を実行す
る。

【００４５】一方、デキュー処理では、ステップ４３０
でＲＰ４００で示されるエントリの実行権フィールド４
０３が『ＤＥＱ』と表示されているか否かをテストす
る。もし、ＤＥＱと表示されていれば、エントリが登録
されており、そのエントリを取り出してもよいことを意
味するので、ステップ４３１でそのディスクリプタリン
グアイテムフィールド４０４からディスクリプタを取り
出し、ステップ４３２でその実行権フィールド４０３を
『ＥＮＱ』に書き替える。ステップ４３３では、このエ
ントリがディスクリプタリングの最後に登録されていた
ものか否かをテストする。ディスクリプタリング４０２
の最後でなければ、ステップ４３４でＲＰ４００をイン
クリメントし、次のデキュー位置を知らせて、ステップ
４３５で取り出したディスクリプタエントリを呼び出
し、元に渡す。ディスクリプタリングの最後であれば、
ステップ４３６でＲＰ４００の値をディスクリプタリン
グのベースアドレスにセットすることにより、ディスク
リプタをサイクリックに使用する。ステップ４３０で実
行権フィールド＝『ＥＮＱ』と表示されていれば、これ
はディスクリプタリングで前回のサイクルエントリを削
除してから、エンキュー側により未だ新しくエントリが
登録されていないことを示しているので、何もせず、リ
ターンする。

【００４６】図２９は、ＩＯＣ配信処理プログラムのフ
ローチャートである。ＩＯＣ配信プログラムは、定期的
に自ＰＭ宛の受信処理ＦＩＦＯ通信エリア（図５〜図７
参照）を読み出し、他のＰＭから受信処理要求が送られ
てきたか否かをチェックする。図３０は、ＩＮＣ送信処
理プログラムのフローチャートである。また、図３１お
よび図３２は、ＩＮＣ受信処理プログラムのフローチャ
ートである。以下、図１８〜図３３を参照しながら、実
施例の動作を説明する。図１０および図１１に示した分
類に従って、次の４つのメッセージ通信のケースについ
て詳述する。 （ケース１）システム内ＰＭ内通信 （ケース２）システム内ＰＭ間通信 （ケース３）システム間中継ＰＭなしの通信（システム
間ＰＭ無中継通信） （ケース４）システム間中継ＰＭありの通信（システム
間ＰＭ中継通信）

【００４７】（ケース１）システム内ＰＭ内通信 （ａ）送信側の処理 プロセッサモジュール（ＰＭ）１８−１内の送信オブジ
ェクトから同じＰＭ（１８−１）内の受信オブジェクト
にメッセージを転送する場合を考える。送信オブジェク
トと受信オブジェクトは互いに非同期で実行されるの
で、その実行順序は種々のケースが考えられるが、ここ
では簡単のために送信オブジェクトが受信オブジェクト
よりも先に実行される図１８のケースを仮定する。図１
８において、Ｓ１００はＡＰＬオブジェクト起動、Ｓ１
０１はＭＢ捕捉、Ｓ１０２はメッセージ書込み、Ｓ１０
３は送信処理、Ｓ１０４はＡＰＬオブジェクト終了であ
る。また、Ｓ１１０はＡＰＬオブジェクト起動、Ｓ１１
１は受信処理、Ｓ１１２はメッセージ読出し、Ｓ１１３
はＭＢ解放、Ｓ１１４はＡＰＬオブジェクト終了であ
る。 「ステップＳ１００」カーネルは、ステップＳ１００
で、アプリケーション（ＡＰＬ）オブジェクトを実行さ
せる準備を行う。ＡＰＬオブジェクトとは、ユーザモー
ドで動作するアプリケーションプログラムのことであ
る。ステップＳ１００の『ＡＰＬオブジェクト起動』の
内容は、図２２に示すように、ステップ３３０でレディ
キュー（実行可能なオブジェクトコントロールブロック
（ＯＣＢ）（図１６の２１０）がリスト構造でリンクさ
れたもの（図１６参照）から、次に実行すべきＡＰＬオ
ブジェクトのＯＣＢ２１０を取り出す。次に、ステップ
３３１で、ＡＰＬオブジェクトに与えられているオブジ
ェクトＩＤ（図１２の１７０）を分散メモリプロテクタ
２３内のカレントコントロールレジスタ（ＣＣＲ）５１
に設定する。このタイミングは、図１８のタイミングｔ
１００により示される。次に、図２２のステップ３３２
で、必要な情報をＯＣＢ２１０からプロセッサ１９にロ
ードして、ＡＰＬオブジェクトの実行を開始する。ここ
では、ＡＰＬオブジェクトが送信オブジェクトであるた
め、送信オブジェクトの実行が開始される。

【００４８】「ステップＳ１０１」送信オブジェクト
が、ＭＢの捕捉をカーネルに要求すると、カーネルは図
２３のＭＢ捕捉処理プログラムを実行する。図２３のス
テップ３５０で、メッセージを受信する受信オブジェク
トのＩＤ（図１２のＲＩＤ１７０）内のシステムＩＤフ
ィールド１７１を取り出す。この値をシステムルーチン
グテーブル（図１７の２４９）のシステムＩＤフィール
ド２５０の各エントリと比較し、一致したエントリのシ
ステム通信モードフィールド２５１、通信リンクフィー
ルド２５２、送信中継ＰＭフィールド２５３の値を取り
出す。ここでは、同一システム内の同一ＰＭ内通信であ
るため、『自システムＩＤ』と記されたエントリ２６０
と一致し、そのシステム通信モードフィールド２５１
は、『システム内通信』２６１と表示されているため、
ステップ３５１からステップ３５２に進む。ステップ３
５３では、受信オブジェクトＩＤ（ＲＩＤ）のＰＭ Ｉ
Ｄフィールド１７２をＰＭルーチングテーブル（図１７
の２８９）のＰＭ ＩＤフィールド２９０の各エントリ
と比較して、一致したエントリのＰＭ通信モードフィー
ルド２９１と、ＭＢ管理マップアドレスフィールド２９
２の値を取り出す。ここでは、同一システム内の同一Ｐ
Ｍ内通信であるため、『自ＰＭ ＩＤ』と記述されたエ
ントリ３００と一致し、その結果、『ＰＭ内通信３０
１』と表示されたＰＭ通信モードフィールドと、『ＰＭ
内通信ＭＢ管理マップベースアドレス３０２』と表示さ
れたＭＢ管理マップアドレスフィールドとを取り出す。

【００４９】ステップ３５３では、選択したＭＢ管理マ
ップアドレス２９２で指定されたＭＢ管理マップを検索
し、空きを表示しているＭＢ管理マップエントリを検出
し、それに対応する空きＭＢアドレスＭＢＡ（図１５の
２０２）を求め、そのＭＢ管理マップエントリ（図１５
の１９０）を『使用中』に書き替える。ＭＢ管理マップ
エントリとＭＢとは、１対１に対応するように構成され
ており、ＭＢ管理マップエントリアドレスからＭＢアド
レスを求めることができるとともに、逆にＭＢアドレス
からもＭＢ管理マップエントリアドレスを求めることが
できる。ここでは、ＰＭ内通信用ＭＢ管理マップが選択
され、その中の適当な空きＭＢ、例えば図５、図７のＭ
Ｂ（Ｘ１１−２）が選択される。ステップ３５３の最後
で、ＭＢ（Ｘ１１−２）に対応するＭＢ管理マップエン
トリ（ＸＭ１１−２）が図１７のタイミングｔ１０１で
『使用中』に書き替えられる。続いて、ステップ３５４
で、ＭＢ（Ｘ１１−２）に対応するメモリケーパビリテ
ィレジスタ（ＭＣＲ）５３のアドレスを求め、ＭＣＲ５
３に、このＭＢへのアクセス権を獲得したオブジェク
ト、つまり送信オブジェクトのＩＤ（ＳＩＤ）が図１８
のタイミングｔ１０２で登録される。以上が、図１８の
ステップＳ１０１のＭＢ捕捉処理である。

【００５０】「ステップＳ１０２」送信オブジェクト
は、図１８のステップＳ１０２で、作成したメッセージ
をＭＢ（Ｘ１１−２）にタイミングｔ１０３で書き込
む。図１８のプロテクションウィンドウ開放期間ｗ１
は、ＣＣＲ５１とＭＣＲ５３の両方に値が設定されてい
る区間で、ＭＣＲとＣＣＲとが指定しているＡＰＬオブ
ジェクト（送信オブジェクト）は、ＭＢ（Ｘ１１−２）
にアクセスすることができるが、他のＡＰＬオブジェク
トはアクセスすることができなくなり、ＭＢに対する強
固な保護が実現される。

【００５１】「ステップＳ１０３」送信オブジェクトが
ステップＳ１０３でカーネルに送信処理を依頼すると、
カーネルは、図２５の送信処理プログラムを実行する。
先ず、図２５のステップ３８０でＭＢ（Ｘ１１−２）に
対応するＭＣＲ５３を図１８のタイミングｔ１０４でク
リアする。これで、図１８のプロテクションウィンドウ
開放期間ｗ１が終了するため、以後、カーネル以外はＭ
Ｂ（Ｘ１１−２）にアクセスできなくなる。次に、図２
５のステップ３８１で、通信モードをチェックする。こ
こでは、『システム内ＰＭ内通信』であるため、ステッ
プ３８２で受信オブジェクトのＯＣＢ２１０のメッセー
ジキューにＭＢ（Ｘ１１−２）のアドレス（ＭＢＡ）を
登録する。続いて、ステップ３８３でＯＣＢ２１０のＳ
ＴＡＴＵＳフィールド（図１５の２１４）が『送信側実
行待ち』となっているか否かをテストする。『送信側実
行待ち』は、受信オブジェクトが送信オブジェクトより
も先に実行された結果、受信オブジェクトが送信オブジ
ェクトの実行を待っている状態を表わす。このケースで
は、送信オブジェクトが受信オブジェクトよりも先に実
行されるため、ステップ３８３は『ＮＯ』となって、ス
テップ３８５でＯＣＢ２１０のＳＴＡＴＵＳフィールド
２１４を『受信側実行待ち』と設定して、受信オブジェ
クトの実行を待つ状態になったことを表示する。

【００５２】「ステップＳ１０４」ステップＳ１０４で
は、カーネルがＡＰＬオブジェクト終了処理を起動す
る。ＡＰＬオブジェクト終了処理プログラムは、図２２
に示されており、ステップ３４０でカレントケーパビリ
ティレジスタＣＣＲ５１の値を図１８のタイミングｔ１
０５でクリアする。続いて、図２２のステップ３４１で
送信オブジェクトの再開に必要な情報をＯＣＢ２１０に
退避することにより、送信オブジェクトの処理を完了す
る。

【００５３】（ｂ）受信側の処理 「ステップＳ１１０」図１８のステップＳ１１０におい
て、カーネルは次に実行すべきオブジェクトして受信オ
ブジェクトを選択し、図２２のＡＰＬオブジェクト起動
プログラムを実行する。送信オブジェクトの場合と同じ
ように、図１８のタイミングｔ１１０で受信オブジェク
トＩＤ（ＲＩＤ）（図１５の１８３）をカレントケーパ
ビリティレジスタ（ＣＣＲ）５１に設定する。

【００５４】「ステップＳ１１１」受信オブジェクトの
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図２６の受信処理プログラ
ムを起動する。図２６のステップ３９０では、受信オブ
ジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド２１
４が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。『受信側実行待ち』は、送信オ
ブジェクトが受信オブジェクトよりも先に実行された結
果、受信オブジェクトの実行を待っている状態である。
また、『同期完了』は、受信オブジェクトが送信オブジ
ェクトよりも先に実行されたため、途中で休止し、その
後、送信オブジェクトが実行されたことにより、送受信
間の同期がとれた状態を示している。このケースでは、
図１８のステップＳ１０３で、ＳＴＡＴＵＳフィールド
２１４を『受信側実行待ち』と設定しているため、ステ
ップ３９０は『ＹＥＳ』となる。これは、メッセージが
送信側から既に届いているため、直ちにメッセージキュ
ーにつながっているメッセージをキューから外し、その
ＭＢ（Ｘ１１−２）のアドレスを取り出す。続いて、ス
テップ３９２では、このＭＢアドレスに対応するＭＣＲ
５３に受信オブジェクトＩＤ（ＲＩＤ）１８３を設定す
る。このタイミングは、図１８のタイミングｔ１１１で
示される。これにより、ＣＣＲ５１とＭＣＲ５３の両方
に受信オブジェクトＩＤ（ＲＩＤ）１８３が設定された
ので、以後、図１８のプロテクションウィンドウ開放期
間（ｗ２）中は、ＭＢ（Ｘ１１−２）が受信オブジェク
ト以外のＡＰＬオブジェクトからアクセスできないよう
にプロテクトされることになる。

【００５５】「ステップＳ１１２」受信オブジェクト
が、ＭＢ（Ｘ１１−２）からタイミングｔ１１２でメッ
セージを読み出して、対応する処理を行う。

【００５６】「ステップＳ１１３」受信オブジェクト
は、ステップＳ１１３でカーネルにＭＢ解放を依頼す
る。カーネルは、図２４のＭＢ解放処理プログラムを起
動する。図２４において、ステップ３６０で、ＭＢ（Ｘ
１１−２）に対応するＭＣＲ５３をクリアする。このタ
イミングは、図１８のタイミングｔ１１３に示されてい
る。続いて、図２４のステップ３６１でＭＢ（Ｘ１１−
２）に対応するＭＢ管理マップエントリ（ＸＭ１１−
２）を『空き』に更新する。このタイミングは、図１８
のタイミングｔ１１４に示されている。ＭＢ管理マップ
エントリを『空き』に更新すると、以後は、いつでもこ
のＭＢ（Ｘ１１−２）を再利用することが可能となる。

【００５７】「ステップＳ１１４」カーネルがＡＰＬオ
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ（ＣＣＲ）５１の値を図１８のタイミングｔ
１１５でクリアする。ＡＰＬオブジェクト終了処理は、
図２２に示されており、送信オブジェクトの場合と同じ
であるため説明を省略する。以上のように、システム内
ＰＭ内通信の場合には、送信オブジェクトと受信オブジ
ェクトがユーザレベルで直接アクセスできる分散共有メ
モリエリアに、メッセージバッファを確保することによ
り、メッセージバッファ間の無駄なコピーを避けること
ができるので、効率的なメッセージ通信が可能となる。

【００５８】（ケース２）システム内ＰＭ間通信 （ａ）送信ＰＭ側の処理 マルチプロセッサシステム１７ー１内のプロセッサモジ
ュール（ＰＭ）１８−１内の送信オブジェクトから、Ｐ
Ｍ１８−２内の受信オブジェクトにメッセージを転送す
る場合を仮定する。さらに、図１９に示すように、送信
オブジェクトの実行終了前に受信オブジェクトの実行が
開始される場合を考える。使用するＭＢを図５のＸ１２
−１とすると、対応するＭＢ管理マップエントリはＸＭ
１２−１となる。また、この処理依頼内容の詳細は受信
ディスクリプタリングＸＤ１２−Ｒに、受信処理要求は
受信ＰＭ１８−２宛の受信処理ＦＩＦＯエリアＸＦ２−
Ｒに登録されるものとする。処理の流れを、図１９の各
ステップに従って説明する。Ｓ１２０はＡＰＬオブジェ
クト起動、Ｓ１２１はＭＢ捕捉、Ｓ１２２はメッセージ
書込み、Ｓ１２３は送信処理、Ｓ１２４はＡＰＬオブジ
ェクト終了である。また、Ｓ１１０はＡＰＬオブジェク
ト起動、Ｓ１１１は受信処理、Ｓ１１２はメッセージ読
出し、Ｓ１１３はＭＢ解放、Ｓ１１４はＡＰＬオブジェ
クト終了である。

【００５９】「ステップＳ１２０」送信ＰＭ１８−１の
カーネルは、ステップＳ１２０でＡＰＬオブジェクト起
動プログラム（図２２）を実行し、送信オブジェクトＩ
Ｄ（ＳＩＤ）を図１９のタイミングｔ１２０でＰＭ１８
−１のＣＣＲ５１−１に設定し、送信オブジェクトの実
行を開始する。

【００６０】「ステップＳ１２１」送信オブジェクトは
ＭＢ捕捉をカーネルに要求し、カーネルは図２３のＭＢ
捕捉処理プログラムを実行する。このケースでは、同一
システム内で２つのＰＭにまたがった通信であるため、
図２３のステップ３５０で検索して取り出されるシステ
ム通信モードフィールド（図１７の２５１）の値は『シ
ステム内通信』２６１となり、ステップ３５１からステ
ップ３５２に進む。ステップ３５２で検索して取り出さ
れるＰＭ通信モードフィールド（図１７の２９１）の値
は『ＰＭ間通信３１１』となり、これに対応して『ＰＭ
間通信ＭＢ管理マップベースアドレス３２２』と表示さ
れたＭＢ管理マップアドレスフィールドを取り出す。ス
テップ３５３では、選択した『ＰＭ間通信ＭＢ管理マッ
プベースアドレス３２２』で指定されたＭＢ管理マップ
を検索し、空きを表示しているＭＢ管理マップエントリ
を検出して、それに対応する空きＭＢアドレスを求め、
そのＭＢ管理マップエントリを『使用中』に書き替え
る。この例では、ＰＭ１８−１からＰＭ１８−２への通
信用ＭＢＸ１２−１が図１９のタイミングｔ１２１で
『使用中』に書き替えられるが、この時点で同時にＸＭ
１２−１と同一アドレスを持つ受信側分散共有メモリ２
１−２のＭＢ管理マップエントリＹＭ１２−１も書き替
えられる。この書き替えは、次のような操作で行われ
る。

【００６１】先ず、送信ＰＭ１８−１のプロセッサ１９
−１がＭＢ管理マップエントリＸＭ１２−１の書き替え
命令を実行すると、ＭＢ管理マップエントリＸＭ１２−
１のアドレスと書き替えデータがプロセッサバス３０−
１（図１参照）に送出される。送信側分散メモリカップ
ラ２２−１では、送信側分散共有メモリ２１−１への書
き込みアクセスがあった場合に、バス信号デコーダ３１
−１が分散共有メモリ２１−１への書き込みアクセスで
あることを検出し、信号線３２−１を経由して転送制御
部３３−１を起動する。転送制御部３３−１は、ＭＢ管
理マップエントリＸＭ１２−１のアドレスと書き替えデ
ータを取り込み、モジュールＩＤ管理部３４−１に、Ｍ
Ｂ管理マップエントリのページアドレスを供給する。モ
ジュールＩＤ管理部３４−１のＣＡＭコマンドレジスタ
（図８の６７−１）には、予め『キーレジスタ（図８の
６６−１）との比較動作』を指示するコマンドが入れら
れているため、ＭＢ管理マップエントリＸＭ１２−１の
ページアドレスがキーレジスタ６６−１に格納される
と、キーレジスタ（６６−１）とＣＡＭセル部（図８の
６１−１）との一斉比較が行われる。ＣＡＭセル部６１
−１の各エントリは、他のＰＭの分散共有メモリエリア
と重複しているエリアのページアドレス６３を含んでい
る。

【００６２】本実施例においては、受信ＰＭ１８−２と
の間で共有されているＸＭ１２−１のページアドレス
と、受信ＰＭ１８−２ＩＤのペアがそれぞれＣＡＭセル
部６１−１とデータメモリ部６２−２に登録されてい
る。従って、ＣＡＭセル部６１−１における比較動作に
より一致が検出され、対応する受信ＰＭ１８−２のＩＤ
がデータメモリ部６２−１から取り出される。これを、
パケット送信レジスタ３５−１に転送する。パケット送
信レジスタ３５−１では、図９に示すように、属性識別
フィールド８０を‘０’に設定して、共有分散メモリア
クセスタイプのパケットであることを表示し、宛先ＰＭ
ＩＤフィールド８１には、モジュールＩＤ管理部から
取り出した値（ＰＭ１８−２のＩＤ）を設定する。ま
た、分散共有メモリアドレスフィールド８２と書き込み
データフィールド８３には、プロセッサバス３０−１上
のアドレス（ＸＭ１２−１のアドレス）とデータ（『使
用中』表示データ）を載せ、書き込み単位フィールド８
４には、プロセッサバス３０−１が指示する信号（バイ
ト書き込みとバイト位置情報）を載せて送信パケットを
編集する。これをパケット送信バッファ３６−１に送出
すると、パケット送信バッファ３６−１は送信パケット
をプロセッサモジュール間通信路２５に送出する。プロ
セッサモジュール間通信路２５は、送信パケットの宛先
ＰＭ ＩＤフィールド８１を見てルーチングを行い、受
信ＰＭ１８−２のパケット受信バッファ３７−２に送り
届ける。

【００６３】受信ＰＭ１８−２のパケット受信バッファ
３７−２のデータはパケット受信レジスタ３８−２に入
れられてパケットデコーダ３９−２でデコードされ、共
有分散メモリ２１−２への書き込みであることがわかる
と、転送制御部３３−２を起動する。転送制御部３３−
２は、パケット受信レジスタ３８−２内の分散共有メモ
リアドレス（ＸＭ１２−１のアドレス）、書き込みデー
タ（『使用中』表示データ）、書き込み単位の情報をプ
ロセッサバス３０−２経由で分散共有メモリ２１−２に
送ることにより、ＸＭ１２−１への書き込みデータと同
じ値が受信側分散共有メモリ２１−２の同じアドレス位
置、つまりＹＭ１２−１に書き込まれる。このようにし
て、分散共有メモリへの書き込み側が自分の分散共有メ
モリへのローカルな書き込みを行うだけで、分散メモリ
カップラ２２の働きにより自動的に宛先の分散共有メモ
リにも同じ値がコピーされるので、ＤＭＡのようなソフ
トウェアによるコピーオーバーヘッドを伴わないという
利点がある。

【００６４】なお、コピーバック型のキャッシュメモリ
を備えるプロセッサ１９では、分散共有メモリ２１への
書き込みアクセスがキャッシュヒットすると、その時点
でキャッシュメモリへの書き込みだけが行われ、分散共
有メモリ２１への書き込みは直ちに行われないことがあ
る。その場合には、キャッシュメモリへの書き込み後、
キャッシュメモリ内の書き込みデータを分散共有メモリ
に戻す命令を実行することにより、送信側分散共有メモ
リ２１−１への書き込みを確実に行うので、受信側分散
共有メモリ２１−２へのコピーも確実に行うことができ
る。次に、図２３のステップ３５４では、ＭＢ（Ｘ１２
−１）に対応するメモリケーパビリティレジスタ５３−
１のアドレスを求め、ＭＣＲ５３−１に対しこのＭＢへ
のアクセス権を獲得した送信オブジェクトのＩＤ（ＳＩ
Ｄ）を図１９のタイミングｔ１２２で登録する。以上
で、ステップＳ１２１のＭＢ捕捉処理を終了する。

【００６５】「ステップＳ１２２」送信オブジェクトが
作成したメッセージを送信側分散共有メモリのＭＢ（Ｘ
１２−１）にタイミングｔ１２３で書き込みを行う度毎
に、この書き込みデータが分散メモリカップラ２２によ
り受信側分散共有メモリの同一アドレスのＭＢ（Ｙ１２
−１）にも伝搬して書き込まれる。その操作は、図１９
のタイミングｔ１２１で説明した通りである。なお、本
実施例のメッセージ書き込みステップでは、図９に示す
ように、書き込み単位、例えば４バイトの書き込みデー
タ毎に１つのパケットを構成し、分散メモリカップラ２
２間で送受する構成であるがメッセージのようにメモリ
の連続エリアへの書き込みが行われる場合には、図９の
送受信パケットを、先頭の書き込みアドレスに続いて複
数個の書き込みデータを１パケットにまとめた構成にし
て、分散メモリカップラ２２間で送受する方法も可能で
ある。その場合には、連続エラアへの書き込みが行われ
ているのか、または単発エリアの書き込みが行われてい
るのかを分散メモリカップラ２２側で事前に検知するこ
とができないため、分散メモリカップラ２２は、予め決
められた時間内に決められた回数の連続アドレスエリア
書き込みがあれば、それらを１パケットにまとめて送
る。また、決められた時間内に決められた回数よる少な
い連続アドレスエリア書き込みであれば、タイムアウト
になった時点で、それまでにたまっている連続アドレス
エリア書き込みデータを１パケットにまとめて送出すれ
ばよい。図１９において、連続番地ＣＣＲ５１−１とＭ
ＣＲ５３−１の両方の値が設定されている区間（ステッ
プＳ１２１からステップＳ１２４までの区間）では、Ｍ
ＣＲとＣＣＲにより指定された送信オブジェクトがＭＢ
（Ｘ１２−１）にアクセスすることができるが、ＰＭ１
８−１内の他のＡＰＬオブジェクトはアクセスすること
ができない。

【００６６】「ステップＳ１２３」送信オブジェクト
は、カーネルに送信処理を依頼する。送信処理プログラ
ムは、図２５に示されるように、先ずステップ３８０で
ＭＢ（Ｘ１２−１）に対応するＭＣＲ５３−１をクリア
する。この動作は、図１９のタイミングｔ１２４に示さ
れており、これによりプロテクションウィンドウ開放期
間が終了するので、これ以後、カーネル以外はＭＢ（Ｘ
１２−１）にアクセスすることができなくなる。次に、
図２５のステップ３８１で通信モードをチェックする。
ここでは、『システム内ＰＭ間通信』であるため、ステ
ップ３８６に進む。ステップ３８６では、図１９のステ
ップＳ１２１で検索一致したＰＭ ＩＤ（図１７の２９
０）、つまりＰＭ１８−２宛の受信ディスクリプタリン
グＸＤ１２−Ｒに受信処理制御情報を登録（エンキュ
ー）すると同時に、図１４のフォーマットの処理要求を
受信ＰＭ１８−２宛の受信処理ＦＩＦＯ（ＸＦ２−Ｒ）
に書き込む。これらの書き込みは、図１９のタイミング
ｔ１２５で行われる。受信ディスクリプタリングＸＤ１
２−Ｒへのエンキュー処理は、図２７に示されているの
で、説明は省略する。受信ディスクリプタリングＸＤ１
２−Ｒに書き込みが行われると、書き込みデータが分散
メモリカップラ２２−１により受信ＰＭ１８−２にも転
送され、その分散共有メモリ２１−２の同一アドレスで
あるＹＤ１２−Ｒにも書き込まれる。

【００６７】一方、受信処理ＦＩＦＯへの書き込みにつ
いて、送信ＰＭ１８−１側の受信処理ＦＩＦＯエリア
（ＸＦ２−Ｒ）は、通常のＲＡＭで構成されているが、
受信ＰＭ１８−２側の受信処理ＦＩＦＯエリア（ＹＦ２
−Ｒ）はＦＩＦＯメモリで構成されている。従って、Ｘ
Ｆ２−Ｒへの書き込みデータが分散メモリカップラ２２
により受信側の分散共有メモリの受信処理ＦＩＦＯエリ
ア（ＹＦ２−Ｒ）に伝達されると、ＹＦ２−Ｒでは、以
前に書き込まれたデータを保存したまま、新しい書き込
みデータが追加して書き込まれる。以上により、メッセ
ージ送信に必要な情報が受信ＰＭ１８−２に全て伝達さ
れた。

【００６８】「ステップＳ１２４」カーネルが図２２の
ＡＰＬオブジェクト終了処理を起動し、カレントケーパ
ビリティレジスタ（ＣＣＲ）５１−１の値を図１８のタ
イミングｔ１２６でクリアする。

【００６９】（ｂ）受信ＰＭ１８−２側の処理 「ステップＳ１３０」図１９のステップＳ１３０におい
て、カーネルは次に実行すべきオブジェクトして受信オ
ブジェクトを選択し、図１９のタイミングｔ１３０で受
信オブジェクトＩＤ（ＲＩＤ）を受信ＰＭ１８−２内の
カレントケーパビリティレジスタ（ＣＣＲ）５１−２に
設定する。

【００７０】「ステップＳ１３１」 受信オブジェクトの実行が開始され、受信オブジェクト
がカーネルに受信処理を要求すると、カーネルは図２６
の受信処理プログラムを起動する。図２６のステップ３
９０では、受信オブジェクトのＯＣＢ２１０のＳＴＡＴ
ＵＳフィールド（図１５（ｄ）の２１４）が『受信側実
行待ち』または『同期完了』になっているか否かをテス
トする。このケースでは、この時点で送信オブジェクト
からのメッセージが到着していないため、『受信側実行
待ち』または『同期完了』の状態になく、『ｎｏ』とな
る。そこで、ステップ３９３で先に受信オブジェクトの
要求が到着したことを示すために、ＳＴＡＴＵＳフィー
ルド２１４を『送信側実行待ち』に設定し、カーネルに
リターンする。

【００７１】「ステップＳ１３２」カーネルは、受信オ
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるために、図２２のＡＰＬオブジェク
ト終了処理を起動し、ステップ３４０でカレントケーパ
ビリティレジスタ（ＣＣＲ）５１−２の値を図１９のタ
イミングｔ１３１でクリアし、ステップ３４１で受信オ
ブジェクト再開に必要な情報をＯＣＢ２１０に退避す
る。

【００７２】「ステップＳ１４０」 受信ＰＭ１８−２のＩＯＣ配信プログラムは、図２９に
示すように、定期的にＰＭ＃２宛の受信処理ＦＩＦＯ
（ＹＦ２−Ｒ（図７））を読み出すことにより受信処理
要求の有無をチェックする。具体的には、図２９のステ
ップ５００で受信処理ＦＩＦＯ（ＹＦ２−Ｒ）から要求
を図１９のタイミングｔ１４０で読み出し、ステップ５
０１で要求の有無をチェックする。もし、要求があれ
ば、ステップ５０２で、引き続き同じタイミングｔ１４
０で読み出した要求が指定している受信ディスクリプタ
リングＹＤ１２−Ｒに対して図２８の『デキュー処理』
を実行し、受信ディスクリプタ（図１５（ｃ）の２０
０）を取り出す。ステップ５０３で、受信ディスクリプ
タ内のＭＢＡ（図１５（ｃ）の２０２）を参照して、図
１５（ａ）で示される構造のＭＢ（Ｙ１２−１）をアク
セスしてＭＢ（Ｙ１２−１）内の受信オブジェクトＩＤ
（ＲＩＤ）（図１５の１８３）を取り出す。ステップ５
０４で、ＲＩＤ１８３に対応する図１５（ｄ）のＯＣＢ
のメッセージキューに、ＭＢ（Ｙ１２−１）のアドレス
ＭＢＡ２０２を登録する。ステップ５０５では、この受
信オブジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィール
ド（図１５の２１４）が『送信側実行待ち』となってい
るか否かをテストする。ここでは、図１９のステップＳ
１３１でＳＴＡＴＵＳフィールド２１４を『送信側実行
待ち』と設定しているため、ステップ５０５は『ｙｅ
ｓ』となる。これは、受信オブジェクトが送信側からメ
ッセージを受け取る準備をして休止状態にいることを表
わしているため、ステップ５０６では、受信オブジェク
トのＯＣＢ２１０のＳＴＡＴＵＳフィールド２１４を
『同期完了』と設定して送信要求と受信要求の両方が揃
ったことを表示する。次に、ステップ５０７で、受信オ
ブジェクトのＯＣＢ２１０をレディキューに登録して受
信オブジェクトが再起動されるようにする。

【００７３】「ステップＳ１５０」受信ＰＭ１８−２の
カーネルは、レディキューの中から次に実行すべきオブ
ジェクトとして受信オブジェクトを選択し、図１９のタ
イミングｔ１５０で受信オブジェクトＩＤ（ＲＩＤ）を
受信ＰＭ１８−２内のカレントケーパビリティレジスタ
（ＣＣＲ）５１−２に設定する。

【００７４】「ステップＳ１５１」受信オブジェクトの
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図２６の受信処理プログラ
ムを起動する。図２６のステップ３９０では、受信オブ
ジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド２１
４が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。このケースでは、図１９のステ
ップＳ１４０でＳＴＡＴＵＳフィールド２１４を『同期
完了』と設定しているため、ステップ３９０は『ｙｅ
ｓ』となる。これは、メッセージが送信側から既に届い
ているので、直ちにメッセージを読み出してもよいこと
を示している。そこで、ステップ３９１では、ＯＣＢ２
１０のメッセージキューにつながっているメッセージを
キューから外し、そのＭＢ（Ｙ１２−１）のアドレスを
取り出する。続いて、ステップ３９２で、このＭＢアド
レスに対応するＭＣＲ５３−２に受信オブジェクトＩＤ
（ＲＩＤ）を設定する。このタイミングは、図１９のタ
イミングｔ１５１で示されている。これにより、ＣＣＲ
５１−２とＭＣＲ５３−２の両方に受信オブジェクトＩ
Ｄ（ＲＩＤ）が設定されたので、以後は、ＭＢ（Ｙ１２
−１）が受信オブジェクト以外のＡＰＬオブジェクトか
らアクセスできないようにプロテクトされた。

【００７５】「ステップＳ１５２」受信オブジェクトが
ＭＢ（Ｙ１２−１）からタイミングｔ１５２でメッセー
ジを読み出し、対応する処理を行う。ここで受信オブジ
ェクトは、送信オブジェクトがメッセージを書き込んだ
送信側分散共有メモリ２１−１のＭＢ（Ｘ１２−１）か
らでなく、そのコピーを記憶する受信側分散共有メモリ
２１−２のＭＢ（Ｙ１２−１）から読み出すため、リモ
ートメモリアクセスを行う場合に比較して極めて高速で
ある。

【００７６】「ステップＳ１５３」受信オブジェクト
は、カーネルにＭＢ解放を依頼する。カーネルは、図２
４のＭＢ解放処理プログラムを起動し、図２４のステッ
プ３６０で、ＭＢ（Ｙ１２−１）に対応するＭＣＲ５３
−２を図１９のタイミングｔ１５３でクリアする。次
に、図２４のステップ３６１でＭＢ（Ｙ１２−１）に対
応するＭＢ管理マップエントリ（ＹＭ１２−１）を図１
９のタイミングｔ１５４で『空き』に書き替える。この
値の書き替えは、受信側の分散共有メモリ２１−２のみ
ならず、同時に送信側の分散共有メモリ２１−１の同一
ロケーションＸＭ１２−１に対しても行われる。その理
由は、受信側分散メモリカップラ２２−２内のモジュー
ルＩＤディレクトリ（図８の６０）に、各ＭＢ管理マッ
プのページアドレスと、送信側ＰＭＩＤのペアが記憶さ
れているので、受信側分散共有メモリ２１−２への書き
込みが生じると、分散メモリカップラ２２−２，２２−
１経由で、送信の分散共有メモリ２１−１にも書き込ま
れるためである。本発明では、ＭＢは常に送信ＰＭで一
元管理するので、図１９のタイミングｔ１５５で、送信
側のＭＢ管理マップェントリＸＭ１２−１への書き替え
が完了すると、この時点以後は、いつでも送信ＰＭでＭ
Ｂ（Ｘ１２−１）を再利用することが可能である。

【００７７】「ステップＳ１５４」カーネルがＡＰＬオ
ブジェクト終了処理を実行し、カレントケーパビリティ
レジスタ（ＣＣＲ）５１−２の値を図１９のタイミング
ｔ１５６でクリアする。以上のように、システム内ＰＭ
間通信の場合には、分散メモリカップラ２２の働きによ
り、メッセージおよびその制御情報を送信ＰＭと受信Ｐ
Ｍ間で極めて簡単に授受を行うことができるので、効率
的なメッセージ通信が行える。

【００７８】（ケース３）システム間ＰＭ無中継通信 （ａ）送信システム１７−１のＰＭ１８−１内処理 送信側マルチプロセッサシステムと受信側マルチプロセ
ッサシステムのいずれも、中継ＰＭを介さないで通信す
るパターンの例を説明する。図２０に示すように、マル
チプロセッサシステム１７−１において送信オブジェク
トの存在するプロセッサモジュール（ＰＭ）１８−１か
らネットワークを介して他のマルチプロセッサシステム
１７−２の受信オブジェクトの存在するＰＭ１８−３に
メッセージを転送する場合を考える。このケースでは、
送信オブジェクトの実行終了前に、受信オブジェクトが
実行開始するものとする。送信側が使用するＭＢは、図
７のＸ１１−１、そのＭＢ管理マップエントリはＸＭ１
１−１とする。また、この処理依頼内容の詳細は、送信
ディスクリプタリングＸＤ１１−Ｓに、送信処理要求は
送信ＰＭ１８−１の送信処理ＦＩＦＯ（ＸＦ１−Ｓ）に
登録されるものとする。処理の流れを図２０の各ステッ
プに沿って説明する。図２０におけるＳ１６０はＡＰＬ
オブジェクト起動、Ｓ１６１はＭＢ捕捉、Ｓ１６２はメ
ッセージ書き込み、Ｓ１６３は送信処理、Ｓ１６４はＡ
ＰＬオブジェクト終了、Ｓ１７０はＩＮＣ送信処理、Ｓ
１８０はＡＰＬオブジェクト起動、Ｓ１８１は受信処
理、Ｓ１８２はＡＰＬオブジェクト終了、Ｓ１９０はＩ
ＮＣ受信処理、Ｓ２００はＡＰＬオブジェクト起動、Ｓ
２０１は受信処理、Ｓ２０２はメッセージ読出し、Ｓ２
０３はＭＢ解放、Ｓ２０４はＡＰＬオブジェクト終了で
ある。

【００７９】「ステップＳ１６０」送信ＰＭ１８−１の
カーネルは、ステップＳ１６０のＡＰＬオブジェクト起
動の実行により、送信オブジェクトのＩＤ（ＳＩＤ）を
タイミングｔ１６０でＰＭ１８−１のＣＣＲ５１−１に
設定し、送信オブジェクトの実行を開始する。

【００８０】「ステップＳ１６１」送信オブジェクトは
ＭＢの捕捉をカーネルに要求すると、カーネルは図２３
のＭＢ捕捉処理プログラムを実行する。このケースは、
異なるシステムに存在する２つのＰＭ間の通信であるた
め、図２３のステップ３５０で検索して取り出されるシ
ステム通信モードフィールド（図１７の２５１）の値は
『システム間通信』２７１となる。従って、図２３のス
テップ３５１では、『システム間通信』側選択され、ス
テップ３５５で対応するエントリの通信リンクＩＤ（図
１７の２７２）と送信中継ＰＭ ＩＤ２７３の値が取り
出される。ステップ３５６で、送信中継ＰＭ ＩＤ２７
３をキーとしてＰＭルーチングテーブル２８９を検索
し、ステップ３５３で送信ＰＭ１８−１と送信中継ＰＭ
との通信で使用するＭＢプールとそのディスクリプタリ
ングを決定する。このケースの送信側システムでは、Ｐ
Ｍ無中継であるため送信ＰＭ１８−１と送信中継ＰＭと
が一致し、ステップ３５６で、ＰＭ内送信用ＭＢプール
Ｘ１１とそのＭＢ管理マップＸＭ１１が選択される。ス
テップ３５３では、ＰＭ内通信用ＭＢマップ端漆歳ＸＭ
１１−１が『使用中』に書き替えられる。次に、図２３
のステップ３５４で、ＭＢ（Ｘ１１−１）に対応するメ
モリケーパビリティレジスタ（ＭＣＲ）５３−１に、こ
のＭＢへのアクセス権を獲得した送信オブジェクトのＩ
Ｄ（ＳＩＤ）が図２０のタイミングｔ１６２で登録され
る。

【００８１】「ステップＳ１６２」送信オブジェクト
は、作成したメッセージを送信側分散共有メモリのＭＢ
（Ｘ１１−１）にタイミングｔ１６３で書き込む。この
メッセージの書き込みステップでは、ｃｃｒ５１−１と
ＭＣＲ５３−１の両方の値が設定されている区間は、Ｍ
ＣＲとＣＣＲにより指定されている送信オブジェクトが
ＭＢ（Ｘ１１−１）にアクセスすることができるが、他
のＡＰＬオブジェクトはアクセスすることができない。

【００８２】「ステップＳ１６３」送信オブジェクトで
は、カーネルに送信処理を依頼する。図２５の送信処理
プログラムではステップ３８０でＭＢ（Ｘ１１−１）に
対応するＭＣＲ５３−１をクリアする。これは、図２０
のタインミングｔ１６４で示されており、これによりプ
ロテクションウィンドウ開放期間が終了するため、以
後、カーネる以外はＭＢ（Ｘ１１−１）にアクセスでき
なくなる。次に、図２５のステップ３８１で、通信モー
ドをチェックする。このケースでは、『システム間ＰＭ
無中継通信（システム間ＰＭ内通信）』であるため、ス
テップ３８７に進み、図２０のステップＳ１６１で検索
一致したＰＭ ＩＤ（図１７の２９０）、つまりＰＭ１
８−１宛の送信ディスクリプタリングＸＤ１１−Ｓに送
信制御情報を登録（エンキュー）し、図１４のフォーマ
ットの処理要求を自ＰＭ１８−１宛の送信処理ＦＩＦＯ
（ＸＦ１−Ｓ）（図７参照）に書き込む。これらの登録
は、図２０のタイミングｔ１６５で行われる。なお、こ
のケースでは、送信ＰＭ１８−１の送信ディスクリプタ
リングＸＤ１１−Ｓと送信処理ＦＩＦＯ（ＸＦ１−Ｓ）
は、他の分散共有メモリ内にコピーを持たないため、分
散メモリカップラによる他分散共有メモリへの書き込み
は行われない。

【００８３】「ステップＳ１６４」カーネルがＡＰＬオ
ブジェクト終了処理を起動し、カレントケーパビリティ
レジスタ（ＣＣＲ）５１−１の値を、図２０のタイミン
グｔ１６６でクリアする。

【００８４】「ステップＳ１７０」送信ＰＭ１８−１の
ＩＮＣ送信処理プログラムは、図３０に示すように、定
期的に自ＰＭ宛の送信処理ＦＩＦＯ（ＸＦ１−Ｓ）を読
み出すことにより要求の有無をチェックしている。具体
的には、図３０のステップ５２０で、送信処理ＦＩＦＯ
（ＸＦ１−Ｓ）から要求を図２０のタイミングｔ１７０
で読み出し、ステップ５２１で要求の有無をチェックす
る。本実施例のステップＳ１７０の時点においては、既
に送信処理ＦＩＦＯ（ＸＦ１−１）に要求が登録されて
いるので、ステップ５２２で、要求が指定している送信
ディスクリプタリングＸＦ１−Ｓに対して図２８の『デ
キュー処理』を実行する。ステップ５２３で、図１３に
示す構造の送信ディスクリプタを引き続き図２０のタイ
ミングｔ１７０で取り出し、この情報をもとにしてネッ
トワークを介した通信に必要とする各種のプロトコル処
理（例えば、ネットワークパケットのヘッダの作成、再
送制御情報の作成、チェックサムの計算等）を行う。次
に、ステップ５２４では、ネットワークアダプタの起動
に必要なアダプタ送信ディスクリプタ（図３０のステッ
プ５３０）を作成する。ステップ５２５では、このアダ
プタ送信ディスクリプタをアダプタ送信ディスクリプタ
リングに、図２０のタイミングｔ１７１で登録する。

【００８５】ネットワークアダプタ２４−１は、常時、
アダプタ送信ディスクリプタリングを監視しており、デ
ィスクリプタの登録があると、この情報をもとにしてネ
ットワークが要求するサイズにメッセージを分割し、ヘ
ッダや誤り制御情報を付加してネットワークパケットと
してネットワークに送出する。このタイミングは図２０
のタイミングｔ１７２で示されている。ネットワークア
ダプタ２４−１は、メッセージの転送を完了するか、あ
るいは通信相手のシステムからメッセージ到着確認の連
絡を受けると、送信側でメッセージバッファを保持して
おく必要がなくなったため、図２０のタイミングｔ１７
３でＭＢ（Ｘ１１−１）に対応するＭＢ管理マップのエ
ントリＸＭ１１−１を『空き』に書き替える。その結
果、この時点以降、送信ＰＭ１８−１では、いつでもこ
のＭＢ（Ｘ１１−１）を再利用することができる。

【００８６】（ｂ）受信システム１７−２のＰＭ１８−
３内処理 「ステップＳ１８０」図２０において、受信システム１
７−２のカーネルは、次に実行すべきオブジェクトとし
て受信オブジェクトを選択し、図２０のタイミングｔ１
８０で受信オブジェクトＩＤ（ＲＩＤ）を受信ＰＭ１８
−３内のカレントケーパビリティレジスタ（ＣＣＲ）５
１−３に設定する。

【００８７】「ステップＳ１８１」受信オブジェクトの
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図２６の受信処理プログラ
ムを起動する。図２６のステップ３９０では、受信オブ
ジェクトのＯＣＢ（図１５（ｄ）の２１０）のＳＴＡＴ
ＵＳフィールド（図１４の２１４）が『受信側実行待
ち』または『同期完了』になっているか否かをテストす
る。このケースでは、この時点で、送信オブジェクトか
らのメッセージは到着していないため、『受信側実行待
ち』または『同期完了』の状態にはなく、『ｎｏ』とな
る。そこで、ステップ３９３で、先に受信オブジェクト
の要求が到着したことを示すために、ＳＴＡＴＵＳフィ
ールド２１４を『送信側実行待ち』に設定し、カーネル
にリターンする。

【００８８】「ステップＳ１８２」カーネルは、受信オ
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるため、図２２のＡＰＬオブジェクト
終了処理プログラムを起動し、ステップ３４０でカレン
トケーパビリティレジスタＣＣＲ５１−３の値を図２０
のタイミングｔ１８１でクリアし、ステップ３４１で受
信オブジェクト再開に必要な情報をＯＣＢ２１０に退避
する。

【００８９】「ステップＳ１９０」図２０のタイミング
ｔ１７２で、送信システム１７−１からネットワークパ
ケットが届くと、受信システム１７−２のネットワーク
アダプタ２４−３は、自分が管理している、分散共有メ
モリ２１−３内のＰＭ＃３内通信領域の空きのローカル
メッセージバッファの１つに、ネットワークパケットを
記憶する。メッセージが複数のネットワークパケットで
分割されて送られて来る場合には、送られてきたネット
ワークパケットをパケットヘッダを見ながらローカルメ
ッセージバッファ内の指定された位置に入れることによ
りメッセージの組み立て処理を行い、最終的に１つのメ
ッセージに組み立てる。そして、でき上ったメッセージ
に関する制御情報をアダプタ受信ディスクリプタリング
に登録する。ＩＮＣ受信処理プログラムは、図３１，図
３２に示すように、定期的にアダプタ受信ディスクリプ
タリングを読み出すことにより要求の有無をチェックす
る。

【００９０】具体的には、図３１および図３２におい
て、受信システム１７−２のＰＭ１８−３のＩＮＣ受信
処理プログラムは、ステップ５６０でアダプタ受信ディ
スクリプタリングに対して、図２８の『デキュー処理』
を実行し、ステップ５６１でアダプタ受信ディスクリプ
タリングにエントリが登録されていたか否かをチェック
する。本実施例のステップＳ１９０の時点では、到着し
たメッセージをアダプタ受信ディスクリプタに登録済み
のため、ステップ５６２でアダプタ受信ディスクリプタ
（図３３の５９０）を図２０のタイミングｔ１９０で取
り出し、この情報をもとにプロトコル受信処理（例え
ば、ネットワークパケットのヘッダのチェック、再送制
御情報の作成等）を行う。次に、ステップ５６３で、ア
ダプタ受信ディスクリプタ中のローカルメッセージバッ
ファアドレス（ＬＢＡ）５９１を参照してローカルメッ
セージバッファをアクセスし、受信オブジェクトＩＤ
（ＲＩＤ）（図１５（ａ）の１８３）を取り出す。ステ
ップ５６４では、ＲＩＤのＰＭＩＤフィールド（図１２
の１７２）をキーにして、ＰＭルーチングテーブル（図
１６の２８９）のＰＭ ＩＤフィールド２９０を探索
し、ＰＭ ＩＤが一致したエントリの通信モードフィー
ルド２９１をチェックする。

【００９１】本実施例では、自ＰＭ１８−３内の受信オ
ブジェクト宛のメッセージであるため、通信モードフィ
ールド２９１＝『ＰＭ内通信』となって、図３１のステ
ップ５６５に進み、受信オブジェクトのメッセージキュ
ーにローカルメッセージバッファアドレス（ＬＢＡ）５
９１を登録する。次に、ステップ５６６で、受信オブジ
ェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド（図１
５の２１４）が『送信側実行待ち』となっているか否か
をテストする。このケースでは、図２０のステップＳ１
８１で、ＳＴＡＴＵＳフィールド２１４を『送信側実行
待ち』と設定しているため、ステップ５６６は『ｙｅ
ｓ』となる。これは、受信オブジェクトが送信側からメ
ッセージを受け取る準備をして休止状態にあることを表
わしているので、ステップ５６７で、受信オブジェクト
のＯＣＢ２１０のＳＴＡＴＵＳフィールド２１４を『同
期完了』と設定して、送信要求と受信要求の両方が揃っ
たことを表示する。次に、ステップ５６８で受信オブジ
ェクトのＯＣＢ２１０をレディキューに登録して、受信
オブジェクトが再起動されるようにする。

【００９２】「ステップＳ２００」受信システム１７−
２の受信ＰＭ１８−３のカーネルは、レディキューの中
から次に実行すべきオブジェクトとして受信オブジェク
トを選択し、図２０のタイミングｔ２００で受信オブジ
ェクトＩＤ（ＲＩＤ）を受信ＰＭ１８−３内のカレント
ケーパビリティレジスタ（ＣＣＲ）５１−３に設定す
る。

【００９３】「ステップＳ２０１」受信オブジェクトの
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは、図２６の受信処理プログ
ラムを起動する。図２６のステップ３９０では、受信オ
ブジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド
（図１５の２１４）が『受信側実行待ち』または『同期
完了』となっているか否かをテストする。このケースで
は、図２０のステップＳ１９０で、ＳＴＡＴＵＳフィー
ルド２１４を『同期完了』と設定しているため、ステッ
プ３９０は『ｙｅｓ』となる。これは、メッセージが送
信側から既に届いているので、直ちにメッセージを読み
出してもよいことを示している。そこで、ステップ３９
１では、ＯＣＢ２１０のメッセージキューにつながって
いるメッセージを参照して、キューから外し、そのＭＢ
アドレスつまりローカルメッセージバッファアドレス
（ＬＢＡ）５９１を取り出す。次に、ステップ３９２
で、このＬＢＡ５９１に対応するＭＣＲ５３−３に受信
オブジェクトＩＤ（ＲＩＤ）を設定する。このタイミン
グは、図２０のタイミングｔ２０１で示されている。こ
れにより、ＣＣＲ５１−３とＭＣＲ５３−３の両方に受
信オブジェクトＩＤ（ＲＩＤ）が設定されたので、これ
以降はローカルメッセージバッファが受信オブジェクト
以外のＡＰＬオブジェクトからアクセスできないように
プロテクトされた。

【００９４】「ステップＳ２０２」受信オブジェクトが
ローカルメッセージバッファから図２０のタイミングｔ
２０２でメッセージを読み出し、対応する処理を行う。
ここで、受信オブジェクトは、受信側分散共有メモリ２
１−３上のローカルメッセージバッファから読み出して
いる。

【００９５】「ステップＳ２０３」受信オブジェクト
は、カーネルにローカルメッセージバッファ解放を依頼
する。カーネルは、図２４のＭＢ解放処理プログラムを
起動して、図２４のステップ３６０でローカルメッセー
ジバッファに対応するＭＣＲ５３−３を図２０のタイミ
ングｔ２０２でクリアする。次に、図２４のステップ３
６１で、ローカルメッセージバッファに対応するＭＢ管
理マップエントリを『空き』という値に書き替える。こ
のタイミングは、図２０のタイミングｔ２０３に示され
ている。このＭＢ管理マップエントリが『空き』に書き
替えられた時点以降は、ネットワークアダプタ２４−３
は、このローカルメッセージバッファを再利用すること
ができる。

【００９６】「ステップＳ２０４」カーネルがＡＰＬオ
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ（ＣＣＲ）５１−３の値を図２０のタイミン
グｔ２０４でクリアする。以上のように、システム間Ｐ
Ｍ無中継通信の場合にも、システム内ＰＭ間通信と大差
ないソフトウェアのオーバヘッドでメッセージ通信を高
速に、効率よく実現することができる。

【００９７】（ケース４）システム間ＰＭ中継通信 送信マルチプロセッサシステム１７−１内の送信プロセ
ッサモジュール（ＰＭ）１８−１内の送信オブジェクト
が作成したメッセージを、宛先システムへの通信リンク
を持つ送信マルチプロセッサシステム内の送信中継ＰＭ
１８−２に引き継ぎ、送信中継ＰＭ１８−２がネットワ
ークを介して他の受信マルチプロセッサシステム１７−
２にメッセージを転送し、受信マルチプロセッサシステ
ム１７−２の受信中継ＰＭ１８−３がメッセージを受信
した後、受信オブジェクトの存在する受信ＰＭ１８−２
にメッセージを引き継ぐ場合を仮定して、送信オブジェ
クトの実行終了前に、受信オブジェクトが実行開始する
ものとする。送信システム１７−１の送信ＰＭ１８−１
が使用するＭＢは図５のＸ１２−２、そのＭＢ管理マッ
プエントリはＸＭ１２−２、メッセージ制御情報は送信
ディスクリプタリングＸＤ１２−Ｓ、送信処理要求は宛
先ＰＭ１８−２用送信処理ＦＩＦＯ（ＸＦ２−Ｓ）に、
それぞれ登録されるものとする。一方、受信システム１
７−２の受信中継ＰＭ１８−３が使用するＭＢを、図５
〜図７のＺ３２−１、そのＭＢ管理マップエントリはＺ
Ｍ３２−１、メッセージ制御は受信ディスクリプタリン
グＺＤ３２−Ｒ、受信処理要求は宛先ＰＭ１８−１情報
用受信処理ＦＩＦＯ（ＺＦ２−Ｒ）に、それぞれ登録さ
れるものとする。処理の流れを図２１の各ステップに沿
って説明する。図２１において、ステップＳ２１０はＡ
ＰＬオブジェクト起動、ステップ２１１はＭＢ捕捉、Ｓ
２１２はメッセージ書込み、Ｓ２１３は送信処理、Ｓ２
２０はＩＮＣ送信、Ｓ２３０はＩＮＣ受信、Ｓ２４０は
ＡＰＬオブジェクト起動、Ｓ２４１は受信処理、Ｓ２４
２はＡＰＬオブジェクト終了、Ｓ２５０はＩＯＣ配信、
Ｓ２６０はＡＰＬオブジェクト起動、Ｓ２６１は受信処
理、Ｓ２６２はメッセージ読出し、Ｓ２６３はＭＢ解
放、Ｓ２６４はＡＰＬオブジェクト終了である。

【００９８】（ａ）送信システム１７−１の送信ＰＭ１
８−１の処理 「ステップＳ２１０」送信マルチプロセッサシステム１
７−１の送信ＰＭ１８−１のカーネルは、図２１のステ
ップＳ２１０のＡＰＬオブジェクト起動プログラムを実
行し、送信オブジェクトのＩＤ（ＳＩＤ）をタイミング
Ｓ２１０でＰＭ１８−１のＣＣＲ５１−１に設定し、送
信オブジェクトの実行を開始する。

【００９９】「ステップＳ２１１」送信オブジェクトは
ＭＢの捕捉をカーネルに要求すると、カーネルは図２３
のＭＢ捕捉処理プログラムを実行する。このケースで
は、送信システム内送信ＰＭ１８−１から送信システム
内中継ＰＭ１８−２への通信であるため、図２３のステ
ップ３５０で検索して取り出されるシステム通信モード
フィールド（図１６の２５１）の値は『システム間通
信』２７１となる。従って、図２３のステップ３５１で
は、『システム間通信』側が選択され、ステップ３５５
で対応するエントリの通信リンクＩＤ（図１７の２７
２）と送信中継ＰＭ ＩＤ２７３の値が取り出される。
このケースでは、送信中継ＰＭ ＩＤ２７３＝『ＰＭ１
８−２』であるため、ステップ３５５，３５６では、
『ＰＭ１８−２』の値をキーとしてＰＭルーチングテー
ブル２８９の検索が行われる。その結果、ＰＭ ＩＤフ
ィールド２９０＝『ＰＭ１８−２』となっているエント
リが一致し、このエントリに対応するＭＢ管理マップア
ドレス＝『ＰＭ１８−１／ＰＭ１８−２間通信ＭＢ（Ｘ
１２）管理マップベースアドレス３１２』が、ＰＭルー
チングテーブル２８９から取り出される。

【０１００】ステップ３５３で、ＰＭ内通信用ＭＢ（Ｘ
１２）のうちの空きＭＢ（Ｘ１２−２）が選択され、そ
のＭＢ管理マップエントリＸＭ１２−２を『使用中』に
書き替える。その書き替えは、図２１のタイミングｔ２
１１で、送信側分散共有メモリ２１−１上のＭＢ管理マ
ップエントリ（ＸＭ１２−２）およびそれと同一アドレ
スを持つ、送信中継側分散共有メモリ２１−２のＭＢ管
理マップエントリ（ＹＭ１２−２）の両方に対して行わ
れる。その具体的方法は、図１９のステップＳ１２１で
説明したので、ここでは省略する。次に、図２３のステ
ップ３５４で、ＭＢ（Ｘ１２−２）に対応するメモリケ
ーパビリティレジスタ（ＭＣＲ）５３−１に、このＭＢ
へのアクセス権を獲得した送信オブジェクトのＩＤ（Ｓ
ＩＤ）を図２１のタイミングｔ２１２で登録する。

【０１０１】「ステップＳ２１２」送信オブジェクト
は、作成したメッセージを送信側分散共有メモリのＭＢ
（Ｘ１２−２）にタイミングｔ２１３で書き込むと、こ
の書き込みデータが分散メモリカップラ２２−１により
送信中継側分散共有メモリ２１−２の同一アドレスのＭ
Ｂ（Ｙ１２−２）にも伝搬して書き込まれる。その操作
は、図１９のｔ１２１で説明したので、省略する。な
お、このメッセージ書き込みステップでは、ＣＣＲ５１
−１とＭＣＲ５３−１の両方の値が設定されている期間
中、ＭＣＲとＣＣＲが指定している送信オブジェクトは
ＭＢ（Ｘ１２−２）にアクセスすることができるが、他
のＡＰＬオブジェクトはアクセスすることができない。
また、送信中継ＰＭ１８−２にも、各ＭＢに対してＭＣ
Ｒ５３−２が用意されているが、ＭＣＲ５３−２には値
が設定されていないため、もし、送信中継ＰＭ１８−２
内のアプリケーションオブジェクトからＭＢ（Ｙ１２−
２）へのアクセスがあった場合にも、ＭＣＲ５３−２と
ＣＣＲ５１−２の不一致が生じて送信中継ＰＭ１８−２
内での不正アクセスを検出することができる。

【０１０２】「ステップＳ２１３」送信オブジェクト
は、カーネルに送信処理を依頼する。送信処理プログラ
ムは、図２５に示すように、先ずステップ３８０でＭＢ
（Ｘ１２−２）に対応するＭＣＲ５３−１を図２１のタ
イミングｔ２１４でクリアする。これにより、プロテク
ションウィンドウ開放期間が終了するので、以降はカー
ネル以外は、ＭＢ（Ｘ１２−２）にアクセスできなくな
る。次に、図２５のステップ３８１で、通信モードが
『システム間ＰＭ中継送信』であることを判定し、ステ
ップ３８７では、図２１のステップＳ２１１で検索が一
致したＰＭ ＩＤ（図１７の２９０）、つまりＰＭ１８
−２宛の送信ディスクリプタリングＸＤ１２−Ｓに、送
信制御情報を登録（エンキュー）し、図１４のフォーマ
ットの処理要求をＰＭ１８−２宛の送信処理ＦＩＦＯ
（ＸＦ２−Ｓ）（図７参照）に書き込む。この書き込み
動作は、図２１のタイミングｔ２１５で示されている。
その結果、分散メモリカップラ２２−１により送信ディ
スクリプタリング（ＸＤ１２−Ｓ）への書き込みデータ
が送信中継側の分散共有メモリ２１−１上の同一アドレ
スロケーションＹＤ−Ｓにコピーされる。同じく、送信
処理ＦＩＦＯ（ＸＦ２−Ｓ）の書き込みデータが、送信
中継ＰＭ宛送信ＦＩＦＯにもコピーされる。これによ
り、メッセージ送信に必要な全ての情報が受信中継ＰＭ
１８−２に伝達される。

【０１０３】「ステップＳ２１４」カーネルがＡＰＬオ
ブジェクト終了処理を起動し、カレントケーパビリティ
レジスタ（ＣＣＲ）５１−１の値を図２１のタイミング
ｔ２１６でクリアする。

【０１０４】（ｂ）送信システム１７−１の送信中継Ｐ
Ｍ１８−２側の処理 「ステップＳ２２０」送信中継ＰＭ１８−２のＩＮＣ送
信処理プログラムは、図３０に示すように、定期的に自
ＰＭ宛の送信処理ＦＩＦＯ（ＹＦ２−Ｓ）を読み出すこ
とにより要求の有無をチェックしている。具体的には、
図３０のステップ５２０で、送信処理ＦＩＦＯ（ＹＦ２
−Ｓ）から要求を図２１のタイミングｔ２２０で読み出
し、ステップ５２１で要求の有無をチェックする。も
し、要求があれば、ステップ５２２で読み出した要求が
指定している送信ディスクリプタリングに対して図２８
の『デキュー処理』を実行する。本実施例では、ステッ
プＳ２１３で既に送信処理ＦＩＦＯ（ＸＦ２−Ｓ）に要
求が登録されているので、ステップ５２３で、図１５
（ｃ）に示す構造の送信ディスクリプタエントリを図２
１のタイミングｔ２２０で取り出し、この情報をもとに
ネットワークを介して通信に必要な各種のプロトコル処
理（例えば、ネットワークパケットのヘッダの作成、再
送制御情報の作成、チェックサムの計算等）を行う。次
に、ステップ５２４では、ネットワークアダプタの起動
に必要なアダプタ用送信ディスクリプタを作成する。ス
テップ５２５では、このアダプタ送信ディスクリプタを
アダプタ送信ディスクリプタリングに図２０のタイミン
グｔ２２１で登録する。

【０１０５】ネットワークアダプタ２４−２は、常時、
アダプタ用送信ディスクリプタリングを監視しており、
ディスクリプタの登録があると、この情報をもとにして
ネットワークが要求するサイズにメッセージを分割し、
ヘッダや誤り制御情報を付加してネットワークパケット
としてネットワークに送出する。このタイミングは、図
２１のタイミングｔ２２２で示されている。ネットワー
クアダプタ２４−２はメッージの転送を完了するか、ま
たは通信相手のシステムからメッセージ到着確認の連絡
を受けると、送信側でメッセージバッファを保持してお
く必要がなくなったので、図２１のタイミングｔ２２３
でＭＢ管理マップエントリＹＭ１２−２を『空き』に書
き替えると、送信側分散共有メモリにも伝搬してＭＢ管
理マップエントリＹＭ１２−２がタイミングｔ２２４で
書き替えられる。その結果、これ以降は、送信ＰＭ１８
−１は、対応するＭＢ（Ｘ１２−２）を再利用すること
ができる。なお、送信中継ＰＭ１８−２では、送信ＰＭ
１８−１のように、ＭＣＲ５３、ＣＣＲ５１にケーパビ
リティを設定していないが、もし送信中継ＰＭ１８−２
内のＡＰＬオブジェクトからＭＢ（Ｙ１２−２）に不正
アクセスが行われた場合、ＭＢ（Ｙ１２−２）対応のＭ
ＣＲ５３−２に値が未設定であることにより、不正アク
セスが検出できる。

【０１０６】（ｃ）受信システム１７−２の受信中継Ｐ
Ｍ１８−３側の処理 「ステップＳ２３０」送信システム１７−１からネット
ワークパケットが届くと、受信システム１７−２の受信
中継ＰＭ１８−３のネットワークアダプタ２４−３は、
予め自分が管理している、分散共有メモリ２１−３上の
ＰＭ＃３内通信領域内の空きのローカルメッセージバッ
ファの１つに、ネットワークパケットを記憶する。メッ
セージが複数のネットワークパケットで分割されて送ら
れて来る場合には、ネットワークアダプタ２４−３は、
受信したパケットをパケットヘッダを見ながらローカル
メッセージバッファ内の指定された位置に入れることに
よりメッセージの組み立て処理を行って、最終的に１つ
のメッセージに組み立てる。そして、完成したメッセー
ジに関する制御情報をアダプタ受信ディスクリプタリン
グに登録する。受信中継ＰＭ１８−３のＩＮＣ受信処理
プログラムは、図３１，図３２に示すように、定期的に
アダプタ受信ディスクリプタリングを読み出すことによ
り要求の有無をチェックする。

【０１０７】具体的には、図３１において、ＩＮＣ受信
処理プログラムのステップ５６０で、アダプタ受信ディ
スクリプタリングに対して図２８の『デキュー処理』を
実行し、ステップ５６１でアダプタ受信ディスクリプタ
リングにエントリが登録されていたか否かをチェックす
る。図２１のステップ２３０の時点においては、到着し
たメッセージをアダプタ受信ディスクリプタに登録済み
であるため、ステップ５６２では、アダプタ受信ディス
クリプタエントリ（図３３の５９０）を図２１のタイミ
ングｔ２３０で取り出し、この情報をもとにプロトコル
受信処理（例えば、ネットワークパケットのヘッダのチ
ェック、再送制御情報の作成等）を行う。次に、ステッ
プ５６３では、アダプタ受信ディスクリプタ中のローカ
ルメッセージバッファアドレスＬＢＡ５９１を参照する
ことによりローカルメッセージバッファをアクセスし、
受信オブジェクトＩＤ（ＲＩＤ）を取り出す。ステップ
５６４では、ＲＩＤのＰＭ ＩＤフィールド（図１２の
１７２）をキーとして、ＰＭルーチングテーブル２８９
のＰＭ ＩＤフィールド＝『受信システム１７−２の受
信ＰＭ１８−２』となっているエントリと一致するの
で、通信モードフィールド２９１＝『ＰＭ間通信』とな
り、ステップ５７０に進む。

【０１０８】図３２のステップ５７０で、一致したエン
トリに対応するＭＢ管理マップアドレス＝『ＰＭ１８−
３／ＰＭ１８−２間通信ＭＢ（Ｘ３２）管理マップＺＭ
３２のベースアドレス』をＰＭルーチングテーブル２８
９から取り出す。ステップ５７１では、ＭＢ管理マップ
ＺＭ３２を参照して空きＭＢ（Ｚ３２−１）を選択し、
そのＭＢ管理マップエントリＺＭ３２−１を図２１のタ
イミングｔ２３１で『使用中』に書き替える。ＺＭ３２
−１を書き替えると、受信システムの分散メモリカップ
ラ２２−３、２２−２経由で、ＺＭ３２−１と同一アド
レスを持つ受信側分共有メモリ２１−２のＭＢ管理マッ
プエントリＹＭ３２−１も『使用中』に書き替えられ
る。次に、ステップ５７２で、ローカルメッセージバッ
ファにあるメッセージをＭＢ（Ｚ３２−１）に図２１の
タイミングｔ２３２でコピーする。このコピー操作を実
行すると、分散メモリカップラ２２−３，２２−２経由
でメッセージが受信ＰＭの分散共有メモリ２１−２のＭ
Ｂ（Ｙ３２−１）にも書き込まれる。つまり、このコピ
ー操作は、受信側分散共有メモリ２１−２に書き込みデ
ータを送るために行ったものである。

【０１０９】図３２のステップ５７３，５７４，５７５
では、送信中継ＰＭ１８−３から受信専１８−２宛の受
信ディスクリプタリングＺＤ３２−Ｒにメッセージ制御
情報を図２１のタイミングｔ２３３で書き込むととも
に、受信処理要求を受信ＰＭ１８−２宛の受信処理ＦＩ
ＦＯ（ＺＦ２−Ｒ）に書き込む。その結果、分散メモリ
カップラ２２−３，２２−１により転送されるので、受
信ディスクリプタリングＺＤ３２−Ｒの内容が受信ＰＭ
１８−２の分散共有メモリ２１−２の同一アドレスロケ
ーションであるＹＤ３２−Ｒに、また受信処理ＦＩＦＯ
（ＺＦ２−Ｒ）の内容が受信ＰＭ１８−２の分散共有メ
モリ２１−２の同一アドレスロケーションであるＹＦ２
−Ｒに、それぞれコピーされる。これにより、メッセー
ジ送信に必要な情報が受信ＰＭ１８−３に伝達された。
なお、受信中継ＰＭ１８−３においては、ＭＣＲ５３、
ＣＣＲ５１にケーパビリティを設定していないが、もし
受信中継ＰＭ１８−３内のＡＰＬオブジェクトからＭＢ
（Ｚ２３−１）に不正アクセスが行われた場合には、Ｍ
Ｂ（Ｚ３２−１）対応するＭＣＲ５３−３に値が未設定
であることにより、不正アクセスは検出できる。

【０１１０】（ｄ）受信システム１７−２の受信ＰＭ１
８−２側の処理 「ステップＳ２４０」図２１のステップＳ２４０で、カ
ーネルは次に実行すべきオブジェクトとして受信オブジ
ェクトを選択し、図２１のタイミングｔ２４０で受信オ
ブジェクトＩＤ（ＲＩＤ）を受信ＰＭ１８−２内のカレ
ントケーパビリティレジスタＣＣＲ５１−２に設定す
る。

【０１１１】「ステップＳ２４１」受信オブジェクトが
カーネルに受信処理を要求すると、カーネルは図２６の
受信処理プログラムを起動する。図２６のステップ３９
０では、受信オブジェクトのＯＣＢ（図１５（ｄ）の２
１４）が『受信側実行待ち』または『同期完了』になっ
ているか否かをテストする。このケースでは、この時点
で送信オブジェクトからのメッセージが到着していない
ので、『受信側実行待ち』あるいは『同期完了』の状態
になく、『ｎｏ』となる。そこで、ステップ３９３で、
先に受信オブジェクトの要求が到着したことを示すため
に、ＳＴＡＴＵＳフィールド２１４を『送信側実行待
ち』に設定し、カーネルにリターンする。

【０１１２】「ステップＳ２４２」カーネルは、受信オ
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるため、カーネルが図２２のＡＰＬオ
ブジェクト終了処理を起動し、ステップ３４０でカレン
トケーパビリティレジスタ（ＣＣＲ）５１−２の値を図
２１のタイミングｔ２４１でクリアし、ステップ３４１
で受信オブジェクト再開に必要な情報をＯＣＢ２１０に
退避する。

【０１１３】「ステップＳ２５０」受信ＰＭ１８−２の
ＩＯＣ配信プログラムは、図２９に示すように、定期的
にＰＭ＃２宛の受信処理ＦＩＦＯ（ＹＦ２−Ｒ）を読み
出すことにより受信処理要求の有無をチェックする。具
体的には、図２９のステップ５００で、ＦＩＦＯから要
求を図２１のタイミングｔ２５０で読み出し、ステップ
５０１で要求の有無をチェックする。もし、要求があれ
ば、ステップ５０２で、読み出した要求が指定している
受信ディスクリプタリング（ＹＤ１２−Ｒ）に対して図
２８の『デキュー処理』を実行する。ステップ５０３で
は、図１５（ｃ）の受信ディスクリプタエントリを同じ
タイミングｔ２５０で取り出し、そのエントリのＭＢＡ
（図１５（ｃ）の２０２）を参照して、図１５（ａ）で
示される構造のＭＢ（Ｙ３２−１）をアクセスする。そ
して、ＭＢ（Ｙ３２−１）内の受信オブジェクトＩＤ
（ＲＩＤ）（図１５（ａ）の１８３）を取り出す。ステ
ップ５０４では、ＲＩＤ１８３に対応するＯＣＢ（図１
５の２１０）のメッセージキューにＭＢ（Ｙ３２−１）
のアドレスＭＢＡ２０２を登録する。

【０１１４】図２９のステップ５０５では、この受信オ
ブジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド２
１４が『送信側実行待ち』となっているか否かをテスト
する。このケースでは、図２１のステップＳ２４１で、
ＳＴＡＴＵＳフィールド２１４を『送信側実行待ち』と
設定しているので、ステップ５０５は『ｙｅｓ』とな
る。これは、受信オブジェクトが送信側からメッセージ
を受け取る準備をして休止状態にいることを表わしてい
る。従って、ステップ５０６では、受信オブジェクトの
ＯＣＢ２１０のＳＴＡＴＵＳフィールド２１４を『同期
完了』と設定して、送信要求と受信要求の両方が揃った
ことを表示する。次に、ステップ５０７では、受信オブ
ジェクトのＯＣＢ２１０をレディキューに登録して、受
信オブジェクトが再起動されるようにする。

【０１１５】「ステップＳ２６０」カーネルは、レディ
キューの中から次に実行すべきオブジェクトとして受信
オブジェクトを選択し、図２１のタイミングｔ２６０
で、受信オブジェクトＩＤ（ＲＩＤ）を受信ＰＭ１８−
２内のカレントケーパビリティレジスタ（ＣＣＲ）５１
−２に設定する。

【０１１６】「ステップＳ２６１」受信オブジェクトの
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図２６の受信処理プログラ
ムを起動する。図２６のステップ３９０では、受信オブ
ジェクトのＯＣＢ２１０のＳＴＡＴＵＳフィールド２１
４が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。このケースでは、図２１のステ
ップＳ２５０でＳＴＡＴＵＳフィールド２１４を『同期
完了』と設定しているので、ステップ３９０は『ｙｅ
ｓ』となる。これは、メッセージが送信側から既に届い
ているので、直ちにメッセージを読み出してもよいこと
を示している。そこで、ステップ３９１で、ＯＣＢ２１
０のメッセージキューにつながっているメッセージを参
照して、キューから外し、そのＭＢ（Ｙ３２−１）のア
ドレスを取り出す。次に、ステップ３９２では、このＭ
Ｂアドレスに対応するＭＣＲ５３−２に受信オブジェク
トＩＤ（ＲＩＤ）を設定する。このタイミングは、図２
１のタイミングｔ２６１で示されている。これにより、
ＣＣＲ５１−２とＭＣＲ５３−２の両方に受信オブジェ
クトＩＤ（ＲＩＤ）が設定されたので、それ以降は、Ｍ
Ｂ（Ｙ３２−１）が受信オブジェクト以外のＡＰＬオブ
ジェクトからアクセスできないようにプロテクトされ
た。

【０１１７】「ステップＳ２６２」受信オブジェクトが
ＭＢ（Ｙ３２−１）から、図２１のタイミングｔ２６２
で受信側分散共有メモリ２１−２のＭＢ（Ｙ３２−１）
からメッセージを読み出し、対応する処理を行う。ＭＢ
（Ｙ３２−１）からの読み出しは、自プロセッサモジュ
ール内に閉じたローカルなメモリアクセスであるため、
リモートメモリアクセスを行う場合に比較して極めて高
速である。

【０１１８】「ステップＳ２６３」受信オブジェクト
は、カーネルにＭＢ解放を依頼する。カーネルは、図２
４のＭＢ解放処理プログラムを起動し、図２４のステッ
プ３６０で、ＭＢ（Ｙ３２−１）に対応するＭＣＲ５３
−２をクリアする。このタイミングは、図２１のタイミ
ングｔ２６３に示されている。次に、図２４のステップ
３６１では、ＭＢ（３２−１）に対応するＭＢ管理マッ
プエントリＹＭ３２−１を『空き』という値に書き替え
る。このタイミングは、図２１のタイミングｔ２６４に
示されている。この値の書き替えは、受信側の分散共有
メモリ２１−２のみならず、同時に分散メモリカップラ
２２−２，２２−１経由で、受信中継側分散共有メモリ
２１−３の同一番地ＺＭ３２−１に対しても行われる。
図２１のタイミングｔ２６５で、受信中継ＰＭ１８−３
のＭＢ管理マップエントリＺＭ３２−１が『空き』に書
き替えられた時点以降は、受信中継ＰＭ１８−３のＭＢ
（Ｚ３２−１）をいつでも再利用することができる。

【０１１９】「ステップＳ２６４」カーネルがＡＰＬオ
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ（ＣＣＲ）５１−２の値を図２１のタイミン
グｔ２６６でクリアする。以上のように、システム間Ｐ
Ｍ中継通信においても、分散メモリカップラ２２の働き
により、送受信中継ＰＭを介してもメッセージおよびそ
の制御情報を送信ＰＭと受信ＰＭ間で極めて簡単、かつ
高速に転送することができるので、効率的なメッセージ
通信が実現される。本実施例においては、図２９のＩＯ
Ｃ配信処理、図３０のＩＮＣ送信処理、図３１，図３２
のＩＮＣ受信処理は、分散共有メモリの特定番地を読み
出すことにより要求を検出する、いわゆるポーリング型
の処理方式で説明したが、これらを図８に示す割り込み
データタイプのパケットと図１の割り込み制御部４２の
機能を用いて割り込み型の処理方式で実現することも可
能である。

【０１２０】（本発明のまとめ）このように、本発明に
おいては、各プロセッサモジュールが分散共有メモリと
分散メモリカップラとを持ち、分散メモリカップラは、
その分散共有メモリのアドレスを共有しているプロセッ
サモジュール情報を記憶する。そして、送信側のプロセ
ッサモジュールの分散共有メモリの共有アドレスロケー
ションへの書き込みが発生した時点で、分散メモリカッ
プラが、アドレスを共有する他のプロセッサモジュール
に書き込み情報を転送し、書き込み情報を受けた受信側
の分散メモリカップラが受信側の分散共有メモリへコピ
ーを行う。この転送動作は、ソフトウェアの介在なしで
実行されるので、従来では、分散共有メモリ間転送用と
してわざわざ必要であったＤＭＡ機構制御用プログラム
の実行は不要となり、ソフトウェアオーバヘッドを大幅
に削減することができる。また、ＤＭＡ機構を使用する
従来の方式では、転送データが全部揃ってから転送を開
始するのに対して、本発明では、送信元の分散共有メモ
リへの書き込みが発生した時点で、相手側の分散共有メ
モリへの転送が開始されるので、メッセージが送信側か
ら受信側に伝達されるまでの遅延時間（レイテンシー）
も大幅に削減される。さらに、分散メモリカップラに登
録するプロセッサモジュール情報に応じて、一方向性通
信、両方向通信、放送型通信等の各種の通信パターンを
自由に実現することができるので、柔軟性が高い。

【０１２１】また、本発明における送信プロセッサモジ
ュールと受信プロセッサモジュール間のメッセージ通信
では、送信プロセッサモジュールでメッセージバッフ
ァ、メッセージの制御情報であるＭＢディスクリプタ、
メッセージバッファ使用状態を示すＭＢ管理マップを分
散共有メモリに配置している。送信プロセッサモジュー
ルが、これらの情報を送信側分散共有メモリに書き込
み、受信側プロセッサモジュールが分散共有メモリの同
じアドレスロケーションから読み出すだけでよいので、
プロセッサモジュール間の通信の同期を簡単かつ容易に
行うことができる。また、受信側プロセッサモジュール
が受信側分散共有メモリのＭＢディスクリプタとＭＢ管
理マップに返事を書き込み、送信側プロセッサモジュー
ルが受信側分散共有メモリの同じアドレス位置のＭＢデ
ィスクリプタとＭＢ管理マップから読み出すことによ
り、ＭＢディスクリプタやＭＢに関する状態を簡単に送
信側に伝達することができ、ＭＢディスクリプタやＭＢ
再使用すればよいか等を簡単に知ることができる。

【０１２２】さらに、本発明では、受信側プロセッサモ
ジュールの分散共有メモリの、あるアドレスロケーショ
ンをＦＩＦＯ構造にしておくことにより、送信側プロセ
ッサモジュールが自分の分散共有メモリに書き込んだ情
報が、受信側分散共有メモリのＦＩＦＯに順次書き込ま
れる。その結果、複数の送信側プロセッサモジュールが
同時に、それぞれの分散共有メモリの同一番地に書き込
みを行った場合にも、受信側の分散共有メモリのＦＩＦ
Ｏで競合整理が行われてＦＩＦＯに順次書き込まれ、ソ
フトウェアによる競合処理を全く必要としない。受信側
は、分散共有メモリ内の要求登録ＦＩＦＯを順次読み出
すのみで、実際に発生した要求のみを効率よく取り出す
ことができ、従来のような多数の監視点を順次サーチし
ていくための処理オーバヘッドを大幅に削減することが
できる。このように、例えば同一メモリエリアへの同時
アクセス等、従来、マルチプロセッサシステムで大きな
問題となっていたプロセッサ間のリソース競合を回避す
ることができるので、多数のプロセッサを組み合わせた
超並列コンピュータシステムを構築した場合でも、プロ
セッサの台数に応じた大きな処理能力を持たせることが
可能である。

【０１２３】

【発明の効果】以上説明したように、本発明によれば、
カーネル等のシステムソフトウェアのオーバヘッドを削
減することができるとともに、転送遅延時間が短く、処
理効率の高いメッセージ転送を実現することが可能であ
る。

【図面の簡単な説明】

【図１】本発明の一実施例を示すプロセッサモジュール
の内部構成図である。

【図２】従来のマルチプロセッサシステムの構成図であ
る。

【図３】従来のプロセッサ間メッセージ通信方法を示す
シーケンスチャートである。

【図４】本発明の一実施例を示すマルチプロセッサシス
テムの構成図である。

【図５】本発明における分散共有メモリのデータ配置を
示す図である。

【図６】同じく、分散共有メモリのデータ配置の残りを
示す図である。

【図７】同じく、分散共有メモリのデータ配置の残りを
示す図である。

【図８】本発明におけるモジュールＩＤ管理部の構成図
である。

【図９】本発明におけるパケット送信レジスタと、パケ
ット受信レジスタのデータフォーマット図である。

【図１０】本発明におけるシステム内メッセージ通信の
概要を示す図である。

【図１１】本発明におけるシステム間メッセージ通信の
概要を示す図である。

【図１２】本発明におけるオブジェクトＩＤのフォーマ
ット図である。

【図１３】本発明における送信ディスクリプタと送信処
理要求のメモリ配置図である。

【図１４】本発明における送信処理要求のフォーマット
図である。

【図１５】本発明における各種制御データの構造を示す
図である。

【図１６】本発明におけるレディキューの構造を示す図
である。

【図１７】本発明におけるシステムルーチングテーブル
とＰＭルーチングテーブルの構造図である。

【図１８】本発明におけるシステム内ＰＭ内通信のタイ
ムチャートである。

【図１９】本発明におけるシステム内ＰＭ間通信のタイ
ムチャートである。

【図２０】本発明におけるシステム間ＰＭ無中継通信の
タイムチャートである。

【図２１】本発明にかけるシステム間ＰＭ中継通信のタ
イムチャートである。

【図２２】本発明におけるアプリケーションオブジェク
トの起動、終了処理のフローチャートである。

【図２３】本発明におけるＭＢ捕捉処理のフローチャー
トである。

【図２４】本発明におけるＭＢ解放処理のフローチャー
トである。

【図２５】本発明における送信処理のフローチャートで
ある。

【図２６】本発明における受信処理のフローチャートで
ある。

【図２７】本発明におけるエンキュー処理のフローチャ
ートである。

【図２８】本発明におけるデキュー処理のフローチャー
トである。

【図２９】本発明におけるＩＯＣ配信処理のフローチャ
ートである。

【図３０】本発明におけるＩＮＣ送信処理のフローチャ
ートおよびアダプタ送信ディスクリプタの構造図であ
る。

【図３１】本発明におけるＩＮＣ受信処理のフローチャ
ートである。

【図３２】同じく、ＩＮＣ受信処理の残りのフローチャ
ートである。

【図３３】本発明におけるアダプタ受信ディスクリプタ
の構造図である。

【符号の説明】

１７・・マルチプロセッサシステム、 １８−１，１８−２，１８−３・・プロセッサモジュー
ル、 １９−１，１９−２，１９−３・・プロセッサ、 ２０−１，２０−２，２０−３・・ローカルメモリ、 ２１−１，２１−２，２１−３・・分散共有メモリ、 ２２−１，２２−２，２２−３・・分散メモリカップ
ラ、 ２３−１，２３−２，２３−３・・分散メモリプロテク
タ、 ２４−１，２４−２，２４−３・・ネットワークアダプ
タ、 ２５・・プロセッサモジュール間通信路、 ２６・・通信ネットワーク、３４・・モジュールＩＤ管
理部、 ３５・・パケット送信レジスタ、３６・・パケット送信
バッファ、 ３７・・パケット受信バッファ、３８・・パケット受信
レジスタ、 ５０・・ＭＣＲメモリ（メモリケーパビリティレジスタ
メモリ）、 ５１・・ＣＣＲ（カレントケーパビリティレジスタ）、 ５３・・ＭＣＲ、６０・・モジュールＩＤディレクト
リ、 ６１・・ＣＡＭ（Content Addressable Memory)、 ６２・・データメモリ部、

───────────────────────────────────────────────────── フロントページの続き (72)発明者 田中 聡 東京都千代田区内幸町１丁目１番６号 日本電信電話株式会社内 (56)参考文献 特開 平４−291660（ＪＰ，Ａ) 特開 平６−19785（ＪＰ，Ａ) Ｍａｔｔｈｉａｓ Ａ．Ｂｌｕｍｒｉ ｃｈ，Ｋａｉ Ｌｉ，Ｒｉｃｈａｒｄ Ａｐｌｐｅｒｔ，Ｃｅｚａｒｙ Ｄｕｂ ｎｉｃｋｉ，Ｅｄｗａｒｄ Ｗ．Ｆｅｌ ｔｅｎ，Ｖｉｒｔｕａｌ Ｍｅｍｏｒｙ Ｍａｐｐｅｄ Ｎｅｔｗｏｒｋ Ｉｎ ｔｅｒｆａｃｅ ｆｏｒ ｔｈｅ ＳＨ ＲＩＭＰ Ｍｕｌｔｉｃｏｍｐｕｔｅ ｒ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔ ｈｅ 21ｓｔ Ａｎｎｕａｌ Ｉｎｔｅ ｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕ ｍ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｒｃｈ ｉｔｅｃｕｔｕｒｅ，米国，ＩＥＥＥ, 1994年４月18日，Ｐ．142−152 Ｓｔｅｖｅｎ Ｋ．Ｒｅｉｎｈａｒｄ ｔ，Ｊａｍｅｓ Ｒ．Ｌａｒｕｓ，Ｄａ ｖｉｄ Ａ．Ｗｏｏｄ，Ｔｅｍｐｅｓｔ ａｎｄ Ｔｙｐｈｏｏｎ：Ｕｅｓｒ− Ｌｅｖｅｌ Ｓｈａｒｅｄ Ｍｅｎｏｒ ｙ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔ ｈｅ 21ｓｔ Ａｎｎｕａｌ Ｉｎｔｅ ｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕ ｍ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｒｃｈ ｉｔｅｃｈｔｕｒｅ，米国，ＩＥＥＥ, 1994年４月18日，Ｐ．325−336 村山秀樹、他５名，マルチコンピュー タにおけるノード間高速通信アーキテク チャの検討，情報処理学会研究報告，日 本，社団法人情報処理学会，1994年３月 11日，Ｖｏｌ．94，Ｎｏ．22，（94−Ａ ＲＣ−105，94−ＨＰＣ−50），Ｐ．89 −96 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/16 - 15/177 G06F 9/46 - 9/54

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 複数のプロセッサモジュールから構成さ
   れたマルチプロセッサシステムにおいて、 上記プロセッサモジュールには、 各プロセッサモジュール間で共通のアドレスを有し、送
   信プロセッサモジュールと受信プロセッサモジュールの
   組み合わせで指定される管理単位毎に分割された分散共
   有メモリと、 上記送信プロセッサモジュールの分散共有メモリ（以
   下、送信側分散共有メモリ）とアドレスを共有する受信
   プロセッサモジュールの識別情報を記憶し、該送信側分
   散共有メモリへの書き込みが発生すると、上記受信プロ
   セッサモジュールの識別情報で指定された受信プロセッ
   サモジュールに、書き込みアドレスと書き込みデータを
   送信するとともに、受信した書き込みアドレスと書き込
   みデータをもとに受信プロセッサモジュールの分散共有
   メモリ（以下、受信側分散共有メモリ）の、送信側と同
   一のアドレスロケーションにコピーを行う分散共有メモ
   リ制御手段と、 送信するメッセージの宛先情報をもとに受信プロセッサ
   モジュールを特定し、上記分散共有メモリ上の送信プロ
   セッサモジュールと受信プロセッサモジュールの組み合
   わせで指定されるメッセージバッファを補捉するメッセ
   ージバッファ管理手段とを有し、 送信プロセッサモジュールから受信プロセッサモジュー
   ルにメッセージを送信する場合に、送信プロセッサモジ
   ュールは、上記メッセージバッファ管理手段により上記
   受信プロセッサモジュール対応の送信メッセージバッフ
   ァを補捉し、該送信メッセージバッファに上記メッセー
   ジを書き込み、 該送信プロセッサモジュールと受信プロセッサモジュー
   ルとが同一モジュールである場合には、上記受信プロセ
   ッサモジュールは、上記送信メッセージバッファから、
   直接、メッセージを読み出すことにより、同一プロセッ
   サ内メッセージ通信を行い、 送信プロセッサモジュールと受信プロセッサモジュール
   が異なるモジュールである場合には、送信側の分散共有
   メモリ制御手段が、上記送信メッセージバッファのアド
   レスをもとに受信プロセッサモジュール識別情報を取り
   出し、該識別情報の受信プロセッサモジュールに送信メ
   ッセージバッファアドレスと書き込みデータを転送し、 受信側の分散共有メモリ制御手段は、受信した上記送信
   メッセージバッファのアドレスと上記書き込みデータを
   もとに受信側の分散共有メモリの、送信側と同一アドレ
   スの受信メッセージバッファにコピーを行い、 上記受信プロセッサモジュールでは、上記受信メッセー
   ジバッファからメッセージを読み出すことにより、異な
   るプロセッサ間のメッセージ通信を行うことを特徴とす
   るマルチプロセッサシステム。
2. 【請求項２】 請求項１に記載のマルチプロセッサシス
   テムにおいて、上記受信側の分散共有メモリ制御手段
   は、さらにアドレスを共有する送信プロセッサモジュー
   ルの識別情報を記憶し、 上記送信プロセッサモジュールでは、該送信プロセッサ
   モジュールと受信プロセッサモジュールの組み合わせで
   指定される分散共有メモリ上の送信制御エリアに、メッ
   セージ制御情報あるいはメッセージバッファ管理情報を
   含む制御データを書き込み、 送信プロセッサモジュールと受信プロセッサモジュール
   とが同一モジュールである場合には、該受信プロセッサ
   モジュールは、上記送信制御エリアから、直接、制御デ
   ータを読み出してメッセージあるいはメッセージバッフ
   ァに関する制御内容を認識し、対応する処理を実行した
   後、上記送信制御エリアに返答制御データを書き込み、 上記送信プロセッサモジュールは、上記送信制御エリア
   から上記返答制御データを読み出して受信側での処理結
   果を認識することにより、同一プロセッサモジュール内
   双方向通信を行い、 送信プロセッサモジュールと受信プロセッサモジュール
   が異なるモジュールである場合には、上記送信側の分散
   共有メモリ制御手段は、上記送信制御エリアのアドレス
   をもとに受信プロセッサモジュール識別情報を取り出
   し、該送信制御エリアアドレスと書き込みデータを上記
   受信プロセッサモジュールに転送し、 上記受信側の分散共有メモリ制御手段は、受信した上記
   送信制御エリアアドレスと上記書き込みデータをもとに
   受信側分散共有メモリの、送信側と同一アドレスの受信
   制御エリアにコピーを行い、 上記受信プロセッサモジュールは、上記受信制御エリア
   から制御データを読み出して、メッセージあるいはメッ
   セージバッファに関する制御内容を認識し、対応する処
   理を実行した後、上記受信制御エリアに返答制御データ
   を書き込むと、 受信側の分散共有メモリ制御手段は、上記受信制御エリ
   アアドレスをもとに、上記送信プロセッサモジュール識
   別情報を取り出し、該識別情報をもとに上記受信制御エ
   リアアドレスと上記返答制御データを上記送信プロセッ
   サモジュールに転送し、 上記送信側の分散共有メモリ制御手段は、受信した上記
   受信制御エリアアドレスと上記返答制御データをもとに
   送信側分散共有メモリの、受信側と同一アドレスの送信
   制御エリアにコピーを行い、 上記送信プロセッサモジュールでは、上記送信制御エリ
   アから上記返答制御データを読み出して、受信側での処
   理結果を認識することにより、プロセッサモジュール間
   双方向通信を行うことを特徴とするマルチプロセッサシ
   ステム。
3. 【請求項３】 複数のプロセッサモジュールから構成さ
   れたマルチプロセッサシステムにおいて、 上記プロセッサモジュールには、 各プロセッサモジュール間で共通の同一アドレスを有
   し、受信プロセッサモジュール対応の管理単位毎に分割
   された分散共有メモリと、 送信側分散共有メモリとアドレスを共有する受信プロセ
   ッサモジュールの識別情報を記憶し、送信側分散共有メ
   モリへの書き込みが発生すると、上記受信プロセッサモ
   ジュール識別情報で指定された受信プロセッサモジュー
   ルに書き込みアドレスと書き込みデータを送信するとと
   もに、受信した書き込みアドレスと書き込みデータをも
   とに受信側分散共有メモリの、送信側と同一のアドレス
   ロケーションに書き込みを行う分散共有メモリ制御手段
   とを有し、 上記受信側の分散共有メモリのエリアはＦＩＦＯメモリ
   で構成され、 複数の送信プロセッサモジュールから１つの受信プロセ
   ッサモジュールに処理要求を通知する際に、上記送信プ
   ロセッサモジュールと受信プロセッサモジュールが同一
   のモジュールである場合には、上記送信プロセッサモジ
   ュールでは、送信側分散共有メモリ上の自プロセッサモ
   ジュール宛処理要求ＦＩＦＯエリアに、処理要求データ
   を書き込み、 上記送信プロセッサモジュールと受信プロセッサモジュ
   ールが異なるモジュールである場合には、上記送信プロ
   セッサモジュールでは、上記送信側分散共有メモリ上の
   受信プロセッサモジュール宛処理要求ＦＩＦＯエリア
   に、処理要求データを書き込み、 送信側分散共有メモリ制御手段は、上記処理要求エリア
   のアドレスをもとに受信プロセッサモジュール識別情報
   を取り出し、上記処理要求エリアアドレスと書き込みデ
   ータを受信プロセッサモジュールに転送し、 受信側分散共有メモリ制御手段は、受信した上記処理要
   求ＦＩＦＯエリアアドレスと上記書き込みデータをもと
   に受信側分散共有メモリの、送信側と同一アドレスの上
   記処理要求ＦＩＦＯエリアに書き込むことにより、上記
   処理要求ＦＩＦＯエリアに複数の処理要求データを到着
   順に蓄積し、 上記受信側プロセッサモジュールでは、受信側分散共有
   メモリ上の上記要求ＦＩＦＯエリアから複数の上記処理
   要求データを順次読み出すことにより、処理要求を検出
   することを特徴とするマルチプロセッサシステム。
4. 【請求項４】 請求項１ないし３のいずれか１つに記載
   のマルチプロセッサシステムにおいて、上記送信側分散
   共有メモリ制御手段は、送信側分散共有メモリの連続す
   る複数のアドレスロケーションに複数のデータが連続的
   に書き込まれた場合、上記複数のデータの先頭アドレス
   と複数のデータとをまとめて受信プロセッサモジュール
   に一括送信し、 受信側分散共有メモリ制御手段は、一括受信した上記先
   頭アドレスと上記複数のデータをもとに受信側分散共有
   メモリ上の同一アドレスロケーションに連続的にコピー
   を行うことを特徴とするマルチプロセッサシステム。
5. 【請求項５】 複数のプロセッサモジュールから構成さ
   れたマルチプロセッサシステムにおいて、 上記プロセッサモジュールには、 各プロセッサモジュール間で共通のアドレスを有し、送
   信プロセッサモジュー ルと受信プロセッサモジュールの
   組み合わせで指定される管理単位毎に分割された分散共
   有メモリと、 上記送信プロセッサモジュールの分散共有メモリ（以
   下、送信側分散共有メモリ）とアドレスを共有する受信
   プロセッサモジュールの識別情報を記憶し、該送信側分
   散共有メモリへの書き込みが発生すると、上記受信プロ
   セッサモジュールの識別情報で指定された受信プロセッ
   サモジュールに、書き込みアドレスと書き込みデータを
   送信するとともに、受信した書き込みアドレスと書き込
   みデータをもとに受信プロセッサモジュールの分散共有
   メモリ（以下、受信側分散共有メモリ）の、送信側と同
   一のアドレスロケーションにコピーを行う分散共有メモ
   リ制御手段と、 送信するメッセージの宛先情報をもとに受信プロセッサ
   モジュールを特定し、上記分散共有メモリ上の送信プロ
   セッサモジュールと受信プロセッサモジュールの組み合
   わせで指定されるメッセージバッファを補捉するメッセ
   ージバッファ管理手段とを有することを特徴とするマル
   チプロセッサシステム。