JPH0863442A - マルチプロセッサシステム - Google Patents
マルチプロセッサシステムInfo
- Publication number
- JPH0863442A JPH0863442A JP6202071A JP20207194A JPH0863442A JP H0863442 A JPH0863442 A JP H0863442A JP 6202071 A JP6202071 A JP 6202071A JP 20207194 A JP20207194 A JP 20207194A JP H0863442 A JPH0863442 A JP H0863442A
- Authority
- JP
- Japan
- Prior art keywords
- transmission
- processor module
- reception
- shared memory
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Storage Device Security (AREA)
- Multi Processors (AREA)
Abstract
削減し、かつ転送遅延時間が短く、処理効率の高いマル
チプロセッサシステムのメッセージ転送を実現する。 【構成】 各プロセッサモジュールは分散共有メモリと
分散メモリカップラとを備え、分散メモリカップラは、
送信側の分散共有メモリに書き込みがあった時点で、ア
ドレスを共有する他のプロセッサモジュールに書き込み
情報を転送し、受信側のメモリにコピーする。MB管理
マップを分散共有メモリに配置することにより、送信側
分散共有メモリに書き込み、受信プロセッサモジュール
が同一アドレスロケーションから読み出すだけで通信の
同期をとることができる。返事は、MBディスクリプタ
とMB管理マップに書き込まれると、送信側が読み出す
ことにより、状態を送信側に伝達できる。また、受信側
分散共有メモリをFIFO構成にすることにより、処理
要求の検出を簡単に行うことができる。
Description
ュールから構成されるマルチプロセッサシステムに関
し、特に転送遅延時間が短く、プロセッサモジュール間
のリソース競合を回避でき、処理効率の高いメッセージ
転送が可能なマルチプロセッサシステムに関するもので
ある。
プロセッサシステムを用いて、複数のオブジェクト(並
列実行の単位となるプロセス)の間でメッセージを交信
しながら処理を進めるオブジェクト指向分散処理方式が
提案されている。例えば、T.Shimizu et al.“Low
-Latency Communication Support for theAP
1000",Proceedings of the 19th International
Symposium onComputer Architecture,pp.288〜29
7,1992には、上記のようなオブジェクト指向分散処理方
式が記述されている。図2および図3は、上記文献によ
る従来例を示すシステム構成図およびプロセッサ間メッ
セージ通信方法を示すシーケンスチャートである。図2
において、1−1,1−2はマルチプロセッサシステム
におけるプロセッサモジュール(PM)、2−1,2−
2はプロセッサモジュール内のプロセッサ、3−1,3
−2はそれぞれ対応するプロセッサ1−1,1−2から
読み書きアクセスが可能なローカルメモリ、4−1,4
−2はPM間でメッセージ転送を行うためのDMA(Di
rect Memory Access)コントローラ、5はプロセッサ
間通信路、6はローカルメモリ3−1上に設けられたメ
ッセージバッファエリア、7は同じくローカルメモリ3
−2上に設けられたメッセージバッファエリアである。
いて、PM1−1からPM1−2にメッセージを転送す
る場合のシーケンスを、図3により説明する。S1はメ
ッセージバッファ要求、S2はメッセージバッファエリ
ア6の確保、S3はメッセージバッファエリア6へメッ
セージを書込み、S4は送信要求、S5はDMAコント
ローラ4−1に制御情報設定、S6はDMA起動、S7
はメッセージバッファエリア6からプロセッサ間通信路
5へ転送、S8はプロセッサ間転送、S9は受信一時バ
ッファに記憶、S10は割込み、S11はメッセージバ
ッファエリア7の確保、S12はDMAコントローラ4
−2に制御情報設定、S13はDMA起動、S14は受
信一時バッファからメッセージバッファエリア7に転
送、S15は割込み、S16は受信先の特定、S17は
受信オブジェクト起動、S18はメッセージの読出しの
各ステップを示している。図3におけるプロセッサモジ
ュール1−1の送信オブジェクト10からメッセージバ
ッファ要求S1があると、オペレーティングシステムの
中心的プログラムであるカーネル11−1がステップS
2でメッセージバッファエリア6をローカルメモリ3−
1内に確保し、送信オブジェクト10に通知する。送信
オブジェクト10は、ステップS3でメッセージバッフ
ァエリア6にメッセージを書き込む。図2においては、
太線矢印L10で示されている。送信オブジェクト10
はカーネル11−1にステップS4で送信要求を出し、
カーネル11−1はステップS5でメッセージバッファ
エリア6の先頭アドレス(図2のADR1)とメッセー
ジサイズ(図2のn)、および転送先のプロセッサモジ
ュール番号等の制御情報をDMAコントローラ4−1に
設定する。これは、図2においては、太線矢印L11で
示される。カーネル11−1は、ステップS6でDMA
コントローラ4−1を起動し、DMAコントローラ4−
1は設定された制御情報に従って、ステップS7,S8
でメッセージをメッセージバッファエリア6から順次読
み出し、プロセッサ間通信路5を経由して受信側PM1
−2のDMAコントローラ4−2に転送する。これは、
図2では、太線矢印L12で示される。
9でメッセージを一時記憶に蓄積すると同時に、並行し
てステップS10でプロセッサ2−2のカーネル11−
2に割り込みをかける。これは、図2においては、太線
矢印L13で示される。カーネル11−2は、ステップ
S11で受信側PM1−2のローカルメモリ3−2上に
メッセージバッファエリア7のアドレス(図2のADR
2)とメッセージサイズ(図2のn)等の制御情報を設
定する。カーネル11−2がステップS13でDMA起
動を行うと、DMAコントローラ4−2はステップS1
4でメッセージをメッセージバッファエリア7に転送し
(図2の太線矢印L14)、ステップS15でカーネル
11−2に転送終了を通知する。カーネル11−2は、
ステップS16でメッセージ内に書込まれた宛先を見
て、図2の受信オブジェクト12を特定し、ステップS
17で起動する。受信オブジェクト12がステップS1
8でローカルメモリ3−2内のメッセージバッファ7か
らメッセージを読み出す(これは図2の太線矢印L1
5)。以上の手順により、PM間のメッセージ転送が行
われる。
オブジェクト10がステップS3でメッセージバッファ
エリア6に書き込んだ段階で、受信PM宛のメッセージ
転送をできるだけ早く開始することが望ましい。また、
受信側においても、図3のステップS9でメッセージを
受信した段階で、できるだけ早く受信オブジェクト12
にメッセージを引き渡すことが望ましい。しかしなが
ら、従来の技術では、図3に示すように、ステップS5
とステップS12のDMA起動準備処理や、ステップS
11における受信側でのメッセージバッファエリアの捕
捉、ステップS10,S15における割り込み処理等が
あり、メッセージ送受信を終了させるまでには多くのカ
ーネル処理が必要である。その結果、メッセージ転送遅
延の増加とカーネルの処理オーバヘッド増加を招くとい
う問題がある。特に、プロセッサ間通信路5の転送速度
が大きい場合には、上記処理オーバヘッドによる転送遅
延の比率は相対的に増加するため、処理オーバヘッドの
削減と転送遅延時間の短縮が必須の条件となってくる。
また、ステップS10,S15では、送信PMからのメ
ッセージ到着を通知する方法として割り込みを用いてい
る。しかし、割り込み要求を受け付けるためには、現在
実行中の情報を退避して、割り込み処理に切り替えるた
めのカーネルの処理オーバヘッドが一般に大である。従
って、割り込み方式を多数のPMを含む超並列システム
に適用した場合には、単位時間当りの割り込み回数の増
加により、処理オーバヘッドが非常に大となって、転送
遅延も増大するという問題が生じる。
り、ポーリング方式と呼ばれる要求受け付け方式が用い
られている。ポーリング方式は、プロセッサ側が外部か
らの処理要求を予め決められたメモリやレジスタ等に記
憶させておき、処理が可能になると、プロセッサが処理
要求を読み出してきて処理を開始する方法である。この
ように、ポーリング方式は、割り込み方式に比較して処
理切り替えのオーバヘッドが少ないが、処理要求を記憶
する全てのメモリやレジスタを読み出す必要があるた
め、処理要求の発生頻度が少ない場合には処理要求の読
み出しが空振りに終る、つまり処理要求が発生していな
い現象となることも多い。特に、多数のPMを有する超
並列システムでは、処理要求の数および種類が多いた
め、それらの全てを定期的に読み出すための処理オーバ
ヘッドが大きく、空振りの回数も増加して処理効率が低
下するという問題があった。また、本出願人は本願に先
立って、『分散共有メモリシステム』(特願平6−74
669号明細書および図面参照)を提案した。上記発明
においては、分散共有メモリを送信プロセッサモジュー
ルと受信プロセッサモジュールの組み合わせ毎に対応し
て分割し、各プロセッサモジュールからメッセージを送
信する場合、自プロセッサモジュールを送信元とする受
信プロセッサモジュール対応のエリアを使用する。その
結果、異なる2つの送信プロセッサモジュールから同一
受信プロセッサモジュールにメッセージ通信要求が同時
に発生しても、互いに使用するメッセージバッファが重
複することがなく、メッセージバッファ確保のための競
合処理に伴う性能低下や性能ボトルネックを回避するこ
とができる。本発明の目的は、上記のような従来の課題
を解決し、先願の発明を利用して、カーネル等のシステ
ムソフトウェアのオーバヘッドを削減するとともに、転
送遅延時間を短縮して、処理効率の高いメッセージ転送
を実現できるマルチプロセッサシステムを提供すること
にある。
め、本発明のマルチプロセッサシステムは、 (イ)複数のプロセッサモジュール(18)から構成さ
れたマルチプロセッサシステム(17)において、上記
プロセッサモジュール(18)には、各プロセッサモジ
ュール間で共通のアドレスを有し、送信プロセッサモジ
ュールと受信プロセッサモジュールの組み合わせで指定
される管理単位毎に分割された分散共有メモリ(21)
と、上記送信プロセッサモジュールの分散共有メモリ
(以下、送信側分散共有メモリ21)とアドレスを共有
する受信プロセッサモジュールの識別情報を記憶し、該
送信側分散共有メモリ(21)への書き込みが発生する
と、上記受信プロセッサモジュールの識別情報で指定さ
れた受信プロセッサモジュールに、書き込みアドレスと
書き込みデータを送信するとともに、受信した書き込み
アドレスと書き込みデータをもとに受信プロセッサモジ
ュールの分散共有メモリ(以下、受信側分散共有メモリ
21)の、送信側と同一のアドレスロケーションにコピ
ーを行う分散共有メモリ制御手段(22)と、送信する
メッセージの宛先情報をもとに受信プロセッサモジュー
ルを特定し、上記分散共有メモリ上の送信プロセッサモ
ジュールと受信プロセッサモジュールの組み合わせで指
定されるメッセージバッファ(16)を捕捉するメッセ
ージバッファ管理手段(200)とを有し、送信プロセ
ッサモジュール(18)から受信プロセッサモジュール
(18)にメッセージを送信する場合に、送信プロセッ
サモジュールは、上記メッセージバッファ管理手段(2
00)により上記受信プロセッサモジュール対応の送信
メッセージバッファ(180)を捕捉し、該送信メッセ
ージバッファ(180)に上記メッセージを書き込み、
該送信プロセッサモジュール(18)と受信プロセッサ
モジュール(18)とが同一モジュールである場合に
は、上記受信プロセッサモジュール(18)は、上記送
信メッセージバッファから、直接、メッセージを読み出
すことにより、同一プロセッサ内メッセージ通信を行
い、送信プロセッサモジュールと受信プロセッサモジュ
ールが異なるモジュールである場合には、送信側の分散
共有メモリ制御手段(22)が、上記送信メッセージバ
ッファのアドレスをもとに受信プロセッサモジュール識
別情報を取り出し、該識別情報の受信プロセッサモジュ
ールに送信メッセージバッファアドレスと書き込みデー
タを転送し、受信側の分散共有メモリ制御手段は、受信
した上記送信メッセージバッファのアドレスと上記書き
込みデータをもとに受信側の分散共有メモリの、送信側
と同一アドレスの受信メッセージバッファにコピーを行
い、上記受信プロセッサモジュールでは、上記受信メッ
セージバッファからメッセージを読み出すことにより、
異なるプロセッサ間のメッセージ通信を行うことを特徴
としている。
段は、さらにアドレスを共有する送信プロセッサモジュ
ールの識別情報を記憶し、上記送信プロセッサモジュー
ルでは、該送信プロセッサモジュールと受信プロセッサ
モジュールの組み合わせで指定される分散共有メモリ上
の送信制御エリアに、メッセージ制御情報あるいはメッ
セージバッファ管理情報を含む制御データを書き込み、
送信プロセッサモジュールと受信プロセッサモジュール
とが同一モジュールである場合には、該受信プロセッサ
モジュールは、上記送信制御エリアから、直接、制御デ
ータを読み出してメッセージあるいはメッセージバッフ
ァに関する制御内容を認識し、対応する処理を実行した
後、上記送信制御エリアに返答制御データを書き込み、
上記送信プロセッサモジュールは、上記送信制御エリア
から上記返答制御データを読み出して受信側での処理結
果を認識することにより、同一プロセッサモジュール内
双方向通信を行い、送信プロセッサモジュールと受信プ
ロセッサモジュールが異なるモジュールである場合に
は、上記送信側の分散共有メモリ制御手段は、上記送信
制御エリアのアドレスをもとに受信プロセッサモジュー
ル識別情報を取り出し、該送信制御エリアアドレスと書
き込みデータを上記受信プロセッサモジュールに転送
し、上記受信側の分散共有メモリ制御手段は、受信した
上記送信制御エリアアドレスと上記書き込みデータをも
とに受信側分散共有メモリの、送信側と同一アドレスの
受信制御エリアにコピーを行い、上記受信プロセッサモ
ジュールは、上記受信制御エリアから制御データを読み
出して、メッセージあるいはメッセージバッファに関す
る制御内容を認識し、対応する処理を実行した後、上記
受信制御エリアに返答制御データを書き込むと、受信側
の分散共有メモリ制御手段は、上記受信制御エリアアド
レスをもとに、上記送信プロセッサモジュール識別情報
を取り出し、該識別情報をもとに上記受信制御エリアア
ドレスと上記返答制御データを上記送信プロセッサモジ
ュールに転送し、上記送信側の分散共有メモリ制御手段
は、受信した上記受信制御エリアアドレスと上記返答制
御データをもとに送信側分散共有メモリの、受信側と同
一アドレスの送信制御エリアにコピーを行い、上記送信
プロセッサモジュールでは、上記送信制御エリアから上
記返答制御データを読み出して、受信側での処理結果を
認識することにより、プロセッサモジュール間双方向通
信を行うことも特徴としている。
成されたマルチプロセッサシステムにおいて、上記プロ
セッサモジュールには、各プロセッサモジュール間で共
通の同一アドレスを有し、受信プロセッサモジュール対
応の管理単位毎に分割された分散共有メモリと、送信側
分散共有メモリとアドレスを共有する受信プロセッサモ
ジュールの識別情報を記憶し、送信側分散共有メモリへ
の書き込みが発生すると、上記受信プロセッサモジュー
ル識別情報で指定された受信プロセッサモジュールに書
き込みアドレスと書き込みデータを送信するとともに、
受信した書き込みアドレスと書き込みデータをもとに受
信側分散共有メモリの、送信側と同一のアドレスロケー
ションに書き込みを行う分散共有メモリ制御手段とを有
し、上記受信側の分散共有メモリのエリアはFIFOメ
モリで構成され、複数の送信プロセッサモジュールから
1つの受信プロセッサモジュールに処理要求を通知する
際に、上記送信プロセッサモジュールと受信プロセッサ
モジュールが同一のモジュールである場合には、上記送
信プロセッサモジュールでは、送信側分散共有メモリ上
の自プロセッサモジュール宛処理要求FIFOエリア
に、処理要求データを書き込み、上記送信プロセッサモ
ジュールと受信プロセッサモジュールが異なるモジュー
ルである場合には、上記送信プロセッサモジュールで
は、上記送信側分散共有メモリ上の受信プロセッサモジ
ュール宛処理要求FIFOエリアに、処理要求データを
書き込み、送信側分散共有メモリ制御手段は、上記処理
要求エリアのアドレスをもとに受信プロセッサモジュー
ル識別情報を取り出し、上記処理要求エリアアドレスと
書き込みデータを受信プロセッサモジュールに転送し、
受信側分散共有メモリ制御手段は、受信した上記処理要
求FIFOエリアアドレスと上記書き込みデータをもと
に受信側分散共有メモリの、送信側と同一アドレスの上
記処理要求FIFOエリアに書き込むことにより、上記
処理要求FIFOエリアに複数の処理要求データを到着
順に蓄積し、上記受信側プロセッサモジュールでは、受
信側分散共有メモリ上の上記要求FIFOエリアから複
数の上記処理要求データを順次読み出すことにより、処
理要求を検出することも特徴としている。
は、送信側分散共有メモリの連続する複数のアドレスロ
ケーションに複数のデータが連続的に書き込まれた場
合、上記複数のデータの先頭アドレスと複数のデータと
をまとめて受信プロセッサモジュールに一括送信し、受
信側分散共有メモリ制御手段は、一括受信した上記先頭
アドレスと上記複数のデータをもとに受信側分散共有メ
モリ上の同一アドレスロケーションに連続的にコピーを
行うことも特徴としている。
ルの分散共有メモリ制御手段に、分散共有メモリアドレ
スを共有する受信プロセッサモジュール識別番号を記憶
することにより、送信側共有メモリへの書き込みが行わ
れると、分散共有メモリ制御手段からそのアドレスに対
応する受信プロセッサモジュール識別番号を読み出し、
対応する受信プロセッサモジュールに書き込み情報を送
出すると、受信側の分散共有メモリ制御手段は、受信側
分散共有メモリの同一アドレスロケーションにコピーを
行う。送信プロセッサモジュール内の分散共有メモリ
は、受信プロセッサ対応にメッセージバッファ群が分割
されており、ある受信プロセッサ対応のメッセージバッ
ファにメッセージが書き込まれると、分散共有メモリ制
御手段により、対応する送受信プロセッサモジュール内
の分散共有メモリの同一ロケーションのメッセージバッ
ファにコピーが行われる。このように、プロセッサモジ
ュール間で高速にオーバヘッドの少ないメッセージ通信
が実現できる。 また、受信側の分散共有メモリ制御手段にも、分散共
有メモリアドレスを共有する送信プロセッサモジュール
識別番号を記憶しておき、これにより受信側分散共有メ
モリのメッセージ制御エリアにメッセージ制御情報を書
き込むと、送信側分散共有メモリにコピーされることに
より、メッセージ制御に必要な双方向通信が行える。
求エリアをFIFOメモリにすることにより、送信側分
散共有メモリに書き込んだ処理要求が、受信側分散共有
メモリのFIFOに順次蓄積される。従って、複数の送
信側プロセッサモジュールが同時に各分散共有メモリの
同一FIFOロケーションに処理要求を書き込んだ場合
でも、受信側の分散共有メモリのFIFOで自動的に順
序付けが行われるので、全ての処理要求がFIFOに順
次書き込まれる。受信側は、分散共有メモリ内の要求登
録FIFOを順次読み出すだけで、発生した要求のみを
効率よく取り出せる。従って、従来のポーリング処理や
割り込み処理で必要とされた処理オーバヘッドを大幅に
削減することができる。 また、先願である特願平6−74669号明細書およ
び図面に記載のものに比較すると、分散共有メモリが全
てのプロセッサモジュール間で共通のアドレスが付加さ
れ、送信プロセッサモジュールと受信プロセッサモジュ
ールの組み合わせで指定される管理単位毎に分割されて
いる点、および分散共有メモリを、自プロセッサモジュ
ール内のローカル転送データのための送受信用と、異な
るプロセッサモジュール間のリモート転送データのため
の送受信用のエリアに分割している点では共通してい
る。しかし、上記明細書では、送信プロセッサモジュー
ルが送信および受信メッセージバッファを捕捉し、受信
プロセッサモジュールがそれらを解放し、受信プロセッ
サモジュールで再利用するか、あるいは送信プロセッサ
モジュールに再利用を許可する方法を用いている。その
結果、2つのプロセッサモジュール間で双方向のメッセ
ージ通信のトラヒックがアンバランスな場合、メッセー
ジバッファの過不足が生じ易く、その制御手順も複雑で
処理オーバヘッドも大きい。これに対して、本発明で
は、送信および受信メッセージバッファの捕捉、解放は
送信プロセッサモジュールで一元的に行われ、送信側プ
ロセッサモジュールで常に再利用されるため、制御手順
も簡単である。また、上記明細書では、送信メッセージ
バッファから受信メッセージバッファへのコピーは、送
信メッセージバッファにメッセージが書かれた後、メッ
セージ送信要求が発せられた時点で開始される。これに
対して、本発明では、送信メッセージバッファから受信
メッセージバッファへのコピーは、送信メッセージバッ
ファにメッセージが書き込まれた瞬間から開始されるた
め、メッセージ転送遅延時間を短縮することができる。
そして、本発明では、さらに受信側の分散共有メモリ制
御手段にも、分散共有メモリアドレスを共有する送信プ
ロセッサモジュール識別番号を記憶しておき、受信側分
散共有メモリのメッセージ制御エリアにメッセージ制御
情報を書き込むと、送信側分散共有メモリにコピーされ
る点が付加されている。また、分散共有メモリの処理要
求エリアをFIFOメモリにする点も新たに追加されて
いる。さらに、分散共有メモリ制御手段に登録されるプ
ロセッサモジュール情報に応じて、一方向性通信、両方
向性通信、放送型通信等の各種の通信パターンを任意に
実現できる点でも追加されている。このように、本発明
によれば、メッセージが送信側から受信側に伝達される
までの遅延時間が大幅に削減されるとともに、一方向
性、両方向性、放送型等の各種通信パターンを選択する
ことができるので、柔軟性が高い。また、受信側プロセ
ッサモジュールは受信側分散共有メモリの同じアドレス
ロケーションから制御データを読み出すだけで、プロセ
ッサモジュール間の通信の同期を簡単にとることがで
き、かつ複数の送信プロセッサモジュールが同時に、分
散共有メモリの同一番地に書き込みされた場合でも、受
信側の分散共有メモリのFIFOに順次書き込まれるの
で、競合処理を全く必要としない。従って、受信側は、
分散共有メモリ内の要求登録FIFOを順次読み出すの
みで、発生した要求のみを効率よく取り出すことがで
き、従来のようなサーチのための処理オーバヘッドを大
幅に削減できる。
説明する。図4は、本発明の一実施例を示すマルチプロ
セッサシステムの構成図であって、3台のプロセッサか
らなる場合を示している。図4において、17はマルチ
プロセッサシステム、18−1,18−2,18−3は
マルチプロセッサシステムにおけるプロセッサモジュー
ル(PM)、19−1,19−2,19−3は各PM内
のプロセッサ、20−1,20−2,20−3はそれぞ
れ対応するプロセッサ19−1〜19−3から読み書き
アクセスが可能なローカルメモリ、21−1,21−
2,21−3は全プロセッサモジュール間で共通のアド
レスが付与された分散共有メモリである。ただし、プロ
セッサ19−1からアクセスできる分散共有メモリはロ
ーカルメモリ21−1のみであって、他のPMのローカ
ルメモリ21−2,21−3にはアクセスできない。同
じように、プロセッサ19−2からアクセスできる分散
共有メモリは21−2のみであり、プロセッサ19−3
からアクセスできる分散共有メモリは21−3のみであ
る。22−1,22−2,22−3は分散メモリカップ
ラであって、これらは分散共有メモリ21−1〜21−
3にデータがそれぞれ書き込まれた時点で、その書き込
みデータを、予め指定された他のプロセッサモジュール
の全てないし1個に送信すると同時に、他のプロセッサ
モジュールから受信した書き込みデータを、分散共有メ
モリ21−1〜21−3のうちの送信側と同一のアドレ
スロケーションに書き込むための装置である。
散メモリプロテクタであって、それぞれ、分散共有メモ
リ21−1〜21−3内のメッセージバッファに記憶さ
れているメッセージを不正なアクセスから保護する装置
である。24−,24−2,24−3はネットワークア
ダプタであって、通信ネットワーク26を介して他の分
散システムとメッセージ等を交換するための装置であ
る。25はプロセッサモジュール間通信路であって、マ
ルチプロセッサシステム17内のPM間でメッセージあ
るいはそれらの制御情報を転送するための装置である。
プロセッサモジュール間通信路の具体的実現手段として
は、システムバス、LAN、パケットスイッチングネッ
トワーク、リングネットワーク等、送信側と受信側で1
対1の通信ができるものであれば何でもよい。26は複
数のマルチプロセッサシステム17間を相互接続するた
めの通信ネットワークであって、ここでは転送データを
固定長のブロックに分割して、それに行き先ヘッダを付
加した53バイトのセルにして、ネットワーク内を転送
するATM(Asynchronous Trasnsfer Mode)ネッ
トワークを想定しているが、その他の種類の通信ネット
ワークでも適用可能であることは勿論である。
散共有メモリのデータ配置例を示す図である。ここで
は、データの配置を物理アドレスレベルで示している。
分散共有メモリ内の通信領域は、PM間通信エリア、
PM内通信エリア、FIFO通信エリア、の3種類
に大別される。このうちPM間通信エリアは、マルチ
プロセッサシステム17内のPM間通信情報を記憶する
エリアであり、PM内通信エリアは、同一PM内で送
受信される通信情報を記憶するエリアであり、またF
IFO(First In First Out)通信エリアは、PM間
にまたがる処理要求をFIFO形式で蓄積記憶するエリ
アである。PM間通信エリアおよびPM内通信エリア
は、 (i)メッセージを記憶するメッセージバッファ(M
B)エリア (ii)メッセージバッファの捕捉/解放状態を表示する
MB管理マップエリア (iii)メッセージバッファアドレス等の送受間引き継
ぎ制御情報(ディスクリプタ)を複数個、連続アドレス
に配置したディスクリプタリングエリア それぞれに分けられる。これらのエリアの具体的使用方
法については、追って説明する。上記MB、MB管理マ
ップ、およびディスクリプタリングは、それぞれページ
を単位として物理メモリの割り当てが行われ、これらの
ページは仮想記憶のページテーブルにより管理されてい
る。そして、MBエリア用のページテーブルには、プロ
セッサのスーパバイザモード(カーネルやカーネルから
起動される各種のシステム制御プログラムが実行される
モード)と、ユーザモード(各種アプリケーションプロ
グラムが実行されるモード)との両方からアクセスが許
されるように保護情報が設定されている。その結果、各
種アプリケーションプログラムがMBエリアにメッセー
ジを直接読み書きすることができるので、処理の効率化
を図ることが可能となる。一方、MB管理マップ用ペー
ジと、MBディスクリプタリング用ページのページテー
ブルには、プロセッサのスーパバイザモードのアクセス
のみを許すように保護情報が設定されている。その結
果、アプリケーションプログラムからMB管理マップお
よびMBディスクリプタリングへの不正書き込みに対し
て保護が行われる。
に、分散共有メモリ21上の各エリアを識別するため
に、Mij−kのような識別名を用いている。ここで、
Mはプロセッサモジュール対応のMB/MB管理マップ
/MBディスクリプタリング/FIFO通信エリアの識
別記号であり、PM(18−1)に対応するMBはX、
そのMB管理マップはXM、MBディスクリプタリング
はXDと表現される。同じように、PM(18−2)に
対応するMBはY、そのMB管理マップはYM、MBデ
ィスクリプタリングはYD、FIFO通信エリアはY
F、PM(18−3)に対応するMBはZ、そのMB管
理マップはZM、MBディスクリプタリングはZD、F
IFO通信エリアはZFのように名称が付けられてい
る。また、i,jは、それぞれ送信PMの識別番号(P
M ID)と受信PMの識別番号(PMID)を表わし
ており、PM#1(18−1)、PM#2(18−
2)、PM#3(18−3)に対応してそれぞれ1,
2,3の番号が付与されている。ただし、例外として、
FIFO通信エリアXF,YF,ZFは値jのみを有
し、値iを持っていない。その理由としては、FIFO
通信エリアが値jで表わされる受信側プロセッサモジュ
ール対応に分割されており、値iで表わされる各送信プ
ロセッサモジュール間で共通に使用するため、エリアの
指定情報として値iを必要としないためである。
/MB管理マップ/MBディスクリプタ/FIFO通信
エリアを識別するためのもので、1から順に値が割り振
られている。例えば、Z13−2は、分散共有メモリ2
1−3上の、PM#1(18−1)からPM#3(18
−3)へのMBのうちの第2番目のMBを表わす。ま
た、XD21−2は、分散共有メモリ21−1上の、P
M#2(18−2)から1番目のPM#1(18−1)
へのMBディスクリプタのうち、第2番目のMBディス
クリプタを表わす。図5〜図7から明らかなように、P
M間通信エリアではi≠j、PM内通信エリアではi=
jとなる。ただし、例外として、MBディスクリプタ/
FIFO通信エリアで、送信処理要求情報が登録される
場合にはSと表現され、受信処理要求情報が登録される
場合にはRと表現される。例えば、XD12−Rは、分
散共有メモリ(21−1)上のPM#1(18−1)か
らPM#2(18−2)への受信ディスクリプタを表わ
し、ZF2−Sは、分散共有メモリ(21−3)上のP
M#2(18−2)への受信処理FIFO通信エリアを
表わしている。各分散共有メモリは、実効的に必要とさ
れるメモリ量、つまり自プロセッサが送受信するために
必要なエリアのみが実装されている。例えば、分散共有
メモリ21−1では、図5、図6のハッチ部分のみが実
装されており、それ以外のエリアにはメモリが実装され
ていない。
値がそれぞれ一致し、Mの値が異なるMBがペアを構成
する。このペアは、異なる分散共有メモリの同一物理ア
ドレスロケーションに配置される。例えば、図5〜図7
において、メッセージバッファX12−1とY12−1
はペアを組んでおり、互いに同じ物理アドレスを有して
いる。各ペアは、送信側PMのカーネルにより動的に捕
捉、解放が行われる。各MBは固定長の大きさで構成さ
れており、図5〜図7に示すように、宛先PM−IDが
同一の複数のMBを、分散共有メモリの連続するアドレ
スロケーションに割り付ける。これを、宛先PM対応M
Bプールと呼ぶ。各MBプール対応にMB管理マップが
存在し、MBプール内のMB数に応じたMB管理マップ
のエントリが用意され、それらが分散共有メモリの連続
エリアに割り付けられている。例えば、図5において、
メッセージバッファX12−1,X12−2は1つのM
Bプールを構成し、X12−1に対してMB管理マップ
エントリXM12−1が、X12−2に対してMB管理
マップエントリXM12−2が対応する。『対応』とい
う意味は、MBの先頭アドレス(以下、単にMBアドレ
スと呼ぶ)が付与されると、そのMB管理マップエント
リアドレスを求めることができ、逆にMB管理マップエ
ントリアドレスからMBアドレスも求めることができる
ことを意味している。MB管理マップの各エントリは、
対応するMBが『未使用』か/『使用中』かの状態を表
示し、カーネルにより値が設定される。MBの場合と同
じ考え方により、送信側分散共有メモリMB管理マップ
エントリと、受信側分散共有メモリの同一アドレスのM
B管理マップエントリがペアを構成している。例えば、
MB管理マップエントリXM12−2とYM12−2が
ペアを組んでいる。
じように、宛先PM−IDが同一の複数のMBディスク
リプタを分散共有メモリの連続するアドレスロケーショ
ンに割り付けており、割り付けた全体をディスクリプタ
リングと呼ぶ。『リング』と呼ばれている理由は、ディ
スクリプタリングに含まれる複数のディスクリプタを若
いアドレス順にサイクリックに使用していくからであ
る。送信側の各ディスクリプタリングと同一アドレスの
エリアが、受信プロセッサモジュールの分散共有メモリ
にも配置される。ディスクリプタリングは、送信オブジ
ェクトからのメッセージ制御情報を他のPMあるいは他
のシステムに引き継ぐための『送信ディスクリプタリン
グ』と、他のPMあるいは他のシステムから受信したメ
ッセージ制御情報を受信オブジェクトに引き継ぐための
『送信ディスクリプタリング』に分けられる。ディスク
リプタリングもMBやMB管理マップの場合と同じよう
に、送信側と受信側の同一アドレス間でペアを構成す
る。ディスクリプタリング内のディスクリプタとMBと
の対応は、実行時にカーネルにより動的に決定される。
具体的には、例えばPM#1(18−1)からPM#2
(18−2)にメッセージを送信する場合に、PM(1
8−1)のカーネルが空きのMBプールの中から適当な
MB(例えばX12−2)を捕捉し、次に対応する送信
ディスクリプタリング(例えばXD12−S)を選択
し、その中の『未使用』の最若アドレスのディスクリプ
タにMBアドレスを登録する。このような方法でディス
クリプタとMBとの対応が動的に決定される。なお、送
信ディスクリプタリングXD12−Sとペアを組む送信
ディスクリプタリングはYD12−Sである。
オブジェクトからのメッセージ送信処理要求を他のPM
または他のシステムに通知するための『送信処理FIF
Oエリア』と、他のPMまたは他のシステムから受信し
たメッセージ受信処理要求を受信オブジェクトに通知す
るための『受信処理FIFOエリア』に分けられる。こ
のうち、メッセージ処理要求送信側の分散共有メモリ
は、通常のRAM(ランダムアクセスメモリ)で構成さ
れるが、メッセージ処理要求受信側の分散共有メモリ
は、FIFOで構成されている。例えば、PM#1(1
8−1)上のPM#1(18−1)宛受信処理FIFO
エリアXF1−Rは、他のPMからのメッセージ受信処
理要求を記憶するためにFIFOメモリで構成されてい
るが、PM#2上のPM#1(18−1)宛受信処理F
IFOエリアYF1−Rおよび、PM#3上のPM#1
(18−1)宛受信処理FIFOエリアZF1−Rは、
いずれもRAMで構成されている。この理由としては、
受信処理要求を書き込む側のPM(PM#2とPM#
3)が受信処理要求をそれぞれ受信処理FIFOエリア
YF1−RとZF1−Rに同時に書き込んだ場合、それ
らが同時に受信処理要求を読み出す側のPM(PM#
1)の受信処理FIFOエリアXF1−Rに到着するの
で、これらの受信処理要求を全て蓄積するためにFIF
Oメモリを使用するからである。
サモジュールの内部構成図である。図1のプロセッサモ
ジュールは、図4におけるPM18−1〜18−3に該
当している。なお、以下の説明では、3つのPM内に存
在する構成要素の各々を識別する必要がないときには、
−1,−2,−3の各識別符号を省略する。例えば、個
々の分散共有メモリを指定しないときには、分散共有メ
モリ21−1,21−2,21−3と記述することな
く、単に分散共有メモリ21と記述することにする。図
1において、16は分散共有メモリ21上に配置された
メッセージバッファ(MB)、30はプロセッサモジュ
ール(PM)18内の各種装置を結合するためのプロセ
ッサバス、22は分散メモリカップラで、分散共有メモ
リ21に実装されているエリアへの書き込みアクセスが
あったとき、他のPMの分散共有メモリの同じアドレス
ロケーションにも書き替えデータを送信する機能、およ
び他のPMから書き替えデータを受信して、自PMの分
散共有メモリへの書き込みを行う機能を有する。分散メ
モリカップラ22は、以下の構成要素を含んでいる。先
ずバス信号デコーダ31であり、これはプロセッサバス
30の信号線上の信号を解読し、所属する分散共有メモ
リ21への書き込みアクセスがあれば、信号線32に
‘1’を出力して、転送制御部33を起動する。転送制
御部33は、分散メモリカップラ22全体の制御を司る
部分であり、ここから内部ロジックに各種制御信号(図
示省略)を供給する。34はモジュールID管理部であ
り、分散共有メモリ21への書き込みデータをPM間で
送受する際に必要な宛先プロセッサモジュールID(P
M ID)を記憶している。モジュールID管理部34
の詳細については図6に示している。
タであって、他のPMに転送する分散共有メモリアドレ
スや書き込みデータ等、または他のPMへの割り込み情
報等を記憶する。36はパケット送信バッファであり、
パケット送信レジスタ35からのデータを受け取り、他
のPMに転送するまでの一時待ち合わせ機能を有してい
る。37はパケット受信バッファであり、他のPMから
転送されてきたデータを受け取り、パケット受信レジス
タ38に渡すまでの一時待ち合わせの機能を有する。パ
ケット受信レジスタ38は、他のPMから転送されてき
た情報を記憶するレジスタであり、パケット送信レジス
タ35が送り出した内容と同じデータが記憶される。3
9はパケットデコーダであり、パケット受信レジスタ3
8内のデータをデコードして、分散共有メモリ21内の
アドレスロケーションへの書き込み要求であれば、信号
線40を介して転送制御部33に分散共有メモリ書き込
みの実行を依頼する。また、デコードの結果が、他のP
Mからの割り込みであれば、信号線41を介して割込み
制御部42に割込み処理を依頼する。割込み制御部42
は、信号線43を経由してプロセッサ19に割り込み要
求を行う。
タであって、分散共有メモリ21に配置されたMB(1
6)内のメッセージを不正なアクセスから保護するハー
ドウェア機構である。分散メモリプロテクタ23は、カ
レントケーパビリティレジスタ(CCR:Curent Ca
pability Register)51、MCRメモリ(MemoryCa
pability Register Memory)50、比較器52を含
んでいる。CCR51は、カレントケーパビリティを記
憶するレジスタである。カレントケーパビリティは、具
体的には、プロセッサ19で実行中のアプリケーション
オブジェクト(プロセッサのユーザモードで実行される
オブジェクト)のIDを意味している。MCRメモリ5
0は、複数のMCR53から構成され、各MCR53は
分散共有メモリ21上の各MB16対応に、メモリケー
パビリティを記憶する。メモリケーパビリティは、具体
的には、対応するMB16へのメモリアクセスが生じる
と、MBアドレスを基に対応するMCR53をMCRメ
モリ50の中から選択し、これを取り出す。比較器52
は、選択されたMCR53とCCR51とを比較してメ
ッセージバッファへの正しいアクセスであるか否かを判
定し、不一致であれば不正アクセスであると判定する。
不正アクセスを検出した場合には、並行して行われてい
るMB16へのアクセスを中継し、信号線54を介して
プロセッサ19に緊急通通する。
18−1内の送信オブジェクトからPM18−2内の受
信オブジェクトへのメッセージ通信に適用した場合の制
御手順について述べる。 (a)送信PM18−1のカーネルは、送信オブジェク
トの実行を開始する前に、カレントケーパビリティレジ
スタCCR51−1にカレントケーパビリティつまり送
信オブジェクトIDを設定する。 (b)送信PM18−1のカーネルは、分散共有メモリ
21−1上に送信MB16−1を捕捉した後、送信MB
16−1対応のMCR53−1にメモリケーパビリティ
を設定する。この時点のメモリケーパビリティは、MB
の捕捉を要求したオブジェクトのIDつまり送信オブジ
ェクトIDである。 (c)送信プロセッサ19−1から送信MB16−1へ
のメモリアクセスがある度毎に、MCR53−1の中か
らMBアドレスを基に対応するMCR53−1を1個選
択して、それをCCR51−1と比較する。MCR53
−1とCCR51−1のオブジェクトIDの値が等しい
ときには正しいアクセスであり、等しくないときには不
正アクセスであると判定する。 (d)メッセージが受信PM18−2の受信MB16−
2に到着したと仮定する。受信PM18−2のカーネル
は、受信オブジェクトの実行を開始する前に、CCR5
1−2にカレントケーパビリティつまり受信オブジェク
トIDを設定する。 (e)受信PM18−2のカーネルは、受信MB16−
2に対応するMCR53−2に、メモリケーパビリティ
を設定する。この時点のメモリケーパビリティは、メッ
セージの宛先であるオブジェクトのIDつまり受信オブ
ジェクトIDである。
B16−2へのメモリアクセスがある度毎に、比較器5
2−2によりMCR53−2とカレントケーパビリティ
レジスタCCR51−2内のオブジェクトIDの値を比
較し、等しければ正しいアクセス、等しくなければ不正
アクセスと判定する。 上記動作において、MCR53とCCR51に、それぞ
れメモリケーパビリティとカレントケーパビリティが設
定されている期間(プロテクションウィンドウ開放期
間)は、MBの所有権が付与された送信または受信オブ
ジェクトのみがそのMBをアクセスできる。プロテクシ
ョンウィンドウ開放期間中に、もし無関係のオブジェク
トがMBアクセスを行うと、MCRとCCRのケーパビ
リティの不一致が生じて、不正アクセスであることが検
出される。プロテクションウィンドウ開放期間以外で
は、送信、受信オブジェクトも含めた全てのアプリケー
ションオブジェクトは、このMBにアクセスすることが
できないので、強固なメモリ保護が実現されることにな
る。なお、分散メモリプロテクタ23は、プロセッサの
アプリケーションモード(またはユーザモード)でのM
Bアクセスで動作するが、カーネルモード(またはスー
パバイザモード)でのメモリアクセスは動作せず、無条
件にメモリアクセスを許容する。この理由としては、一
般にカーネルモードで実行されるプログラム(例えばカ
ーネル)は、アプリケーションオブジェクトに比較して
潜在バグの含有率が小さく、不正なメモリアクセスをす
る可能性が少ないからである。
部の内部構成図である。図8において、60はモジュー
ルIDディレクトリであり、CAM(ContentAddress
able Memory)セル部61とデータメモリ部62から構
成される。CAMとは、検索キーデータを入力して、こ
れと各ワード(CAMセル)の記憶データの内容を一斉
に比較照合して、指定された検索条件に合致した内容の
CAMセルを選択表示するメモリである。CAMセルの
各々には、『分散共有メモリページアドレス63』が記
憶されている。分散共有メモリページアドレス63は、
他のプロセッサモジュールと共用されているアドレスの
ページである。例えば、分散共有メモリ21の連続エリ
アに配置された宛先PM対応のMBプールのページアド
レス、そのMB管理マップのページアドレス、ディスク
リプタリングのページアドレス、宛先PM対応のFIF
O通信エリアのページアドレス等が設定される。図5〜
図7で説明したように、MB、MB管理マップ、ディス
クリプタリング、FIFO通信エリアは、それぞれ宛先
PM毎に異なるページに割り付けられている。一方、デ
ータメモリ部62は、各CAMセルのワードに対応する
補助データを記憶するRAMであり、分散共有メモリペ
ージアドレス63を共有している宛先プロセッサモジュ
ールのID(宛先PM ID)64を記憶している。
リングは、送信PM、受信PMの両方から書き込みが行
えるようにするため、送信PMのモジュールIDディレ
クトリ60には、〔共有ページアドレス、受信PM I
D〕のペアが記憶され、受信PMMのモジュールIDデ
ィレクトリ60には、〔送信側と同じ共有ページアドレ
ス、送信PM ID〕のペアが記憶される。このよう
に、各PMのモジュールIDディレクトリ60には、コ
ピーをしたい全てのPMのPM IDが登録されてい
る。図8の65はキーレジスタであり、これはCAMセ
ル部61の内容と比較照合するための検索キーデータを
記憶する。66はマスクレジスタであり、これはキーレ
ジスタ65内の検索キーデータとCAMセル部61との
比較を行う場合に、比較しないビット位置を指定するた
めのレジスタである。67はCAMコマンドレジスタで
あり、CAMセル部61に関する各種指令を記憶する。
68は結果レジスタであり、これは検索した結果、附畜
マCAMセルの有無の表示、複数セル一致の有無の表
示、空きセルの有無の表示等を行う部分である。キーレ
ジスタ65とCAMセル部61との比較処合の結果、一
致したCAMを使用しなくても、よく知られているよう
にハッシングの技術とRAMとを組み合わせて、CAM
と同じような機能を実現することができる。
以下のように動作する。分散共有メモリ21への書き込
みアクセスがあると、そのアドレスがキーレジスタ65
に格納され、そのページアドレスとCAMセル部61と
が比較される。一致したセルが検出されると、そのアド
レスが他のPMにより共用されていることを意味するの
で、データメモリ部62から対応する宛先PM ID6
4を読み出し、これを分散共有メモリアドレスに付与し
た後、書き込みデータと合わせて送信パケットを作成
し、図1に示すパケット送信レジスタ35に設定する。
パケット送信レジスタ35からパケット送信バッファ3
6を経由してパケットを宛先PMに送出する。受信側の
分散メモリカップラ22では、パケット受信バッファ3
7で、他のPMから転送されてきたデータを受け取り、
パケット受信レジスタ38に引き渡す。パケット受信レ
ジスタ38では、受信したデータをデコードし、指定さ
れた分散共有メモリアドレスロケーションにデータを書
き込む。このようにして、送信側分散共有メモリから受
信側分散共有メモリにコピーが行われる。なお、送信側
分散共有メモリへの書き込みアクセスでは、受信側分散
共有メモリへのコピーアクセスの完了を待たずにアクセ
スを完了する。
Mにポイントツーポイントでコピーを行う構成を基本と
して説明しているが、ポイントツーマルチポイントでコ
ピーを行うことも可能である。その場合には、モジュー
ルIDディレクトリ60には1つの分散共有メモリペー
ジアドレス63に対して、複数の宛先PM ID64を
登録しておく。その結果、分散共有メモリへの1回の書
き込みに対して複数のパケットが生成され、それぞれ指
定されたPMにパケットが送信されるので、複数のPM
の分散共有メモリにコピーを行うことができる。また、
同一の分散共有メモリページアドレス63に対して、送
信側PMのモジュールIDディレクトリ60には、受信
側PM IDを登録し、受信側PMのモジュールIDデ
ィレクトリ60には、送信側PM IDを登録しておく
ことにより、分散共有メモリのエリアに送信側、受信側
のどちらから書き込んでも、互いに相手側の分散共有メ
モリにコピーを行う、つまり双方向通信を行うことがで
きる。
タおよびパケット受信レジスタに共通のデータフォーマ
ット図である。ここでは、分散共有メモリアクセスタイ
プと割込みデータタイプの2種類のフォーマットを示し
ている。図9において、80,90は属性識別フィール
ドであり、‘0’ならば分散共有メモリアクセスタイプ
であることを示し、‘1’ならば割込みデータタイプで
あることを示す。分散共有メモリアクセスタイプの場合
には、モジュールID管理部34が出力する『宛先PM
ID81』,『分散共有メモリアドレス82』,『書
込みデータ83』,『書込み単位84』の各フィールド
を含む。『書込み単位84』フィールドは、書込みのデ
ータ幅、例えばバイト、ハーフワード(16ビット)、
ロングワード(32ビット)等を指定するものである。
一方、割込みデータタイプの場合には、モジュールID
管理部34が出力する『宛先PM ID91』,割込み
発生源を示す『送信モジュールID92』,割込みの種
別を示す『割込み識別データ93』,『書込み単位9
4』の各フィールドを含む。なお、宛先PM ID8
1,91がある特定の値の場合には、放送型パケットと
して全てのPMでパケットを受信するように構成するこ
とが可能である。
て使用される各種のメッセージ通信のパターンと、その
処理の流れを示す説明図である。図10はシステム内メ
ッセージ通信の場合である。図10において、120は
送信オブジェクト、121は受信オブジェクト、122
はメッセージキュー、123は送信オブジェクト、12
4は受信ディスクリプタリング、125はIOC配信オ
ブジェクト、126はメッセージキュー、127は受信
オブジェクトである。メッセージパターンは、以下のよ
うに分類される。 (a)システム内メッセージ通信・・・送信オブジェク
トと受信オブジェクトが同一マルチプロセッサシステム
(図1の17)内に存在する場合である。システム内メ
ッセージ通信には、次の2通りのケースが存在する。 (a1)PM内通信・・送信オブジェクト120と受信
オブジェクト121が同一PM内に存在する場合であ
る。PM内通信の場合、カーネルは受信オブジェクト1
21のメッセージキュー122のアドレスを知っている
ので、カーネルは、送信オブジェクト120から受信オ
ブジェクト121のメッセージキュー122に直接、メ
ッセージを登録することができる。受信オブジェクト1
27はメッセージキュー126からメッセージを取り出
し、対応する処理を行う。 (a2)PM間通信・・送信オブジェクト123と受信
オブジェクト127が同一マルチプロセッサシステム1
7内の異なるPMに存在する場合である。PM間通信の
場合、送信オブジェクト123の存在するPM(送信P
M)のカーネルからは、受信PM内の受信オブジェクト
127の制御情報(例えばメッセージキュー126のア
ドレス)が見えないので、直接、受信オブジェクト12
7のメッセージキュー126にメッセージを登録するこ
とができない。そこで、送信PMでは、送信カーネル
が、事前に知っている受信ディスクリプタリング124
にメッセージを登録し、受信PMではIOC(Interob
ject Communication)配信オブジェクト125が、受
信ディスクリプタリング124を読出し、受信オブジェ
クト127のメッセージキュー126にメッセージを登
録する。
合である。図11において、140は送信オブジェク
ト、141は送信ディスクリプタリング、142はIN
C送信処理オブジェクト、143はアダプタ送信ディス
クリプタリング、144はアダプタ受信ディスクリプタ
リング、146はメッセージキュー、147は受信オブ
ジェクト、150は送信オブジェクト、151は送信デ
ィスクリプタリング、152はINC送信処理オブジェ
クト、153はアダプタ送信ディスクリプタリング、1
54はアダプタ受信ディスクリプタリング、155はI
NC受信処理オブジェクト、156は受信ディスクリプ
タリング、157はIOC配信オブジェクト、158は
メッセージキュー、159は受信オブジェクトである。 (b)システム間メッセージ通信・・送信オブジェクト
と受信オブジェクトが異なるマルチプロセッサシステム
17に存在する場合である。送信システムあるいは受信
システムで中継PMがない場合と、ある場合の2通りが
ある。 (b1)中継PMがない場合・・送信システムの場合、
送信オブジェクト140の存在するPM(送信PM)
と、受信システム宛の通信リンクを持っているPM(送
信中継PM)とが一致している場合である。受信側シス
テムの場合、通信リンクを終端しているPM(受信中継
PM)と受信オブジェクト147の存在するPM(受信
PM)とが一致している場合である。送信システムで送
信中継PMがない場合、送信PMでは、カーネルが送信
オブジェクト140からのメッセージを自PM内の送信
ディスクリプタリング141に登録する。INC(Inte
r-System Communication)送信処理オブジェクト14
2は、送信ディスクリプタリング141を読み出してネ
ットワークプロトコル処理を行い、アダプタ送信ディス
クリプタリング143にメッセージを登録する。ネット
ワークアダプタ24は、アダプタ送信ディスクリプタリ
ング143からメッセージを取り出して、通信ネットワ
ーク26に送出する。
場合、通信ネットワーク26からメッセージが送り届け
られ、受信PMのネットワークアダプタ24がメッセー
ジをアダプタ受信ディスクリプタリング144に登録す
る。そして、INC受信処理オブジェクト145がアダ
プタ用受信ディスクリプタリング144を読み出して、
同一PM内の受信オブジェクト147のメッセージキュ
ー146にメッセージを登録する。 (b2)中継PMがある場合・・送信システムの場合、
送信オブジェクト150の存在するPM(送信PM)
が、受信システムへの通信リンクを持ち合わせておら
ず、他のPM(送信中継PM)が持ち合わせている場合
である。また、受信システムの場合、通信リンクを終端
しているPM(受信中継PM)と受信オブジェクト15
9の存在するPM(受信PM)とが異なる場合である。
送信システムでは、送信中継PMがある場合、送信PM
のカーネルの送信処理プログラム17が送信オブジェク
ト150からのメッセージを送信中継PM宛の送信ディ
スクリプタリング151に登録する。送信中継PMのI
NC送信処理オブジェクト152は送信ディスクリプタ
リング151を読み出して、ネットワークプロトコル処
理を行ってアダプタ送信ディスクリプタリング153に
メッセージを登録する。ネットワークアダプタ24はア
ダプタ送信ディスクリプタリング153からメッセージ
を取り出して通信ネットワーク26に送出する。
場合、通信ネットワーク26からメッセージが送り届け
られ、受信PMのネットワークアダプタ24がメッセー
ジをアダプタ受信ディスクリプタリング154に登録す
る。次に、受信中継PMのINC受信処理オブジェクト
155がアダプタ受信ディスクリプタリング154を読
み出し、最終宛先の受信PM宛の受信ディスクリプタリ
ング156にメッセージを登録し、受信PMではIOC
(Interobject Communication)配信オブジェクト1
57が受信ディスクリプタリング156を読み出し、受
信オブジェクト159のメッセージキュー158にメッ
セージを登録する。なお、図11のシステム間メッセー
ジ通信の組み合わせパターンの数は、〔送信中継あり/
なし〕,〔受信中継あり/なし〕の合計4通りである。
図12は、各アプリケーションオブジェクトに付与され
たオブジェクトIDのフォーマットを示す図である。図
12において、170はオブジェクトID、171はそ
のオブジェクトが存在するマルチプロセッサシステムの
番号で、通信ネットワーク内で一意に識別可能なように
形成される。172はプロセッサモジュールID(PM
ID)で、マルチプロセッサシステム内で一意に識別
可能の値をとる。173はローカルIDであり、PM内
でオブジェクトを一意に識別するための番号である。
プタと送信処理要求のメモリ配置例を示す図であり、図
14は、送信処理要求のフォーマット図である。PM#
1(18−1)からPM#3(18−3)宛の送信ディ
スクリプタリングを(XD13−S,ZD13−S)の
ペアで、PM#2(18−2)からPM#3(18−
3)宛の送信ディスクリプタリングを(YD23−S,
ZD23−S)のペアで、PM#3内の送信ディスクリ
プタリングをZD33−Sで、それぞれ表わす。また、
PM#1(18−1)上のPM#3(18−3)宛の送
信処理FIFOをXF3−Sで、PM#2(18−2)
上のPM#3(18−3)宛の送信処理FIFOをYF
3−Sで、PM#3(18−3)内の送信処理FIFO
をZF3−Sで、それぞれ表わす。このように、図13
はシステム間PM中継通信の送信システムの例を示して
いる。送信オブジェクトはPM#1(18−1)、PM
#2(18−2)、PM#3(18−3)に分散してお
り、送信中継PMはPM#3(18−3)とする。各P
Mの送信オブジェクトから合計5個のメッセージMi
(i=1,2,・・5)がPM#3(18−3)を経由
して通信ネットワークに送出されるものとし、各メッセ
ージの送信ディスクリプタを順にQ1,Q2,Q3,Q
4,Q5と表わし、それらに対応する送信処理要求を順
にQA1,QA2,QA3,QA4,QA5と表わす。
送信ディスクリプタの構造は、後述の図15(c)に示
されている。送信処理要求のデータ構造(フォーマッ
ト)は、図14に示すように、要求元プロセッサモジュ
ールID(PM ID)175と、送信ディスクリプタ
へのポインタ176から構成されている。送信要求は、
次のように伝達される。先ず、PM#1(18−1)で
メッセージM1の送信要求が発生すると、PM#1(1
8−1)ではPM#3(18−3)宛送信ディスクリプ
タリングXD13−Sに送信ディスクリプタQ1を登録
し、次にPM#3宛送信処理FIFOエリアXF3−S
に送信処理要求QA1を登録する。これらが分散メモリ
カップラ22により、それぞれPM#3上の送信ディス
クリプタリングZD13−SとPM#3上の送信処理要
求FIFOエリアZF3−Sにコピーされる。
がPM#3(18−3)内で発生したと仮定すると、P
M#3(18−3)内の送信MBディスクリプタリング
ZD33−Sに送信ディスクリプタQ2を、PM#3
(18−3)宛送信処理FIFOエリアZF3−Sに送
信処理要求QA2を登録する。この場合には、PM内通
信であるため、他のPMへのコピーは行われない。な
お、送信処理FIFOエリアZF3−SはFIFOメモ
リ構造であるため、最初に登録されたQA1が保存され
たままQA2が追加登録される。次に、3番目のメッセ
ージM3の送信要求がPM#2(18−2)で発生した
ものとすると、PM#2(18−2)上のPM#3宛送
信MBディスクリプタリングYD23−Sに送信ディス
クリプタQ3がPM#3宛送信処理FIFOエリアYF
3にQA3が登録される。それらが、それぞれPM#3
(18−3)上の送信MBディスクリプタリングZD2
3−SとPM#3上の送信処理要求FIFOエリアZF
3−Sにコピーされる。送信処理FIFOエリアZF3
−SにはQA1,QA2が保存されたまま、QA3が追
加登録される。送信ディスクリプタQ4,Q5について
も、全く同じように、Q5までの要求登録が終了した段
階では、図13のような記憶状態となる。
のINC送信処理オブジェクトは、PM#3(18−
3)宛の送信処理FIFOエリアZF3−Sを読み出す
と、入力した順に送信処理要求QA1,QA2,QA
3,QA4,QA5を取り出すことができる。要求の中
に記載されている送信元PM ID175と送信ディス
クリプタポインタ176から、対応する送信ディスクリ
プタQiの所在位置を求め、送信ディスクリプタQiか
らメッセージバッファの所在位置を求めることができ
る。このようにして、メッセージMiを順に処理してネ
ットワークに送出していく。ここで、従来のポーリング
方式では、3つの送信ディスクリプタリングZD13−
S、ZD23−S、ZD33−Sを順にポーリングして
送信要求の有無をチェックしており、処理要求の有無に
かかわらず、全ての送信ディスクリプタリングを見る必
要があった。そのため、読み出しても送信要求が見つか
らない空振りが生じることがあり、その結果、処理のオ
ーバヘッドが大きかった。これに対して本実施例では、
PM#3(18−3)で自PM宛送信処理FIFOエリ
アZF3−Sを周期的に読み出すだけで発生した送信要
求を取り出すことができ、無駄な空振りが生じることが
ないので、極めて処理効率が高い。また、PM#1(1
8−1)から送信処理FIFOエリアXF3−Sを経由
した送信処理FIFOエリアZF3−Sへの登録と、P
M#2(18−2)から送信処理FIFOエリアYF3
−Sを経由した送信処理FIFOエリアZF3−Sへの
登録が同時に発生しても、送信処理FIFOエリアZF
3−SのFIFOメモリの構造により、登録要求が直列
化されて全て蓄積されていくため、マルチプロセッサ間
の競合処理を行う必要がなく、処理オーバヘッドは極め
て軽減される。なお、図13では、送信要求の場合を例
に説明しているが、受信要求の場合にも全く同じよう
に、自PM宛の受信要求を指定された受信処理FIFO
エリアから読み出すため、発生した受信要求のみを効率
よく検出できる。
る各種データ構造を示す図である。図15(a)はメッ
セージバッファ(MB)180のデータ構造であり、N
EXTMP181は受信オブジェクト宛のメッセージを
リスト構造で接続するためのポインタ、SID182は
このメッセージの送信元である送信オブジェクトのI
D、RID183はこのメッセージの宛先である受信オ
ブジェクトのID、SIZE184はメッセージ本体
(BODY)186のサイズを表わしている。また、A
TTR185はこのメッセージの付属属性を表示したフ
ィールド、BODY186はメッセージの中味を示すフ
ィールドである。MB180の先頭アドレスは、MBA
202として付与される。各MBは固定長であり、前述
のように宛先PM IDが同じであるMB群が分散共有
メモリ21の連続するエリアに割り付けられて1つのM
Bプールを構成している。各MBプール対応にMB管理
マップが存在する。このMB管理マップは、MBプール
内のMB数に応じたMB管理マップエントリから構成さ
れる。
190の構造を示しており、V=0の場合には、対応す
るMBが『未使用』の状態であり、V=1の場合には、
対応するMBが『使用中』の状態を表わしている。MB
が1つ与えられると、その先頭アドレスMBA200の
値から、対応するMB管理マップエントリV190のア
ドレスが簡単に計算で求められるように構成される。同
じように、各宛先PM対応MBプール毎に送信ディスク
リプタリングと受信ディスクリプタリングが1つずつ存
在して、両者を合わせてディスクリプタリングと呼ぶ。
図14で説明したように、送信ディスクリプタリングは
他のシステムへのメッセージ制御情報を記憶し、受信デ
ィスクリプタリングは他のシステムから、あるいはシス
テム内の他PMからのメッセージ制御情報を記憶する。
ディスクリプタリングの各エントリ(ディスクリプタ)
はMBの各々に対応している。図15(c)は、ディス
クリプタ200の構造を示したものであって、201は
論理リンク番号で、対応するMB上のメッセージを通信
ネットワーク26経由で他のシステムに転送する場合に
使用する通信リンクの識別番号である。202は対応す
るMBの先頭アドレスMBAを記憶するフィールドで、
図15(a)で示したMBA202と同一である。20
3は実行権を表わす情報であり、実行権=『ENQ』で
あるならば、ディスクリプタリングにディスクリプタを
登録できる状態(エンキュー)におることを示してお
り、実行権=『DEQ』であれば、ディスクリプタリン
グからそのディスクリプタを取り出せる状態(デキュ
ー)にあることを示している。
クトの実行に必要な各種の制御データを記憶するオブジ
ェクトコントロールブロック(OCB)の構造を示した
もので、OCBA211はOCBの先頭アドレスを示す
ポインタ、NEXTOP212はOCBをレディキュー
にリンクする時のポインタ、MSGP213はオブジェ
クト宛のメッセージを記憶しているMBのアドレスを示
す。STATUS214は、オブジェクトの実行状態を
示すフィールドであり、送受信オブジェクト間の同期制
御に使用される。その他の制御215は、その他の制御
フィールドである。図16では、プロセッサ19実行待
ちのOCBを登録したレディキューの構造と、各種制御
データ構造との関係を示している。READYP220
で示されるレディキューに2つのOCB(OCBi22
1,OCBj222)が登録されており、OCBi22
1は2個のメッセージを受信し、OCBj222は3個
のメッセージを受信している状態にある例を示してい
る。
PMルーチングテーブルの構造図である。受信オブジェ
クトID(RID)(図15の183)の値を基にし
て、メッセージをシステム内のどのPMを経由して送受
信するかを指定するルーチングテーブルであって、本実
施例では、システムルーチングテーブル249とPMル
ーチングテーブル289から構成され、それぞれ各PM
のローカルメモリ20に記憶されている。システムルー
チングテーブル249の各エントリは、システムIDフ
ィールド250、システム通信モードフィールド25
1、通信リンクフィールド252、送信中継PMフィー
ルド253から構成されている。システムIDフィール
ド250に『自システムID260』が登録されている
エントリの場合には、そのエントリのシステム通信モー
ドフィールド251は、『システム内通信261』と表
示されている。一方、システムIDフィールド250に
『他システムID270』が登録されているエントリの
場合には、そのエントリのシステム通信モードフィール
ド251は『システム間通信271』と表示され、通信
リンクフィールド252には、他システムに結合されて
いる通信リンクの『通信リンクID272』が登録され
ている。また、送信中継PMフィールド253には、通
信リンクID272に対応する通信リンクを収容してい
る『送信中継PMのID273』を記憶している。ある
マルチプロセッサシステム17が、他のK個のマルチプ
ロセッサシステムと接続されている場合には、システム
ルーチングテーブル249のエントリ総数は(1+K)
個となる。
IDフィールド290、PM通信モードフィールド29
1、MB管理マップアドレスフィールド292から構成
される。PM IDフィールド290に『自PM ID
300』が登録されているエントリの場合には、そのエ
ントリのPM通信モードフィールド291には『PM内
通信301』と記述されており、MB管理マップアドレ
スフィールド292には『PM内通信MB管理マップベ
ースアドレス302』が登録されている。また、PM
IDフィールド290に、『他PM ID310』が登
録されているエントリの場合には、PM通信モードフィ
ールド291には『PM間通信311』と記述されてお
り、MB管理マップアドレスフィールド292には、そ
のPMIDに対応する『PM間通信MB管理マップベー
スアドレス312』が登録されている。各フィールドの
詳細な使用方法は後述する。なお、あるマルチプロセッ
サシステム17がJ個のPMから構成されている場合に
は、PMルーチングテーブルのエントリ総数はJ個であ
る。
内通信のタイムチャートであり、図19は同じくシステ
ム内PM間通信のタイムチャートであり、図20はシス
テム間PM無中継通信のタイムチャートであり、図21
はシステム間PM中継通信のタイムチャートである。な
お、図18〜図21のプロセッサの実行ステップのう
ち、太い罫線で示されたステップ(例えば、図18のス
テップS100)はプロセッサのスーパバイザモードで
実行している部分であり、これに対して細い罫線で示さ
れたステップ(例えば、図18のステップS102)は
プロセッサのユーザモードで実行している部分である。
図22〜図32は、アプリケーション(APL)オブジ
ェクトからの要求により、カーネル自身のプログラムあ
るいはカーネルが起動するプログラムのフローチャート
であって、いずれも全てプロセッサのスーパバイザモー
ドで実行される。図22は、カーネルの一部であって、
アプリケーション(APL)オブジェクトの起動および
終了処理を行うプログラムのフローチャートである。ま
た、図23および図24は、MB捕捉処理プログラムお
よびMB解放処理プログラムの各フローチャートであっ
て、APLオブジェクトからの要求により起動される。
また、図25および図26は、送信処理および受信処理
プログラムのフローチャートであり、これらもAPLオ
ブジェクトからの要求により起動される。
タリング、受信ディスクリプタリング、アダプタ送信デ
ィスクリプタリング、アダプタ受信ディスクリプタリン
グに共通なエンキュー処理(各ディスクリプタリングに
エントリを登録する処理)およびデキュー処理(各ディ
スクリプタリングからエントリを削除する処理)のプロ
グラムのフローチャートである。図27(a)はディス
クリプタリングの一般的な論理構造を示す図、図27
(b)はエンキュー処理のフローチャート、図28はデ
キュー処理のフローチャートである。図27(a)にお
いて、400はリードポインタ(RP)であり、ディス
クリプタリングからエントリを取り出す場合(デキュー
処理)のエントリ読み出しアドレスを指定する。401
はライトポインタ(WP)であり、ディスクリプタリン
グにエントリを登録する場合(エンキュー処理)のエン
トリ書き込みアドレスを指定する。各エントリは実行権
フィールド403と、処理要求内容を記憶するディスク
リプタアイテムフィールド404に分割される。ディス
クリプタアイテムフィールド404は、ディスクリプタ
リングの種類(例えば、送信ディスクリプタリングか/
アダプタ送信ディスクリプタリングかの違い)に依存し
て内容が変わることがある。実行権フィールド403
は、そのエントリにアクセスする主体がエンキュー側に
あるか/デキュー側にあるかを指定するもので、『EN
Q』と表わされているときには新しいエントリを登録し
てもよいことを意味し、『DEQ』の表わされていると
きには登録されているエントリを取り出してもよいこと
を意味する。エンキュー側はエントリを登録する毎にW
P401をインクリメントし、次のエンキュー位置を知
らせる。また、デキュー側はエントリを取り出す毎にR
P400をインクリメントし、次のデキュー位置を知ら
せる。
ー処理の各フローが示される。エンキュー処理では、ス
テップ420で、WP401で示されるエントリの実行
権フィールド403が『ENQ』と表示されているか否
かをテストする。もし、ENQと表示されているなら
ば、新しいエントりを登録してもよいことを意味するの
で、ステップ421でそのディスクリプタアイテムフィ
ールド404に新エントリ情報を書き込み、ステップ4
22でそのエントリの実行権フィールド403を『DE
Q』に書き替える。ステップ423では、このエントリ
の登録によりディスクリプタリングの最後に到達したか
否かをテストする。到達していなければ、ステップ42
4でWP401をインクリメントし、次のエンキュー位
置を設定する。ディスクリプタリングの最後に到達して
いれば、ステップ425でWP401の値をディスクリ
プタリングのベースアドレスにセットすることにより、
ディスクリプタリングをサイクリックに使用する。ステ
ップ420で実行権フィールド=『DEQ』と表示され
ているときには、これはディスクリプタリング402に
前回登録したエントリがデキュー側により未だ読み出さ
れずに残っていることを示すので、ステップ426でデ
ィスクリプタリングオーバフローのエラー処理を実行す
る。
でRP400で示されるエントリの実行権フィールド4
03が『DEQ』と表示されているか否かをテストす
る。もし、DEQと表示されていれば、エントリが登録
されており、そのエントリを取り出してもよいことを意
味するので、ステップ431でそのディスクリプタリン
グアイテムフィールド404からディスクリプタを取り
出し、ステップ432でその実行権フィールド403を
『ENQ』に書き替える。ステップ433では、このエ
ントリがディスクリプタリングの最後に登録されていた
ものか否かをテストする。ディスクリプタリング402
の最後でなければ、ステップ434でRP400をイン
クリメントし、次のデキュー位置を知らせて、ステップ
435で取り出したディスクリプタエントリを呼び出
し、元に渡す。ディスクリプタリングの最後であれば、
ステップ436でRP400の値をディスクリプタリン
グのベースアドレスにセットすることにより、ディスク
リプタをサイクリックに使用する。ステップ430で実
行権フィールド=『ENQ』と表示されていれば、これ
はディスクリプタリングで前回のサイクルエントリを削
除してから、エンキュー側により未だ新しくエントリが
登録されていないことを示しているので、何もせず、リ
ターンする。
ローチャートである。IOC配信プログラムは、定期的
に自PM宛の受信処理FIFO通信エリア(図5〜図7
参照)を読み出し、他のPMから受信処理要求が送られ
てきたか否かをチェックする。図30は、INC送信処
理プログラムのフローチャートである。また、図31お
よび図32は、INC受信処理プログラムのフローチャ
ートである。以下、図18〜図33を参照しながら、実
施例の動作を説明する。図10および図11に示した分
類に従って、次の4つのメッセージ通信のケースについ
て詳述する。 (ケース1)システム内PM内通信 (ケース2)システム内PM間通信 (ケース3)システム間中継PMなしの通信(システム
間PM無中継通信) (ケース4)システム間中継PMありの通信(システム
間PM中継通信)
ェクトから同じPM(18−1)内の受信オブジェクト
にメッセージを転送する場合を考える。送信オブジェク
トと受信オブジェクトは互いに非同期で実行されるの
で、その実行順序は種々のケースが考えられるが、ここ
では簡単のために送信オブジェクトが受信オブジェクト
よりも先に実行される図18のケースを仮定する。図1
8において、S100はAPLオブジェクト起動、S1
01はMB捕捉、S102はメッセージ書込み、S10
3は送信処理、S104はAPLオブジェクト終了であ
る。また、S110はAPLオブジェクト起動、S11
1は受信処理、S112はメッセージ読出し、S113
はMB解放、S114はAPLオブジェクト終了であ
る。 「ステップS100」カーネルは、ステップS100
で、アプリケーション(APL)オブジェクトを実行さ
せる準備を行う。APLオブジェクトとは、ユーザモー
ドで動作するアプリケーションプログラムのことであ
る。ステップS100の『APLオブジェクト起動』の
内容は、図22に示すように、ステップ330でレディ
キュー(実行可能なオブジェクトコントロールブロック
(OCB)(図16の210)がリスト構造でリンクさ
れたもの(図16参照)から、次に実行すべきAPLオ
ブジェクトのOCB210を取り出す。次に、ステップ
331で、APLオブジェクトに与えられているオブジ
ェクトID(図12の170)を分散メモリプロテクタ
23内のカレントコントロールレジスタ(CCR)51
に設定する。このタイミングは、図18のタイミングt
100により示される。次に、図22のステップ332
で、必要な情報をOCB210からプロセッサ19にロ
ードして、APLオブジェクトの実行を開始する。ここ
では、APLオブジェクトが送信オブジェクトであるた
め、送信オブジェクトの実行が開始される。
が、MBの捕捉をカーネルに要求すると、カーネルは図
23のMB捕捉処理プログラムを実行する。図23のス
テップ350で、メッセージを受信する受信オブジェク
トのID(図12のRID170)内のシステムIDフ
ィールド171を取り出す。この値をシステムルーチン
グテーブル(図17の249)のシステムIDフィール
ド250の各エントリと比較し、一致したエントリのシ
ステム通信モードフィールド251、通信リンクフィー
ルド252、送信中継PMフィールド253の値を取り
出す。ここでは、同一システム内の同一PM内通信であ
るため、『自システムID』と記されたエントリ260
と一致し、そのシステム通信モードフィールド251
は、『システム内通信』261と表示されているため、
ステップ351からステップ352に進む。ステップ3
53では、受信オブジェクトID(RID)のPM I
Dフィールド172をPMルーチングテーブル(図17
の289)のPM IDフィールド290の各エントリ
と比較して、一致したエントリのPM通信モードフィー
ルド291と、MB管理マップアドレスフィールド29
2の値を取り出す。ここでは、同一システム内の同一P
M内通信であるため、『自PM ID』と記述されたエ
ントリ300と一致し、その結果、『PM内通信30
1』と表示されたPM通信モードフィールドと、『PM
内通信MB管理マップベースアドレス302』と表示さ
れたMB管理マップアドレスフィールドとを取り出す。
ップアドレス292で指定されたMB管理マップを検索
し、空きを表示しているMB管理マップエントリを検出
し、それに対応する空きMBアドレスMBA(図15の
202)を求め、そのMB管理マップエントリ(図15
の190)を『使用中』に書き替える。MB管理マップ
エントリとMBとは、1対1に対応するように構成され
ており、MB管理マップエントリアドレスからMBアド
レスを求めることができるとともに、逆にMBアドレス
からもMB管理マップエントリアドレスを求めることが
できる。ここでは、PM内通信用MB管理マップが選択
され、その中の適当な空きMB、例えば図5,図7のM
B(X11−2)が選択される。ステップ353の最後
で、MB(X11−2)に対応するMB管理マップエン
トリ(XM11−2)が図17の及楽石械胤t101で
『使用中』に書き替えられる。続いて、ステップ354
で、MB(X11−2)に対応するメモリケーパビリテ
ィレジスタ(MCR)53のアドレスを求め、MCR5
3に、このMBへのアクセス権を獲得したオブジェク
ト、つまり送信オブジェクトのID(SID)が図18
のタイミングt102で登録される。以上が、図18の
ステップS101のMB捕捉処理である。
は、図18のステップS102で、作成したメッセージ
をMB(X11−2)にタイミングt103で書き込
む。図18のプロテクションウィンドウ開放期間w1
は、CCR51とMCR53の両方に値が設定されてい
る区間で、MCRとCCRとが指定しているAPLオブ
ジェクト(送信オブジェクト)は、MB(X11−2)
にアクセスすることができるが、他のAPLオブジェク
トはアクセスすることができなくなり、MBに対する強
固な保護が実現される。
ステップS103でカーネルに送信処理を依頼すると、
カーネルは、図25の送信処理プログラムを実行する。
先ず、図25のステップ380でMB(X11−2)に
対応するMCR53を図18のタイミングt104でク
リアする。これで、図18のプロテクションウィンドウ
開放期間w1が終了するため、以後、カーネル以外はM
B(X11−2)にアクセスできなくなる。次に、図2
5のステップ381で、通信モードをチェックする。こ
こでは、『システム内PM内通信』であるため、ステッ
プ382で受信オブジェクトのOCB210のメッセー
ジキューにMB(X11−2)のアドレス(MBA)を
登録する。続いて、ステップ383でOCB210のS
TATUSフィールド(図15の214)が『送信側実
行待ち』となっているか否かをテストする。『送信側実
行待ち』は、受信オブジェクトが送信オブジェクトより
も先に実行された結果、受信オブジェクトが送信オブジ
ェクトの実行を待っている状態を表わす。このケースで
は、送信オブジェクトが受信オブジェクトよりも先に実
行されるため、ステップ383は『NO』となって、ス
テップ385でOCB210のSTATUSフィールド
214を『受信側実行待ち』と設定して、受信オブジェ
クトの実行を待つ状態になったことを表示する。
は、カーネルがAPLオブジェクト終了処理を起動す
る。APLオブジェクト終了処理プログラムは、図22
に示されており、ステップ340でカレントケーパビリ
ティレジスタCCR51の値を図18のタイミングt1
05でクリアする。続いて、図22のステップ341で
送信オブジェクトの再開に必要な情報をOCB210に
退避することにより、送信オブジェクトの処理を完了す
る。
て、カーネルは次に実行すべきオブジェクトして受信オ
ブジェクトを選択し、図22のAPLオブジェクト起動
プログラムを実行する。送信オブジェクトの場合と同じ
ように、図18のタイミングt110で受信オブジェク
トID(RID)(図15の183)をカレントケーパ
ビリティレジスタ(CCR)51に設定する。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図26の受信処理プログラ
ムを起動する。図26のステップ390では、受信オブ
ジェクトのOCB210のSTATUSフィールド21
4が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。『受信側実行待ち』は、送信オ
ブジェクトが受信オブジェクトよりも先に実行された結
果、受信オブジェクトの実行を待っている状態である。
また、『同期完了』は、受信オブジェクトが送信オブジ
ェクトよりも先に実行されたため、途中で休止し、その
後、送信オブジェクトが実行されたことにより、送受信
間の同期がとれた状態を示している。このケースでは、
図18のステップS103で、STATUSフィールド
214を『受信側実行待ち』と設定しているため、ステ
ップ390は『YES』となる。これは、メッセージが
送信側から既に届いているため、直ちにメッセージキュ
ーにつながっているメッセージをキューから外し、その
MB(X11−2)のアドレスを取り出す。続いて、ス
テップ392では、このMBアドレスに対応するMCR
53に受信オブジェクトID(RID)183を設定す
る。このタイミングは、図18のタイミングt111で
示される。これにより、CCR51とMCR53の両方
に受信オブジェクトID(RID)183が設定された
ので、以後、図18のプロテクションウィンドウ開放期
間(w2)中は、MB(X11−2)が受信オブジェク
ト以外のAPLオブジェクトからアクセスできないよう
にプロテクトされることになる。
が、MB(X11−2)からタイミングt112でメッ
セージを読み出して、対応する処理を行う。
は、ステップS113でカーネルにMB解放を依頼す
る。カーネルは、図24のMB解放処理プログラムを起
動する。図24において、ステップ360で、MB(X
11−2)に対応するMCR53をクリアする。このタ
イミングは、図18のタイミングt113に示されてい
る。続いて、図24のステップ361でMB(X11−
2)に対応するMB管理マップエントリ(XM11−
2)を『空き』に更新する。このタイミングは、図18
のタイミングt114に示されている。MB管理マップ
エントリを『空き』に更新すると、以後は、いつでもこ
のMB(X11−2)を再利用することが可能となる。
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ(CCR)51の値を図18のタイミングt
115でクリアする。APLオブジェクト終了処理は、
図22に示されており、送信オブジェクトの場合と同じ
であるため説明を省略する。以上のように、システム内
PM内通信の場合には、送信オブジェクトと受信オブジ
ェクトがユーザレベルで直接アクセスできる分散共有メ
モリエリアに、メッセージバッファを確保することによ
り、メッセージバッファ間の無駄なコピーを避けること
ができるので、効率的なメッセージ通信が可能となる。
ュール(PM)18−1内の送信オブジェクトから、P
M18−2内の受信オブジェクトにメッセージを転送す
る場合を仮定する。さらに、図19に示すように、送信
オブジェクトの実行終了前に受信オブジェクトの実行が
開始される場合を考える。使用するMBを図5のX12
−1とすると、対応するMB管理マップエントリはXM
12−1となる。また、この処理依頼内容の詳細は受信
ディスクリプタリングXD12−Rに、受信処理要求は
受信PM18−2宛の受信処理FIFOエリアXF2−
Rに登録されるものとする。処理の流れを、図19の各
ステップに従って説明する。S120はAPLオブジェ
クト起動、S121はMB捕捉、S122はメッセージ
書込み、S123は送信処理、S124はAPLオブジ
ェクト終了である。また、S110はAPLオブジェク
ト起動、S111は受信処理、S112はメッセージ読
出し、S113はMB解放、S114はAPLオブジェ
クト終了である。
カーネルは、ステップS120でAPLオブジェクト起
動プログラム(図22)を実行し、送信オブジェクトI
D(SID)を図19のタイミングt120でPM18
−1のCCR51−1に設定し、送信オブジェクトの実
行を開始する。
MB捕捉をカーネルに要求し、カーネルは図23のMB
捕捉処理プログラムを実行する。このケースでは、同一
システム内で2つのPMにまたがった通信であるため、
図23のステップ350で検索して取り出されるシステ
ム通信モードフィールド(図17の251)の値は『シ
ステム内通信』261となり、ステップ351からステ
ップ352に進む。ステップ352で検索して取り出さ
れるPM通信モードフィールド(図17の291)の値
は『PM間通信311』となり、これに対応して『PM
間通信MB管理マップベースアドレス322』と表示さ
れたMB管理マップアドレスフィールドを取り出す。ス
テップ353では、選択した『PM間通信MB管理マッ
プベースアドレス322』で指定されたMB管理マップ
を検索し、空きを表示しているMB管理マップエントリ
を検出して、それに対応する空きMBアドレスを求め、
そのMB管理マップエントリを『使用中』に書き替え
る。この例では、PM18−1からPM18−2への通
信用MBX12−1が図19のタイミングt121で
『使用中』に書き替えられるが、この時点で同時にXM
12−1と同一アドレスを持つ受信側分散共有メモリ2
1−2のMB管理マップエントリYM12−1も書き替
えられる。この書き替えは、次のような操作で行われ
る。
−1がMB管理マップエントリXM12−1の書き替え
命令を実行すると、MB管理マップエントリXM12−
1のアドレスと書き替えデータがプロセッサバス30−
1(図1参照)に送出される。送信側分散メモリカップ
ラ22−1では、送信側分散共有メモリ21−1への書
き込みアクセスがあった場合に、バス信号デコーダ31
−1が分散共有メモリ21−1への書き込みアクセスで
あることを検出し、信号線32−1を経由して転送制御
部33−1を起動する。転送制御部33−1は、MB管
理マップエントリXM12−1のアドレスと書き替えデ
ータを取り込み、モジュールID管理部34−1に、M
B管理マップエントリのページアドレスを供給する。モ
ジュールID管理部34−1のCAMコマンドレジスタ
(図8の67−1)には、予め『キーレジスタ(図8の
66−1)との比較動作』を指示するコマンドが入れら
れているため、MB管理マップエントリXM12−1の
ページアドレスがキーレジスタ66−1に格納される
と、キーレジスタ(66−1)とCAMセル部(図8の
61−1)との一斉比較が行われる。CAMセル部61
−1の各エントリは、他のPMの分散共有メモリエリア
と重複しているエリアのページアドレス63を含んでい
る。
の間で共有されているXM12−1のページアドレス
と、受信PM18−2IDのペアがそれぞれCAMセル
部61−1とデータメモリ部62−2に登録されてい
る。従って、CAMセル部61−1における比較動作に
より一致が検出され、対応する受信PM18−2のID
がデータメモリ部62−1から取り出される。これを、
パケット送信レジスタ35−1に転送する。パケット送
信レジスタ35−1では、図9に示すように、属性識別
フィールド80を‘0’に設定して、共有分散メモリア
クセスタイプのパケットであることを表示し、宛先PM
IDフィールド81には、モジュールID管理部から
取り出した値(PM18−2のID)を設定する。ま
た、分散共有メモリアドレスフィールド82と書き込み
データフィールド83には、プロセッサバス30−1上
のアドレス(XM12−1のアドレス)とデータ(『使
用中』表示データ)を載せ、書き込み単位フィールド8
4には、プロセッサバス30−1が指示する信号(バイ
ト書き込みとバイト位置情報)を載せて送信パケットを
編集する。これをパケット送信バッファ36−1に送出
すると、パケット送信バッファ36−1は送信パケット
をプロセッサモジュール間通信路25に送出する。プロ
セッサモジュール間通信路25は、送信パケットの宛先
PM IDフィールド81を見てルーチングを行い、受
信PM18−2のパケット受信バッファ37−2に送り
届ける。
37−2のデータはパケット受信レジスタ38−2に入
れられてパケットデコーダ39−2でデコードされ、共
有分散メモリ21−2への書き込みであることがわかる
と、転送制御部33−2を起動する。転送制御部33−
2は、パケット受信レジスタ38−2内の分散共有メモ
リアドレス(XM12−1のアドレス)、書き込みデー
タ(『使用中』表示データ)、書き込み単位の情報をプ
ロセッサバス30−2経由で分散共有メモリ21−2に
送ることにより、XM12−1への書き込みデータと同
じ値が受信側分散共有メモリ21−2の同じアドレス位
置、つまりYM12−1に書き込まれる。このようにし
て、分散共有メモリへの書き込み側が自分の分散共有メ
モリへのローカルな書き込みを行うだけで、分散メモリ
カップラ22の働きにより自動的に宛先の分散共有メモ
リにも同じ値がコピーされるので、DMAのようなソフ
トウェアによるコピーオーバーヘッドを伴わないという
利点がある。
を備えるプロセッサ19では、分散共有メモリ21への
書き込みアクセスがキャッシュヒットすると、その時点
でキャッシュメモリへの書き込みだけが行われ、分散共
有メモリ21への書き込みは直ちに行われないことがあ
る。その場合には、キャッシュメモリへの書き込み後、
キャッシュメモリ内の書き込みデータを分散共有メモリ
に戻す命令を実行することにより、送信側分散共有メモ
リ21−1への書き込みを確実に行うので、受信側分散
共有メモリ21−2へのコピーも確実に行うことができ
る。次に、図23のステップ354では、MB(X12
−1)に対応するメモリケーパビリティレジスタ53−
1のアドレスを求め、MCR53−1に対しこのMBへ
のアクセス権を獲得した送信オブジェクトのID(SI
D)を図19のタイミングt122で登録する。以上
で、ステップS121のMB捕捉処理を終了する。
作成したメッセージを送信側分散共有メモリのMB(X
12−1)にタイミングt123で書き込みを行う度毎
に、この書き込みデータが分散メモリカップラ22によ
り受信側分散共有メモリの同一アドレスのMB(Y12
−1)にも伝搬して書き込まれる。その操作は、図19
のタイミングt121で説明した通りである。なお、本
実施例のメッセージ書き込みステップでは、図9に示す
ように、書き込み単位、例えば4バイトの書き込みデー
タ毎に1つのパケットを構成し、分散メモリカップラ2
2間で送受する構成であるがメッセージのようにメモリ
の連続エリアへの書き込みが行われる場合には、図9の
送受信パケットを、先頭の書き込みアドレスに続いて複
数個の書き込みデータを1パケットにまとめた構成にし
て、分散メモリカップラ22間で送受する方法も可能で
ある。その場合には、連続エラアへの書き込みが行われ
ているのか、または単発エリアの書き込みが行われてい
るのかを分散メモリカップラ22側で事前に検知するこ
とができないため、分散メモリカップラ22は、予め決
められた時間内に決められた回数の連続アドレスエリア
書き込みがあれば、それらを1パケットにまとめて送
る。また、決められた時間内に決められた回数よる少な
い連続アドレスエリア書き込みであれば、タイムアウト
になった時点で、それまでにたまっている連続アドレス
エリア書き込みデータを1パケットにまとめて送出すれ
ばよい。図19において、連続番地CCR51−1とM
CR53−1の両方の値が設定されている区間(ステッ
プS121からステップS124までの区間)では、M
CRとCCRにより指定された送信オブジェクトがMB
(X12−1)にアクセスすることができるが、PM1
8−1内の他のAPLオブジェクトはアクセスすること
ができない。
は、カーネルに送信処理を依頼する。送信処理プログラ
ムは、図25に示されるように、先ずステップ380で
MB(X12−1)に対応するMCR53−1をクリア
する。この動作は、図19のタイミングt124に示さ
れており、これによりプロテクションウィンドウ開放期
間が終了するので、これ以後、カーネル以外はMB(X
12−1)にアクセスすることができなくなる。次に、
図25のステップ381で通信モードをチェックする。
ここでは、『システム内PM間通信』であるため、ステ
ップ386に進む。ステップ386では、図19のステ
ップS121で検索一致したPM ID(図17の29
0)、つまりPM18−2宛の受信ディスクリプタリン
グXD12−Rに受信処理制御情報を登録(エンキュ
ー)すると同時に、図14のフォーマットの処理要求を
受信PM18−2宛の受信処理FIFO(XF2−R)
に書き込む。これらの書き込みは、図19のタイミング
t125で行われる。受信ディスクリプタリングXD1
2−Rへのエンキュー処理は、図27に示されているの
で、説明は省略する。受信ディスクリプタリングXD1
2−Rに書き込みが行われると、書き込みデータが分散
メモリカップラ22−1により受信PM18−2にも転
送され、その分散共有メモリ21−2の同一アドレスで
あるYD12−Rにも書き込まれる。
いて、送信PM18−1側の受信処理FIFOエリア
(XF2−R)は、通常のRAMで構成されているが、
受信PM18−2側の受信処理FIFOエリア(YF2
−R)はFIFOメモリで構成されている。従って、X
F2−Rへの書き込みデータが分散メモリカップラ22
により受信側の分散共有メモリの受信処理FIFOエリ
ア(YF2−R)に伝達されると、YF2−Rでは、以
前に書き込まれたデータを保存したまま、新しい書き込
みデータが追加して書き込まれる。以上により、メッセ
ージ送信に必要な情報が受信PM18−2に全て伝達さ
れた。
APLオブジェクト終了処理を起動し、カレントケーパ
ビリティレジスタ(CCR)51−1の値を図18のタ
イミングt126でクリアする。
て、カーネルは次に実行すべきオブジェクトして受信オ
ブジェクトを選択し、図19のタイミングt130で受
信オブジェクトID(RID)を受信PM18−2内の
カレントケーパビリティレジスタ(CCR)51−2に
設定する。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図26の受信処理プログラ
ムを起動する。図26のステップ390では、受信オブ
ジェクトのOCB210のSTATUSフィールド(図
15(d)の214)が『受信側実行待ち』または『同
期完了』になっているか否かをテストする。このケース
では、この時点で送信オブジェクトからのメッセージが
到着していないため、『受信側実行待ち』または『同期
完了』の状態になく、『no』となる。そこで、ステッ
プ393で先に受信オブジ敵クトの要求が到着したこと
を示すために、STATUSフィールド214を『送信
側実行待ち』に設定し、カーネルにリターンする。
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるために、図22のAPLオブジェク
ト終了処理を起動し、ステップ340でカレントケーパ
ビリティレジスタ(CCR)51−2の値を図19のタ
イミングt131でクリアし、ステップ341で受信オ
ブジェクト再開に必要な情報をOCB210に退避す
る。
IOC配信プログラムは、図29に示すように、定期的
にPM#2宛の受信処理FIFO(YF2−R(図
7))を読み出すことにより受信処理要求の有無をチェ
ックする。具体的には、図29のステップ500で受信
処理FIFO(YF2−R)から要求を図19のタイミ
ングt140で読み出し、ステップ501で要求の有無
をチェックする。もし、要求があれば、ステップ502
で、引き続き同じタイミングt140で読み出した要求
が指定している受信ディスクリプタリングYD12−R
に対して図28の『デキュー処理』を実行し、受信ディ
スクリプタ(図15(c)の200)を取り出す。ステ
ップ503で、受信ディスクリプタ内のMBA(図15
(c)の202)を参照して、図15(a)で示される
構造のMB(Y12−1)をアクセスしてMB(Y12
−1)内の受信オブジェクトID(RID)(図15の
183)を取り出す。ステップ504で、RID183
に対応する図15(d)のOCBのメッセージキュー
に、MB(Y12−1)のアドレスMBA202を登録
する。ステップ505では、この受信オブジェ説のOC
B210のSTATUSフィールド(図15の214)
が『送信側実行待ち』となっているか否かをテストす
る。ここでは、図19のステップS131でSTATU
Sフィールド214を『送信側実行待ち』と設定してい
るため、ステップ505は『yes』となる。これは、
受信オブジェクトが送信側からメッセージを受け取る準
備をして休止状態にいることを表わしているため、ステ
ップ506では、受信オブジェクトのOCB210のS
TATUSフィールド214を『同期完了』と設定して
送信要求と受信要求の両方が揃ったことを表示する。次
に、ステップ507で、受信オブジェクトのOCB21
0をレディキューに登録して受信オブジェクトが再起動
されるようにする。
カーネルは、レディキューの中から次に実行すべきオブ
ジェクトとして受信オブジェクトを選択し、図19のタ
イミングt150で受信オブジェクトID(RID)を
受信PM18−2内のカレントケーパビリティレジスタ
(CCR)51−2に設定する。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図26の受信処理プログラ
ムを起動する。図26のステップ390では、受信オブ
ジェクトのOCB210のSTATUSフィールド21
4が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。このケースでは、図19のステ
ップS140でSTATUSフィールド214を『同期
完了』と設定しているため、ステップ390は『ye
s』となる。これは、メッセージが送信側から既に届い
ているので、直ちにメッセージを読み出してもよいこと
を示している。そこで、ステップ391では、OCB2
10のメッセージキューにつながっているメッセージを
キューから外し、そのMB(Y12−1)のアドレスを
取り出する。続いて、ステップ392で、このMBアド
レスに対応するMCR53−2に受信オブジェクトID
(RID)を設定する。このタイミングは、図19のタ
イミングt151で示されている。これにより、CCR
51−2とMCR53−2の両方に受信オブジェクトI
D(RID)が設定されたので、以後は、MB(Y12
−1)が受信オブジェクト以外のAPLオブジェクトか
らアクセスできないようにプロテクトされた。
MB(Y12−1)からタイミングt152でメッセー
ジを読み出し、対応する処理を行う。ここで受信オブジ
ェクトは、送信オブジェクトがメッセージを書き込んだ
送信側分散共有メモリ21−1のMB(X12−1)か
らでなく、そのコピーを記憶する受信側分散共有メモリ
21−2のMB(Y12−1)から読み出すため、リモ
ートメモリアクセスを行う場合に比較して極めて高速で
ある。
は、カーネルにMB解放を依頼する。カーネルは、図2
4のMB解放処理プログラムを起動し、図24のステッ
プ360で、MB(Y12−1)に対応するMCR53
−2を図19のタイミングt153でクリアする。次
に、図24のステップ361でMB(Y12−1)に対
応するMB管理マップエントリ(YM12−1)を図1
9のタイミングt154で『空き』に書き替える。この
値の書き替えは、受信側の分散共有メモリ21−2のみ
ならず、同時に送信側の分散共有メモリ21−1の同一
ロケーションXM12−1に対しても行われる。その理
由は、受信側分散メモリカップラ22−2内のモジュー
ルIDディレクトリ(図8の60)に、各MB管理マッ
プのページアドレスと、送信側PMIDのペアが記憶さ
れているので、受信側分散共有メモリ21−2への書き
込みが生じると、分散メモリカップラ22−2,22−
1経由で、送信の分散共有メモリ21−1にも書き込ま
れるためである。本発明では、MBは常に送信PMで一
元管理するので、図19のタイミングt155で、送信
側のMB管理マップェントリXM12−1への書き替え
が完了すると、この時点以後は、いつでも送信PMでM
B(X12−1)を再利用することが可能である。
ブジェクト終了処理を実行し、カレントケーパビリティ
レジスタ(CCR)51−2の値を図19のタイミング
t156でクリアする。以上のように、システム内PM
間通信の場合には、分散メモリカップラ22の働きによ
り、メッセージおよびその制御情報を送信PMと受信P
M間で極めて簡単に授受を行うことができるので、効率
的なメッセージ通信が行える。
ッサシステムのいずれも、中継PMを介さないで通信す
るパターンの例を説明する。図20に示すように、マル
チプロセッサシステム17−1において送信オブジェク
トの存在するプロセッサモジュール(PM)18−1か
らネットワークを介して他のマルチプロセッサシステム
17−2の受信オブジェクトの存在するPM18−3に
メッセージを転送する場合を考える。このケースでは、
送信オブジェクトの実行終了前に、受信オブジェクトが
実行開始するものとする。送信側が使用するMBは、図
7のX11−1、そのMB管理マップエントリはXM1
1−1とする。また、この処理依頼内容の詳細は、送信
ディスクリプタリングXD11−Sに、送信処理要求は
送信PM18−1の送信処理FIFO(XF1−S)に
登録されるものとする。処理の流れを図20の各ステッ
プに沿って説明する。図20におけるS160はAPL
オブジェクト起動、S161はMB捕捉、S162はメ
ッセージ書き込み、S163は送信処理、S164はA
PLオブジェクト終了、S170はINC送信処理、S
180はAPLオブジェクト起動、S181は受信処
理、S182はAPLオブジェクト終了、S190はI
NC受信処理、S200はAPLオブジェクト起動、S
201は受信処理、S202はメッセージ読出し、S2
03はMB解放、S204はAPLオブジェクト終了で
ある。
カーネルは、ステップS160のAPLオブジェクト起
動の実行により、送信オブジェクトのID(SID)を
タイミングt160でPM18−1のCCR51−1に
設定し、送信オブジェクトの実行を開始する。
MBの捕捉をカーネルに要求すると、カーネルは図23
のMB捕捉処理プログラムを実行する。このケースは、
異なるシステムに存在する2つのPM間の通信であるた
め、図23のステップ350で検索して取り出されるシ
ステム通信モードフィールド(図17の251)の値は
『システム間通信』271となる。従って、図23のス
テップ351では、『システム間通信』側選択され、ス
テップ355で対応するエントリの通信リンクID(図
17の272)と送信中継PM ID273の値が取り
出される。ステップ356で、送信中継PM ID27
3をキーとしてPMルーチングテーブル289を検索
し、ステップ353で送信PM18−1と送信中継PM
との通信で使用するMBプールとそのディスクリプタリ
ングを決定する。このケースの送信側システムでは、P
M無中継であるため送信PM18−1と送信中継PMと
が一致し、ステップ356で、PM内送信用MBプール
X11とそのMB管理マップXM11が選択される。ス
テップ353では、PM内通信用MBマップ端漆歳XM
11−1が『使用中』に書き替えられる。次に、図23
のステップ354で、MB(X11−1)に対応するメ
モリケーパビリティレジスタ(MCR)53−1に、こ
のMBへのアクセス権を獲得した送信オブジェクトのI
D(SID)が図20のタイミングt162で登録され
る。
は、作成したメッセージを送信側分散共有メモリのMB
(X11−1)にタイミングt163で書き込む。この
メッセージの書き込みステップでは、ccr51−1と
MCR53−1の両方の値が設定されている区間は、M
CRとCCRにより指定されている送信オブジェクトが
MB(X11−1)にアクセスすることができるが、他
のAPLオブジェクトはアクセスすることができない。
は、カーネルに送信処理を依頼する。図25の送信処理
プログラムではステップ380でMB(X11−1)に
対応するMCR53−1をクリアする。これは、図20
のタインミングt164で示されており、これによりプ
ロテクションウィンドウ開放期間が終了するため、以
後、カーネる以外はMB(X11−1)にアクセスでき
なくなる。次に、図25のステップ381で、通信モー
ドをチェックする。このケースでは、『システム間PM
無中継通信(システム間PM内通信)』であるため、ス
テップ387に進み、図20のステップS161で検索
一致したPM ID(図17の290)、つまりPM1
8−1宛の送信ディスクリプタリングXD11−Sに送
信制御情報を登録(エンキュー)し、図14のフォーマ
ットの処理要求を自PM18−1宛の送信処理FIFO
(XF1−S)(図7参照)に書き込む。これらの登録
は、図20のタイミングt165で行われる。なお、こ
のケースでは、送信PM18−1の送信ディスクリプタ
リングXD11−Sと送信処理FIFO(XF1−S)
は、他の分散共有メモリ内にコピーを持たないため、分
散メモリカップラによる他分散共有メモリへの書き込み
は行われない。
ブジェクト終了処理を起動し、カレントケーパビリティ
レジスタ(CCR)51−1の値を、図20のタイミン
グt166でクリアする。
INC送信処理プログラムは、図30に示すように、定
期的に自PM宛の送信処理FIFO(XF1−S)を読
み出すことにより要求の有無をチェックしている。具体
的には、図30のステップ520で、送信処理FIFO
(XF1−S)から要求を図20のタイミングt170
で読み出し、ステップ521で要求の有無をチェックす
る。本実施例のステップS170の時点においては、既
に送信処理FIFO(XF1−1)に要求が登録されて
いるので、ステップ522で、要求が指定している送信
ディスクリプタリングXF1−Sに対して図28の『デ
キュー処理』を実行する。ステップ523で、図13に
示す構造の送信ディスクリプタを引き続き図20のタイ
ミングt170で取り出し、この情報をもとにしてネッ
トワークを介した通信に必要とする各種のプロトコル処
理(例えば、ネットワークパケットのヘッダの作成、再
送制御情報の作成、チェックサムの計算等)を行う。次
に、ステップ524では、ネットワークアダプタの起動
に必要なアダプタ送信ディスクリプタ(図30のステッ
プ530)を作成する。ステップ525では、このアダ
プタ送信ディスクリプタをアダプタ送信ディスクリプタ
リングに、図20のタイミングt171で登録する。
アダプタ送信ディスクリプタリングを監視しており、デ
ィスクリプタの登録があると、この情報をもとにしてネ
ットワークが要求するサイズにメッセージを分割し、ヘ
ッダや誤り制御情報を付加してネットワークパケットと
してネットワークに送出する。このタイミングは図20
のタイミングt172で示されている。ネットワークア
ダプタ24−1は、メッセージの転送を完了するか、あ
るいは通信相手のシステムからメッセージ到着確認の連
絡を受けると、送信側でメッセージバッファを保持して
おく必要がなくなったため、図20のタイミングt17
3でMB(X11−1)に対応するMB管理マップのエ
ントリXM11−1を『空き』に書き替える。その結
果、この時点以降、送信PM18−1では、いつでもこ
のMB(X11−1)を再利用することができる。
3内処理 「ステップS180」図20において、受信システム1
7−2のカーネルは、次に実行すべきオブジェクトとし
て受信オブジェクトを選択し、図20のタイミングt1
80で受信オブジェクトID(RID)を受信PM18
−3内のカレントケーパビリティレジスタ(CCR)5
1−3に設定する。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図26の受信処理プログラ
ムを起動する。図26のステップ390では、受信オブ
ジェクトのOCB(図15(d)の210)のSTAT
USフィールド(図14の214)が『受信側実行待
ち』または『同期完了』になっているか否かをテストす
る。このケースでは、この時点で、送信オブジェクトか
らのメッセージは到着していないため、『受信側実行待
ち』または『同期完了』の状態にはなく、『no』とな
る。そこで、ステップ393で、先に受信オブジェクト
の要求が到着したことを示すために、STATUSフィ
ールド214を『送信側実行待ち』に設定し、カーネル
にリターンする。
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるため、図22のAPLオブジェクト
終了処理プログラムを起動し、ステップ340でカレン
トケーパビリティレジスタCCR51−3の値を図20
のタイミングt181でクリアし、ステップ341で受
信オブジェクト再開に必要な情報をOCB210に退避
する。
t172で、送信システム17−1からネットワークパ
ケットが届くと、受信システム17−2のネットワーク
アダプタ24−3は、自分が管理している、分散共有メ
モリ21−3内のPM#3内通信領域の空きのローカル
メッセージバッファの1つに、ネットワークパケットを
記憶する。メッセージが複数のネットワークパケットで
分割されて送られて来る場合には、送られてきたネット
ワークパケットをパケットヘッダを見ながらローカルメ
ッセージバッファ内の指定された位置に入れることによ
りメッセージの組み立て処理を行い、最終的に1つのメ
ッセージに組み立てる。そして、でき上ったメッセージ
に関する制御情報をアダプタ受信ディスクリプタリング
に登録する。INC受信処理プログラムは、図31,図
32に示すように、定期的にアダプタ受信ディスクリプ
タリングを読み出すことにより要求の有無をチェックす
る。
て、受信システム17−2のPM18−3のINC受信
処理プログラムは、ステップ560でアダプタ受信ディ
スクリプタリングに対して、図28の『デキュー処理』
を実行し、ステップ561でアダプタ受信ディスクリプ
タリングにエントリが登録されていたか否かをチェック
する。本実施例のステップS190の時点では、到着し
たメッセージをアダプタ受信ディスクリプタに登録済み
のため、ステップ562でアダプタ受信ディスクリプタ
(図33の590)を図20のタイミングt190で取
り出し、この情報をもとにプロトコル受信処理(例え
ば、ネットワークパケットのヘッダのチェック、再送制
御情報の作成等)を行う。次に、ステップ563で、ア
ダプタ受信ディスクリプタ中のローカルメッセージバッ
ファアドレス(LBA)591を参照してローカルメッ
セージバッファをアクセスし、受信オブジェクトID
(RID)(図15(a)の183)を取り出す。ステ
ップ564では、RIDのPMIDフィールド(図12
の172)をキーにして、PMルーチングテーブル(図
16の289)のPM IDフィールド290を探索
し、PM IDが一致したエントリの通信モードフィー
ルド291をチェックする。
ブジェクト宛のメッセージであるため、通信モードフィ
ールド291=『PM内通信』となって、図31のステ
ップ565に進み、受信オブジェクトのメッセージキュ
ーにローカルメッセージバッファアドレス(LBA)5
91を登録する。次に、ステップ566で、受信オブジ
ェクトのOCB210のSTATUSフィールド(図1
5の214)が『送信側実行待ち』となっているか否か
をテストする。このケースでは、図20のステップS1
81で、STATUSフィールド214を『送信側実行
待ち』と設定しているため、ステップ566は『ye
s』となる。これは、受信オブジェクトが送信側からメ
ッセージを受け取る準備をして休止状態にあることを表
わしているので、ステップ567で、受信オブジェクト
のOCB210のSTATUSフィールド214を『同
期完了』と設定して、送信要求と受信要求の両方が揃っ
たことを表示する。次に、ステップ568で受信オブジ
ェクトのOCB210をレディキューに登録して、受信
オブジェクトが再起動されるようにする。
2の受信PM18−3のカーネルは、レディキューの中
から次に実行すべきオブジェクトとして受信オブジェク
トを選択し、図20のタイミングt200で受信オブジ
ェクトID(RID)を受信PM18−3内のカレント
ケーパビリティレジスタ(CCR)51−3に設定す
る。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは、図26の受信処理プログ
ラムを起動する。図26のステップ390では、受信オ
ブジェクトのOCB210のSTATUSフィールド
(図15の214)が『受信側実行待ち』または『同期
完了』となっているか否かをテストする。このケースで
は、図20のステップS190で、STATUSフィー
ルド214を『同期完了』と設定しているため、ステッ
プ390は『yes』となる。これは、メッセージが送
信側から既に届いているので、直ちにメッセージを読み
出してもよいことを示している。そこで、ステップ39
1では、OCB210のメッセージキューにつながって
いるメッセージを参照して、キューから外し、そのMB
アドレスつまりローカルメッセージバッファアドレス
(LBA)591を取り出す。次に、ステップ392
で、このLBA591に対応するMCR53−3に受信
オブジェクトID(RID)を設定する。このタイミン
グは、図20のタイミングt201で示されている。こ
れにより、CCR51−3とMCR53−3の両方に受
信オブジェクトID(RID)が設定されたので、これ
以降はローカルメッセージバッファが受信オブジェクト
以外のAPLオブジェクトからアクセスできないように
プロテクトされた。
ローカルメッセージバッファから図20のタイミングt
202でメッセージを読み出し、対応する処理を行う。
ここで、受信オブジェクトは、受信側分散共有メモリ2
1−3上のローカルメッセージバッファから読み出して
いる。
は、カーネルにローカルメッセージバッファ解放を依頼
する。カーネルは、図24のMB解放処理プログラムを
起動して、図24のステップ360でローカルメッセー
ジバッファに対応するMCR53−3を図20のタイミ
ングt202でクリアする。次に、図24のステップ3
61で、ローカルメッセージバッファに対応するMB管
理マップエントリを『空き』という値に書き替える。こ
のタイミングは、図20のタイミングt203に示され
ている。このMB管理マップエントリが『空き』に書き
替えられた時点以降は、ネットワークアダプタ24−3
は、このローカルメッセージバッファを再利用すること
ができる。
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ(CCR)51−3の値を図20のタイミン
グt204でクリアする。以上のように、システム間P
M無中継通信の場合にも、システム内PM間通信と大差
ないソフトウェアのオーバヘッドでメッセージ通信を高
速に、効率よく実現することができる。
ッサモジュール(PM)18−1内の送信オブジェクト
が作成したメッセージを、宛先システムへの通信リンク
を持つ送信マルチプロセッサシステム内の送信中継PM
18−2に引き継ぎ、送信中継PM18−2がネットワ
ークを介して他の受信マルチプロセッサシステム17−
2にメッセージを転送し、受信マルチプロセッサシステ
ム17−2の受信中継PM18−3がメッセージを受信
した後、受信オブジェクトの存在する受信PM18−2
にメッセージを引き継ぐ場合を仮定して、送信オブジェ
クトの実行終了前に、受信オブジェクトが実行開始する
ものとする。送信システム17−1の送信PM18−1
が使用するMBは図5のX12−2、そのMB管理マッ
プエントリはXM12−2、メッセージ制御情報は送信
ディスクリプタリングXD12−S、送信処理要求は宛
先PM18−2用送信処理FIFO(XF2−S)に、
それぞれ登録されるものとする。一方、受信システム1
7−2の受信中継PM18−3が使用するMBを、図5
〜図7のZ32−1、そのMB管理マップエントリはZ
M32−1、メッセージ制御は受信ディスクリプタリン
グZD32−R、受信処理要求は宛先PM18−1情報
用受信処理FIFO(ZF2−R)に、それぞれ登録さ
れるものとする。処理の流れを図21の各ステップに沿
って説明する。図21において、ステップS210はA
PLオブジェクト起動、ステップ211はMB捕捉、S
212はメッセージ書込み、S213は送信処理、S2
20はINC送信、S230はINC受信、S240は
APLオブジェクト起動、S241は受信処理、S24
2はAPLオブジェクト終了、S250はIOC配信、
S260はAPLオブジェクト起動、S261は受信処
理、S262はメッセージ読出し、S263はMB解
放、S264はAPLオブジェクト終了である。
8−1の処理 「ステップS210」送信マルチプロセッサシステム1
7−1の送信PM18−1のカーネルは、図21のステ
ップS210のAPLオブジェクト起動プログラムを実
行し、送信オブジェクトのID(SID)をタイミング
S210でPM18−1のCCR51−1に設定し、送
信オブジェクトの実行を開始する。
MBの捕捉をカーネルに要求すると、カーネルは図23
のMB捕捉処理プログラムを実行する。このケースで
は、送信システム内送信PM18−1から送信システム
内中継PM18−2への通信であるため、図23のステ
ップ350で検索して取り出されるシステム通信モード
フィールド(図16の251)の値は『システム間通
信』271となる。従って、図23のステップ351で
は、『システム間通信』側が選択され、ステップ355
で対応するエントリの通信リンクID(図17の27
2)と送信中継PM ID273の値が取り出される。
このケースでは、送信中継PM ID273=『PM1
8−2』であるため、ステップ355,356では、
『PM18−2』の値をキーとしてPMルーチングテー
ブル289の検索が行われる。その結果、PM IDフ
ィールド290=『PM18−2』となっているエント
リが一致し、このエントリに対応するMB管理マップア
ドレス=『PM18−1/PM18−2間通信MB(X
12)管理マップベースアドレス312』が、PMルー
チングテーブル289から取り出される。
12)のうちの空きMB(X12−2)が選択され、そ
のMB管理マップエントリXM12−2を『使用中』に
書き替える。その書き替えは、図21のタイミングt2
11で、送信側分散共有メモリ21−1上のMB管理マ
ップエントリ(XM12−2)およびそれと同一アドレ
スを持つ、送信中継側分散共有メモリ21−2のMB管
理マップエントリ(YM12−2)の両方に対して行わ
れる。その具体的方法は、図19のステップS121で
説明したので、ここでは省略する。次に、図23のステ
ップ354で、MB(X12−2)に対応するメモリケ
ーパビリティレジスタ(MCR)53−1に、このMB
へのアクセス権を獲得した送信オブジェクトのID(S
ID)を図21のタイミングt212で登録する。
は、作成したメッセージを送信側分散共有メモリのMB
(X12−2)にタイミングt213で書き込むと、こ
の書き込みデータが分散メモリカップラ22−1により
送信中継側分散共有メモリ21−2の同一アドレスのM
B(Y12−2)にも伝搬して書き込まれる。その操作
は、図19のt121で説明したので、省略する。な
お、このメッセージ書き込みステップでは、CCR51
−1とMCR53−1の両方の値が設定されている期間
中、MCRとCCRが指定している送信オブジェクトは
MB(X12−2)にアクセスすることができるが、他
のAPLオブジェクトはアクセスすることができない。
また、送信中継PM18−2にも、各MBに対してMC
R53−2が用意されているが、MCR53−2には値
が設定されていないため、もし、送信中継PM18−2
内のアプリケーションオブジェクトからMB(Y12−
2)へのアクセスがあった場合にも、MCR53−2と
CCR51−2の不一致が生じて送信中継PM18−2
内での不正アクセスを検出することができる。
は、カーネルに送信処理を依頼する。送信処理プログラ
ムは、図25に示すように、先ずステップ380でMB
(X12−2)に対応するMCR53−1を図21のタ
イミングt214でクリアする。これにより、プロテク
ションウィンドウ開放期間が終了するので、以降はカー
ネル以外は、MB(X12−2)にアクセスできなくな
る。次に、図25のステップ381で、通信モードが
『システム間PM中継送信』であることを判定し、ステ
ップ387では、図21のステップS211で検索が一
致したPM ID(図17の290)、つまりPM18
−2宛の送信ディスクリプタリングXD12−Sに、送
信制御情報を登録(エンキュー)し、図14のフォーマ
ットの処理要求をPM18−2宛の送信処理FIFO
(XF2−S)(図7参照)に書き込む。この書き込み
動作は、図21のタイミングt215で示されている。
その結果、分散メモリカップラ22−1により送信ディ
スクリプタリング(XD12−S)への書き込みデータ
が送信中継側の分散共有メモリ21−1上の同一アドレ
スロケーションYD−Sにコピーされる。同じく、送信
処理FIFO(XF2−S)の書き込みデータが、送信
中継PM宛送信FIFOにもコピーされる。これによ
り、メッセージ送信に必要な全ての情報が受信中継PM
18−2に伝達される。
ブジェクト終了処理を起動し、カレントケーパビリティ
レジスタ(CCR)51−1の値を図21のタイミング
t216でクリアする。
M18−2側の処理 「ステップS220」送信中継PM18−2のINC送
信処理プログラムは、図30に示すように、定期的に自
PM宛の送信処理FIFO(YF2−S)を読み出すこ
とにより要求の有無をチェックしている。具体的には、
図30のステップ520で、送信処理FIFO(YF2
−S)から要求を図21のタイミングt220で読み出
し、ステップ521で要求の有無をチェックする。も
し、要求があれば、ステップ522で読み出した要求が
指定している送信ディスクリプタリングに対して図28
の『デキュー処理』を実行する。本実施例では、ステッ
プS213で既に送信処理FIFO(XF2−S)に要
求が登録されているので、ステップ523で、図15
(c)に示す構造の送信ディスクリプタエントリを図2
1のタイミングt220で取り出し、この情報をもとに
ネットワークを介して通信に必要な各種のプロトコル処
理(例えば、ネットワークパケットのヘッダの作成、再
送制御情報の作成、チェックサムの計算等)を行う。次
に、ステップ524では、ネットワークアダプタの起動
に必要なアダプタ用送信ディスクリプタを作成する。ス
テップ525では、このアダプタ送信ディスクリプタを
アダプタ送信ディスクリプタリングに図20のタイミン
グt221で登録する。
アダプタ用送信ディスクリプタリングを監視しており、
ディスクリプタの登録があると、この情報をもとにして
ネットワークが要求するサイズにメッセージを分割し、
ヘッダや誤り制御情報を付加してネットワークパケット
としてネットワークに送出する。このタイミングは、図
21のタイミングt222で示されている。ネットワー
クアダプタ24−2はメッージの転送を完了するか、ま
たは通信相手のシステムからメッセージ到着確認の連絡
を受けると、送信側でメッセージバッファを保持してお
く必要がなくなったので、図21のタイミングt223
でMB管理マップエントリYM12−2を『空き』に書
き替えると、送信側分散共有メモリにも伝搬してMB管
理マップエントリYM12−2がタイミングt224で
書き替えられる。その結果、これ以降は、送信PM18
−1は、対応するMB(X12−2)を再利用すること
ができる。なお、送信中継PM18−2では、送信PM
18−1のように、MCR53、CCR51にケーパビ
リティを設定していないが、もし送信中継PM18−2
内のAPLオブジェクトからMB(Y12−2)に不正
アクセスが行われた場合、MB(Y12−2)対応のM
CR53−2に値が未設定であることにより、不正アク
セスが検出できる。
M18−3側の処理 「ステップS230」送信システム17−1からネット
ワークパケットが届くと、受信システム17−2の受信
中継PM18−3のネットワークアダプタ24−3は、
予め自分が管理している、分散共有メモリ21−3上の
PM#3内通信領域内の空きのローカルメッセージバッ
ファの1つに、ネットワークパケットを記憶する。メッ
セージが複数のネットワークパケットで分割されて送ら
れて来る場合には、ネットワークアダプタ24−3は、
受信したパケットをパケットヘッダを見ながらローカル
メッセージバッファ内の指定された位置に入れることに
よりメッセージの組み立て処理を行って、最終的に1つ
のメッセージに組み立てる。そして、完成したメッセー
ジに関する制御情報をアダプタ受信ディスクリプタリン
グに登録する。受信中継PM18−3のINC受信処理
プログラムは、図31,図32に示すように、定期的に
アダプタ受信ディスクリプタリングを読み出すことによ
り要求の有無をチェックする。
処理プログラムのステップ560で、アダプタ受信ディ
スクリプタリングに対して図28の『デキュー処理』を
実行し、ステップ561でアダプタ受信ディスクリプタ
リングにエントリが登録されていたか否かをチェックす
る。図21のステップ230の時点においては、到着し
たメッセージをアダプタ受信ディスクリプタに登録済み
であるため、ステップ562では、アダプタ受信ディス
クリプタエントリ(図33の590)を図21のタイミ
ングt230で取り出し、この情報をもとにプロトコル
受信処理(例えば、ネットワークパケットのヘッダのチ
ェック、再送制御情報の作成等)を行う。次に、ステッ
プ563では、アダプタ受信ディスクリプタ中のローカ
ルメッセージバッファアドレスLBA591を参照する
ことによりローカルメッセージバッファをアクセスし、
受信オブジェクトID(RID)を取り出す。ステップ
564では、RIDのPM IDフィールド(図12の
172)をキーとして、PMルーチングテーブル289
のPM IDフィールド=『受信システム17−2の受
信PM18−2』となっているエントリと一致するの
で、通信モードフィールド291=『PM間通信』とな
り、ステップ570に進む。
トリに対応するMB管理マップアドレス=『PM18−
3/PM18−2間通信MB(X32)管理マップZM
32のベースアドレス』をPMルーチングテーブル28
9から取り出す。ステップ571では、MB管理マップ
ZM32を参照して空きMB(Z32−1)を選択し、
そのMB管理マップエントリZM32−1を図21のタ
イミングt231で『使用中』に書き替える。ZM32
−1を書き替えると、受信システムの分散メモリカップ
ラ22−3、22−2経由で、ZM32−1と同一アド
レスを持つ受信側分共有メモリ21−2のMB管理マッ
プエントリYM32−1も『使用中』に書き替えられ
る。次に、ステップ572で、ローカルメッセージバッ
ファにあるメッセージをMB(Z32−1)に図21の
タイミングt232でコピーする。このコピー操作を実
行すると、分散メモリカップラ22−3,22−2経由
でメッセージが受信PMの分散共有メモリ21−2のM
B(Y32−1)にも書き込まれる。つまり、このコピ
ー操作は、受信側分散共有メモリ21−2に書き込みデ
ータを送るために行ったものである。
では、送信中継PM18−3から受信専18−2宛の受
信ディスクリプタリングZD32−Rにメッセージ制御
情報を図21のタイミングt233で書き込むととも
に、受信処理要求を受信PM18−2宛の受信処理FI
FO(ZF2−R)に書き込む。その結果、分散メモリ
カップラ22−3,22−1により転送されるので、受
信ディスクリプタリングZD32−Rの内容が受信PM
18−2の分散共有メモリ21−2の同一アドレスロケ
ーションであるYD32−Rに、また受信処理FIFO
(ZF2−R)の内容が受信PM18−2の分散共有メ
モリ21−2の同一アドレスロケーションであるYF2
−Rに、それぞれコピーされる。これにより、メッセー
ジ送信に必要な情報が受信PM18−3に伝達された。
なお、受信中継PM18−3においては、MCR53、
CCR51にケーパビリティを設定していないが、もし
受信中継PM18−3内のAPLオブジェクトからMB
(Z23−1)に不正アクセスが行われた場合には、M
B(Z32−1)対応するMCR53−3に値が未設定
であることにより、不正アクセスは検出できる。
8−2側の処理 「ステップS240」図21のステップS240で、カ
ーネルは次に実行すべきオブジェクトとして受信オブジ
ェクトを選択し、図21のタイミングt240で受信オ
ブジェクトID(RID)を受信PM18−2内のカレ
ントケーパビリティレジスタCCR51−2に設定す
る。
カーネルに受信処理を要求すると、カーネルは図26の
受信処理プログラムを起動する。図26のステップ39
0では、受信オブジェクトのOCB(図15(d)の2
14)が『受信側実行待ち』または『同期完了』になっ
ているか否かをテストする。このケースでは、この時点
で送信オブジェクトからのメッセージが到着していない
ので、『受信側実行待ち』あるいは『同期完了』の状態
になく、『no』となる。そこで、ステップ393で、
先に受信オブジェクトの要求が到着したことを示すため
に、STATUSフィールド214を『送信側実行待
ち』に設定し、カーネルにリターンする。
ブジェクトが『送信側実行待ち』になったことを知り、
送信オブジェクトからメッセージが届くまで受信オブジ
ェクトを休止させるため、カーネルが図22のAPLオ
ブジェクト終了処理を起動し、ステップ340でカレン
トケーパビリティレジスタ(CCR)51−2の値を図
21のタイミングt241でクリアし、ステップ341
で受信オブジェクト再開に必要な情報をOCB210に
退避する。
IOC配信プログラムは、図29に示すように、定期的
にPM#2宛の受信処理FIFO(YF2−R)を読み
出すことにより受信処理要求の有無をチェックする。具
体的には、図29のステップ500で、FIFOから要
求を図21のタイミングt250で読み出し、ステップ
501で要求の有無をチェックする。もし、要求があれ
ば、ステップ502で、読み出した要求が指定している
受信ディスクリプタリング(YD12−R)に対して図
28の『デキュー処理』を実行する。ステップ503で
は、図15(c)の受信ディスクリプタエントリを同じ
タイミングt250で取り出し、そのエントリのMBA
(図15(c)の202)を参照して、図15(a)で
示される構造のMB(Y32−1)をアクセスする。そ
して、MB(Y32−1)内の受信オブジェクトID
(RID)(図15(a)の183)を取り出す。ステ
ップ504では、RID183に対応するOCB(図1
5の210)のメッセージキューにMB(Y32−1)
のアドレスMBA202を登録する。
ブジェクトのOCB210のSTATUSフィールド2
14が『送信側実行待ち』となっているか否かをテスト
する。このケースでは、図21のステップS241で、
STATUSフィールド214を『送信側実行待ち』と
設定しているので、ステップ505は『yes』とな
る。これは、受信オブジェクトが送信側からメッセージ
を受け取る準備をして休止状態にいることを表わしてい
る。従って、ステップ506では、受信オブジェクトの
OCB210のSTATUSフィールド214を『同期
完了』と設定して、送信要求と受信要求の両方が揃った
ことを表示する。次に、ステップ507では、受信オブ
ジェクトのOCB210をレディキューに登録して、受
信オブジェクトが再起動されるようにする。
キューの中から次に実行すべきオブジェクトとして受信
オブジェクトを選択し、図21のタイミングt260
で、受信オブジェクトID(RID)を受信PM18−
2内のカレントケーパビリティレジスタ(CCR)51
−2に設定する。
実行が開始され、受信オブジェクトがカーネルに受信処
理を要求すると、カーネルは図26の受信処理プログラ
ムを起動する。図26のステップ390では、受信オブ
ジェクトのOCB210のSTATUSフィールド21
4が『受信側実行待ち』または『同期完了』となってい
るか否かをテストする。このケースでは、図21のステ
ップS250でSTATUSフィールド214を『同期
完了』と設定しているので、ステップ390は『ye
s』となる。これは、メッセージが送信側から既に届い
ているので、直ちにメッセージを読み出してもよいこと
を示している。そこで、ステップ391で、OCB21
0のメッセージキューにつながっているメッセージを参
照して、キューから外し、そのMB(Y32−1)のア
ドレスを取り出す。次に、ステップ392では、このM
Bアドレスに対応するMCR53−2に受信オブジェク
トID(RID)を設定する。このタイミングは、図2
1のタイミングt261で示されている。これにより、
CCR51−2とMCR53−2の両方に受信オブジェ
クトID(RID)が設定されたので、それ以降は、M
B(Y32−1)が受信オブジェクト以外のAPLオブ
ジェクトからアクセスできないようにプロテクトされ
た。
MB(Y32−1)から、図21のタイミングt262
で受信側分散共有メモリ21−2のMB(Y32−1)
からメッセージを読み出し、対応する処理を行う。MB
(Y32−1)からの読み出しは、自プロセッサモジュ
ール内に閉じたローカルなメモリアクセスであるため、
リモートメモリアクセスを行う場合に比較して極めて高
速である。
は、カーネルにMB解放を依頼する。カーネルは、図2
4のMB解放処理プログラムを起動し、図24のステッ
プ360で、MB(Y32−1)に対応するMCR53
−2をクリアする。このタイミングは、図21のタイミ
ングt263に示されている。次に、図24のステップ
361では、MB(32−1)に対応するMB管理マッ
プエントリYM32−1を『空き』という値に書き替え
る。このタイミングは、図21のタイミングt264に
示されている。この値の書き替えは、受信側の分散共有
メモリ21−2のみならず、同時に分散メモリカップラ
22−2,22−1経由で、受信中継側分散共有メモリ
21−3の同一番地ZM32−1に対しても行われる。
図21のタイミングt265で、受信中継PM18−3
のMB管理マップエントリZM32−1が『空き』に書
き替えられた時点以降は、受信中継PM18−3のMB
(Z32−1)をいつでも再利用することができる。
ブジェクト終了処理を実行して、カレントケーパビリテ
ィレジスタ(CCR)51−2の値を図21のタイミン
グt266でクリアする。以上のように、システム間P
M中継通信においても、分散メモリカップラ22の働き
により、送受信中継PMを介してもメッセージおよびそ
の制御情報を送信PMと受信PM間で極めて簡単、かつ
高速に転送することができるので、効率的なメッセージ
通信が実現される。本実施例においては、図29のIO
C配信処理、図30のINC送信処理、図31,図32
のINC受信処理は、分散共有メモリの特定番地を読み
出すことにより要求を検出する、いわゆるポーリング型
の処理方式で説明したが、これらを図8に示す割り込み
データタイプのパケットと図1の割り込み制御部42の
機能を用いて割り込み型の処理方式で実現することも可
能である。
おいては、各プロセッサモジュールが分散共有メモリと
分散メモリカップラとを持ち、分散メモリカップラは、
その分散共有メモリのアドレスを共有しているプロセッ
サモジュール情報を記憶する。そして、送信側のプロセ
ッサモジュールの分散共有メモリの共有アドレスロケー
ションへの書き込みが発生した時点で、分散メモリカッ
プラが、アドレスを共有する他のプロセッサモジュール
に書き込み情報を転送し、書き込み情報を受けた受信側
の分散メモリカップラが受信側の分散共有メモリへコピ
ーを行う。この転送動作は、ソフトウェアの介在なしで
実行されるので、従来では、分散共有メモリ間転送用と
してわざわざ必要であったDMA機構制御用プログラム
の実行は不要となり、ソフトウェアオーバヘッドを大幅
に削減することができる。また、DMA機構を使用する
従来の方式では、転送データが全部揃ってから転送を開
始するのに対して、本発明では、送信元の分散共有メモ
リへの書き込みが発生した時点で、相手側の分散共有メ
モリへの転送が開始されるので、メッセージが送信側か
ら受信側に伝達されるまでの遅延時間(レイテンシー)
も大幅に削減される。さらに、分散メモリカップラに登
録するプロセッサモジュール情報に応じて、一方向性通
信、両方向通信、放送型通信等の各種の通信パターンを
自由に実現することができるので、柔軟性が高い。
ュールと受信プロセッサモジュール間のメッセージ通信
では、送信プロセッサモジュールでメッセージバッフ
ァ、メッセージの制御情報であるMBディスクリプタ、
メッセージバッファ使用状態を示すMB管理マップを分
散共有メモリに配置している。送信プロセッサモジュー
ルが、これらの情報を送信側分散共有メモリに書き込
み、受信側プロセッサモジュールが分散共有メモリの同
じアドレスロケーションから読み出すだけでよいので、
プロセッサモジュール間の通信の同期を簡単かつ容易に
行うことができる。また、受信側プロセッサモジュール
が受信側分散共有メモリのMBディスクリプタとMB管
理マップに返事を書き込み、送信側プロセッサモジュー
ルが受信側分散共有メモリの同じアドレス位置のMBデ
ィスクリプタとMB管理マップから読み出すことによ
り、MBディスクリプタやMBに関する状態を簡単に送
信側に伝達することができ、MBディスクリプタやMB
再使用すればよいか等を簡単に知ることができる。
ジュールの分散共有メモリの、あるアドレスロケーショ
ンをFIFO構造にしておくことにより、送信側プロセ
ッサモジュールが自分の分散共有メモリに書き込んだ情
報が、受信側分散共有メモリのFIFOに順次書き込ま
れる。その結果、複数の送信側プロセッサモジュールが
同時に、それぞれの分散共有メモリの同一番地に書き込
みを行った場合にも、受信側の分散共有メモリのFIF
Oで競合整理が行われてFIFOに順次書き込まれ、ソ
フトウェアによる競合処理を全く必要としない。受信側
は、分散共有メモリ内の要求登録FIFOを順次読み出
すのみで、実際に発生した要求のみを効率よく取り出す
ことができ、従来のような多数の監視点を順次サーチし
ていくための処理オーバヘッドを大幅に削減することが
できる。このように、例えば同一メモリエリアへの同時
アクセス等、従来、マルチプロセッサシステムで大きな
問題となっていたプロセッサ間のリソース競合を回避す
ることができるので、多数のプロセッサを組み合わせた
超並列コンピュータシステムを構築した場合でも、プロ
セッサの台数に応じた大きな処理能力を持たせることが
可能である。
カーネル等のシステムソフトウェアのオーバヘッドを削
減することができるとともに、転送遅延時間が短く、処
理効率の高いメッセージ転送を実現することが可能であ
る。
の内部構成図である。
る。
シーケンスチャートである。
テムの構成図である。
示す図である。
示す図である。
示す図である。
である。
ット受信レジスタのデータフォーマット図である。
概要を示す図である。
概要を示す図である。
ット図である。
理要求のメモリ配置図である。
図である。
図である。
である。
とPMルーチングテーブルの構造図である。
ムチャートである。
ムチャートである。
タイムチャートである。
イムチャートである。
トの起動、終了処理のフローチャートである。
トである。
トである。
ある。
ある。
ートである。
トである。
ートである。
ートおよびアダプタ送信ディスクリプタの構造図であ
る。
ートである。
ートである。
の構造図である。
ル、 19−1,19−2,19−3・・プロセッサ、 20−1,20−2,20−3・・ローカルメモリ、 21−1,21−2,21−3・・分散共有メモリ、 22−1,22−2,22−3・・分散メモリカップ
ラ、 23−1,23−2,23−3・・分散メモリプロテク
タ、 24−1,24−2,24−3・・ネットワークアダプ
タ、 25・・プロセッサモジュール間通信路、 26・・通信ネットワーク、34・・モジュールID管
理部、 35・・パケット送信レジスタ、36・・パケット送信
バッファ、 37・・パケット受信バッファ、38・・パケット受信
レジスタ、 50・・MCRメモリ(メモリケーパビリティレジスタ
メモリ)、 51・・CCR(カレントケーパビリティレジスタ)、 53・・MCR、60・・モジュールIDディレクト
リ、 61・・CAM(Content Addressable Memory)、 62・・データメモリ部、
に、分散共有メモリ21上の各エリアを識別するため
に、Mij−kのような識別名を用いている。ここで、
Mはプロセッサモジュール対応のMB/MB管理マップ
/MBディスクリプタリング/FIFO通信エリアの識
別記号であり、PM(18−1)に対応するMBはX、
そのMB管理マップはXM、MBディスクリプタリング
はXD、FIFO通信エリアはXFと表現される。同じ
ように、PM(18−2)に対応するMBはY、そのM
B管理マップはYM、MBディスクリプタリングはY
D、FIFO通信エリアはYF、PM(18−3)に対
応するMBはZ、そのMB管理マップはZM、MBディ
スクリプタリングはZD、FIFO通信エリアはZFの
ように名称が付けられている。また、i,jは、それぞ
れ送信PMの識別番号(PM ID)と受信PMの識別
番号(PM ID)を表わしており、PM#1(18−
1)、PM#2(18−2)、PM#3(18−3)に
対応してそれぞれ1,2,3の番号が付与されている。
ただし、例外として、FIFO通信エリアXF,YF,
ZFは値jのみを有し、値iを持っていない。その理由
としては、FIFO通信エリアが値jで表わされる受信
側プロセッサモジュール対応に分割されており、値iで
表わされる各送信プロセッサモジュール対応に分割され
ており、値iで表わされる各送信プロセッサモジュール
間で共通に使用するため、エリアの指定情報として値i
を必要としないためである。
じように、宛先PM−IDが同一の複数のMBディスク
リプタを分散共有メモリの連続するアドレスロケーショ
ンに割り付けており、割り付けた全体をディスクリプタ
リングと呼ぶ。『リング』と呼ばれている理由は、ディ
スクリプタリングに含まれる複数のディスクリプタを若
いアドレス順にサイクリックに使用していくからであ
る。送信側の各ディスクリプタリングと同一アドレスの
エリアが、受信プロセッサモジュールの分散共有メモリ
にも配置される。ディスクリプタリングは、送信オブジ
ェクトからのメッセージ制御情報を他のPMあるいは他
のシステムに引き継ぐための『送信ディスクリプタリン
グ』と、他のPMあるいは他のシストムから受信したメ
ッセージ制御情報を受信オブジェクトに引き継ぐための
『受信ディスクリプタリング』に分けられる。ディスク
リプタリングもMBやMB管理マップの場合と同じよう
に、送信側と受信側の同一アドレス間でペアを構成す
る。ディスクリプタリング内のディスクリプタとMBと
の対応は、実行時にカーネルにより動的に決定される。
具体的には、例えばPM#1(18−1)からPM#2
(18−2)にメッセージを送信する場合に、PM(1
8−1)のカーネルが空きのMBプールの中から適当な
MB(例えばX12−2)を捕捉し、次に対応する送信
ディスクリプタリング(例えばX12−S)を選択し、
その中の『未使用』の最若アドレスのディスクリプタに
MBアドレスを登録する。このような方法でディスクリ
プタとMBとの対応が動的に決定される。なお、送信デ
ィスクリプタリングXD12−Sとペアを組む送信ディ
スクリプタリングはYD12−Sである。
オブジェクトからのメッセージ受信処理要求を他のPM
または他のシステムに通知するための『送信処理FIF
Oエリア』と、他のPMまたは他のシステムから受信し
たメッセージ受信処理要求を受信オブジェクトに通知す
るための『受信処理FIFOエリア』に分けられる。こ
のうち、メッセージ処理要求送信側の分散共有メモリ
は、通常のRAM(ランダムアクセスメモリ)で構成さ
れるが、メッセージ処理要求受信側の分散共有メモリ
は、FIFOで構成されている。例えば、PM#1(1
8−1)上のPM#1(18−1)宛受信処理FIFO
エリアXF1−Rは、他のPMからのメッセージ受信処
理要求を記憶するためにFIFOメモリで構成されてい
るが、PM#2上のPM#1(18−1)宛受信処理F
IFOエリアYF1−Rおよび、PM#3上のPM#1
(18−1)宛受信処理FIFOエリアZF1−Rは、
いずれもRAMで構成されている。この理由としては、
受信処理要求を書き込む側のPM(PM#2とPM#
3)が受信処理要求をそれぞれ受信処理FIFOエリア
YF1−RとZF1−Rに同時に書き込んだ場合、それ
らが同時に受信処理要求を読み出す側のPM(PM#
1)の受信処理FIFOエリアXF1−Rに到着するの
で、これらの受信処理要求を全て蓄積するためにFIF
Oメモリを使用するからである。
Claims (4)
- 【請求項1】複数のプロセッサモジュールから構成され
たマルチプロセッサシステムにおいて、 上記プロセッサモジュールには、 各プロセッサモジュール間で共通のアドレスを有し、送
信プロセッサモジュールと受信プロセッサモジュールの
組み合わせで指定される管理単位毎に分割された分散共
有メモリと、 上記送信プロセッサモジュールの分散共有メモリ(以
下、送信側分散共有メモリ)とアドレスを共有する受信
プロセッサモジュールの識別情報を記憶し、該送信側分
散共有メモリへの書き込みが発生すると、上記受信プロ
セッサモジュールの識別情報で指定された受信プロセッ
サモジュールに、書き込みアドレスと書き込みデータを
送信するとともに、受信した書き込みアドレスと書き込
みデータをもとに受信プロセッサモジュールの分散共有
メモリ(以下、受信側分散共有メモリ)の、送信側と同
一のアドレスロケーションにコピーを行う分散共有メモ
リ制御手段と、 送信するメッセージの宛先情報をもとに受信プロセッサ
モジュールを特定し、上記分散共有メモリ上の送信プロ
セッサモジュールと受信プロセッサモジュールの組み合
わせで指定されるメッセージバッファを捕捉するメッセ
ージバッファ管理手段とを有し、 送信プロセッサモジュールから受信プロセッサモジュー
ルにメッセージを送信する場合に、送信プロセッサモジ
ュールは、上記メッセージバッファ管理手段により上記
受信プロセッサモジュール対応の送信メッセージバッフ
ァを捕捉し、該送信メッセージバッファに上記メッセー
ジを書き込み、 該送信プロセッサモジュールと受信プロセッサモジュー
ルとが同一モジュールである場合には、上記受信プロセ
ッサモジュールは、上記送信メッセージバッファから、
直接、メッセージを読み出すことにより、同一プロセッ
サ内メッセージ通信を行い、 送信プロセッサモジュールと受信プロセッサモジュール
が異なるモジュールである場合には、送信側の分散共有
メモリ制御手段が、上記送信メッセージバッファのアド
レスをもとに受信プロセッサモジュール識別情報を取り
出し、該識別情報の受信プロセッサモジュールに送信メ
ッセージバッファアドレスと書き込みデータを転送し、 受信側の分散共有メモリ制御手段は、受信した上記送信
メッセージバッファのアドレスと上記書き込みデータを
もとに受信側の分散共有メモリの、送信側と同一アドレ
スの受信メッセージバッファにコピーを行い、 上記受信プロセッサモジュールでは、上記受信メッセー
ジバッファからメッセージを読み出すことにより、異な
るプロセッサ間のメッセージ通信を行うことを特徴とす
るマルチプロセッサシステム。 - 【請求項2】請求項1に記載のマルチプロセッサシステ
ムにおいて、上記受信側の分散共有メモリ制御手段は、
さらにアドレスを共有する送信プロセッサモジュールの
識別情報を記憶し、 上記送信プロセッサモジュールでは、該送信プロセッサ
モジュールと受信プロセッサモジュールの組み合わせで
指定される分散共有メモリ上の送信制御エリアに、メッ
セージ制御情報あるいはメッセージバッファ管理情報を
含む制御データを書き込み、 送信プロセッサモジュールと受信プロセッサモジュール
とが同一モジュールである場合には、該受信プロセッサ
モジュールは、上記送信制御エリアから、直接、制御デ
ータを読み出してメッセージあるいはメッセージバッフ
ァに関する制御内容を認識し、対応する処理を実行した
後、上記送信制御エリアに返答制御データを書き込み、 上記送信プロセッサモジュールは、上記送信制御エリア
から上記返答制御データを読み出して受信側での処理結
果を認識することにより、同一プロセッサモジュール内
双方向通信を行い、 送信プロセッサモジュールと受信プロセッサモジュール
が異なるモジュールである場合には、上記送信側の分散
共有メモリ制御手段は、上記送信制御エリアのアドレス
をもとに受信プロセッサモジュール識別情報を取り出
し、該送信制御エリアアドレスと書き込みデータを上記
受信プロセッサモジュールに転送し、 上記受信側の分散共有メモリ制御手段は、受信した上記
送信制御エリアアドレスと上記書き込みデータをもとに
受信側分散共有メモリの、送信側と同一アドレスの受信
制御エリアにコピーを行い、 上記受信プロセッサモジュールは、上記受信制御エリア
から制御データを読み出して、メッセージあるいはメッ
セージバッファに関する制御内容を認識し、対応する処
理を実行した後、上記受信制御エリアに返答制御データ
を書き込むと、 受信側の分散共有メモリ制御手段は、上記受信制御エリ
アアドレスをもとに、上記送信プロセッサモジュール識
別情報を取り出し、該識別情報をもとに上記受信制御エ
リアアドレスと上記返答制御データを上記送信プロセッ
サモジュールに転送し、 上記送信側の分散共有メモリ制御手段は、受信した上記
受信制御エリアアドレスと上記返答制御データをもとに
送信側分散共有メモリの、受信側と同一アドレスの送信
制御エリアにコピーを行い、 上記送信プロセッサモジュールでは、上記送信制御エリ
アから上記返答制御データを読み出して、受信側での処
理結果を認識することにより、プロセッサモジュール間
双方向通信を行うことを特徴とするマルチプロセッサシ
ステム。 - 【請求項3】複数のプロセッサモジュールから構成され
たマルチプロセッサシステムにおいて、 上記プロセッサモジュールには、 各プロセッサモジュール間で共通の同一アドレスを有
し、受信プロセッサモジュール対応の管理単位毎に分割
された分散共有メモリと、 送信側分散共有メモリとアドレスを共有する受信プロセ
ッサモジュールの識別情報を記憶し、送信側分散共有メ
モリへの書き込みが発生すると、上記受信プロセッサモ
ジュール識別情報で指定された受信プロセッサモジュー
ルに書き込みアドレスと書き込みデータを送信するとと
もに、受信した書き込みアドレスと書き込みデータをも
とに受信側分散共有メモリの、送信側と同一のアドレス
ロケーションに書き込みを行う分散共有メモリ制御手段
とを有し、 上記受信側の分散共有メモリのエリアはFIFOメモリ
で構成され、 複数の送信プロセッサモジュールから1つの受信プロセ
ッサモジュールに処理要求を通知する際に、上記送信プ
ロセッサモジュールと受信プロセッサモジュールが同一
のモジュールである場合には、上記送信プロセッサモジ
ュールでは、送信側分散共有メモリ上の自プロセッサモ
ジュール宛処理要求FIFOエリアに、処理要求データ
を書き込み、 上記送信プロセッサモジュールと受信プロセッサモジュ
ールが異なるモジュールである場合には、上記送信プロ
セッサモジュールでは、上記送信側分散共有メモリ上の
受信プロセッサモジュール宛処理要求FIFOエリア
に、処理要求データを書き込み、 送信側分散共有メモリ制御手段は、上記処理要求エリア
のアドレスをもとに受信プロセッサモジュール識別情報
を取り出し、上記処理要求エリアアドレスと書き込みデ
ータを受信プロセッサモジュールに転送し、 受信側分散共有メモリ制御手段は、受信した上記処理要
求FIFOエリアアドレスと上記書き込みデータをもと
に受信側分散共有メモリの、送信側と同一アドレスの上
記処理要求FIFOエリアに書き込むことにより、上記
処理要求FIFOエリアに複数の処理要求データを到着
順に蓄積し、 上記受信側プロセッサモジュールでは、受信側分散共有
メモリ上の上記要求FIFOエリアから複数の上記処理
要求データを順次読み出すことにより、処理要求を検出
することを特徴とするマルチプロセッサシステム。 - 【請求項4】請求項1ないし3のいずれか1つに記載の
マルチプロセッサシステムにおいて、上記送信側分散共
有メモリ制御手段は、送信側分散共有メモリの連続する
複数のアドレスロケーションに複数のデータが連続的に
書き込まれた場合、上記複数のデータの先頭アドレスと
複数のデータとをまとめて受信プロセッサモジュールに
一括送信し、 受信側分散共有メモリ制御手段は、一括受信した上記先
頭アドレスと上記複数のデータをもとに受信側分散共有
メモリ上の同一アドレスロケーションに連続的にコピー
を行うことを特徴とするマルチプロセッサシステム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20207194A JP3312362B2 (ja) | 1994-08-26 | 1994-08-26 | マルチプロセッサシステム |
US08/317,647 US5617537A (en) | 1993-10-05 | 1994-10-03 | Message passing system for distributed shared memory multiprocessor system and message passing method using the same |
EP94115617A EP0646876B1 (en) | 1993-10-05 | 1994-10-04 | Message passing system for distributed shared memory multiprocessor system and message passing method using the same |
DE69424114T DE69424114T2 (de) | 1993-10-05 | 1994-10-04 | Nachrichtenübertragungssystem für Multiprozessorsystem mit verteiltem gemeinsamen Speicher und dazu gehöriges Nachrichtenübertragungsverfahren |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20207194A JP3312362B2 (ja) | 1994-08-26 | 1994-08-26 | マルチプロセッサシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH0863442A true JPH0863442A (ja) | 1996-03-08 |
JP3312362B2 JP3312362B2 (ja) | 2002-08-05 |
Family
ID=16451474
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP20207194A Expired - Lifetime JP3312362B2 (ja) | 1993-10-05 | 1994-08-26 | マルチプロセッサシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3312362B2 (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006350406A (ja) * | 2005-06-13 | 2006-12-28 | Seiko Epson Corp | マルチcpu装置およびcpu間通信方法 |
JP2007323591A (ja) * | 2006-06-05 | 2007-12-13 | Nippon Telegr & Teleph Corp <Ntt> | データ転送制御装置、及びデータ転送制御プログラム |
JP2008015617A (ja) * | 2006-07-03 | 2008-01-24 | Nippon Telegr & Teleph Corp <Ntt> | 分散共有メモリを用いた同報通信方法および装置 |
US7418705B2 (en) | 2003-06-27 | 2008-08-26 | Kabushiki Kaisha Toshiba | Method and system for performing real-time operation |
US7657890B2 (en) | 2003-06-27 | 2010-02-02 | Kabushiki Kaisha Toshiba | Scheduling system and method in which threads for performing a real-time operation are assigned to a plurality of processors |
JP2010198520A (ja) * | 2009-02-27 | 2010-09-09 | Hitachi Ltd | コントローラ通信方法およびコントローラ通信装置 |
JP2014048965A (ja) * | 2012-08-31 | 2014-03-17 | Fujitsu Ltd | 情報処理装置,処理方法及びプログラム |
JP2020537235A (ja) * | 2017-10-12 | 2020-12-17 | エイアールエム リミテッド | データ処理システムにおけるメッセージ受渡し |
US11983127B2 (en) | 2019-12-18 | 2024-05-14 | Sony Group Corporation | Information processing system, information processing method, and information processing device to reduce load on an information processing unit |
-
1994
- 1994-08-26 JP JP20207194A patent/JP3312362B2/ja not_active Expired - Lifetime
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7418705B2 (en) | 2003-06-27 | 2008-08-26 | Kabushiki Kaisha Toshiba | Method and system for performing real-time operation |
US7657890B2 (en) | 2003-06-27 | 2010-02-02 | Kabushiki Kaisha Toshiba | Scheduling system and method in which threads for performing a real-time operation are assigned to a plurality of processors |
US8171477B2 (en) | 2003-06-27 | 2012-05-01 | Kabushiki Kaisha Toshiba | Method and system for performing real-time operation |
JP2006350406A (ja) * | 2005-06-13 | 2006-12-28 | Seiko Epson Corp | マルチcpu装置およびcpu間通信方法 |
JP2007323591A (ja) * | 2006-06-05 | 2007-12-13 | Nippon Telegr & Teleph Corp <Ntt> | データ転送制御装置、及びデータ転送制御プログラム |
JP2008015617A (ja) * | 2006-07-03 | 2008-01-24 | Nippon Telegr & Teleph Corp <Ntt> | 分散共有メモリを用いた同報通信方法および装置 |
JP2010198520A (ja) * | 2009-02-27 | 2010-09-09 | Hitachi Ltd | コントローラ通信方法およびコントローラ通信装置 |
JP2014048965A (ja) * | 2012-08-31 | 2014-03-17 | Fujitsu Ltd | 情報処理装置,処理方法及びプログラム |
JP2020537235A (ja) * | 2017-10-12 | 2020-12-17 | エイアールエム リミテッド | データ処理システムにおけるメッセージ受渡し |
US11983127B2 (en) | 2019-12-18 | 2024-05-14 | Sony Group Corporation | Information processing system, information processing method, and information processing device to reduce load on an information processing unit |
Also Published As
Publication number | Publication date |
---|---|
JP3312362B2 (ja) | 2002-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5617537A (en) | Message passing system for distributed shared memory multiprocessor system and message passing method using the same | |
JP3697831B2 (ja) | コンピュータシステム | |
US5752078A (en) | System for minimizing latency data reception and handling data packet error if detected while transferring data packet from adapter memory to host memory | |
US8375145B2 (en) | Doorbell handling with priority processing function | |
US7533197B2 (en) | System and method for remote direct memory access without page locking by the operating system | |
US7124211B2 (en) | System and method for explicit communication of messages between processes running on different nodes in a clustered multiprocessor system | |
JP3473975B2 (ja) | ネットワークシステムおよびネットワークにおける通信方法 | |
JPH09506727A (ja) | 大規模並列処理システムのためのメッセージ機構 | |
AU2020213829B2 (en) | Handling an input/output store instruction | |
US7640549B2 (en) | System and method for efficiently exchanging data among processes | |
WO2020157594A1 (en) | Handling an input/output store instruction | |
JP3312362B2 (ja) | マルチプロセッサシステム | |
US20120265883A1 (en) | Multiple overlapping block transfers | |
USRE41010E1 (en) | System for data transfer through an I/O device using a memory access controller which receives and stores indication of a data status signal | |
WO2008057833A2 (en) | System and method for remote direct memory access without page locking by the operating system | |
JP3303045B2 (ja) | ネットワーク分散処理システム | |
Sitsky et al. | An MPI library which uses polling, interrupts and remote copying for the Fujitsu AP1000+ | |
JPH08106440A (ja) | 分散共有メモリ計算機システム | |
CN118410001A (zh) | 图形处理单元间数据传输方法、***、装置、产品及设备 | |
KR850000562B1 (ko) | 계산기 시스템간 통신방식 | |
JP2971119B2 (ja) | 複数プロセッサシステムにおける高速データ転送方式 | |
JPH10150468A (ja) | 送信履歴ビットを持つデータ処理装置およびデータ通信方法 | |
Jung et al. | Performance issues of message transmission on cluster-based multicomputer | |
JPH0675883A (ja) | メッセージ通信装置 | |
Richardson | Distributed Communications in Embedded Military Systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090531 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090531 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100531 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100531 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110531 Year of fee payment: 9 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120531 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130531 Year of fee payment: 11 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140531 Year of fee payment: 12 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
EXPY | Cancellation because of completion of term |