JPH02238534A

JPH02238534A - マルチプロセツサ・システム

Info

Publication number: JPH02238534A
Application number: JP1057761A
Authority: JP
Inventors: Takashi Matsumoto; 尚松本
Original assignee: NIPPON I B M KK; IBM Japan Ltd
Current assignee: NIPPON I B M KK; IBM Japan Ltd
Priority date: 1989-03-13
Filing date: 1989-03-13
Publication date: 1990-09-20
Anticipated expiration: 2010-03-08
Also published as: JPH0721781B2; EP0388032A2; EP0388032A3

Abstract

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

Description

【発明の詳細な説明】Ａ．産業上の利用分野この発明は複数のプロセッサがプライベート・キャッシ
ュを介して共有バスおよび共有メモリに接続されている
マルチプロセッサ・システムに関し、とくに各プライベ
ート・キャッシュがわに制御装置を設け共有バス上の信
号を監視することによりキャッシュにおけるデータの操
作、たとえばプライベート・キャッシュ間のデータの一
貫性を維持する操作を行う、いわゆるスヌープ・キャッ
シュを有するマルチプロセッサ・システムに関する。

Ｂ．従来技術共有メモリ、共有バス型のマルチプロセッサ・システム
においては、バスおよびメモリへのアクセスの競合を減
ずるために各プロセッサにプライベート・キャッシュを
付加する方法が広く用いられている。このような方法に
おいては複数キャッシュ間のデータの一貫性を保証する
機構が必要になる。またこのような機構により、バス・
トラ一４一フィックを一層効率よく行えれば好都合である。

そしてその機構のひとつとしてスヌープ・キャッシュと
よばれるものが・ある。

第１図はスヌープ・キャッシュ方式のマルチプロセッサ
・システムを示す。第１図において複数のプロセッサＰ
ＩＰ２・・・Ｐｏはそれぞれプライベート・キャッシュ
ＣＩＧ・・・Ｃｎを介して共有バス１および共有メモリ
Ｍに接続されている。そして各プライベート・キャッシ
ュがわに制御装置を設けて共有バス１上の信号を監視さ
せ、分散制御方式によりデータの一貫性を実現する。す
なわちこの方式では各制御装置が共有バス１上のプロト
コールにしたがって動作することによりデータの一貫性
を実現する。

従来のプロトコールは、共有データに関する書込み時の
手順の観点から、インパリデート・タイプ（ｉｎｖａｌ
ｉｄａｔｅ　ｔｙｐｅ）とアップデート壷タイプ（ｕｐ
ｄａｔｅ　ｔｙｐｅ）とに分類できる。インバリデート
・タイプにおいては所定のプライベート・キャッシュの
共有データに書込みが行なわれると、当該共有データを
有する他のプライベート・キャッシュでその共有データ
を無効化する。他方アツプデート・タイプにおいては書
き込んだデータの複製を他のプライベート・キャッシュ
に送出し、共有データの更新を実行する。

ところで以上のプロトコールには一長一短があり、すべ
てのタイプの共有データに対して適しているわけではな
い。メモリがあるタイプの共有データに割り付けられた
とき、どういうブロトコールが一番適しているか、イン
バリデート・　タイプと　アップデート・タイプタイプ
のプロトコールについて例を挙げて説明する。

１）　ある変数がセマフォやプロセッサ間のデータの受
渡しに使用されている場合はその変数は頻繁に複数のプ
ロセッサから参照されるので、参照の際のキャッシュ・
ヒットの可能性を高めるためにアップデート・タイプタ
イプのプロトコールで処理されることが望ましい。

２）ある変数がローカル変数で１つのプロセッサのみが
使用する場合（ローカル変数でもページ管理の都合で他
のキャッシュにもその変数の物理アドレスが張り付いた
ままで、共有データになる可能性がある場合）や、ある
変数またはワークエリアがクリティカル・セクション内
にあり１つのプロセッサが長期にわたって独占使用する
とき場合は、共有データのまま複数のキャッシュ内に存
在し続けると、データの書き込みの度にアクセスがキャ
ッシュの外側の共有バスまで出てしまい効率が悪い。よ
って、これらの時はインバリデート・　タイプとして他
のキャッシュ内のデータ・エントリを無効化すると効率
が上がる。

なおキャッシュのプロトコールという言葉は、データ書
込みの扱い方やデータの置き換えの方式等、かなり広い
意味で使われることがある。しかし、本文章では共有デ
ータの取扱い方に的を絞っているので、特に断らない限
りブロトコールと言えば、共有データの取扱い方を指す
ものとする。

以上のようにデータのタイプ毎のプロトコールの最適化
を考慮したときには従来のマルチプロセッサ・システム
では十分ではないことがわかる。以下検討する。

ａ〕多くのシステムではプロトコールが一種類に固定さ
れている。または、システムの立上げ時にプロトコール
を選択し、その後は一種類に固定されている。これでは
ある種の共有データについては効率が悪く、通常、様々
なタイプの共有データが混在するので、そのタイプによ
ってプロトコールが動的に選択可能な方が効率が良い。

ｂ）日本アイ・ビー・エム株式会社東京基礎研究所で試
作したＴＯＰ−１　（プロトタイプ名）では、プロセッ
サ毎（キャッシュ毎）にアップデート・タイプかインバ
リデート・　タイプかを決定できる。しかし、前述のよ
うに変数またはワークエリア毎に適合するプロトコール
が異なっている。そこで、プロセッサ毎にプロトコール
を決めるよりも、変数またはワークエリア毎にどのプロ
トコールでアクセスするかを決める方が効率の向上が望
める。ＴＯＰ−１ではキャッシュ内のレジスターの変更
でプロトコールのタイプを選択するようになっているが
、これではきめ細かく制御するためにはレジスタを書換
える命令をデータのアクセスの度に挿入しなければなら
ない。これについては特願平１−４７９９号を参照され
たい。

Ｃ．発明が解決しようとする問題点この発明は以上の事情を考慮してなされたものであり、
効率のよいマルチプロセッサ・システムを実現するため
に、簡易な構成で変数またはワークエリア毎につまり共
有データのタイプによってプロトコールをオーバーヘッ
ドなしに切替可能なキャッシュの制御機構を提供するこ
とを目的としている。

また、ある特定のプロセッサ群の中でのみ効力を働かせ
たいプロトコールをサポートするためのキャッシュの制
御機構を提供することを目的としている。

Ｄ．問題点を解決するための手段共有バス，共有メモリ型でスヌープ・キャッシュを持っ
たマルチプロセッサ・システムにおいて、ある特定の記
憶領域毎にこの領域に属するデータをアクセスする時に
キャッシュが用いるブロトコールを指定する情報を付加
しておく。プロセッサ（またはメモリ管理ユニット）は
メモリアクセス時に操作対象のメモリの属する領域に対
応するその付加情報を信号として出力する。メモリアク
セスが共有バスを用いて実行される際は、その付加情報
の信号は共有バス上にも出力される。共有バスに接続さ
れているすべてのキャッシュは共有バス上のその信号で
プロトコールを選択して、バス・スヌープ（バス監視）
を実行する。

また、共有バスを拡張して、プロセッサ群を指定するた
めのバスを新たに設けて、バスアクセス時にプロセッサ
群の識別信号がバスを使用しているプロセッサから出力
されるようにしておくこともできる。ある種のプロトコ
ールの際にはその信号を基に、同じプロセッサ群に属し
ているかどうかによってキャッシュのスヌーブ動作を制
御する。

Ｅ．実施例以下この発明の実施例について第２図以降の図面を参照
して説明する。

第２図は記憶領域毎にアップデート・タイプタイプ、イ
ンバリデート・　タイプおよびオール・リード・タイプ
（ａｌｌ−ｒｅａｄ　ｔｙｐｅ）のプロトコールの設定
を行える１実施例を全体として示している。なお第２図
において第１図と対応する箇所には対応する番号を付し
て詳細な説明を省略する。

またオール・リード・タイプのプロトコールについては
後に詳述する。

第２図においてプロセッサＰＩＦ２・・・Ｐｎはプロト
コール・タイプを表示する信号Ｔ１、Ｔ２およびＴ３を
対応するプライベート・キャッシュＣＩＣ・・・Ｃｎを
介してプロトコール・タイプ・バス２に送出シている。

信号Ｔ１、Ｔ２およびＴ３は共有バス１上のデータに対
するプロトコール・タイプがそれぞれアップデート・タ
イプ、インバリデート・タイプおよびオール・リード・
タイプであることを示す。プライベート・キャッシュＣ
ＩＣ・・・Ｃｎは図示しないがキャッシュ制御機構をそ
れぞれ有しており、このキャッシュ制御機構がプロトコ
ール・タイプ・バス２を監視して共有バス１上のデータ
に対するプロトコールを判別し、必要に応じて一１　１
一（該当する共有データを保持するとき）そのプロトコー
ルの手順を実行する。

この実施例ではデータのアドレス毎にプロトコール・タ
イプ表示情報を付加するのでなく、一定の記憶領域毎に
この情報を割り当てている。すなわち、従来技術に関連
して説明したように、メモリ毎（変数やワークエリア毎
）に適したキャッシュのプロトコールが異なっている。

よって、メモリ毎にプロトコールを制御することがパフ
ォーマンスを向上する上で重要である。しかし、各アド
レス毎にプロトコールのタイプを表す情報を付加したの
では、その情報のための記憶領域や管理のハードウエア
がかなりの量となり、効率的ではない。

そこで一定の記憶領域ごとにプロトコールのタイプを表
す情報を付加し管理する。ここでは実現の容易さから、
従来型のプロセッサ（またはその専用ＭＭＵ）にすでに
インプリメントされているページ管理機構に注目し、ペ
ージ毎にその情報を付加することにする。

第３図は第２図のプロセッサＰに関連する人出力信号を
示し、第４図は第２図実施例のページ管理機構とページ
・エントリの構成例を示す。

第３図および第４図において（とくに第４図において）
、ページ管理機構はメモリをページという単位（図では
４Ｋバイト単位）で管理しており、ページ毎にそのペー
ジを実メモリのどこに配置するか、どのような保護を行
うかといったことを記述したページ・エントリを持って
いる。プロセッサのメモリ・アクセスの際は論理アドレ
スの上位ビットで選択されたページ・エントリ（または
ページ・エントリをプロセッサ内にコピーしたトランス
レーション・ルックアサイド・バッファ：ＴＬＢ）が必
ず参照されてアクセス権がチェックされ、ページ・エン
トリの頁・フレーム・アドレスを基に実メモリのアドレ
スが算出される。そして、アクセス権を満たしていると
実メモリへのアクセスが行なわれる。

第４図のページ・エントリのＰＩ，ＰＯはアクセス権を
示すビットで、次表のようにプロテクション・レベルに
対応している。

ページ・エントリのＡ．Ｄ．Ｅは仮想記憶の管理に用い
られるビットで、それぞれページ内がアクセスされたか
、書き替えられたか、ページが実メモリに存在するかを
示す。

さて、Ｔ２１７ｌｌＴＯが本発明の特徴であるページの
プロトコールのタイプを表すビットである。つまり、こ
のページに属するデータはどのタイプのブロトコールを
使ってアクセスするかを示す情報である。ここでは３ビ
ットでプロトコールのタイプを表わすことにしているが
、この数はシステムがサポートするプロトコールの数に
対応している（３ビットでは２３＝８種類までのプロト
コールに対応）。プロセッサ（またはＭＭＵ）がメモリ
・アクセスする際に、このアクセスはどのブロトコール
で処理しなければならないかを示すため、このプロトコ
ールのタイプを示すビットを外部に出力する信号線をプ
ロセッサに設ける（第３図）。そして、第２図のように
マルチプロセッサを構成し、キャッシュＣ１Ｃ・・・ｃ
ｏから共有バス１上にアクセスが出るとき、つまり共有
バス１のトラフィックが必要なときには、共有バス１に
もプロトコールのタイプを示す信号が出力され、他のキ
ャッシュＣＩＧ・・・ｃｏはこの信号でブロトコールを
選択しながらバス・スヌープ（バス監視）を行う。

第５図は第４図のプロトコール制御を従来型のＣＰＵや
ＭＭＵでインプリメントした変形例を示す。第５図の変
形例では、ページ・エントリ内にＴ２，ＴＩ，Ｔｏのよ
うなビットはないので、アドレスの一１５ー上位２〜３ビットをプロトコールのタイプを示すビット
として使用する（第５図）。３２ビットの実アドレス線
があれば、２〜３ピットこの用途に使用しても５１２Ｍ
バイト〜ＩＧバイトの実メモリ空間が使用可能で実用上
問題ないと思われる。

次にオール・リード（ａｌｌ　ｒｅａｄ）　　・タイプ
のプロトコールについて説明しておく。

以上のように効率的にプロトコールを切替る機構を実現
することが可能となると、ある種のデータにのみ有効だ
が、他のデータに用いると効率が悪くなるため今まで使
われなかったようなブロトコールも有効に使えるように
なる。そのようなプロトコールに対してはその適合する
データにのみ選択的に用いられるように制御する。この
ようなプロトコールの例がａｌｌ　ｒｅａｄ　というプ
ロトコールである。このプロトコールはバス・スヌープ
を行っているキャッシュが他のキャッシュによる共有パ
スを使っての読み出しの際に積極的にバス上のデータを
取り込むプロトコールである。

このプロトコールは以下のような場合に適している。全
プロセッサが同じデータを参照する必要があるときに各
プロセッサが個別にリードを行ない、メモリからキャッ
シュにデータを張り付けるとすると、キャッシュ内にデ
ータが持ってこられるまでに、データ数×プロセッサ数
　のバス・トラフィックが共有バスで発生する。そこで
、ａｌｌｒｅａｄをこのデータに対するプロトコールと
して用いれば、データ数だけのバス・トラフィックで済
み効率が良い。

つぎにアップデート・タイプ、インバリデート・タイプ
およびオール・リード・タイプのプロトコールを例に用
いて、キャッシュのスヌーブ時の動作を説明する。バス
・スヌーブの結果のキャッシュの動作を箇条書きにする
と以下のようになる。

アップデート・タイプ・書込みアクセスでキャッシュ・ヒットなら、バス上の
データでキャッシュ内　　　　のデータを更新する。

・他の場合なら、何もしない（注参照）。

（注）ここでは、キャッシュの動作のうち、ブロトコー
ルをデータ毎に変更することで効率が上がるようなもの
のみに注目している。そこで、この箇条書きでは書込み
動作がどんな方式で行なわれるかということを簡単のた
めに考慮していない。

書込み動作の方式がｗｒｉｔｅ　ｂａｃｋ等の場合は、
データのオウナーシップ（誰が一番最新の正しいデータ
を持っており、バスに供給する責任があるか）によりキ
ャッシュのスヌーブ時の動作はもう少し複雑になる。

インバリデート・　タイプ・書込みアクセスでキャッシュ・ヒットなら、キャッシ
ュ内のデータを無効化（ｉｎｖａｌｉｄａｔｅ）する。

・他の場合なら何もしない（上記注参照）。

オール・リード・タイプ・読み出しアクセスでキャッシュ・ヒットではなく、か
つデータのりプレイスによるライト・バック（　ｗｒｉ
ｔｅ　ｂａｃｋ　，つまりシステム・パスへのアクセス
）を引き起こすことなしにデータを取り込めるなら、バ
ス上のデータをキャッシュ内に取り込む。

・書込みアクセスでキャッシュ・ヒットなら、アップデ
ート・タイプの書込みアクセス時と同じ処理を行う。

・他の場合なら何もしない（上記注参照）。

また、キャッシュのプロトコールの種類としては、他の
プロセッサの共有バスを使った読み出しアクセスでキャ
ッシュ・ヒットしたら、スヌープしているキャッシュは
キャッシュ内のデータを無効化するインバリート・リー
ド　（ｉｎｖａｌｉｃｌａｔｅ　ｒｅａｄ）　　等他に
も色々考えられるが、ここでは上記の３種を列挙するに
留めておく。

ページ毎の変数やワークエリアの振り分けの例を第６図
に示す。コンパイラによるアクセス・パターンの解析や
プログラマによるプロトコール・タイプの指示等によっ
て、変数やワークエリアをそれに適したプロトコールの
タイプを持つページ内に割り振る。また、プロセッサの
命令コードについても、全プロセッサが同じコードを共
有するときはａｌｌ−ｒｅａｄタイプのページに割り付
けるの一１９ーが効率上得策である。

つぎにオール・リード・タイプの有効に利用する実施例
について第７図を参照して説明する。なお第７図におい
て第１図および第２図に対応する箇所には対応する符号
を付して詳細な説明を省略する。

第７図実施例はつぎの点を考慮したものである。

すなわちａｌｌ−ｒｅａｄタイプのプロトコールを指定
したバス・アクセスにおいて、関係のないキャッシュに
までデータを取り込ませることがないように、データを
取り込んで欲しいキャッシュ群（プロセッサ群）を指定
できることが望ましい。特に，ＯＳ上でアプリケーショ
ン・プログラムとしてプログラムが走るようなときには
、複数のお互いに無関係なタスクがマルチプロプセツサ
・システム上で同時に走ることが想定され、このような
機能が望まれる。この機能の実現のためには、システム
・バス上でキャッシュ群を指定する情報を伝えるための
バスとその情報を蓄えておいて　ａｌｌ−ｒｅａｄタイ
プのアクセス時に外部に出力するような−２０一ハードウエアがあればよい。そして、各キャッシュはス
ヌーブ動作で、バスのアクセスがａｌｌ−ｒｅａｄタイ
プの際に、゛プロセッサ群を指定するバスも監視して自
分のプロセッサが選択されているときのみ前記の動作を
行うようにする。このプロセッサ群の指定にもきめ細か
い制御が要求されるのであれば、この指定の情報はペー
ジ・エントリ内に記憶され、ページ毎に指定が変えられ
るインプリメントが望ましい。しかし、それではプロセ
ッサ（またはＭＭＵ）のビン数がかなり増大してしまう
。また、ａｌｌ−ｒｅａｄはあるタスクを一緒に処理し
ているプロセッサ群のすべてのキャッシュにデータを張
り付けるというのが基本的な考えなので、この同一のタ
スクを処理するプロセッサ群を指定する情報は各キャッ
シュに１つ記憶できれば良い。

そこで、キャッシュ毎に１つのレジスターを用意する（
第７図）。

第７図のプロセッサ群指定回路３，３２・・・３ｎとプ
ロセッサ群指定バス４がこの処理を実現するためのキャ
ッシュ制郭機構である。プロセッサ指定バス４のバス幅
はｌｏｇ２（ｎ＋２）−１本（ｎはプロセッサ台数）で
ある。その動作は以下の通りである。

・プロセッサ群指定回路３１３２・・・３ｎは自分の担
当するプロセッサＰＩＰ２・・・Ｐ．が共有バス１を使
ってａｌｌ−ｒｅａｄタイプのアクセスをするときに、
内部のレジスタに保持したプロセッサ群を指定する識別
番号をプロセッサ群指定バス４上に出力する。

・プロセッサ群指定回路３１３２・・・３ｎは自分の担
当するプロセッサＰ　＋　Ｐ　２・・・Ｐ．が共有バス
１を使用していないときは、プロセッサ群指定バス４を
監視（スヌープ）シ、レジスターの値と比較して、自分
の担当するプロセッサＰＩＰ２・・・Ｐ，が選択されて
いるかどうかの信号をキャッシュＣ　ＩＣ・・ｃｏに出
力する。キャッシュＣ　＋　Ｃ・・・Ｃｎは共有バス１
のアクセスがａｌｌ　ｒｅａｄタイプの場合、その信号
によってスヌープ動作を切替る。

プロセッサ群指定回路３１３２・・・３ｎ内部のレジス
タにプロセッサ群を指定する識別番号を設定するのはプ
ロセッサがソフトウェアで行う。ＯＳが存在する時はＯ
Ｓがタスクにプロセッサを割り付ける毎にこのレジスタ
の設定を行えばよい。第７図中のキャッシュＣＩＣ・・
・ｃｏとプロセッサ群指定回路３１３２・・・３ｎ間の
信号線Ａ，Ｅはそれぞれ、プロセッサＰ　ｒ　Ｐ　２・
・・Ｐｎがａｌｌ−ｒｅａｄタイプのアクセスを行って
いることを示す信号線とプロセッサＰＩＰ２・・・Ｐｎ
が選択されていることを示す信号線である。

もちろん、このプロセッサ群指定バス４は操作対象とす
るプロセッサ群（キャッシュ群）を指定するために用い
ているだけなので、ａｌｌ，，−ｒｅａｄのプロトコー
ル以外でも使用できる。

データ（変数）の中にプログラムのある部分では全プロ
セッサＰＩＰ２・・・Ｐｎに参照され、ある部分では１
つのプロセッサが独占使用するというようなものが存在
する、つまり望ましいプロトコール・タイプが１つのプ
ログラム中で大きく変化するデータが存在するときは、
同じように変化するデータを１つのページに集めて途中
でそのページ・エントリのプロトコール・タイプを書換
えること一２３ーで対応できる。

Ｆ．発明の効果本発明によれば、共有データのタイプによってキャッシ
ュのプロトコールをオーバーヘッドなしに切替可能とな
る。これにより、共有データ毎に最適なプロトコールを
選択でき、共有バスの使用頻度を減らすことができる。

そして、マルチプロセッサ・システムの性能の向上を図
ることができる。

【図面の簡単な説明】

第１図は共有バス，共有メモリ型でスヌープ・キャッシ
ュを持った従来のマルチプロセッサ・システムを示すブ
ロック図、第２図は本発明の１実施例の全体構成を示す
ブロック図、第３図は第２図実施例のプロセッサに関連
する信号を説明する図、第４図は第２図実施例で用いる
ページ管理機構およびページ・エントリの構成例を説明
する図、第５図は第４図構成例を従来型のプロセッサで
実現するように変形した他の構成例を説明する図、第６
図はプロトコールのタイプによるページの割一２４一り付けを説明する図、第７図はプロセッサ群の指定を可
能にする、この発明の他の実施例の全体構成図を示すブ
ロック図である。ｐ．ｐ２・・・Ｐｒｌ・・・プロセッサ、Ｃ　１Ｃ・・
・Ｃｎ・・・キャッシュ、Ｍ・・・共有メモリ、１・・
・共有バス、２・・・プロトコール・タイプ・バス、３
１３２・・−３ｎ・・・プロセッサ群指定回路、４・・
・プロセッサ群指定バス。出願人　日本アイ・ビー・エム株式会社復代理人

Claims

【特許請求の範囲】

（１）複数のプロセッサをそれぞれプライベート・キャ
ッシュを介して共有バスおよび共有メモリに接続し、こ
の共有バスへのアクセスを監視して所定のプロトコール
にしたがって上記プライベート・キャッシュにおけるデ
ータの操作を実行するマルチプロセッサ・システムにお
いて、プロトコール・タイプを表示するプロトコール・タイプ
信号を受け取るプロトコール・タイプ・バスと、上記プライベート・キャッシュ毎に設けられるとともに
上記プロトコール・タイプ・バスに共通して接続された
キャッシュ制御機構とを有し、各制御機構は、データの記憶領域毎に割り当てられたプロトコール・タ
イプを記憶するプロトコール・タイプ記憶手段と、データがアクセスされたときにそのデータの属する記憶
領域のプロトコール・タイプを上記プロトコール・タイ
プ記憶手段から取り出し、対応するプロトコール・タイ
プ信号を上記プロトコール・タイプ・バスに送出するプ
ロトコール・タイプ信号生成手段と、上記プロトコール・タイプ・バス上のプロトコール・タ
イプ信号を監視して当該信号に応じたプロトコールで対
応するプライベート・キャッシュにおいてデータの操作
を実行する手段とを有することを特徴とするマルチプロ
セッサ・システム。
（２）上記データの記憶領域の単位をページとした特許
請求の範囲第１項記載のマルチプロセッサ・システム。
（３）上記プロトコール・タイプ記憶手段およびプロト
コール・タイプ信号生成手段をページ管理機構により構
成した特許請求の範囲第２項記載のマルチプロセッサ・
システム。
（４）複数のプロセッサをそれぞれプライベート・キャ
ッシュを介して共有バスおよび共有メモリに接続し、こ
の共有バスへのアクセスを監視して所定のプロトコール
にしたがって上記プライベート・キャッシュにおけるデ
ータの操作を実行するマルチプロセッサ・システムにお
いて、プロトコール・タイプを表示するプロトコール・タイプ
信号を受け取るプロトコール・タイプ・バスと、１または複数種類のプロトコールについてそのプロトコ
ールに応じてデータの操作を実行するプロセッサを限定
的に指定するプロセッサ限定信号を受け取るプロセッサ
限定バスと、上記プライベート・キャッシュ毎に設けられるとともに
上記プロトコール・タイプ・バスおよびプロセッサ限定
バスに共通して接続されたキャッシュ制御機構とを有し
、各制御機構は、データの記憶領域毎に割り当てられたプロトコール・タ
イプを記憶するプロトコール・タイプ記憶手段と、データがアクセスされたときにそのデータの属する記憶
領域のプロトコール・タイプを上記プロトコール・タイ
プ記憶手段から取り出し、対応するプロトコール・タイ
プ信号を上記プロトコール・タイプ・バスに送出するプ
ロトコール・タイプ信号生成手段と、上記プロトコール・タイプ信号が、上記プロセッサを限
定するプロトコール・タイプを表示するときに、上記プ
ロセッサ限定信号を上記プロセッサ限定バスに送出する
プロセッサ限定信号生成手段と、上記プロトコール・タイプ・バス上のプロトコール・タ
イプ信号および上記プロセッサ限定バス上のプロセッサ
限定信号を監視して、対応するプライベート・キャッシ
ュにおいてデータの操作が必要かどうかを判別するとと
もに、必要なときには上記プロトコール・タイプ信号に
応じたプロトコールで対応するプライベート・キャッシ
ュにおいてデータの操作を実行する手段とを有すること
を特徴とするマルチプロセッサ・システム。