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

マルチプロセッサシステム Download PDF

Info

Publication number
JP3751741B2
JP3751741B2 JP02113598A JP2113598A JP3751741B2 JP 3751741 B2 JP3751741 B2 JP 3751741B2 JP 02113598 A JP02113598 A JP 02113598A JP 2113598 A JP2113598 A JP 2113598A JP 3751741 B2 JP3751741 B2 JP 3751741B2
Authority
JP
Japan
Prior art keywords
message
control unit
address
node
memory
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.)
Expired - Lifetime
Application number
JP02113598A
Other languages
English (en)
Other versions
JPH11219343A (ja
Inventor
岳生 細見
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP02113598A priority Critical patent/JP3751741B2/ja
Priority to US09/241,069 priority patent/US6408365B1/en
Priority to DE19904049A priority patent/DE19904049A1/de
Publication of JPH11219343A publication Critical patent/JPH11219343A/ja
Application granted granted Critical
Publication of JP3751741B2 publication Critical patent/JP3751741B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0817—Cache consistency protocols using directory methods
    • G06F12/0828—Cache consistency protocols using directory methods with concurrent directory accessing, i.e. handling multiple concurrent coherency transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/25—Using a specific main memory architecture
    • G06F2212/254—Distributed memory
    • G06F2212/2542—Non-uniform memory access [NUMA] architecture

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、疎結合型のマルチプロセッサシステムに関し、特にこのようなマルチプロセッサシステムにおける主記憶装置とキャッシュメモリとのデータの一貫性（コヒーレンシー）の維持に関するものである。
【０００２】
【従来の技術】
従来の疎結合型マルチプロセッサシステムにおけるキャッシュメモリと主メモリとのデータの一貫性（コヒーレンシー）を維持するための技術が、文献(「The Directory-Based Cache Coherence Protocol for the DASH Multiprocessor」，Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta and John Hennessy，In Proceedings of 17th International Symposium on Computer Architecture，p148-159,1990)に開示されている。
【０００３】
図３４は、このような従来のマルチプロセッサシステムの構成を示すブロック図である。
【０００４】
図示するように、このマルチプロセッサシステムは、複数のノードＰｅ０〜Ｐｅｎ−１と、各ノードを結合する二つの相互結合網１０−１、１０−２とから構成されている。
【０００５】
各ノード（図では、Ｐｅｉのみを示す）は、演算やメモリアクセス等を行うプロセッサ５０と、データを保持する主メモリ５１と、プロセッサ５０がデータを一時的に保持する主メモリ５１よりも高速アクセスが可能なキャッシュメモリ５２と、主メモリ５１とキャッシュメモリ５２（他のノードのものを含む）との間のデータの一貫性を維持するための一貫性維持制御部５３とを有している。
【０００６】
一貫性維持制御部５３は、主メモリ５１に格納されているデータの状態およびデータのコピーをキャッシュメモリ５２に保持しているノードの情報（以降保持ノード情報と呼ぶ）を保持している。データの状態は、Ｃ、Ｍの２つからなる。Ｃは、複数のノードのキャッシュメモリ５２にデータのコピーが存在する状態を表す。この時、キャッシュメモリ５２のコピーと主メモリ５１のデータの値は同じである。Ｍは、１つのノードのキャッシュメモリ５２のみがデータのコピーを保持している状態を表す。この時、キャッシュメモリ５２のコピーの値と主メモリ５１のデータの値は異なり、コピーの値が最新の値である。
【０００７】
一貫性維持制御部５３は、キャッシュメモリ５２に格納されているデータの状態およびデータのタグアドレスを保持している。状態はＩ、Ｓ、Ｄの３つからなる。Ｉは、一貫性が維持された有効なデータのコピーが存在しない状態である。Ｓは、データの有効なコピーが存在し、かつ他のノードのキャッシュメモリ５２にも有効なコピーが存在する可能性がある、という状態である。Ｄは、データの有効なコピーが存在し、かつ他のノードのキャッシュメモリ５２には有効なコピーが存在せず、かつ主メモリ５１のデータの値と異なる、という状態である。タグアドレスはどのアドレスのデータであるかを示す。
【０００８】
相互結合網１０−１は、ノード間でやり取りされる要求メッセージを配信する。相互結合網１０−２は、ノード間でやり取りされる応答メッセージを配信する。このように、要求メッセージと応答メッセージを配信する相互結合網をそれぞれ別々に用意することによって、主メモリ５１とキャッシュメモリ５２とのデータの一貫性維持処理におけるデッドロックを回避するものである。
【０００９】
以下、プロセッサ５０が所定のアドレスのデータに対してロード或いはストアアクセスをしたときの、このマルチプロセッサシステムにおいて主メモリ５１とキャッシュメモリ５２とのデータの一貫性を維持するための動作について、説明する。
【００１０】
最初に、例えば、ノードＰｅ１のプロセッサ５０が、ロードアクセスを行ったときの動作について説明する。
【００１１】
一貫性維持制御部５３は、該当するアドレスのデータについて有効なコピーがキャッシュメモリ５２にも存在するかどうかを調べる。キャッシュメモリ５２に有効なコピーが存在する場合、すなわち状態がＳまたはＤである場合は、一貫性制御部５３は、プロセッサ５０にキャッシュメモリ５２から読み出したデータを渡すことによってプロセッサに応答し、処理を終了する。
【００１２】
キャッシュメモリ５２に有効なコピーが存在しない場合、すなわち状態がＩの場合は、ノードＰｅ１の一貫性維持制御部５３は、該当するアドレスのデータを保持しているノード、例えば、ノードＰｅｈ宛に、当該データの読み出し要求メッセージを相互結合網１０−１を介して送信する。
【００１３】
読み出し要求メッセージを受けたノードＰｅｈの一貫性維持制御部５３は、該当するアドレスのデータについての最新の値がノードＰｅｈの主メモリ５１に存在するかどうかを調べる。該当するアドレスのデータについての最新の値が主メモリ５１に存在する場合、すなわち状態がＣである場合には、ノードＰｅｈの一貫性維持制御部５３は、主メモリ５１に格納されているデータを相互結合網１０−２を介してノードＰｅ１に送信すると共に、保持ノード情報にノードＰｅ１を加える。
【００１４】
ノードＰｅｈからのデータを受信したノードＰｅ１の一貫性維持制御部５３は、プロセッサ５０に受け取ったデータを渡すと共に、キャッシュメモリ５２にそのデータをコピーする。さらに、ノードＰｅ１の一貫性維持制御部５３は、状態をＳとする。
【００１５】
一方、読み出し要求メッセージを受けたノードＰｅｈにおいて、該当するアドレスのデータについての最新の値が主メモリ５１に存在しない場合、すなわち状態がＭである場合には、ノードＰｅｈの一貫性維持制御部５３は、保持ノード情報を参照して、最新のデータを保持するノード、例えば、ノードＰｅｒに読み出し要求メッセージを相互結合網１０−１を介して送信する。
【００１６】
読み出し要求メッセージを受けたノードＰｅｒの一貫性維持制御部５３は、キャッシュメモリ５２に状態がＤのデータが存在するかどうかを調べる。キャッシュメモリ５２に状態がＤのデータが存在する場合には、ノードＰｅｒの一貫性維持制御部５３は、キャッシュメモリ５２に格納されているデータを相互結合網１０−２を介してノードＰｅ１に送信すると共に、キャッシュメモリ５２に格納されているデータを付加した書き戻し要求メッセージを相互結合網１０−１を介してノードＰｅｈに送信する。ノードＰｅｒの一貫性維持制御部５３は、さらにキャッシュメモリ５２に存在する当該データの状態をＳに更新する。
【００１７】
書き戻し要求メッセージを受けたノードＰｅｈの一貫性維持制御部５３は、主メモリ５１のデータを、書き戻し要求メッセージに付加されていたデータに更新する。さらに、そのデータの状態をＣに更新し、保持ノード情報にノードＰｅ１を加える。
【００１８】
一方、読み出し要求メッセージを受けたノードＰｅｒにおいて、キャッシュメモリ５２に状態がＤのデータが存在しない場合には、ノードＰｅｒの一貫性維持制御部５３は、Ｎａｋ（否定応答）メッセージを相互結合網１０−２を介してノードＰｅ１に送信する。
【００１９】
Ｎａｋメッセージを受け取ったノードＰｅ１の一貫性維持制御部５３は、再度ノードＰｅｈに読み出し要求メッセージを送信する。以降、ノードＰｅ１にデータが送信されて、ノードＰｅ１のプロセッサ５０にデータが渡されるまで、同様の処理が繰り返される。
【００２０】
次に、例えば、ノードＰｅ１のプロセッサ５０が、ストアアクセスを行ったときの動作について説明する。
【００２１】
一貫性維持制御部５３は、該当するアドレスのデータについてのシステム内での唯一のコピーがキャッシュメモリ５２にも存在するかどうかを調べる。キャッシュメモリ５２に有効なコピーが存在する場合、すなわち状態がＤである場合は、キャッシュメモリ５２のデータを更新し、プロセッサ５０にアクセス完了を通知して、処理を終了する。
【００２２】
キャッシュメモリ５２に唯一のコピーが存在しない場合、すなわち状態がＩまたはＳの場合は、ノードＰｅ１の一貫性維持制御部５３は、該当するアドレスのデータを保持しているノード、例えば、ノードＰｅｈ宛に、排他読み出し要求メッセージを相互結合網１０−１を介して送信する。
【００２３】
排他読み出し要求メッセージを受けたノードＰｅｈの一貫性維持制御部５３は、該当するアドレスのデータについての最新の値がノードＰｅｈの主メモリ５１に存在するかどうかを調べる。該当するアドレスのデータについての最新の値が主メモリ５１に存在する場合、すなわち状態がＣである場合には、ノードＰｅｈの一貫性維持制御部５３は、主メモリ５１に格納されているデータを相互結合網１０−２を介してノードＰｅ１に送信する。
【００２４】
ノードＰｅ１以外のノードがそのキャッシュメモリ５２に当該データのコピーを保持している場合には、そのデータのコピーが存在するノードＰｅ１以外のノードのすべて（ノードＰｅｋとする）に、無効化要求メッセージを相互結合網１０−１を介して送信する。さらに、ノードＰｅｈの一貫性維持制御部５３は、主メモリ５１のデータの状態をＭに更新し、保持ノード情報をノードＰｅ１のみとする。なお、ノードＰｅ１に送信されるデータには、無効化要求メッセージを送信したノードＰｅｋの数が付加される。
【００２５】
無効化要求メッセージを受けたノードＰｅｋの一貫性維持制御部５３は、キャッシュメモリ５２のデータの状態をＩに更新し、Ａｃｋ（肯定応答）メッセージを相互結合網１０−２を介してノードＰｅ１に送信する。
【００２６】
ノードＰｅｈからのデータを受信したノードＰｅ１の一貫性維持制御部５３は、データに付加されていたノードＰｅｋの数の分だけのＡｃｋメッセージを受信するのを待つ。ノードＰｅｋの数の分だけのＡｃｋメッセージを受信すると、キャッシュメモリ５２にそのデータをプロセッサ５０が行ったストアアクセスのデータに更新する。さらに、ノードＰｅ１の一貫性維持制御部５３は、状態をＤに更新し、プロセッサ５０にアクセス完了を通知して処理を終了する。
【００２７】
一方、排他読み出し要求メッセージを受けたノードＰｅｈにおいて、該当するアドレスのデータについての最新の値が主メモリ５１に存在しない場合、すなわち状態がＭである場合には、ノードＰｅｈの一貫性維持制御部５３は、保持ノード情報を参照して、最新のデータを保持するノード、例えば、ノードＰｅｒに排他読み出し要求メッセージを相互結合網１０−１を介して送信する。
【００２８】
排他読み出し要求メッセージを受けたノードＰｅｒの一貫性維持制御部５３は、キャッシュメモリ５２に状態がＤのデータが存在するかどうかを調べる。キャッシュメモリ５２に状態がＤのデータが存在しない場合には、ノードＰｅｒの一貫性維持制御部５３は、相互結合網１０−２を介してＮａｋメッセージを送る。
【００２９】
Ｎａｋメッセージを受け取ったノードＰｅ１の一貫性維持制御部５３は、再度ノードＰｅｈに対して、排他読み出し要求メッセージを送信する。以降、同様の処理が繰り返される。
【００３０】
一方、キャッシュメモリ５２に状態がＤのデータが存在する場合には、ノードＰｅｒの一貫性維持制御部５３は、キャッシュメモリ５２に格納されているデータを相互結合網１０−２を介してノードＰｅ１に送信する。また、ノードＰｅｒの一貫性維持制御部５３は、保持ノード更新要求メッセージを相互結合網１０−１を介してノードＰｅｈに送信すると共に、キャッシュメモリ５２のデータの状態をＩに更新する。
【００３１】
保持ノード更新要求メッセージを受けたノードＰｅｈの一貫性維持制御部５３は、主メモリ５１のデータを、ノードＰｅ１のみが保持しているとして保持ノード情報を更新し、Ａｃｋメッセージを相互結合網１０−２を介してノードＰｅ１に送信する。
【００３２】
ノードＰｅｒからのデータを受信したノードＰｅ１の一貫性維持制御部５３は、ノードＰｅｈからのＡｃｋメッセージを受信するのを待つ。ノードＰｅｈからのＡｃｋメッセージを受信すると、キャッシュメモリ５２にそのデータをプロセッサ５０が行ったストアアクセスのデータに更新する。さらに、ノードＰｅ１の一貫性維持制御部５３は、状態をＤに更新し、プロセッサ５０にアクセス完了を応答して処理を終了する。
【００３３】
【発明が解決しようとする課題】
しかしながら、上記従来技術のマルチプロセッサシステムには、次のような問題点があった。
【００３４】
第１に、一貫性維持のための処理が無限ループに陥ってしまう可能性がある。上記の例でいえば、ノードＰｅ１のプロセッサ５０がアクセスを行ったときに、ノードＰｅｒからノードＰｅ１のＮａｋメッセージが繰り返されている場合などが該当する。このため、上記従来技術のマルチプロセッサシステムでは、有限時間内でプロセッサ５０に応答が行えない場合が存在するという問題があった。
【００３５】
第２に、要求メッセージをやり取りするための相互結合網１０−１と、応答メッセージをやり取りするための相互結合網１０−２とを、それぞれ別々に設けることによって、デッドロックの発生を回避していた。このため、ハードウェアのコストが高くなると共に、故障の発生率も高くなり、システムの信頼性が低下するという問題点があった。
【００３６】
本発明は、上記従来技術の問題点を解消するためになされたものであり、主記憶装置とキャッシュメモリとのデータの一貫性（コヒーレンシー）を維持しつつ、処理装置によるデータアクセスが有限時間内で完了することを保証することができるマルチプロセッサシステムを提供することを目的とする。
【００３７】
本発明は、また、デッドロックの発生を回避するためにハードウェアを付加する必要がなく、低コストで信頼性の高いマルチプロセッサシステムを提供することを目的とする。
【００３８】
【課題を解決するための手段】
上記目的を達成するため、本発明の第１の観点にかかるマルチプロセッサシステムは、
相互結合網 (10) を介して互いに接続された複数のノード (PEi) から構成されるマルチプロセッサシステムであって、
前記複数のノード (PEi) は、それぞれ、
データのアクセス要求を発行するプロセッサ (20) と、
データが格納される主メモリ (30) と、
前記プロセッサ (20) がアクセスした主メモリ (30) のデータをブロック単位で一時保持する、前記主メモリ (30) よりも高速アクセスが可能なキャッシュメモリ (21) と、
前記キャッシュメモリ (21) に記憶されているデータの状態をブロック毎に記憶するタグメモリ (22) と、
前記主メモリ (30) に格納されているデータの一貫性に関する状態と、一貫性に関する状態の変化を待っているアクセス要求が存在するかどうか、をブロック毎に記憶するディレクトリメモリ (31) と、
前記プロセッサ (20) が発行したアクセス要求を受けて、キャッシュメモリ (21) とタグメモリ (22) にアクセスして一貫性処理を行い、必要に応じて該当するデータを保持する主メモリ (30) を有するノード (PEi) に対してアクセス要求を通知するローカルアクセス制御部 (25) と、
前記ローカルアクセス制御部 (25) からアクセス要求を受け、主メモリ (30) およびディレクトリメモリ (31) にアクセスして一貫性処理を行うと共に、必要に応じてアクセス要求をコンフリクトキューに退避するホームアクセス制御部 (27) とを備え、
前記ホームアクセス制御部 (27) は、
前記ローカルアクセス制御部 (25) からアクセス要求を受けたとき、該アクセス要求に応じたブロックのディレクトリメモリ (31) が一貫性処理中の状態にあることを示す場合には、該アクセス要求を前記コンフリクトキューに退避し、
アクセス要求を退避する時に前記コンフリクトキューが空であった場合は、対応するブロックのディレクトリメモリ (31) の内容を一貫性に関する状態の変化を待っているアクセス要求が存在することを示す値に更新し、
ディレクトリメモリ (31) の内容が一貫性に関する状態の変化を待っているアクセス要求が存在することを示すブロックに関して、該ブロックの状態が一貫性処理中の状態からそれ以外の状態に更新された場合に、前記コンフリクトキューの先頭のアクセス要求を読み出して一貫性処理を行い、該ブロックのディレクトリメモリ (31) の内容を一貫性に関する状態の変化を持っているアクセス要求が存在しないことを示す値に更新し、
前記コンフリクトキューから読み出されたアクセス要求を処理し、かつ別のアクセス要求が前記コンフリクトキューに蓄積されている場合、引き続き次のアクセス要求を前記コンフリクトキューから読み出し、
該当するブロックのディレクトリメモリ (31) の内容が、一貫性処理中であることを示す状態である場合には、前記コンフリクトキューから読み出したアクセス要求の処理を中止し、該ブロックのディレクトリメモリ (31) のエントリの内容を一貫性に関する状態の変化を待っているアクセス要求が存在することを示す値に更新し、
該当するブロックのディレクトリメモリ (31) の内容が、一貫性処理中でないことを示す状態である場合は、一貫性処理を行い、別のアクセス要求が前記コンフリクトキューにまだ蓄積されている場合は、引き続き次のアクセス要求を前記コンフリクトキューから読み出す
ことを特徴とする。
【００３９】
上記第１の観点にかかるマルチプロセッサシステムにおいて、
前記コンフリクトキューは、前記主メモリ (30) 内に設けられたものとすることができる。
【００４０】
上記第１の観点にかかるマルチプロセッサシステムにおいて、
前記複数のノード (PEi) が、Ｎ個 ( Ｎ＝自然数 ) のノードで構成され、
前記プロセッサ (20) が、最大ｋ個 ( ｋ＝自然数 ) のアクセス要求を同時に発行する手段を有する場合には、
前記コンフリクトキューは、Ｎ×ｋ個のエントリで構成されたものとすることができる。
【００４１】
上記目的を達成するため、本発明の第２の観点にかかるマルチプロセッサシステムは、
相互結合網 (10) を介して互いに接続された複数のノード (PEi) から構成されるマルチプロセッサシステムであって、
前記複数のノード (PEi) は、それぞれ、
データのアクセス要求を発行するプロセッサ (20) と、
データが格納される主メモリ (30) と、
前記プロセッサ (20) がアクセスした主メモリ (30) のデータをブロック単位で一時保持する、前記主メモリ (30) よりも高速アクセスが可能なキャッシュメモリ (21) と、
前記キャッシュメモリ (21) に記憶されているデータの状態をブロック毎に記憶するタグメモリ (22) と、
前記主メモリ (30) に記憶されているデータの状態をブロック毎に記憶するディレクトリメモリ (31) と、
前記プロセッサ (20) が発行したアクセス要求を受けて、キャッシュメモリ (21) とタグメモリ (22) をアクセスして一貫性処理を行い、必要に応じて該当するデータを保持する主メモリ (30) を有するノード (PEi) に対してアクセス要求を通知するローカルアクセス制御部 (25) と、
前記ローカルアクセス制御部 (25) からアクセス要求を受けて、主メモリ (30) およびディレクトリメモリ (31) をアクセスして一貫性処理を行うホームアクセス制御部 (27) と、
前記ローカルアクセス制御部 (25) に対する応答を受け取り、該応答を蓄積するリプライバッファ (32) と、
前記ローカルアクセス制御部 (25) に対する一貫性処理要求を受け取り、該一貫性処理要求を蓄積するリクエストバッファ (33) と、
前記ホームアクセス制御部 (27) が一貫性処理を行って他のノード (PEi) に送出する一貫性処理要求および応答を生成するための情報を前記ホームアクセス制御部 (27) より受け取り、該情報を蓄積するリモートバッファ (34) と
を備えることを特徴とする。
【００４２】
上記第２の観点にかかるマルチプロセッサシステムにおいて、
前記リクエストバッファ (33) は、前記ローカルアクセス制御部 (25) に対する一貫性処理要求を、前記主メモリ (30) に設けられたリクエスト退避キューに退避する手段と、該リクエスト退避キューに退避した一貫性処理要求を読み出す手段とを有するものとすることができる。
【００４３】
上記第２の観点にかかるマルチプロセッサシステムにおいて、
前記リモートバッファ (34) は、前記ホームアクセス制御部 (27) が他のノード (PEi) に送出する一貫性処理要求および応答を生成するための情報を、前記主メモリ (30) に設けられたリモート退避キューに退避する手段と、該リモート退避キューに退避した情報を読み出す手段と、該一貫性処理要求及び応答を生成するための情報から必要に応じて一貫性要求及び応答を生成する手段とを有するものとすることができる。
【００４４】
上記第２の観点にかかるマルチプロセッサシステムにおいて、
前記複数のノード (PEi) が、Ｎ個 ( Ｎ＝自然数 ) のノードで構成され、
前記プロセッサ (20) が、最大ｋ個 ( ｋ＝自然数 ) のアクセス要求を同時に発行する手段を有する場合には、
前記リプライバッファ (32) は、ｋ個のエントリで構成され、
前記リクエストバッファ (33) は、Ｎ×ｋ個のエントリで構成され、
前記リモートバッファ (34) は、Ｎ×ｋ個のエントリで構成されたものとすることができる。
【００４５】
上記第２の観点にかかるマルチプロセッサシステムにおいて、
前記ディレクトリメモリ (31) は、さらに、どのノード (PEi) のキャッシュメモリ (21) がデータを保持しているかをブロック毎に記憶し、
前記一貫性処理要求および応答を生成するための情報には、前記ディレクトリメモリ (31) に格納されている、どのノード (PEi) のキャッシュメモリ (21) がデータを保持しているかを示す情報が含まれるものとすることができる。
【００５４】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態について説明する。
【００５５】
［第１の実施の形態］
図１は、この実施の形態にかかる疎結合型のマルチプロセッサシステムの構成を示すブロック図である。
【００５６】
図示するように、このマルチプロセッサシステムは、複数のノードＰＥ０〜ＰＥｎ−１と、各ノードを結合し、ノード間でやり取りされる要求メッセージ及び応答メッセージをそれぞれ配信する相互結合網１０とから構成されている。この実施の形態においては、ｎ＝１０２４とする。
【００５７】
図２は、図１のノードＰＥｉ（ｉ＝０〜ｎ−１）の機能構成を示すブロック図である。
【００５８】
図示するように、ノードＰＥｉ（ｉ＝０〜ｎ−１）は、それぞれプロセッサ２０と、主メモリ３０と、キャッシュメモリ２１と、一貫性維持制御部１６とを有する。
【００５９】
プロセッサ２０は、メモリアクセスを行ったとき、そのメモリアクセスに関する情報、即ちアクセスの種類（ロードかストアか）、アドレス、データ等をローカルバッファ３８に出力する。プロセッサ２０は、メモリアクセスが対してロードアクセスであればデータを、ストアアクセスであれば完了信号を受け取ることにより、そのメモリアクセスがプロセッサ２０の外部で処理されたことを確認する。プロセッサ２０は前のメモリアクセスが外部で処理されたことを確認する前に次のメモリアクセスを発行することができる。このため、各メモリアクセスにはｉｄが付加され、アクセスの種類、アドレス、データと共にｉｄがローカルバッファ３８に出力される。プロセッサ２０への応答にもこのｉｄが付加されどのメモリアクセスに対する応答であるかが識別される。
【００６０】
アクセスの種類は、１ビットで表され、０がロード、１がストアアクセスを表すものとする。また、アドレスは４０ビット、データは６４ビットで構成される。プロセッサ２０は、最大４個のメモリアクセスを同時に発行することができ、２ビットのｉｄで区別されるものとする。なお、以降の説明では、アドレスの最下位ビットを第０ビット、最上位ビットを第３９ビットとする。
【００６１】
主メモリ３０は、６４ビット幅×２Ｍエントリ＝５１２Ｍバイト（１Ｍ＝１０２４×１０２４）である。
【００６２】
プロセッサ２０が出力するアドレスは、その上位ビットでどのノードＰＥｉの主メモリ３０に格納されたデータであるかを表し、その下位ビットで主メモリ３０でのオフセットを表す。ここでは、プロセッサ２０が出力するアドレス４０ビットのうち、第３９ビットから第３０ビットまでの上位１０ビットがどのノードＰＥｉの主メモリ３０のデータであるかを表し、第２９ビットから第０ビットまでの下位３０ビットが各主メモリ３０でのオフセットとなる。
【００６３】
キャッシュメモリ２１は、主メモリ３０よりも少量ではあるが高速なメモリで構成される。これにより、データがキャッシュメモリ２１に存在した場合、プロセッサ２０のメモリアクセスに対して早く応答することができ、メモリアクセスに要する時間を短縮することができる。キャッシュメモリ２１は、６４ビット幅×１２８Ｋエントリ＝１Ｍバイト（１Ｋ＝１０２４）であるとする。また、キャッシュメモリ２１と主メモリ３０との間のデータの転送は、ブロックと呼ばれる固定サイズ（以降１２８バイトとする）で行われる。なお、キャッシュメモリは、一般に命令キャッシュとデータキャッシュとに分かれるが、ここでは、データキャッシュが対象となる。
【００６４】
このマルチプロセッサシステムでは、主メモリ３０にあるデータのコピーが複数のキャッシュメモリ２１に存在することがある。このため、それらコピーや主メモリ３０のデータとの間でデータの一貫性を維持する制御が必要となる。一貫性維持制御部１６は、このような一貫性の維持の制御を行うもので、キャッシュメモリ２１にあるデータのコピーの状態や主メモリ３０のデータがシステム内でどういう状態にあるのかを管理する。一貫性維持制御部１６は、メモリアクセスに応じてノードＰＥｉ間でメッセージをやり取りし、それらの状態を変更したりデータの転送を行う機能を有する。一貫性維持制御部１６の構成については、さらに詳しく後述する。
【００６５】
図１に示す相互結合網１０は、メッセージに含まれるルーティング情報に基づきあるノードＰＥｉからあるノードＰＥｉにメッセージを配送する機能を有する。このルーティング情報として、ここでは宛先ノード番号が必要十分な情報であるものとする。また、あるノードからあるノードへのパスは一つであり、同じパスを通るメッセージ間で追い越しは発生しないものとする。ただし、送信ノードまたは受信ノードどちらか一方でも異なる場合には、メッセージ間での到着順序は保証されない。
【００６６】
次に、相互結合網１０を介してノードＰＥｉ間でやり取りされるメッセージについて説明する。
【００６７】
メッセージは、ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒ、Ａｃｋ、ＡｃｋＤａｔａ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの１２種類からなる。
【００６８】
ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒの４種は、メモリアクセスが行われたノードＰＥｉから、主メモリ３０にデータを保持するノードＰＥｉへ送信される要求メッセージである。ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖの３種は、主メモリ３０にデータを保持するノードＰＥｉから当該データのコピーをキャッシュメモリ２１に保持するノードＰＥｉへ送信される要求メッセージである。
【００６９】
Ａｃｋ、ＡｃｋＤａｔａの２種は、データのコピーをキャッシュメモリ２１に保持するノードＰＥｉから主メモリ３０にデータを保持するノードＰＥｉへ送信される報告メッセージである。ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの３種は、主メモリ３０にデータを保持するノードＰＥｉからメモリアクセスが行われたノードＰＥｉへ送信されるメモリアクセス完了メッセージである。
【００７０】
次に、各メッセージの構成について、図３を参照しながら説明する。
メッセージは、基本メッセージとブロックデータ付きメッセージに２分される。ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、Ａｃｋ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、Ｃｍｐの８種のメッセージは基本メッセージである。ＢｌｋＷｒ、ＡｃｋＤａｔａ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘの４種のメッセージはブロックデータ付きのメッセージである。
【００７１】
基本メッセージは、図３（ａ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（計１２個なので４ビットで表現）、要求元ノード番号（１０ビット）、ｍｉｄ（２ビット）、アドレス（４０ビット）の計６６ビットで構成される。
【００７２】
ブロックデータ付きメッセージは、図３（ｂ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（４ビット）、要求元ノード番号（１０ビット）、ｍｉｄ（２ビット）、アドレス（４０ビット）に加えて、ブロックサイズのデータ（１２８バイト）の計６６ビット＋１２８バイトで構成される。
【００７３】
以下、図２の一貫性維持制御部１６について、さらに詳しく説明する。
一貫性維持制御部１６は、タグメモリ２２、キャッシュメモリアクセス記憶部２３、タグメモリアクセス制御部２４、ローカルアクセス制御部２７、主メモリアクセス制御部２８、ディレクトリメモリアクセス制御部２９、ディレクトリメモリ３１、リプライバッファ３２、リクエストバッファ３３、リモートバッファ３４、メッセージ送信部３５、メッセージ受信部３６、リクエスト管理テーブル３７、及びローカルバッファ３８を含む。
【００７４】
ディレクトリメモリ３１は、主メモリ３０に格納されているデータについて、その状態を表す情報をブロック単位で格納している。ディレクトリメモリ３１に格納されている各ブロックの情報は、トップビット、ブロックの状態、およびコピーをキャッシュメモリ２１に保持しているノードの情報（以降保持ノード情報と呼ぶ）である。
【００７５】
トップビットは１ビットで表され、ホームアクセス制御部２５の動作に関わる。ブロックの状態は、Ｃ、Ｍ、ＲＳＰ、ＲＥＰ、ＵＰの５つのうちのいずれかで表され、例えば、Ｃは“０００”、Ｍは“００１”、ＲＳＰは“１００”、ＲＥＰは“１０１”、ＵＰは“１１０”というように３ビットでコーディングされる。
【００７６】
ブロックの状態としてＣは、０以上の複数のノードＰＥｉのキャッシュメモリ２１にデータのコピーが存在する状態を表す。この時、キャッシュメモリ２１のコピーと主メモリ３０のデータの値は同じである。ブロックの状態としてＭは、１つのノードＰＥｉのキャッシュメモリ２１のみがデータのコピーを保持している状態を表す。この時、キャッシュメモリ２１のコピーの値と主メモリ３０のデータの値は異なり、コピーの値が最新の値である可能性がある。ブロックの状態としてＲＳＰ、ＲＥＰ、ＵＰは、あるメモリアクセスから派生した一貫性維持処理の要求メッセージを受け、コピーを保持するキャッシュメモリ２１に一貫性維持処理の要求メッセージを発行し、応答を待っている状態であることを示している。
【００７７】
保持ノード情報は、ブロックの状態によって保持形態が異なる。ブロックの状態がＭおよびＲＳＰの場合は、ノードＰＥｉを特定するノード番号（１０ビットで表される）が一つ保持される。ブロックの状態がＲＥＰおよびＵＰの場合は、ノード数（１０ビットで表される）が保持される。ブロックの状態がＣの場合は、例えば、コースベクタ方式を単純化した方式でデータのコピーを保持するノードを管理する。
【００７８】
この方式は、ノードＰＥｉを幾つかのグループに分割し、グループ数分のビットで保持者（ノード）を管理する方式である。各ビットを立てるかどうかは、各ビットに対応するグループの中に一つでもコピーを保持するノードＰＥｉが存在するかどうかによって決定される。ここでは、これを８ビットで表し、第０ビットがノードＰＥ０からノードＰＥ１２７、第１ビットがノードＰＥ１２８からノードＰＥ２５５、．．．．．、第７ビットがノードＰＥ８９６からノードＰＥ１０２３にそれぞれ対応する。この構成の場合、ディレクトリメモリは１４ビット幅４Ｍ（主メモリサイズ／ブロックサイズ）エントリ分のデータを保持するメモリとなる。ディレクトリメモリ３１に格納されている各ブロックの情報は初期状態は、トップビットは０、状態はＣ、保持ノード情報は０ｘ０００（０ｘは１６進表記）となる。
【００７９】
タグメモリ２２は、キャッシュメモリ２１に格納されているデータについて、その状態を表す情報をブロック単位で保持している。タグメモリ２２に格納されている各ブロックの情報は、ブロックの状態およびタグアドレスである。ブロックの状態はＩ、Ｓ、Ｅ、Ｄの４つのいずれかによって表され、それぞれ対応するブロックがどの状態にあるかを示している。例えば、ブロックの状態は、Ｉは“００”、Ｓは“０１”、Ｅは“１０”、Ｄは“１１”というように２ビットでコーディングされる。
【００８０】
ブロックの状態としてＩは、一貫性が維持された有効なデータのコピーが存在しない状態を示す。ブロックの状態としてＳは、データの有効なコピーが存在し、かつ他のノードのキャッシュメモリ２１にも有効なコピーが存在する可能性がある、という状態を示す。ブロックの状態としてＥは、データの有効なコピーが存在し、かつ他のノードのキャッシュメモリ２１には有効なコピーが存在せず、かつ主メモリのデータの値と同じ、という状態を示す。ブロックの状態としてＤは、データの有効なコピーが存在し、かつ他のノードのキャッシュメモリ２１には有効なコピーが存在せず、かつ主メモリのデータの値と異なる、という状態を示す。
【００８１】
タグアドレスは、対応するブロックがどのアドレスのデータであるかを示す。ここでは、あるアドレスのデータがキャッシュメモリ２１のどのブロックに格納されるかが一意に決定されるダイレクトマップ方式でキャッシュメモリ２１が制御されている。この場合、キャッシュメモリ２１のサイズが１Ｍバイトであるので、アドレス４０ビットのうち第３９ビットから第２０ビットまでの上位２０ビットがタグアドレスとなる。よって、この構成の場合、タグメモリ２２は２２ビット幅８Ｋ（キャッシュメモリサイズ／ブロックサイズ）エントリ分のデータを保持するメモリとなる。タグメモリ２２に格納されている各ブロックの情報は初期状態は、状態はＩ、タグアドレスは任意の値となる。
【００８２】
キャッシュメモリアクセス制御部２３は、ローカルアクセス制御部２５からのアクセス要求に従い、キャッシュメモリ２１にアクセスを行う機能を有する。ローカルアクセス制御部２５からのアクセス要求には、ブロックデータの読み出しおよび書き込み、並びに６４ビットデータの読み出しおよび書き込みがある。
【００８３】
タグメモリアクセス制御部２４は、ローカルアクセス制御部２５からのアクセス要求に従い、タグメモリ２２にアクセスを行う機能を有する。ローカルアクセス制御部２５からのアクセス要求には、１エントリ（ここでは１エントリ２２ビット）分のデータの読み出しおよび書き込みがある。
【００８４】
主メモリアクセス制御部２８は、リクエストバッファ３３、リモートバッファ３４、ホームアクセス制御部２７からのアクセス要求を調停し、受け付けたアクセス要求に従い、主メモリ３０にアクセスを行う機能を有する。リクエストバッファ３３およびリモートバッファ３４からのアクセス要求には、メッセージ情報の読み書き（詳細は後述）がある。ホームアクセス制御部２７からのアクセス要求には、ブロックデータの読み書き、及びメッセージ情報の読み書き（詳細は後述）がある。
【００８５】
ディレクトリメモリアクセス制御部２９は、ホームアクセス制御部２７からのアクセス要求に従い、ディレクトリメモリ３１にアクセスを行う機能を有する。ホームアクセス制御部２７からのアクセス要求には、１エントリ（ここでは１４ビット）分のデータの読み出し及び書き込みがある。
【００８６】
メッセージ送信部３５およびメッセージ受信部３６は、それぞれ相互結合網１０と接続されており、ノードＰＥｉから相互結合網１０へのメッセージの送信、および相互結合網１０からのメッセージの受信を行う。
【００８７】
メッセージ送信部３５は、ローカルアクセス制御部２５およびリモートバッファ３４の２モジュールと接続されており、各モジュールが出力するメッセージを調停し、取り込む。
【００８８】
メッセージ受信部は、リプライバッファ３２、リクエストバッファ３３、ホームアクセス制御部２７の３モジュールと接続しており、相互結合網１０から受け取ったメッセージの種類に応じて前記３モジュールにメッセージを出力する。受け取ったメッセージの種類がＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒ、Ａｃｋ、ＡｃｋＤａｔａの場合、メッセージの出力先はホームアクセス制御部２７となる。ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖの場合、メッセージの出力先はリクエストバッファ３３となる。ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの場合、メッセージの出力先はリプライバッファ３２となる。
【００８９】
ローカルバッファ３８は、プロセッサ２０が発行したメモリアクセスを受けるバッファであり、プロセッサ２０が最大４個のメモリアクセスを同時に発行できるのに対応して４エントリで構成される。各エントリで保持される情報は、アクセスの種類（１ビット）、アドレス（４０ビット）、データ（６４ビット）、ｉｄ（２ビット）の計１０７ビットとなる。
【００９０】
ローカルバッファ３８に貯められたメモリアクセスは、順次ローカルアクセス制御部２５に出力される。出力したメモリアクセスをローカルアクセス制御部２５が受け取ると、当該メモリアクセスを破棄し、次のメモリアクセスを出力する。ただし、出力しようとするメモリアクセスのアドレスが、後述するリクエスト管理テーブル３７に登録されているエントリのアドレスとブロックアドレスで一致する場合（ここでは、第１９ビットから第７ビットまでの１３ビットが一致する場合）には、メモリアクセスの出力は抑止される。このため、ローカルバッファ３８の先頭エントリのアドレスがリクエスト管理テーブル３７に出力される。ローカルバッファ３８は、リクエスト管理テーブル３７がそのアドレスの値を使用して生成したペンディング信号が「１」である場合に、ローカルアクセス制御部２５への出力を抑止する。
【００９１】
リクエスト管理テーブル３７は、プロセッサ２０が同時に発行可能なメモリアクセスの最大数（ここでは４）に対応して４エントリからなるテーブルである。各エントリは、エントリが有効かどうかを示す有効ビット（１ビット）、アクセスの種類（１ビット）、アドレス（４０ビット）、データ（６４ビット）、チェックビット（１ビット）の計１０７ビットからなる。
【００９２】
リクエスト管理テーブル３７は次のような機能を有する。
１）ローカルアクセス制御部２５の指示に従い、ローカルアクセス制御部２５が出力された前記設定データ（１０７ビット）を、ローカルアクセス制御部２５が指定するエントリに書き込む機能。
【００９３】
２）ローカルアクセス制御部２５が指定するエントリの内容をローカルアクセス制御部２５に出力する機能。
【００９４】
３）ローカルバッファ３８が出力するアドレス信号（４０ビット）とエントリの設定データ中のアドレス（４０ビット）との第１９ビットから第７ビットの１３ビットで一致し、かつ有効ビットが「１」のエントリが存在するかどうかをペンディング信号（存在する場合「１」）にして出力する機能。
【００９５】
４）ローカルアクセス制御部２５の指示に従い、ローカルアクセス制御部２５が出力するアドレス信（４０ビット）とエントリのアドレス部（４０ビット）との第３９ビットから第７ビットまでの上位３３ビットが一致し、かつ有効ビットが「１」の場合、該当するエントリのチェックビットを「１」に設定する機能。
【００９６】
リプライバッファ３２は、ホームアクセス制御部２７およびメッセージ受信部３６が出力するメッセージを取り込み貯めておくバッファである。このバッファ３６に書き込まれ得るメッセージはＣｍｐ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘに限られる。これらのメッセージはプロセッサ２０が発行するメモリアクセスに対応してリプライバッファ３２に書き込まれるメッセージであり、１メモリアクセスに対して１メッセージより多く書き込まれることはない。
【００９７】
リプライバッファ３２は、プロセッサ２０が最大４個のメモリアクセスを同時に発行できるのに対応して、４エントリで構成される。各エントリは、６６ビット＋１２８バイトで構成されるブロックデータ付きメッセージを保持することができる。これにより、出力先のローカルアクセス制御部２５がリプライバッファ３２に貯められたメッセージを一つも処理しなくても、リプライバッファ３２に出力されるメッセージを全て取り込むことができるようになっている。
【００９８】
リプライバッファ３２は、受け取ったメッセージを、順にローカルアクセス制御部２５に出力する。出力したメッセージがローカルアクセス制御部２５に受け取られると、リプライバッファ３２は、出力しているメッセージを破棄し、次のメッセージの処理を開始する。
【００９９】
リクエストバッファ３３は、後述するホームアクセス制御部２７およびメッセージ受信部３６が出力するメッセージを貯めておくバッファである。このバッファに書き込まれるメッセージは、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖに限られ、ブロックデータ付きメッセージは存在しない。
【０１００】
リクエストバッファ３３は、デッドロックを回避するため、バッファが一杯になると主メモリ３０に設けたリクエスト退避キューにメッセージ情報を吐出し、必要に応じて吐出したメッセージ情報を読み出す機能を有する。このリクエスト退避キューの各エントリは、ブロックデータ付きでない６６ビットのメモリを保持することができる。また、このリクエスト退避キューは、プロセッサ２０が発行する最大メモリアクセス数４にノード数１０２４を掛け合わせた４０９６エントリからなる。
【０１０１】
リクエストバッファ３３は、リクエスト退避キューにメッセージを退避することにより、出力先のローカルアクセス制御部２５がリクエストバッファ３３に貯められたメッセージを一つも処理しなくても、出力されるメッセージを全て取り込むことができる。リクエストバッファ３３は、受け取ったメッセージを順にローカルアクセス制御部２５に出力する。出力したメッセージがローカルアクセス制御部２５に受け取られると、リクエストバッファ３３は、出力しているメッセージを破棄し、次のメッセージの処理を開始する。
【０１０２】
図４に、リクエストバッファ３３の構成例を示す。
図示するように、リクエストバッファ３３は、セレクタ１０１と、バッファ１０２と、セレクタ１０３と、バッファ１０４とによって構成される。
【０１０３】
ホームアクセス制御部２７およびメッセージ受信部３６から出力するメッセージは、セレクタ１０１で調停選択され、バッファ１０２に書き込まれる。バッファ１０２に書き込まれたメッセージは、バッファ１０４に有効なメッセージが存在する場合、またはその時点で前述のリクエスト退避キューにメッセージが存在する場合、キューに書き込まれる。バッファ１０４およびリクエスト退避キューにメッセージが存在しない場合、バッファ１０４にメッセージが出力されセレクタ１０３により選択され書き込まれる。
【０１０４】
バッファ１０４は、当該バッファに有効なメッセージが存在しない場合、バッファ１０２が出力するメッセージ、あるいはキューから読み出したメッセージをセレクタ１０３で選択して取り込む。キューにメッセージが存在する場合はそのキューからメッセージを取り込み、キューが空でバッファ１０２にメッセージが存在する場合はバッファ１０２が出力するメッセージを取り込む。キューに書き込まれたメッセージ情報は、読み出されるとによりキューから削除される。バッファ１０４は、書き込まれたメッセージをローカルアクセス制御部２５に出力する。
【０１０５】
図２のリモートバッファ３４は、ホームアクセス制御部２７が出力するメッセージ生成情報を貯めておくバッファである。リモートバッファ３４に書き込まれる情報は、メッセージ生成のために必要なメッセージの種類（４ビット）、アドレス（４０ビット）、要求元ノード番号（１０ビット）、ｍｉｄ（２ビット）およびディレクトリメモリ３１に保持されていた保持ノード情報（１０ビット）であり、６６ビットからなる。
【０１０６】
リモートバッファ３４は、リクエストバッファ３３と同様にデッドロックを回避するため、バッファが一杯になると主メモリ３０に設けたリモート退避キューにメッセージ情報を吐出し、必要に応じて吐出したメッセージ情報をリモート退避キューから読み出す機能を有する。このリモート退避キューの各エントリは、上記の６６ビットの情報を保持することができる。また、このリモート退避キューは、プロセッサ２０が発行する最大メモリアクセス数４にノード数１０２４を掛け合わせた４０９６エントリのキューによって構成される。
【０１０７】
リモートバッファ３４は、リモート退避キューにメッセージ情報を退避することにより、出力先のメッセージ送信部３３に一つもメッセージを出力できなくても、リモートバッファ３４に出力されるメッセージ生成情報を取り込むことができる。
【０１０８】
リモートバッファ３４は、また、書き込まれたメッセージ生成情報からメッセージを生成する機能を有し、その際に必要があれば主メモリアクセス制御部２８を介して主メモリ３１からブロックデータの読み出しを行う。リモートバッファ３４は、受け取ったメッセージ生成情報から順にメッセージを生成し、メッセージ送信部３５に出力する。出力したメッセージがメッセージ送信部３５に受け取られると、出力しているメッセージを破棄し、次のメッセージ生成情報の処理を開始する。
【０１０９】
図５に、リモートバッファ３４の構成例を示す。
図示する量に、リモートバッファ３４は、バッファ１１１と、セレクタ１１２と、バッファ１１３と、データバッファ１１５と、メッセージ生成回路１１４とから構成される。
【０１１０】
ホームアクセス制御部２７が出力するメッセージ生成情報はバッファ１１１に書き込まれる。バッファ１１１に書き込まれたメッセージ生成情報は、バッファ１１３に有効なメッセージ生成情報が存在する場合、またはその時点でリモート退避キューにメッセージ生成情報が存在する場合、キューに書き込まれる。バッファ１１３およびキューにメッセージ生成情報が存在しない場合、バッファ１１３にメッセージ生成情報が出力されセレクタ１１２により選択され書き込まれる。
【０１１１】
バッファ１１３は、当該バッファに有効なメッセージ生成情報が存在しない場合、バッファ１１１が出力するメッセージ生成情報、あるいはキューから読み出したメッセージ生成情報をセレクタ１１２で選択して取り込む。キューにメッセージ生成情報が存在する場合はそれを取り込み、キューが空でバッファ１１１にメッセージ生成情報が存在する場合はバッファ１１１が出力するメッセージ生成情報を取り込む。キューに書き込まれたメッセージ生成情報は、読み出されることによりキューから削除される。バッファ１１３にメッセージ生成情報が書き込まれると、メッセージ生成回路１１４は、メッセージを生成し、メッセージ送信部３５に出力する。
【０１１２】
メッセージ生成回路１１４は、メッセージ生成情報のうちメッセージの種類を表すコード（４ビット）に応じて次のような処理をする。
【０１１３】
ここで、メッセージの種類は、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの６種類である。全てのメッセージでメッセージの種類（４ビット）、要求元ノード番号（１０ビット）、アドレス（４０ビット）、ｍｉｄ（２ビット）はメッセージ生成情報としてバッファ１１３に蓄えられたデータがそのまま生成されるメッセージに用いられる。
【０１１４】
メッセージの種類がＩｎｔｖＳｈあるいはＩｎｔｖＥｘの場合、不足している情報は、宛先ノード番号のみである。この場合には、保持ノード情報がそのまま使用される。このとき生成されるメッセージは、このメッセージ一つのみである。
【０１１５】
メッセージの種類がＩｎｖの場合、不足している情報は、宛先ノード番号のみである。この場合は、宛先ノード番号の異なる複数のメッセージを生成する。この宛先ノード番号は、保持ノード情報に従って生成される。保持ノード情報はコースベクタ形式であり、この形式で表されている複数のノードＰＥｉ（要求元ノードを除く）に対して宛先の異なる同一のメッセージを生成し出力することとなる。
【０１１６】
例えば、保持ノード情報が“００１１０１００”で、要求元ノード番号が“００１００１０１１０”の場合、宛先ノードはＰＥ２５６〜ＰＥ３８３、ＰＥ５１２〜ＰＥ８０７の合計３８４ノードとなり、これらの３８４個のノードにＩｎｖメッセージが送信される。また、例えば、保持ノード情報が“１１００１０１１”で、要求元ノード番号が“００１００１０１１０”の場合、宛先ノードはＰＥ０〜ＰＥ１４９、ＰＥ１５１〜ＰＥ２５５、ＰＥ３８４〜ＰＥ５１１、ＰＥ８０８〜ＰＥ１０２３の合計６７９ノードとなり、これらの６７９ノードにＩｎｖメッセージが送信される。
【０１１７】
メッセージの種類がＣｍｐＤａｔＳｈおよびＣｍｐＤａｔＥｘの場合、不足している情報は、宛先ノード番号およびブロックデータである。この場合、宛先ノード番号には、要求元ノード番号がそのまま用いられる。主メモリアクセス制御部２８を介してバッファ１１３から出力されているアドレスに対応するブロックが読み出され、ブロックデータとしてデータバッファ１１５に蓄えられる。メッセージ生成回路１１４は、データバッファ１１５に蓄えられたブロックデータを用いてメッセージを生成し出力する。生成されるメッセージはこのメッセージ一つのみである。
【０１１８】
メッセージ情報がＣｍｐの場合、不足している情報は宛先ノード番号のみである。この場合、宛先ノード番号には、要求元ノード番号が使用される。また、生成されるメッセージは、このメッセージ一つのみである。
【０１１９】
ローカルアクセス制御部２５は、ローカルバッファ３８が出力するメモリアクセス、リプライバッファ３２が出力するメッセージ、およびリクエストバッファ３３が出力するメッセージを調停して選択し、データ一貫性維持のための処理を行う機能を有する。ローカルアクセス制御部２５が行うデータ一貫性維持のための処理には、タグメモリアクセス制御部２４を介したタグメモリ２２へのアクセス、キャッシュメモリアクセス制御部２３を介したキャッシュメモリ２１へのアクセス、リクエスト管理テーブル３７へのアクセス、プロセッサ２０への応答、メッセージ送信部３５あるいはホームアクセス制御部２７へのメッセージの出力がある。
【０１２０】
ホームアクセス制御部２７は、ローカルアクセス制御部２５が出力するメッセージ、およびメッセージ受信部３４が出力するメッセージを受け、データ一貫性維持のための処理を行う機能を有する。ホームアクセス制御部２７が行うデータ一貫性維持のための処理には、ディレクトリアクセス制御部２９を介したディレクトリメモリ３１アクセス、主メモリアクセス制御部２８を介した主メモリ３０アクセス、リプライバッファ３２あるいはリクエストバッファ３３へのメッセージ出力、及びリモートバッファ３４へのメッセージ生成情報の出力がある。
【０１２１】
ホームアクセス制御部２７は、また、主メモリ３０上にメッセージを貯めておくコンフリクトキューを管理制御している。このキューは総プロセッサ数にプロセッサ２０が同時に発行可能なメモリアクセス数をかけたエントリ数を持つ。ここでは、１０２４×４＝４０９６エントリのキューとなる。１つのエントリは、基本メッセージ（６６ビット）を保持することができる。コンフリクトキューにキューイングされるメッセージの種類は、ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、あるいはＵｐｇｒａｄｅの３種に限られる。
【０１２２】
以下、図６〜図１１を参照して、ローカルアクセス制御部２５の動作について説明する。
【０１２３】
なお、以下の説明において、ローカルアクセス制御部２５がキャッシュメモリ２１或いはタグメモリ２２にアクセスする場合は、実際にはキャッシュメモリアクセス制御部２３或いはタグメモリアクセス制御部２４の機能が用いられる。
【０１２４】
図６は、ローカルバッファ３８が出力するメモリアクセスを受け、そのメモリアクセスがロードアクセスであった場合に、ローカルアクセス制御部２５が実行す処理を示すフローチャートである。
【０１２５】
この時、ローカルアクセス制御部３８は、ローカルバッファ３８からアクセスの種類（１ビット）、アドレス（４０ビット）、ｉｄ（２ビット）、データ（６４ビット）の情報を受ける。
【０１２６】
ステップＳ１１１では、ローカルアクセス制御部２５は、タグメモリアクセス制御部２４を利用してタグメモリ２２にアクセスし、該当するブロックのデータ（状態およびタグアドレス）を読み出す。ここでは、８Ｋ（１Ｋ＝１０２４）あるエントリのうち、ローカルバッファ３８から得たアドレスの第１９ビットから第７ビットの１３ビットで指定されるエントリのデータを読み出す。
【０１２７】
ステップＳ１１２では、ローカルアクセス制御部２５は、アクセスの種類、状態、及びアドレスの第３９ビットから第２０ビットまでの上位２０ビットとタグアドレス（２０ビット）が一致するかどうかの３つの情報から、後述するＡＡ〜ＡＤの処理タイプのうちのどの処理タイプとなるかを決定する。
【０１２８】
前記３情報からは、処理タイプがＡＡまたはＡＢの場合にそれぞれステップＳ１１３およびＳ１１５で出力されるメッセージの種類、およびステップＳ１１８で更新されるブロックの状態（タグアドレスはアドレスの上位２０ビットに必ず更新される）も決定される。
【０１２９】
なお、前記３情報と処理タイプ、メッセージの種類、次状態の関係は、図７に示すようになる。ローカルアクセス制御部２５は、この関係を示すテーブルを有している。
【０１３０】
ステップＳ１１２において決定された処理タイプがＡＡの場合、ステップＳ１１３に進む。ステップＳ１１３では、ローカルアクセス制御部２５は、図７に示すテーブルに従って、メッセージを生成し出力する。メッセージの宛先ノード番号（１０ビット）には、アドレスの第３９ビットから第３０ビットまでの上位１０ビットが、要求元ノード番号（１０ビット）には、当該ノードＰＥｉのノード番号（１０ビット）が、それぞれ用いられる。ｍｉｄ、アドレスには、ローカルバッファ３８から得たｉｄ、アドレスが、それぞれ用いられる。この時、ローカルアクセス制御部２５は、生成したメッセージをメッセージ送信部３５へ出力するか、あるいはホームアクセス制御部２７へ出力するかを次のようにして決定する。ローカルアクセス制御部２５は、宛先ノード番号と当該ノードＰＥｉのノード番号とを比較する。この結果が、不一致の場合はメッセージはメッセージ送信部３５へ出力され、一致の場合はメッセージはホームアクセス制御部２７へ出力される。
【０１３１】
ステップＳ１１３では、ローカルアクセス制御部２５は、同時にリクエスト管理テーブル３７への登録も行う。ローカルアクセス制御部２５は、有効ビット「１」、チェックビット「０」、並びに受けたメモリアクセスに付加されていたアクセスの種類、アドレス及びデータを設定データとしてリクエスト管理テーブル３７に出力し、受けたメモリアクセスに付加されていたｉｄ番目が示すエントリ（０〜３）に設定する。ステップＳ１１３の処理が終了すると、ステップＳ１１８に進む。
【０１３２】
ステップＳ１１２において決定された処理タイプがＡＢであった場合、ステップＳ１１４に進む。ステップＳ１１４では、ローカルアクセス制御部２５は、ローカルバッファ３８から得られたアドレスの第１９ビットから第７ビットまでの１３ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した１７ビットで指定される合計１６エントリ、１２８バイトのブロックデータをキャッシュメモリ２１（１２８Ｋエントリ×６４ビット幅）から読み出し、そのブロックデータを付加したＢｌｋＷｒメッセージを生成する。
【０１３３】
このＢｌｋＷｒメッセージの宛先ノード番号には、タグアドレスの第１９ビットから第１０ビットまでの上位１０ビットが用いられ、要求元ノード番号には、当該ノードＰＥｉのノード番号が用いられる。また、アドレスには、タグアドレス（２０ビット）を上位２０ビットとし、下位２０ビットはローカルバッファ３８から得られたアドレスの第１９ビットから第０ビットまでの下位２０ビットとしたものが用いられる。また、ｍｉｄはどんな値でも構わない。ローカルアクセス制御部２５は、生成したメッセージをメッセージ送信部３８とホームアクセス制御部２７とのいずれに出力するかを、ステップＳ１１３の場合と同様に、宛先ノード番号と当該ノード番号との比較結果によって決定する。
【０１３４】
ステップＳ１１４の処理が終了すると、ステップＳ１１５に進む。ステップＳ１１５でローカルアクセス制御部２５が実行する処理は、ステップＳ１１３での処理と同じであるので、説明は省略する。ステップＳ１１５の処理が完了すると、ステップＳ１１８に進む。
【０１３５】
ステップＳ１１２において決定された処理タイプがＡＣであった場合、ステップＳ１１６に進む。ステップＳ１１６では、ローカルアクセス制御部２５は、ローカルバッファ３８から得られたアドレスのうちの第１９ビットから第３ビットまでの１７ビットで指定されるエントリに対応する６４ビットのデータをキャッシュメモリ２１から読み出し、その読み出したデータをプロセッサ２０に応答する。この時、ローカルアクセス制御部２５は、ローカルバッファ３８から得られたｉｄも、同時にプロセッサ２０に渡し、当該ｉｄのメモリアクセスに対する応答であることをプロセッサ２０に示す。ステップＳ１１６の処理が完了すると、ステップＳ１１８に進む。
【０１３６】
ステップＳ１１２において決定された処理タイプがＡＤであった場合、ステップＳ１１７に進む。ステップＳ１１７では、ローカルアクセス制御部２５は、ローカルバッファ３８から得られたアドレスのうちの第１９ビットから第３ビットまでの１７ビットで指定されるキャッシュメモリ２１のエントリに、ローカルバッファ３８から得られた６４ビットのデータを書き込む。また、ローカルアクセス制御部２５は、プロセッサ２０に対してｉｄを出力し、メモリアクセスの完了通知を行う。これにより、当該ｉｄのメモリアクセスに対する処理が完了した旨がプロセッサに通知される。ステップＳ１１７の処理が終わると、ステップＳ１１８に進む。
【０１３７】
ステップＳ１１８では、ローカルアクセス制御部２５は、タグメモリ２２を更新するための処理を行う。更新を行うエントリはステップＳ１１１において指定されたエントリであり、状態は図７で示される次状態に、タグアドレスはローカルバッファ３８から得たアドレスの第３９ビットから第２０ビットまでの上位２０ビットに、更新される。ステップＳ１１８の処理が終了すると、当該メモリアクセスに関する処理は終了する。
【０１３８】
図８は、リクエストバッファ３３が出力するメッセージを受け付けた場合に、ローカルアクセス制御部２５が実行する処理を示すフローチャートである。
【０１３９】
ステップＳ１２１では、ローカルアクセス制御部２５は、メッセージに含まれるアドレスを用いてタグメモリ２２に読み出しアクセスを行う。アクセスされるタグメモリ２２のエントリは、アドレスの第１９ビットから第７ビットまでの１３ビットで指定される。これにより、該当するブロックの状態およびタグアドレスが読み出される。
【０１４０】
ステップＳ１２２では、メッセージの種類、状態、及びメッセージに付加されていたアドレスの第３９ビットから第２０ビットまでの上位２０ビットとタグアドレスが一致するかどうかの３つの情報から、ローカルアクセス制御部２５は、後述するＢＡとＢＢのうちのどの処理タイプとなるかを決定する。また、前記３情報からは、ステップＳ１２３で出力するメッセージの種類、およびステップＳ１２５で更新するブロックの状態（タグアドレスの値は変更されない）も決定される。
【０１４１】
なお、前記３情報と処理タイプ、メッセージの種類、次状態の関係は、図９に示すようになる。ローカルアクセス制御部２５は、この関係を示すテーブルを有している。
【０１４２】
ステップＳ１２２において決定された処理タイプがＢＡであった場合、ステップＳ１２３に進む。ステップＳ１２３では、ローカルアクセス制御部２５は、図９に示すテーブルに従って、メッセージを生成する。メッセージの生成時に、要求元ノード番号、アドレス、ｍｉｄには、受けたメッセージのものがそのまま用いられる。また、宛先ノード番号には、受けたメッセージのアドレスの第３９ビットから第３０ビットまでの上位１０ビットが用いられる。ローカルアクセス制御部２５は、生成したメッセージをメッセージ送信部３８とホームアクセス制御部２７とのいずれに出力するかを、ステップＳ１１３の場合と同様に、宛先ノード番号と当該ノード番号との比較結果によって決定する。ステップＳ１２３の処理が終了すると、ステップＳ１２５に進む。
【０１４３】
ステップＳ１２２において決定された処理タイプがＢＢであった場合、ステップＳ１２４に進む。ステップＳ１２４では、ローカルアクセス制御部２５は、受けたメッセージのアドレスの第１９ビットから第７ビットまでの１３ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した１７ビットで指定される合計１６エントリ、１２８バイトのブロックデータを読み出す。ローカルアクセス制御部２５は、図９のテーブルに従ってメッセージを生成し、読み出したブロックデータを生成されたメッセージに付加し、送信部３５を介して送信する。メッセージの生成時に、要求元ノード番号、アドレス、ｍｉｄには、受けたメッセージのものがそのまま用いられる。宛先ノード番号には、受けたメッセージのアドレスの第３９ビットから第３０ビットまでの上位１０ビットが用いられる。ローカルアクセス制御部２５は、生成したメッセージをメッセージ送信部３８とホームアクセス制御部２７とのいずれに出力するかを、ステップＳ１１３の場合と同様に、宛先ノード番号と当該ノード番号との比較結果によって決定する。ステップＳ１２４の処理が終了すると、ステップＳ１２５に進む。
【０１４４】
ステップＳ１２５では、ローカルアクセス制御部２５は、タグメモリ２２の更新を行う。更新するエントリはステップＳ１２１において指定されたエントリであり、状態は図９で示される次状態に、タグアドレスはステップＳ１２１で読み出したタグアドレスに、それぞれ更新される。
【０１４５】
ローカルアクセス制御部２５は、また、リクエスト管理テーブル３７の検査も行う。受けたメッセージに付加されていたアドレスをリクエスト管理テーブル３７に出力し、同一ブロック（第３９ビット〜第７ビットが一致）のメモリアクセスが登録されていた場合、該当するエントリのチェックビットを「１」に設定する。ステップＳ１２５の処理が終了すると、当該メッセージに関する処理は終了する。
【０１４６】
図１０は、リプライバッファ３２が出力するメッセージを受けつけた場合に、ローカルアクセス制御部２５が実行する処理を示すフローチャートである。
【０１４７】
ここで、リプライバッファ３２から出力されるメッセージの種類は、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの３種類にかぎられる。
【０１４８】
ステップＳ１３１では、ローカルアクセス制御部２５は、まずリプライバッファ３２よりメッセージを受け取り、メッセージに含まれるｍｉｄをリクエスト管理テーブル３７に出力し、ｍｉｄ番目のエントリの情報を読み出す。これにより、リクエスト管理テーブル３７から、有効ビット、アクセスの種類、アドレス、データ（６４ビット）、チェックビットの情報を得る。ステップＳ１３１の処理が終了すると、ステップＳ１３２に進む。
【０１４９】
ステップＳ１３２では、ローカルアクセス制御部２５は、受けたメッセージがデータ付きかどうか、即ちＣｍｐＤａｔＳｈあるいはＣｍｐＤａｔＥｘであるか、データ付きでないＣｍｐメッセージであるかを判定する。
【０１５０】
ステップＳ１３２でデータ付きのメッセージでないと判定された場合は、場合ステップＳ１３３に進む。一方、ステップＳ１３２でデータ付きのメッセージであると判定された場合は、ステップＳ１３５に進む。
【０１５１】
ステップＳ１３３では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られたチェックビットの値を検査する。ステップＳ１３３で検査したチェックビットの値が「１」であった場合は、ステップＳ１３４に進む。一方、ステップＳ１３３で検査したチェックビットの値が「０」であった場合は、ステップＳ１３７に進む。
【０１５２】
ステップＳ１３４では、ローカルアクセス制御部２５は、ＢｌｋＲｄＥｘメッセージを生成し、出力する。この時、要求ノード番号には、リクエスト管理テーブル３７から得たアドレスの第３９ビットから第３０ビットの上位１０ビットが、要求元ノード番号には、当該ノードＰＥｉのノード番号が、ｍｉｄには受けたメッセージのｍｉｄが、アドレスには、リクエスト管理テーブル３７から得たアドレスがそれぞれ用いられる。ローカルアクセス制御部２５は、生成したメッセージをメッセージ送信部３８とホームアクセス制御部２７とのいずれに出力するかを、ステップＳ１１３の場合と同様に、宛先ノード番号と当該ノード番号との比較結果によって決定する。ステップＳ１３４の処理が終了すると、受けたメッセージについての処理は終了する。
【０１５３】
ステップＳ１３５では、ローカルアクセス制御部２５は、メッセージについていたブロックデータ（１２８バイト）を、キャッシュメモリ２１の該当するブロックに書き込む。書き込まれるエントリは、リクエスト管理テーブル３７から得られるアドレスの第１９ビットから第７ビットまでの１３ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した１７ビットのインデックス信号で指定される。ステップＳ１３５の処理が終了すると、ステップＳ１３６に進む。
【０１５４】
ステップＳ１３６では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られるアクセスの種類を検査する。
【０１５５】
ステップＳ１３６で検査されたアクセスの種類がストアであった場合には、ステップＳ１３７に進む。一方、ステップＳ１３６で検査されたアクセスの種類がロードであった場合には、ステップＳ１３８に進む。
【０１５６】
ステップＳ１３７では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られるデータ（６４ビット）を、キャッシュメモリ２１の該当するエントリに書き込む。書き込まれるエントリは、リクエスト管理テーブル３７から得られるアドレスの第１９ビットから第３ビットまでの１７ビットで指定される。
【０１５７】
ローカルアクセス制御部２５は、また、リクエスト管理テーブル３７に有効ビットを「０」にしたデータを出力し、その値を受けたメッセージのｍｉｄで指定するエントリに対して書き込む。これにより、リクエスト管理テーブル３７からエントリが削除される。
【０１５８】
ローカルアクセス制御部２５は、さらにタグメモリ２２を更新するための処理も行う。更新されるエントリのアドレスは、リクエスト管理テーブル３７より得られるアドレスの第１９ビットから第７ビットまでの１３ビットで特定される。更新するデータは、ブロックの状態およびタグアドレスである。ブロックの状態に関しては、アクセスの種類（ここではストア）と受けたメッセージの種類によって決定される。
【０１５９】
アクセスの種類、受けたメッセージの種類、次状態の関係は、図１１に示すようになる。ローカルアクセス制御部２５は、この関係を示すテーブルを有している。ブロックの状態は、図１１のテーブルに従って更新される。タグアドレスには、リクエスト管理テーブル３７から読み出したアドレスの第３９ビットから第２０ビットまでの上位２０ビットが用いられる。
【０１６０】
ローカルアクセス制御部２５は、さらに、プロセッサ２０への完了通知も行う。このとき、メッセージに付加されていたｍｉｄがプロセッサ２０へ出力され、どのメモリアクセスが完了したのかが通知される。ステップＳ１３７の処理が終了すると、受けたメッセージの処理は終了する。
【０１６１】
ステップＳ１３８では、ローカルアクセス制御部２５は、キャッシュメモリ２１からリクエスト管理テーブル３７から得られたアドレスの第１９ビットから第３ビットまでの１７ビットで指定されるエントリの６４ビットデータを読み出す。読み出された６４ビットのデータは、ｍｉｄとともにプロセッサ２０へ渡される。
【０１６２】
ローカルアクセス制御部２５は、また、リクエスト管理テーブル３７の更新およびタグメモリ２２の更新も行う。これらの処理は、いずれもステップＳ１３７におけるそれぞれの処理と同一であり、説明は省略する。ステップＳ１３８の処理が終了すると、受けたメッセージの処理は終了する。
【０１６３】
以下、図１２〜図１６を参照して、ホームアクセス制御部２７の動作について説明する。
【０１６４】
図１２は、ホームアクセス制御部２７が実行する処理を示すフローチャートである。
【０１６５】
なお、以下の説明において、ホームアクセス制御部２７が、主メモリ３０或いはディレクトリメモリ３１にアクセスするときは、実際には主メモリアクセス制御部２８或いはディレクトリメモリアクセス制御部２９の機能が用いられる。
【０１６６】
図１２のフローチャートの処理において、ホームアクセス制御部２７は、受けたメッセージの種類、ディレクトリメモリ３１から読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、及び保持ノード情報と当該ノード番号が一致するかどうかの５つの情報を元に、ステップＳ１４２でディレクトリメモリ３１に格納するブロックの状態および保持ノード情報に対する操作、ステップＳ１４３での処理タイプ、ステップＳ１４４、ステップＳ１４５、ステップＳ１４６で出力するメッセージあるいはメッセージ生成情報のメッセージの種類および出力先のバッファを決定する。
【０１６７】
図１３、図１４は、これらの関係を示すテーブルである。ホームアクセス記憶部２７は、図１３、図１４に示すテーブルを有している。なお、図１３、図１４において“−−”は、いずれの値でも構わないことを示している。
【０１６８】
ホームアクセス記憶部２７は、また、後述するステップＳ１４９でコンフリクトキューから読み出したメッセージの処理なのかそうでないのか、コンフリクトキューが空かどうか、図１３、図１４から求まる処理タイプがＣＤかどうか、の３つの情報を元に、ステップＳ１４２でディレクトリメモリ３１に格納するトップビットの値、ステップＳ１４２でコンフリクトキューの先頭エントリを削除するかどうかを決定する。
【０１６９】
図１５は、これらの関係を示すテーブルである。ホームアクセス記憶部２７は、図１５に示すテーブルを有している。
【０１７０】
図１３、図１４に示すアンキャッシュド情報は、それを求めるための保持ノード情報の形態によって、それぞれ求めかたが異なる。保持ノード情報が、状態がＭやＲＳＰの場合の形態である保持ノード番号であるときは、保持ノード番号が受けたメッセージの要求元ノード番号と一致した場合には、アンキャッシュド情報はＹｅｓとなり、一致しなかった場合には、Ｎｏとなる。
【０１７１】
保持ノード情報が、状態がＲＥＰやＵＰの場合の形態である保持ノード数の場合、保持ノード数から「１」ひいた値が「０」になった場合には、アンキャッシュド情報はＹｅｓとなり、「０」にならなかった場合には、Ｎｏとなる。保持ノード情報が、状態がＣの場合の形態であるコースベクタ形式のときには、コースベクタが８ビットとも「０」の場合には、アンキャッシュド情報はＹｅｓとなり、１ビットでも１が立っている場合には、Ｎｏとなる。この情報は、要求元ノードＰＥｉを除く他のノードＰＥｉがコピーを保持していないかいるかを求めるものである。
【０１７２】
次に、図１３、図１４に示した保持ノード情報に対する操作（図では、「保持ノード操作」と記す）について説明する。保持ノード情報に対する操作として、ｓｅｔ、ａｄｄ、ｃｏｕｎｔ、ｄｅｃ、ｃｌｅａｎ、ｎｏｎｅの６つの操作がある。
【０１７３】
ｓｅｔは、受けたメッセージの要求元ノード番号を保持ノード番号として設定するものである。ａｄｄは、保持ノード番号形式とコースベクタ形式に対して行われる操作である。保持ノード番号形式の場合は読み出した保持ノード番号の上位３ビットをデコードして得られる８ビットを、コースベクタ形式の場合はそのままの８ビットを、要求元ノード番号の上位３ビットをデコードして得られる８ビットと論理和をとって得られる値に設定するものである。
【０１７４】
ｃｏｕｎｔは、保持ノード番号形式あるいはコースベクタ形式に対して行われる操作である。読み出した保持ノード情報から、要求元ノード番号をのぞいて幾つのノードＰＥｉがコピーを保持していることになるかを求める操作である。ｃｏｕｎｔは、保持ノード番号形式の場合は「１」に設定される。コースベクタ形式の場合は、８ビット中１が立っているビットの数と１ビットが表すノードＰＥｉの数１２８とを掛けたもので求められる。ただし、要求元ノード番号に対応するビットが１の場合前記で求めた数から「１」引いた値が設定される。
【０１７５】
ｄｅｃは、保持ノード数形式に対して行われる操作である。ｄｅｃは、読み出した保持ノード数から「１」引いた値に設定するものである。ｃｌｅａｎは、１０ビットをすべて「０」に設定するものである。ｎｏｎｅは、読み出した値に何の操作も加えずにそのまま設定するものである。
【０１７６】
以下、図１２のフローチャートの処理について、説明する。
ステップＳ１４１では、ホームアクセス制御部２７は、該当するディレクトリメモリのエントリのデータ（トップビット、状態、保持ノード情報）を読み出す。読み出されるエントリは、受けたメッセージのアドレスの第２８ビットから第７ビットまでの２２ビットでインデックスされるディレクトリメモリ３１のデータである。
【０１７７】
ステップＳ１４２では、ホームアクセス制御部２７は、ステップＳ１４１で読み出したディレクトリメモリ３１のエントリの値を更新する。状態は、図１３、図１４に示すテーブルに従って決定される。保持ノード情報は、図１３、図１４に示した操作がステップＳ１４１で読み出した保持ノード情報に対して行われ求められる。トップビットは、図１５に示すテーブルに従って決定される。ステップＳ１４２で更新するエントリは、ステップＳ１４１でアクセスしたエントリと同一のエントリである。
【０１７８】
ステップＳ１４２では、ホームアクセス制御部２７は、データ付きのメッセージであれば主メモリ３０へブロックデータを書き込む処理も行う。ブロックデータが書き込まれる主メモリ３０のエントリは、受けたメッセージのアドレスの第２８ビットから第７ビットまでの２２ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した２６ビットで指定される合計１６エントリ（１２８バイト）である。ステップＳ１４２の処理が終了すると、ステップＳ１４３に進む。
【０１７９】
ステップＳ１４３では、ホームアクセス制御部２７は、ディレクトリメモリ３１から読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、保持ノード情報と当該ノード番号が一致するかどうか、の５つの情報から処理タイプがＣＡ〜ＣＥのいずれになるかを判定する。
【０１８０】
ステップＳ１４３で処理タイプがＣＡであると判定された場合には、ステップＳ１４４に進む。ステップＳ１４３で処理タイプがＣＢであると判定された場合には、ステップＳ１４５に進む。ステップＳ１４３で処理タイプがＣＣであると判定された場合には、ステップＳ１４６に進む。ステップＳ１４３で処理タイプがＣＤであると判定された場合には、ステップＳ１４７に進む。ステップＳ１４３で処理タイプがＣＥであると判定された場合には、ステップＳ１４８に進む。
【０１８１】
ステップＳ１４４では、ホームアクセス制御部２７は、メッセージ生成情報を生成し、リモートバッファ３４に出力する。出力されるメッセージ生成情報（メッセージの種類、アドレス、ｍｉｄ、要求元ノード番号、保持ノード情報）は、次のようにして生成される。メッセージの種類は、図１３、図１４で求められるメッセージの種類となる。アドレス、ｍｉｄ、要求元ノード番号は、それぞれ受けたメッセージのアドレスとｍｉｄと要求元ノード番号となる。保持ノード情報（メッセージ生成情報の場合）は、ステップＳ１４１で読み出した値となる。ステップＳ１４４の処理が終了すると、ステップＳ１４８に進む。
【０１８２】
ステップＳ１４５では、ホームアクセス制御部２７は、主メモリ３０（６４Ｍエントリ×６４ビット幅）から該当するブロックデータ（１２８バイト）を読み出す。読み出されるブロックデータは、受けたメッセージのアドレスの第２８ビットから第７ビットまでの２２ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した２６ビットで指定される合計１６エントリで、１２８バイトで構成される。このブロックデータは、生成されるメッセージに付加され、リプライバッファ３２に出力される。宛先ノード番号は、要求元ノード番号となる。メッセージの種類は、図１３、図１４から求められる。アドレス、ｍｉｄ、要求元ノード番号については、受けたメッセージに付加されていたアドレス、ｍｉｄ、要求元ノード番号を使用する。ステップＳ１４５の処理が終了すると、ステップＳ１４８に進む。
【０１８３】
ステップＳ１４７では、ホームアクセス制御部２７は、受けたメッセージを主メモリ３０に設けたキューの最後に書き込む。ただし、処理しているメッセージがステップＳ１４９でコンフリクトキューから読み出したメッセージの場合には、ステップＳ１４７では何もしないで、ステップＳ１４８に進む。ここで、書き込まれるメッセージは、ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅに限られる。キューに書き込まれる情報は、メッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（２ビット）、要求元ノード番号（１０ビット）の計５６ビットで構成される。ステップＳ１４７の処理が終了すると、ステップＳ１４８に進む。
【０１８４】
ステップＳ１４８では、ホームアクセス制御部２７は、主メモリ３０のキューからメッセージを読み出す必要があるかどうかを判定する。ここで、キューからメッセージを読み出す必要があるかどうかは、後述するステップＳ１４９で読み出したメッセージの処理であったかどうか、また処理したメッセージの種類、コンフリクトキューが空かどうか、また処理したメッセージの処理タイプが何であったか、及びステップＳ１４１で読み出したトップビットの値が何であったか５つの情報を元に決定される。
【０１８５】
前記５つの情報と、決定されるキューの読み出しとの関係を図１６に示す。ホームアクセス制御部２７は、図１６に示すテーブルを有している。
【０１８６】
ステップＳ１４８でキューからメッセージを読み出す必要があると判定された場合には、ステップＳ１４９に進む。ステップＳ１４８でキューからメッセージを読み出す必要がないと判定された場合には、図１２のフローチャートの処理を終了する。
【０１８７】
ステップＳ１４９では、ホームアクセス制御部２７は、主メモリ３０に設けれらたコンフリクトキューの先頭のメッセージを読み出す。ここでは、メッセージを読み出すだけであり、キューからのメッセージの削除は行われない。ステップＳ１４９の処理が終わると、ステップＳ１４１に戻り、ローカルアクセス制御部２５やメッセージ受信部３５から受けたメッセージを処理した場合と同様に、キューから読み出したメッセージが処理されていく。なお、キューからの先頭のメッセージの削除は、前述した通り、ステップＳ１４２において行われる。
【０１８８】
以下、この実施の形態にかかるマルチプロセッサシステムの動作について、具体例を示して説明する。
【０１８９】
この例では、ノードＰＥｉ（ｉ＝０〜１０２３）において、次のようにしてメモリアクセスが行われた場合の動作を示す。
【０１９０】
最初ノードＰＥ１で、ロードアクセスがｉｄ＝０でアドレス０ｘ００４００３００００に行われる。次いで、ノードＰＥ１で、ストアアクセスがｉｄ＝１でアドレス０ｘ００４００３００００に行われる。次いで、ノードＰＥ２で、ロードアクセスがｉｄ＝２でアドレス０ｘ００４００３００００に行われる。次いで、ノードＰＥ５で、ストアアクセスがｉｄ＝３でアドレス０ｘ００４００３０００８に行われる。次いで、ノードＰＥ１２８で、ロードアクセスがｉｄ＝０でアドレス０ｘ００４００３００２０に行われる。次いで、ノードＰＥ２でストアアクセスがｉｄ＝１でアドレス０ｘ００４００３００１０に行われる。
【０１９１】
（フェーズ１）
ノードＰＥ１のプロセッサ２０がアドレス０ｘ００４００３００００にｉｄ＝０でロードアクセスを行ったとする。
【０１９２】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。リクエスト管理テーブル３７は、検査した結果をペンディング信号にして出力する（１の場合、同一キャッシュブロックに対するリクエストが存在することを示す）。ローカルバッファ３８は、ペンディング信号が１の場合ローカルリクエスト制御部２５への出力を行わず、ペンディング信号が０になるのを待って、ローカルアクセス制御部２５に出力する。
【０１９３】
前記メモリアクセス（アクセスの種類はロード、アドレスは０ｘ００４００３００００、ｉｄ＝０）を受けたローカルアクセス制御部２５は、次のように動作する。まず、タグメモリ２２の０ｘ０６００番地（ローカルバッファから得たアドレス０ｘ００４００３００００の第１９ビット〜第７ビットの１３ビット）のデータを読み出す。初期の状態はＩであるため、図７より処理タイプはＡＡ、発行するメッセージはＢｌｋＲｄＳｈ、次状態はＩに決定する（ステップＳ１１１）。
【０１９４】
処理タイプがＡＡであることから（ステップＳ１１２）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。生成出力するメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１となる。また、宛先ノード番号と要求元ノード番号が両者とも０ｘ００１と一致するので、出力先は当該ノードＰＥ１のホームアクセス制御部２７となる。また、リクエスト管理テーブルの０（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はロード、アドレスは０ｘ００４００３００００というデータを書き込む（ステップＳ１１３）。
【０１９５】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＩに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ロードアクセスの処理を終了する。
【０１９６】
前記ＢｌｋＲｄＳｈメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１）を受けたホームアクセス制御部２７は次のように動作する。まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれ初期状態の０、Ｃ、０ｘ０００である。受けたメッセージの種類がＢｌｋＲｄＳｈであり、読み出した状態がＣ、保持ノード情報が０ｘ０００でりアンキャッシュドであること、要求元ノード番号と当該ノード番号が一致することから、処理タイプはＣＢ、次状態はＭ、保持ノード操作はｓｅｔ、出力するメッセージの種類はＣｍｐＤａｔＥｘ、出力先はリプライバッファ３２に決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０１９７】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＭ、保持ノード情報は０ｘ００１に更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込を行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０１９８】
処理タイプがＣＢであることから（ステップＳ１４３）、主メモリ３０の０ｘ０００６０００番地〜０ｘ０００６００ｆ番地までの６４ビット×１６エントリ＝１２８バイトのブロックデータを読み出し、生成するメッセージに付加しリプライバッファ３２に出力する。このメッセージは、宛先ノード番号を０ｘ００１、メッセージの種類をＣｍｐＤａｔＥｘ、アドレスを０ｘ００４００３００００、ｍｉｄを「０」、要求元ノード番号を０ｘ００１、ブロックデータを当該ステップＳ１４５で読み出したブロックデータとするメッセージである（ステップＳ１４５）。
【０１９９】
メッセージの生成出力を終えると、コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＢｌｋＲｄＳｈであるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＳｈメッセージの処理を終了する。
【０２００】
ホームアクセス制御部２７が出力した前記ＣｍｐＤａｔＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１）を受たリプライバッファ３２は、その情報をそのままローカルアクセス制御部２５に出力する。
【０２０１】
ＣｍｐＤａｔＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の０（＝ｍｉｄ）番エントリの情報を読みだし、アクセスの種類はロード、アドレスは０ｘ００４００３００００、チェックビットは「０」という情報を得る（ステップＳ１３１）。
【０２０２】
ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０２０３】
アクセスタイプがロードであることから（ステップＳ１３６）、キャッシュメモリ２１から０ｘ０６０００番地の６４ビットデータを読み出し、プロセッサ２０に対してｉｄ＝０のメモリアクセスに対する応答データとして渡す。また、リクエスト管理テーブルの０番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリの０ｘ０６００番地の状態およびタグアドレスを、それぞれＥおよび０ｘ００４００に更新する（ステップＳ１３８）。以上でローカルアクセス制御部２５は、ＣｍｐＤａｔＥｘメッセージの処理を終了する。
【０２０４】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１の主メモリ３０およびノードＰＥ１のキャッシュメモリ２１に存在する状態となる。
【０２０５】
（フェーズ２）
次いで、ノードＰＥ１で、ストアアクセスがｉｄ＝１でアドレス０ｘ００４００３００００に行われたとする。
【０２０６】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。リクエスト管理テーブル３７は検査した結果をペンディング信号にして出力する（「１」の場合、同一キャッシュブロックに対するリクエストが存在することを示す）。
【０２０７】
フェーズ１で処理していたロードアクセスがまだ終了していなかった場合、ペンディング信号は「１」となり、ローカルバッファ３８はローカルリクエスト制御部２５へ受けたメモリアクセスを出力しない。フェーズ１の処理が完了し、リクエスト管理テーブル３７からロードアクセスのエントリが削除されると出力を開始する。
【０２０８】
フェーズ１のロードアクセスの処理を終了し、前記ストアアクセス（アクセスの種類はストア、アドレスは０ｘ００４００３００００、ｉｄ＝１）を受けたローカルアクセス制御部２５は、次のように動作する。まず、タグメモリ２２の０ｘ０６００番地（ローカルバッファから得たアドレス０ｘ００４００３００００の第１９ビット〜第７ビットの１３ビット）のデータを読み出す。フェーズ１において状態はＥ、タグアドレスは０ｘ００４００に更新されており、その値が読み出される。アクセスの種類がストアであり、タグアドレスが一致し、状態がＥであることから、処理タイプはＡＤ、次状態はＤに決定する（ステップＳ１１１）。
【０２０９】
処理タイプがＡＤであることから（ステップＳ１１２）、キャッシュメモリ２１の０ｘ０６０００番地のデータ６４ビットを、受けたストアアクセスのデータに更新する処理を行う。まだ同時に、プロセッサへｉｄを出力し、ｉｄ＝１のメモリアクセスが完了した旨をプロセッサ２０に通知する（ステップＳ１１７）。
【０２１０】
タグメモリ２２の０ｘ０６００番地のデータを、状態はＤ、タグアドレスは０ｘ００４００に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ストアアクセスの処理を終了する。
【０２１１】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１にのみ存在する状態となる。
【０２１２】
（フェーズ３）
次いで、ノードＰＥ２で、ロードアクセスがｉｄ＝２でアドレス０ｘ００４００３００００に行われたとする。
【０２１３】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。存在しなければローカルアクセス制御部２５に対して出力する。
【０２１４】
前記メモリアクセス（アクセスの種類はロード、アドレスは０ｘ００４００３００００、ｉｄ＝２）を受けたローカルアクセス制御部２５はまず、タグメモリ２２の０ｘ０６００番地のデータを読み出す（ステップＳ１１１）。初期の状態はＩであるため、図７より処理タイプはＡＡ、発行するメッセージはＢｌｋＲｄＳｈ、次状態はＩに決定する。
【０２１５】
処理タイプがＡＡであることから（ステップＳ１１２）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。生成出力するメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２となる。また、宛先ノード番号と要求元ノード番号が異なるので、出力先はメッセージ送信部３５となる。また、この時リクエスト管理テーブルの２（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はロード、アドレスは０ｘ００４００３００００というデータを書き込む（ステップＳ１１３）。
【０２１６】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＩに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ロードアクセスの処理を終了する。
【０２１７】
ＢｌｋＲｄＳｈメッセージは、ノードＰＥ２のメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られる。
【０２１８】
前記ＢｌｋＲｄＳｈメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２）を受けたホームアクセス制御部２７は次のように動作する。
【０２１９】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ１において、トップビット、状態、保持ノード情報はそれぞれ０、Ｍ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類はＢｌｋＲｄＳｈであり、読み出した状態はＭ、保持ノード情報は０ｘ００１でありアンキャッシュドでないこと、保持ノード情報０ｘ００１と当該ノード番号０ｘ００１は一致することから、処理タイプはＣＣ、次状態はＲＳＰ、保持ノード操作はｎｏｎｅ、出力するメッセージの種類はＩｎｔｖＳｈ、出力先はリクエストバッファ３３に決定する。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２２０】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＲＳＰ、保持ノード情報は０ｘ００１に更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込を行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０２２１】
処理タイプがＣＣであることから（ステップＳ１４３）、宛先ノード番号を０ｘ００１、メッセージの種類をＩｎｔｖＳｈ、アドレスを０ｘ００４００３００００、ｍｉｄを「２」、要求元ノード番号を０ｘ００２、とするメッセージを生成し、リクエストバッファ３３に出力する（ステップＳ１４６）。
【０２２２】
メッセージの生成出力を終えると、コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＢｌｋＲｄＳｈであるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＳｈメッセージの処理を終了する。
【０２２３】
ＩｎｔｖＳｈメッセージはリクエストバッファ３３を介してローカルアクセス制御部２５に出力される。
【０２２４】
ＩｎｔｖＳｈメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＩｎｔｖＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２）を受けたローカルアクセス制御部２５は、タグメモリ２２の０ｘ０６００番地のデータを読みだす。フェーズ２において、状態及びタグアドレスはそれぞれＤ及び０ｘ００４００に更新されており、この値が読み出される。受けたメッセージがＩｎｔｖＳｈであり、タグアドレスが一致し、状態がＤであることから、処理タイプはＢＢ、出力するメッセージの種類はＡｃｋＤａｔａ、次状態はＳに決定する（ステップＳ１２１）。
【０２２５】
処理タイプがＢＢであることから（ステップＳ１２２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地までの６４ビット×１６エントリ＝１２８バイトのブロックデータを読み出し、生成するＡｃｋＤａｔａメッセージに付加する。生成するＡｃｋＤａｔａメッセージの、宛先ノード番号は０ｘ００１、メッセージの種類はＡｃｋＤａｔａ、アドレスは０ｘ００４００３００００、要求元ノード番号は０ｘ００２、ｍｉｄは「２」、ブロックデータはキャッシュメモリ２１から読み出したデータとなる。宛先ノード番号０ｘ００１と当該ノードＰＥ１のノード番号０ｘ００１が一致することから出力先はホームアクセス制御部２７となる（ステップＳ１２４）。
【０２２６】
タグメモリの０ｘ０６００番地の状態およびタグアドレスを、それぞれＳおよび０ｘ００４００に更新する。また、リクエスト管理テーブル３７へ、受けたメッセージのアドレス（０ｘ００４００３００００）を出力する。リクエスト管理テーブル３７では、各エントリのアドレスと、ローカルアクセス制御部２５が出力するアドレスの、第３９ビット〜第７ビットが一致するかどうかを検査し、一致するエントリのチェックビットを「１」に更新する（ステップＳ１２５）。以上でローカルアクセス制御部２５は、ＩｎｔｖＳｈメッセージの処理を終了する。
【０２２７】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１に存在し、その最新のデータが付加されたＡｃｋＤａｔａメッセージがノードＰＥ１のホームアクセス制御部２７に出力されている状態となる。
【０２２８】
（フェーズ４）
この時、ノードＰＥ５で、ストアアクセスがｉｄ＝３でアドレス０ｘ００４００３０００８に行われていたとする。
【０２２９】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。存在しなければローカルアクセス制御部２５に対して出力する。
【０２３０】
前記メモリアクセス（アクセスの種類はストア、アドレスは０ｘ００４００３０００８、ｉｄ＝３）を受けたローカルアクセス制御部２５は、まず、タグメモリ２２の０ｘ０６００番地のデータを読み出す。初期の状態はＩであるため、図７より処理タイプはＡＡ、発行するメッセージはＢｌｋＲｄＥｘ、次状態はＩに決定する（ステップＳ１１１）。
【０２３１】
処理タイプがＡＡであることから（ステップＳ１１２）（ステップＳ１１３）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。発行されるメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３０００８の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５となる。また、宛先ノード番号と要求元ノード番号が異なるので、出力先はメッセージ送信部３５となる。また、この時リクエスト管理テーブルの３（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はストア、アドレスは０ｘ００４００３０００８、及びストアデータを書き込む（ステップＳ１１３）。
【０２３２】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＩに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３０００８の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ストアアクセスの処理を終了する。
【０２３３】
ＢｌｋＲｄＥｘメッセージは、ノードＰＥ５のメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られる。ホームアクセス制御部２７において、このＢｌｋＲｄＥｘメッセージが、フェーズ３の最後でノードＰＥ１のローカルアクセス制御部２５がホームアクセス制御部に２７に出力しているＡｃｋＤａｔａメッセージよりも先に処理されたとする。
【０２３４】
前記ＢｌｋＲｄＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５）を受けたホームアクセス制御部２７は次のように動作する。
【０２３５】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ３において、トップビット、状態、保持ノード情報はそれぞれ０、ＲＳＰ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類がＢｌｋＲｄＥｘであり、読み出した状態がＲＳＰであることから、処理タイプはＣＤ、次状態はＲＳＰ、保持ノード操作はｎｏｎｅに決定される。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤであることから、トップビットは「１」に更新し、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２３６】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＲＳＰ、保持ノード情報は０ｘ００１に更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込は行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０２３７】
処理タイプがＣＤであり（ステップＳ１４３）、ステップＳ１４９でキューから読み出したメッセージの処理ではないので、コンフリクトキューにメッセージ情報（メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３０００８、要求元ノード番号は０ｘ００５、ｍｉｄは「３」）を書き込む。キューは空であったためこのメッセージがキューの先頭となる（ステップＳ１４７）。
【０２３８】
コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＢｌｋＲｄＥｘであるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＥｘメッセージの処理を終了する。
【０２３９】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１に存在し、その最新のデータが付加されたＡｃｋＤａｔａメッセージがノードＰＥ１のホームアクセス制御部２７に出力されている状態となる。
【０２４０】
（フェーズ５）
その後、ホームアクセス制御部２７は、ローカルアクセス制御部２５からＡｃｋＤａｔａメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＡｃｋＤａｔａ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２、ブロックデータは最新のデータ）を受け、次のように動作する。
【０２４１】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれフェーズ４で１、ＲＳＰ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋＤａｔａであり、読み出した状態がＲＳＰ、要求元ノード番号０ｘ００２と当該ノード番号０ｘ００１が一致しないことから、処理タイプはＣＡ、次状態はＣ、保持ノード操作はａｄｄ、出力するメッセージの種類はＣｍｐＤａｔＳｈ、出力先はリモートバッファ３４に決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空でないことから、トップビットは読み出した値「１」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２４２】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＣ、保持ノード情報は０ｘ００１に更新する。また、この時受けたメッセージがブロックデータ付きのＡｃｋＤａｔａメッセージであることから主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地に、付加されていたブロックデータを書き込む。これにより、主メモリ３０に最新のデータが存在する状態となる。コンフリクトキューの先頭エントリの削除は行わない（ステップＳ１４２）。
【０２４３】
処理タイプがＣＡであることから（ステップＳ１４３）、ＣｍｐＤａｔＳｈメッセージ生成情報を生成し、リモートバッファ３４に出力する。このメッセージ生成情報は、メッセージの種類をＣｍｐＤａｔＳｈ、アドレスを０ｘ００４００３００００、ｍｉｄを「２」、要求元ノード番号を０ｘ００２、保持ノード情報を０ｘ００１とする（ステップＳ１４４）。
【０２４４】
メッセージ生成情報の出力を終えると、コンフリクトキューからの読み出が必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＡｃｋＤａｔａであり、ステップＳ１４１で読み出したトップビットの値は「１」であることから、コンフリクトキューからの読み出しを行う（ステップＳ１４９）。
【０２４５】
読み出されるメッセージはフェーズ４でコンフリクトキューに書き込まれた、ＢｌｋＲｄＥｘメッセージ（メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３０００８、要求元ノード番号は０ｘ００５、ｍｉｄは「３」）である。以上で、ホームアクセス制御部２７は、ＡｃｋＤａｔａメッセージの処理を終了し、コンフリクトキューから読み出したＢｌｋＲｄＥｘメッセージの処理を開始する。
【０２４６】
ホームアクセス制御部２７がステップＳ１４９で読み出したＢｌｋＲｄＥｘメッセージの処理の説明は次のフェーズ６で行う。ここでは、ステップＳ１４４でリモートバッファ３４に出力されたＣｍｐＤａｔＳｈメッセージ生成情報について説明する。
【０２４７】
前記ＣｍｐＤａｔＳｈメッセージ生成情報（メッセージの種類はＣｍｐＤａｔＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２、保持ノード情報は０ｘ００１）を受けたリモートバッファ３４は、主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地までの１２８バイトのデータを読み出し、宛先ノード番号を０ｘ００２、メッセージの種類をＣｍｐＤａｔＳｈ、アドレスを０ｘ００４００３００００、ｍｉｄを「２」、要求元ノード番号を０ｘ００２、ブロックデータを主メモリ３０から読み出したブロックデータとするメッセージを生成し、メッセージ送信部３５へ出力する。このブロックデータは最新のデータである。
【０２４８】
このＣｍｐＤａｔＳｈメッセージは、ノードＰＥ１のメッセージ送信部３５、相互結合網１０、ノードＰＥ２のメッセージ受信部３６、ノードＰＥ２にのリプライバッファ３２を介して、ノードＰＥ２のローカルバッファ２５に出力される。
【０２４９】
前記ＣｍｐＤａｔＳｈメッセージ（宛先ノード番号は０ｘ００２、メッセージの種類はＣｍｐＤａｔＳｈ、アドレスは０ｘ００４００３００００、ｍｉｄは「２」、要求元ノード番号は０ｘ００２、ブロックデータは最新のデータ）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の２（＝ｍｉｄ）番エントリの情報を読みだし、アクセスの種類はロード、アドレスは０ｘ００４００３００００、チェックビットは「０」という情報を得る（ステップＳ１３１）。
【０２５０】
ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０２５１】
そして、アクセスタイプがロードであることから（ステップＳ１３６）、キャッシュメモリ２１から０ｘ０６０００番地の６４ビットデータを読み出し、プロセッサ２０に対してｉｄ＝２のメモリアクセスに対する応答データとして渡す。また、リクエスト管理テーブルの２番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリの０ｘ０６００番地の状態およびタグアドレスを、それぞれＳおよび０ｘ００４００に更新する（ステップＳ１３８）。以上でローカルアクセス制御部２５は、ＣｍｐＤａｔＳｈメッセージの処理を終了する。
【０２５２】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ２のキャッシュメモリ２１に存在する状態になる。
【０２５３】
（フェーズ６）
フェーズ５において、ノードＰＥ１のホームアクセス制御部２７は同ノードのローカルアクセス制御部２５が出力するＡｃｋＤａｔａメッセージを受けそれを処理した。その処理において、コンフリクトキューからのメッセージ情報の読み出しが必要と判断し（ステップＳ１４８）、主メモリ３０をアクセスし、ＢｌｋＲｄＥｘメッセージ（メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３０００８、要求元ノード番号は０ｘ００５、ｍｉｄは「３」）を読み出した（ステップＳ１４９）。ここでは、このＢｌｋＲｄＥｘメッセージを読み出したホームアクセス制御部２７の動作を説明する。
【０２５４】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３０００８の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ５において、トップビット、状態、保持ノード情報はそれぞれ１、Ｃ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類がＢｌｋＲｄＥｘであり、読み出した状態がＣであり、保持ノード情報が０ｘ００１でアンキャッシュドではないことことから、処理タイプはＣＡ、次状態はＲＥＰ、保持ノード操作はｃｏｕｎｔ、出力するメッセージの種類はＩｎｖ、出力先はリモートバッファ３４に決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理であり、処理タイプがＣＤでないことから、トップビットは「０」に更新し、また、コンフリクトキューの先頭エントリの削除を行うことが決定する（図１５参照）（ステップＳ１４１）。
【０２５５】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＲＥＰ、保持ノード情報は０ｘ０７ｆに更新する。処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。コンフリクトキューの先頭エントリの削除は行い、読み出したＢｌｋＲｄＥｘメッセージのエントリを削除する。これにより、コンフリクトキューは空となる（ステップＳ１４２）。
【０２５６】
処理タイプがＣＡであるので（ステップＳ１４３）、メッセージ生成情報を生成しリモートバッファ３４に出力する。メッセージ生成情報は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３０００８、ｍｉｄを「３」、要求元ノード番号を０ｘ００５、保持ノード情報を０ｘ００１とする（ステップＳ１４４）。
【０２５７】
さらにコンフリクトキューから情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理であり、コンフリクトキューが空であることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、コンフリクトキューから読み出したＢｌｋＲｄＥｘメッセージの処理を終了する。
【０２５８】
前記Ｉｎｖメッセージ生成情報（種類はＩｎｖ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５、保持ノード情報は０ｘ００１）を受け取ったリモートバッファ３４は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３０００８、ｍｉｄを「３」、要求元ノード番号を０ｘ００５とし、宛先ノード番号が０ｘ０００〜０ｘ０７ｆの内０ｘ００５を除いたものとする１２７個のメッセージを順次生成しメッセージ送信部３５に出力する。
【０２５９】
これらのＩｎｖメッセージはノードＰＥ１のメッセージ送信部３５、相互結合網１０、各ノードＰＥ０〜ＰＥ１２７（ＰＥ５除く）のメッセージ受信部３６、リクエストバッファ３３を介してローカルアクセス制御部２５に出力される。
【０２６０】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ２のキャッシュメモリ２１に存在する状態である。
【０２６１】
（フェーズ７）
この時、ノードＰＥ１２８で、ロードアクセスがｉｄ＝０でアドレス０ｘ００４００３００２０に行われていたとする。
【０２６２】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。存在しなければローカルアクセス制御部２５に対して出力する。
【０２６３】
前記メモリアクセス（アクセスの種類はロード、アドレスは０ｘ００４００３００２０、ｉｄ＝０）を受けたローカルアクセス制御部２５は、まず、タグメモリ２２の０ｘ０６００番地のデータを読み出す。初期の状態はＩであるため、図７より処理タイプはＡＡ、発行するメッセージはＢｌｋＲｄＳｈ、次状態はＩに決定する（ステップＳ１１１）。
【０２６４】
処理タイプがＡＡであることから（ステップＳ１１２）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。生成出力するメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０となる。また、宛先ノード番号と要求元ノード番号が異なるので、出力先はメッセージ送信部３５となる。また、この時リクエスト管理テーブルの０（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はロード、アドレスは０ｘ００４００３００２０というデータを書き込む（ステップＳ１１３）。
【０２６５】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＩに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ロードアクセスの処理を終了する。
【０２６６】
ＢｌｋＲｄＳｈメッセージは、ノードＰＥ１２８のメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られる。
【０２６７】
前記ＢｌｋＲｄＳｈメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０）を受けたホームアクセス制御部２７は次のように動作する。
【０２６８】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００２０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ６において、トップビット、状態、保持ノード情報はそれぞれ０、ＲＥＰ、０ｘ０７ｆに更新されており、その値が読み出される。受けたメッセージの種類がＢｌｋＲｄＳｈであり、読み出した状態がＲＥＰであることから、処理タイプはＣＤ、次状態はＲＥＰ、保持ノード操作はｎｏｎｅに決定される（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤであることから、トップビットは「１」に更新し、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２６９】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＲＥＰ、保持ノード情報は０ｘ０７ｆに更新する。また、処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０２７０】
処理タイプがＣＤであり（ステップＳ１４３）、ステップＳ１４９でキューから読み出したメッセージの処理ではないので、コンフリクトキューにメッセージ情報（メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００２０、要求元ノード番号は０ｘ０８０、ｍｉｄは「０」）を書き込む。キューは空であったためこのメッセージがキューの先頭となる（ステップＳ１４７）。
【０２７１】
コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージの種類がＢｌｋＲｄＳｈであることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＳｈメッセージの処理を終了する。
【０２７２】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ２のキャッシュメモリ２１に存在する状態である。
【０２７３】
（フェーズ８）
またこの時ノードＰＥ２で、ストアアクセスがｉｄ＝１でアドレス０ｘ００４００３００１０に行われていたとする。
【０２７４】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。存在しなければローカルアクセス制御部２５に対して出力する。
【０２７５】
前記メモリアクセス（アクセスの種類はストア、アドレスは０ｘ００４００３００１０、ｉｄ＝１）を受けたローカルアクセス制御部２５はまず、タグメモリ２２の０ｘ０６００番地のデータを読み出す。フェーズ５において状態はＳ、タグアドレスは０ｘ００４００に更新されており、その値が読み出される。アクセスの種類はストアであり、タグアドレスは０ｘ００４００で一致、状態はＳであるため、処理タイプはＡＡ、出力するメッセージの種類はＵｐｇｒａｄｅ、次状態はＳに決定する（図７参照）（ステップＳ１１１）。
【０２７６】
処理タイプがＡＡであることから（ステップＳ１１２）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。生成出力するメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００１０の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２となる。また、宛先ノード番号と要求元ノード番号が異なるので、出力先はメッセージ送信部３５となる。また、この時リクエスト管理テーブルの１（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はストア、アドレスは０ｘ００４００３００１０、及びストアデータを書き込む（ステップＳ１１３）。
【０２７７】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＳに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００１０の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。
【０２７８】
Ｕｐｇｒａｄｅメッセージは、ノードＰＥ２のメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られる。
【０２７９】
前記Ｕｐｇｒａｄｅメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２）を受けたホームアクセス制御部２７は次のように動作する。
【０２８０】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ７において、トップビット、状態、保持ノード情報はそれぞれ１、ＲＥＰ、０ｘ０７ｆに更新されており、その値が読み出される。受けたメッセージの種類がＵｐｇｒａｄｅであり、読み出した状態がＲＥＰであることから、処理タイプはＣＤ、次状態はＲＥＰ、保持ノード操作はｎｏｎｅに決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空でないことから、トップビットは読み出した値「１」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２８１】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＲＥＰ、保持ノード情報は０ｘ０７ｆに更新する。また、処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わず、また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４３）。
【０２８２】
処理タイプがＣＤであり（ステップＳ１４３）、ステップＳ１４９でキューから読み出したメッセージの処理ではないので、コンフリクトキューにメッセージ情報（メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、要求元ノード番号は０ｘ００２、ｍｉｄは「１」）を書き込む（ステップＳ１４７）。
【０２８３】
コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、ステップＳ１４９でコンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージの種類がＵｐｇｒａｄｅであることから、コンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ｕｐｇｒａｄｅメッセージの処理を終了する。
【０２８４】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ２のキャッシュメモリ２１に存在する状態である。
【０２８５】
（フェーズ９）
フェーズ６でノードＰＥ１から送信された１２７個のＩｎｖメッセージ（宛先ノードは０ｘ０００〜０ｘ０７ｆで０ｘ００５を除いたもの、種類はＩｎｖ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５）は、相互結合網１０、各宛先ノードのメッセージ受信部３６、リクエストバッファ３３を介してローカルアクセス制御部２５に出力される。
【０２８６】
Ｉｎｖメッセージを受けたローカルアクセス制御部２５は、タグメモリ２２の０ｘ０６００番地のデータを読み出す。読み出したタグアドレスが０ｘ００４００と一致するかどうか、また状態がなにであるかによって、処理タイプ、出力するメッセージの種類、タグメモリ２２の次状態が決定する（図９参照）（ステップＳ１２１）。
【０２８７】
この場合必ず処理タイプがＢＡとなり（ステップＳ１２２）、Ａｃｋメッセージを生成する。このＡｃｋメッセージは、宛先ノード番号を０ｘ００１、メッセージの種類をＡｃｋ、アドレスを０ｘ００４００３００００８、ｍｉｄを「３」、要求元ノード番号を０ｘ００５とするメッセージである。出力先は宛先ノード番号０ｘ００１と当該ノード番号の比較結果によって決定する。ノードＰＥ１であれば、一致するのでホームアクセス制御部２７に出力する。他のノードであれば、一致しないのでメッセージ送信部３５に出力する（ステップＳ１２３）。
【０２８８】
タグメモリの更新を行う。更新するエントリは先ほど読み出を行った０ｘ０６００番地のエントリであり、状態は図９から求まる次状態を、タグアドレスは先ほどタグメモリ２２から読み出した値をそのまま書き込む。また、リクエスト管理テーブル３７へ、受けたメッセージのアドレス（０ｘ００４００３０００８）を出力する。リクエスト管理テーブル３７では、各エントリのアドレスと、ローカルアクセス制御部２５が出力するアドレスの、第３９ビット〜第７ビットが一致するかどうかを検査し、一致するエントリのチェックビットを「１」に更新する。
【０２８９】
例えばノードＰＥ２では、フェーズ８でアドレス０ｘ００４００３００１０に対するストアアクセスを処理し、リクエスト管理テーブル３７の１番のエントリに当該メモリアクセスを登録している。リクエスト管理テーブル３７の１番エントリのアドレス０ｘ００４００３００１０と、ローカルアクセス制御部２５がリクエスト管理テーブル３７に出力したアドレス０ｘ００４００３０００８の、第３９ビット〜第７ビットが一致するので、１番エントリのチェックビットが「１」に更新される（ステップＳ１２５）。以上でローカルアクセス制御部２５は、Ｉｎｖメッセージの処理を終了する。
【０２９０】
ノードＰＥ０、ノードＰＥ２〜ノードＰＥ４、ノードＰＥ６〜ノードＰＥ１２７は、それぞれＡｃｋメッセージ（宛先ノードは０ｘ００１、種類はＡｃｋ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５）をノードＰＥ１に対して送信する。このＡｃｋメッセージは、各ノードのメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られてくる。
【０２９１】
一方、ノードＰＥ１では、ローカルアクセス制御部２５から、Ａｃｋメッセージ（宛先ノードは０ｘ００１、種類はＡｃｋ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５）がホームアクセス制御部２７に出力される。ノードＰＥ１のホームアクセス制御部２７は、合計１２７個の同じＡｃｋメッセージを受け取り処理することになる。最初のＡｃｋメッセージをノードＰＥ１のホームアクセス制御部２７が受けた場合、次のように動作する。
【０２９２】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３０００８の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれフェーズ８で１、ＲＥＰ、０ｘ０７ｆに更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋであり、読み出した状態がＲＥＰ、また保持ノード情報が０ｘ０７ｆでありアンキャッシュドでないことから、処理タイプはＣＥ、次状態はＲＥＰ、保持ノード操作はｄｅｃ、出力するメッセージはなしに決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空でないことから、トップビットは読み出した値「１」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２９３】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＲＥＰ、保持ノード情報は０ｘ０７ｅに更新する。処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０２９４】
処理タイプがＣＥであることから（ステップＳ１４３）、コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージの種類がＡｃｋであり、処理タイプがＣＥであることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ａｃｋメッセージの処理を終了する。
【０２９５】
ホームアクセス制御部２７は、各ノードＰＥｉからのＡｃｋメッセージを、前記同様に処理していき、ディレクトリメモリ３１の値を読み出し、保持ノード情報を「１」引いた値に更新する処理が行われていく。この処理は、読み出した保持ノード情報から「１」引いた値が０ｘ０００でない場合、即ちアンキャッシュドでない場合まで継続される。ただし、アンキャッシュドになる場合、即ち最後の１２７個目のＡｃｋメッセージを受けたときは、次のように動作する。
【０２９６】
最後の１２７個目のメッセージを受けたホームアクセス制御部２７は、まずディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３０００８の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれ１、ＲＥＰ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋであり、読み出した状態がＲＥＰ、保持ノード情報が０ｘ００１でありアンキャッシュドであること、また要求元ノード番号０ｘ００５が当該ノードＰＥ１のノード番号０ｘ００１と異なることから、処理タイプはＣＡ、次状態はＭ、保持ノード操作はｓｅｔ、出力するメッセージの種類はＣｍｐＤａｔＥｘ、出力先はリモートバッファ３４に決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空でないことから、トップビットは読み出した値「１」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０２９７】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＭ、保持ノード情報は０ｘ００５に更新する。また、処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０２９８】
処理タイプがＣＡであることから（ステップＳ１４３）、ＣｍｐＤａｔＥｘメッセージ生成情報が生成され、リモートバッファ３４に出力される。このＣｍｐＤａｔＥｘメッセージ生成情報は、メッセージの種類をＣｍｐＤａｔＥｘ、アドレスを０ｘ００４００３０００８、ｍｉｄを「３」、要求元ノード番号を０ｘ００５、保持ノード情報を０ｘ００１とする（ステップＳ１４４）。
【０２９９】
コンフリクトキューからメッセージ情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージの種類がＡｃｋであり、処理タイプがＣＡであり、トップビットが「１」であることから、リクトキューからの読み出しを行う。
【０３００】
この時、コンフリクトキューにはフェーズ７おいてＢｌｋＲｄＳｈメッセージが、フェーズ８においてＵｐｇｒａｄｅメッセージが書き込まれており前者のＢｌｋＲｄＳｈメッセージ（メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００２０、要求元ノード番号は０ｘ０８０、ｍｉｄは「０」）が読み出される（ステップＳ１４９）。以上で、ホームアクセス制御部２７は、Ａｃｋメッセージの処理を終了し、コンフリクトキューから読み出したＢｌｋＲｄＳｈメッセージの処理を開始する。
【０３０１】
ホームアクセス制御部２７がステップＳ１４９で読み出したＢｌｋＲｄＳｈメッセージの処理の説明は次のフェーズ１０で行う。ここでは、ステップＳ１４４でリモートバッファ３４に出力されたＣｍｐＤａｔＥｘメッセージ生成情報について説明する。
【０３０２】
前記ＣｍｐＤａｔＥｘメッセージ生成情報（メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５、保持ノード情報は０ｘ００１）を受けたリモートバッファ３４は、主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地までの１２８バイトのデータを読み出し、宛先ノード番号を０ｘ００５、メッセージの種類をＣｍｐＤａｔＥｘ、アドレスを０ｘ００４００３０００８、ｍｉｄを「３」、要求元ノード番号を０ｘ００５、ブロックデータを主メモリ３０から読み出したブロックデータとするメッセージを生成し、メッセージ送信部３５へ出力する。このブロックデータは最新のデータである。
【０３０３】
このＣｍｐＤａｔＥｘメッセージは、ノードＰＥ１のメッセージ送信部３５、相互結合網１０、ノードＰＥ５のメッセージ受信部３６、リプライバッファ３２を介して、ローカルバッファ２５に出力される。
【０３０４】
ＣｍｐＤａｔＥｘメッセージ（宛先ノード番号は０ｘ００５、メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３０００８、ｍｉｄは「３」、要求元ノード番号は０ｘ００５、ブロックデータは最新のデータ）を受けたローカルアクセス制御部２５は、まずリクエスト管理テーブル３７の３（＝ｍｉｄ）番エントリの情報を読みだし（ステップＳ１３１）、アクセスの種類はストア、アドレスは０ｘ００４００３０００８、チェックビットは「０」という情報及びストアデータを得る。
【０３０５】
ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０３０６】
そして、アクセスタイプがストアであることから（ステップＳ１３６）、キャッシュメモリ２１の０ｘ０６０００番地のデータ６４ビットを、リクエスト管理テーブル３７から得たストアデータに更新する処理を行う。また、リクエスト管理テーブルの３（＝ｍｉｄ）番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリ２２の０ｘ０６００番地のデータを、状態はＤ（図１１参照）、タグアドレスは０ｘ００４００（リクエスト管理テーブルから得たアドレス０ｘ００４００３０００８の第３９ビット〜第２０ビットの２０ビット）に更新する。また、プロセッサへｍｉｄを出力し、ｉｄ＝３のメモリアクセスが完了した旨を通知する（ステップＳ１３７）。以上でローカルアクセス制御部２５は、ＣｍｐＤａｔＥｘメッセージの処理を終了する。
【０３０７】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ５のキャッシュメモリ２１にのみ存在する状態となる。
【０３０８】
（フェーズ１０）
フェーズ９において、ノードＰＥ１のホームアクセス制御部２７はＡｃｋメッセージを１２７個処理した。その１２７個目のＡｃｋメッセージの処理（ステップＳ１４８）において、コンフリクトキューからのメッセージ情報の読み出しが必要と判断し、主メモリ３０をアクセスし、ＢｌｋＲｄＳｈメッセージ（メッセージの種類はＢｌｋＲｄＳｈ、アドレスは０ｘ００４００３００２０、要求元ノード番号は０ｘ０８０、ｍｉｄは「０」）を読み出した（ステップＳ１４９）。ここでは、このＢｌｋＲｄＳｈメッセージを読み出したホームアクセス制御部２７の動作を説明する。
【０３０９】
まず、ディレクトリメモリ３１の０ｘ０００６００（コンフリクトキューから読み出したメッセージ情報のアドレス０ｘ００４００３００２０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ９において、トップビット、状態、保持ノード情報はそれぞれ１、Ｍ、０ｘ００５に更新されており、その値が読み出される。キューから読み出したメッセージの種類がＢｌｋＲｄＳｈであり、読み出した状態がＭ、保持ノード情報が０ｘ００５でアンキャッシュドではないこと、保持ノード情報が０ｘ００５で当該ノード番号０ｘ００１とことなることから、処理タイプはＣＡ、次状態はＲＳＰ、保持ノード操作はｎｏｎｅ、出力するメッセージの種類はＩｎｔｖＳｈ、出力先はリモートバッファと決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理であり、処理タイプがＣＤでないことから、トップビットは「０」に更新し、また、コンフリクトキューの先頭エントリの削除を行うことが決定する（図１５参照）（ステップＳ１４１）。
【０３１０】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＲＳＰ、保持ノード情報を０ｘ００５に更新する。また、処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。コンフリクトキューの先頭エントリの削除は行い、読み出したＢｌｋＲｄＳｈメッセージのエントリを削除する。これにより、コンフリクトキューにはフェーズ８で書き込まれたＵｐｇｒａｄｅメッセージのみが存在する（ステップＳ１４２）。
【０３１１】
処理タイプがＣＡであるので（ステップＳ１４４）、メッセージ生成情報を生成しリモートバッファ３４に出力する。メッセージ生成情報は、メッセージの種類をＩｎｔｖＳｈ、アドレスを０ｘ００４００３００２０、ｍｉｄを「０」、要求元ノード番号を０ｘ０８０、保持ノード情報を０ｘ００５とする（ステップＳ１４３）。
【０３１２】
さらにコンフリクトキューから情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図１６より、ステップＳ１４９でコンフリクトキューから読み出したメッセージの処理であり、キューが空でなく、処理タイプがＣＡであることから、コンフリクトキューからの読み出しを行う。
【０３１３】
この時、フェーズ８において書き込まれたＵｐｇｒａｄｅメッセージの情報（メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、要求元ノード番号は０ｘ００２、ｍｉｄは「１」）が読み出される（ステップＳ１４９）。以上で、ホームアクセス制御部２７は、コンフリクトキューから読み出したＢｌｋＲｄＳｈメッセージの処理を終了し、さらにコンフリクトキューから読み出したＵｐｇｒａｄｅメッセージの処理を開始する。
【０３１４】
ホームアクセス制御部２７がステップＳ１４４でリモートバッファ３４に出力したＩｎｔｖＳｈメッセージ生成情報については次のフェーズ１１で説明する。ここでは、コンフリクトキューから読み出したＵｐｇｒａｄｅメッセージの処理について説明する。前記Ｕｐｇｒａｄｅメッセージ生成情報を読み出したホームアクセス制御部２７は、次のように動作する。
【０３１５】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。同フェーズ１０において、トップビット、状態、保持ノード情報はそれぞれ０、ＲＳＰ、０ｘ００５に更新されており、その値が読み出される。処理しているメッセージの種類がＵｐｇｒａｄｅであり、読み出した状態がＲＳＰであることから、処理タイプはＣＥ、次状態はＲＳＰ、保持ノード操作はｎｏｎｅに決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理であり、処理タイプがＣＤであることから、トップビットは「１」に更新し、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０３１６】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＲＳＰ、保持ノード情報は０ｘ００５に更新する。また、処理しているメッセージがデータ付きではないので主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０３１７】
処理タイプがＣＤであり（ステップＳ１４３）、ステップＳ１４９でキューから読み出したメッセージの処理なので、コンフリクトキューにメッセージ情報を書き込まず（ステップＳ１４７）、さらにコンフリクトキューからメッセージ情報を読み出すかどうかを検査する（ステップＳ１４８）。
【０３１８】
図１６より、コンフリクトキューから読み出したメッセージの処理であり、キューが空でなく、処理タイプがＣＤであることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、コンフリクトキューから読み出したＵｐｇｒａｄｅメッセージの処理を終了する。
【０３１９】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ５のキャッシュメモリ２１にのみ存在する状態である。
【０３２０】
（フェーズ１１）
フェーズ１０において、ノードＰＥ１のホームアクセス制御部２７はコンフリクトキューから読み出したＢｌｋＲｄＳｈメッセージを処理した。その処理において、リモートバッファ３４にＩｎｔｖＳｈメッセージ生成情報を出力している。ここでは、このＩｎｔｖＳｈメッセージ生成情報について説明する。
【０３２１】
前記ＩｎｔｖＳｈメッセージ生成情報（種類はＩｎｔｖＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０、保持ノード情報は０ｘ００５）を受け取ったリモートバッファ３４は、宛先ノード番号を０ｘ００５、メッセージの種類をＩｎｔｖＳｈ、アドレスを０ｘ００４００３００２０、ｍｉｄを「０」、要求元ノード番号を０ｘ０８０とするメッセージを生成し、メッセージ送信部３５に出力する。
【０３２２】
このＩｎｔｖＳｈメッセージはノードＰＥ１のメッセージ送信部３５、相互結合網、ノードＰＥ５のメッセージ受信部３６、ノードＰＥ５のリクエストバッファ３３を介して、ノードＰＥ５のローカルアクセス制御部２５に出力される。
【０３２３】
ＩｎｔｖＳｈメッセージ（宛先ノード番号は０ｘ００５、メッセージの種類はＩｎｔｖＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０）を受けたローカルアクセス制御部２５は、タグメモリ２２の０ｘ０６００番地のデータを読み出す。フェーズ９において、状態及びタグアドレスはそれぞれＤ及び０ｘ００４００に更新されており、この値が読み出される。受けたメッセージがＩｎｔｖＳｈであり、タグアドレスが一致し、状態がＤであることから、処理タイプはＢＢ、出力するメッセージの種類はＡｃｋＤａｔａ、次状態はＳに決定する（ステップＳ１２１）。
【０３２４】
処理タイプがＢＢであることから（ステップＳ１２２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地までの６４ビット×１６エントリ＝１２８バイトのブロックデータを読み出し、生成するＡｃｋＤａｔａメッセージに付加する。生成するＡｃｋＤａｔａメッセージの、宛先ノード番号は０ｘ００１、メッセージの種類はＡｃｋＤａｔａ、アドレスは０ｘ００４００３００２０、要求元ノード番号は０ｘ０８０、ｍｉｄは「０」、ブロックデータはキャッシュメモリ２１から読み出したデータとなる。宛先ノード番号０ｘ００１と当該ノード番号０ｘ００５が一致しないことから出力先はメッセージ送信部３５となる（ステップＳ１２４）。
【０３２５】
タグメモリの０ｘ０６００番地の状態およびタグアドレスを、それぞれＳ（図９参照）および０ｘ００４００（タグメモリ２２から読み出したタグアドレス）に更新する。また、リクエスト管理テーブル３７へ、受けたメッセージのアドレス（０ｘ００４００３００００）を出力する。リクエスト管理テーブル３７では、各エントリのアドレスと、ローカルアクセス制御部２５が出力するアドレスの、第３９ビット〜第７ビットが一致するかどうかを検査し、一致するエントリのチェックビットを「１」に更新する（ステップＳ１２５）。以上でローカルアクセス制御部２５は、ＩｎｔｖＳｈメッセージの処理を終了する。
【０３２６】
ＡｃｋＤａｔａメッセージは、ノードＰＥ５のメッセージ送信部、相互結合網１０、ノードＰＥ１のメッセージ受信部を介して、ノードＰＥ１のホームアクセス制御部に出力される。
【０３２７】
ＡｃｋＤａｔａメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＡｃｋＤａｔａ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０、ブロックデータは最新のデータ）を受けたホームアクセス制御部２７は、次のように動作する。
【０３２８】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００２０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれフェーズ１０で１、ＲＳＰ、０ｘ００５に更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋＤａｔａであり、読み出した状態がＲＳＰ、要求元ノード番号０ｘ０８０と当該ノード番号０ｘ００１が一致しないことから、処理タイプはＣＡ、次状態はＣ、保持ノード操作はａｄｄ、出力するメッセージの種類はＣｍｐＤａｔＳｈ、出力先はリモートバッファ３４に決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空でないことから、トップビットは読み出した値「１」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０３２９】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「１」、状態はＣ、保持ノード情報は０ｘ００３に更新する。また、処理しているメッセージがブロックデータ付きのＡｃｋＤａｔａメッセージであることから主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地に、付加されていたブロックデータを書き込む。これにより、主メモリ３０に最新のデータが存在する状態となる。また、コンフリクトキューの先頭エントリの削除は行わない（ステップＳ１４２）。
【０３３０】
処理タイプがＣＡであることから（ステップＳ１４３）、ＣｍｐＤａｔＳｈメッセージ生成情報を生成しリモートバッファ３４に出力する。このメッセージ生成情報は、メッセージの種類をＣｍｐＤａｔＳｈ、アドレスを０ｘ００４００３００２０、ｍｉｄを「０」、要求元ノード番号を０ｘ０８０、保持ノード情報を０ｘ００５とする（ステップＳ１４４）。
【０３３１】
メッセージ生成情報の出力を終えると、コンフリクトキューからの読み出が必要かどうかを検査する（ステップＳ１４８）。図１６より、ステップＳ１４９でコンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージの種類がＡｃｋＤａｔａであり、処理タイプがＣＡであり、ステップＳ１４１で読み出したトップビットの値が「１」であることから、コンフリクトキューからの読み出しを行う。読み出されるメッセージはフェーズ８でコンフリクトキューに書き込まれた、Ｕｐｇｒａｄｅメッセージ（メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、要求元ノード番号は０ｘ００２、ｍｉｄは「１」）である（ステップＳ１４９）。以上で、ホームアクセス制御部２７は、ＡｃｋＤａｔａメッセージの処理を終了し、コンフリクトキューから読み出したＵｐｇｒａｄｅメッセージの処理を開始する。
【０３３２】
ホームアクセス制御部２７がステップＳ１４９で読み出したＵｐｇｒａｄｅメッセージの処理の説明は次のフェーズ１２で行う。ここでは、ステップＳ１４４でリモートバッファ３４に出力されたＣｍｐＤａｔＳｈメッセージ生成情報について説明する。
【０３３３】
ＣｍｐＤａｔＳｈメッセージ生成情報（メッセージの種類はＣｍｐＤａｔＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０、保持ノード情報は０ｘ００５）を受けたリモートバッファ３４は、主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地までの１２８バイトのデータを読み出し、宛先ノード番号を０ｘ０８０、メッセージの種類をＣｍｐＤａｔＳｈ、アドレスを０ｘ００４００３００２０、ｍｉｄを「０」、要求元ノード番号を０ｘ０８０、ブロックデータを主メモリ３０から読み出したブロックデータとするメッセージを生成し、メッセージ送信部３５へ出力する。このブロックデータは最新のデータである。
【０３３４】
このＣｍｐＤａｔＳｈメッセージは、ノードＰＥ１のメッセージ送信部３５、相互結合網１０、ノードＰＥ８０のメッセージ受信部３６、ノードＰＥ８０のリプライバッファ３２を介して、ノードＰＥ８０のローカルバッファ２５に出力される。
【０３３５】
前記ＣｍｐＤａｔＳｈメッセージ（宛先ノード番号は０ｘ０８０、メッセージの種類はＣｍｐＤａｔＳｈ、アドレスは０ｘ００４００３００２０、ｍｉｄは「０」、要求元ノード番号は０ｘ０８０、ブロックデータは最新のデータ）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の０（＝ｍｉｄ）番エントリの情報を読みだし、アクセスの種類はロード、アドレスは０ｘ００４００３００２０、チェックビットは「０」という情報を得る（ステップＳ１３１）。
【０３３６】
ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０３３７】
そして、アクセスタイプがロードであることから（ステップＳ１３６）、キャッシュメモリ２１から０ｘ０６００４番地の６４ビットデータを読み出し、プロセッサ２０に対してｉｄ＝０のメモリアクセスに対する応答データとして渡す。また、リクエスト管理テーブルの０番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリの０ｘ０６００番地の状態およびタグアドレスを、それぞれＳ（図１１参照）および０ｘ００４００（リクエスト管理テーブル３７に付加されていたアドレス０ｘ００４００３００２０の第３９ビット〜第２０ビットまでの２０ビット）に更新する（ステップＳ１３８）。以上でローカルアクセス制御部２５は、ＣｍｐＤａｔＳｈメッセージの処理を終了する。
【０３３８】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ５のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ８０のキャッシュメモリ２１に存在する状態になる。
【０３３９】
（フェーズ１２）
フェーズ１１において、ノードＰＥ１のホームアクセス制御部２７はＡｃｋＤａｔａメッセージを処理した。その処理（ステップＳ１４８）において、コンフリクトキューからのメッセージ情報の読み出しが必要と判断し（ステップＳ１４９）、主メモリ３０をアクセスし、Ｕｐｇｒａｄｅメッセージ（メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００１０、要求元ノード番号は０ｘ００２、ｍｉｄは「１」）を読み出した。ここでは、このＵｐｇｒａｄｅメッセージを読み出した後のホームアクセス制御部２７の動作を説明する。
【０３４０】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。フェーズ１１において、トップビット、状態、保持ノード情報はそれぞれ１、Ｃ、０ｘ００３に更新されており、その値が読み出される。受けたメッセージの種類がＵｐｇｒａｄｅであり、読み出した状態がＣであり、保持ノード情報が０ｘ００３でアンキャッシュドではないことことから、処理タイプはＣＡ、次状態はＵＰ、保持ノード操作はｃｏｕｎｔ、出力するメッセージの種類はＩｎｖ、出力先はリモートバッファ３４に決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理であり、処理タイプがＣＤでないことから、トップビットは「０」に更新し、また、コンフリクトキューの先頭エントリの削除を行うことが決定する（図１５参照）（ステップＳ１４１）。
【０３４１】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＵＰ、保持ノード情報は０ｘ０ｆｆに更新する。また、処理しているメッセージがブロックデータ付きのメッセージでないことから主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除は行い、読み出したＵｐｇｒａｄｅメッセージのエントリを削除する。これにより、コンフリクトキューは空となる（ステップＳ１４２）。
【０３４２】
処理タイプがＣＡであるので（ステップＳ１４３）、メッセージ生成情報を生成しリモートバッファ３４に出力する。メッセージ生成情報は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２、保持ノード情報を０ｘ００３とする（ステップＳ１４４）。
【０３４３】
さらにコンフリクトキューから情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理であり、コンフリクトキューが空であることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、コンフリクトキューから読み出したＵｐｇｒａｄｅメッセージの処理を終了する。
【０３４４】
前記Ｉｎｖメッセージ生成情報（種類はＩｎｖ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２、保持ノード情報は０ｘ００３）を受け取ったリモートバッファ３４は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２とし、宛先ノード番号が０ｘ０００〜０ｘ０ｆｆの内０ｘ００２を除いたものとする２５５個のメッセージを順次生成しメッセージ送信部３５に出力する。
【０３４５】
これらのＩｎｖメッセージはノードＰＥ１のメッセージ送信部３５、相互結合網、各ノードＰＥ０〜ＰＥ２５５（ＰＥ２除く）のメッセージ受信部３６、リクエストバッファ３３を介してローカルアクセス制御部２５に出力される。
【０３４６】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ５のキャッシュメモリ２１、ノードＰＥ１の主メモリ３０、ノードＰＥ８０のキャッシュメモリ２１に存在する状態である
【０３４７】
（フェーズ１３）
前記Ｉｎｖメッセージを受けた各ノードＰＥｉ（ｉ＝０、１、３、・・・、２５５）のローカルアクセス制御部２５は次のように動作する。
【０３４８】
Ｉｎｖメッセージ（宛先ノード番号は受けたノードの番号、メッセージの種類はＩｎｖ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２）を受けたローカルアクセス制御部２５は、タグメモリ２２の０ｘ０６００番地のデータを読み出す。読み出したタグアドレスが０ｘ００４００と一致するかどうか、また状態がなにであるかによって、処理タイプ、出力するメッセージの種類、タグメモリ２２の次状態が決定する（図９参照）（ステップＳ１２１）。
【０３４９】
この場合必ず処理タイプがＢＡとなり（ステップＳ１２２）、Ａｃｋメッセージの生成が行われる。このＡｃｋメッセージは、宛先ノード番号を０ｘ００１、メッセージの種類をＡｃｋ、アドレスを０ｘ００４００３０００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２とする。出力先は宛先ノード番号０ｘ００１と当該ノード番号の比較結果によって決定する。ノードＰＥ１であれば、一致するのでホームアクセス制御部２７に出力する。他のノードであれば、一致しないのでメッセージ送信部３５に出力する（ステップＳ１２３）。
【０３５０】
タグメモリの更新を行う。更新するエントリは先ほど読み出を行った０ｘ０６００番地のエントリであり、状態は図９から求まる次状態に更新され、タグアドレスは先ほどタグメモリ２２から読み出した値がそのまま書き込まれる。また、リクエスト管理テーブル３７へ、受けたメッセージのアドレス（０ｘ００４００３０００８）を出力する。リクエスト管理テーブル３７では、各エントリのアドレスと、ローカルアクセス制御部２５が出力するアドレスの、第３９ビット〜第７ビットが一致するかどうかを検査し、一致するエントリのチェックビットを「１」に更新する（ステップＳ１２５）。以上でローカルアクセス制御部２５は、ＩｎｔｖＳｈメッセージの処理を終了する。
【０３５１】
ノードＰＥ０、ノードＰＥ３〜ノードＰＥ２５５は、それぞれＡｃｋメッセージ（宛先ノードは０ｘ００１、種類はＡｃｋ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２）をノードＰＥ１に対して送信する。このＡｃｋメッセージは、各ノードのメッセージ送信部３５、相互結合網１０、ノードＰＥ１のメッセージ受信部３６を介してノードＰＥ１のホームアクセス制御部２７に送られてくる。
【０３５２】
一方、ノードＰＥ１では、ローカルアクセス制御部２５から、Ａｃｋメッセージ（宛先ノードは０ｘ００１、種類はＡｃｋ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２）がホームアクセス制御部２７に出力される。ノードＰＥ１のホームアクセス制御部２７は、合計２５５個の同じＡｃｋメッセージを受け取り処理することになる。最初のＡｃｋメッセージをノードＰＥ１のホームアクセス制御部２７が受けた場合、次のように動作する。
【０３５３】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれフェーズ１２で０、ＵＰ、０ｘ０ｆｆに更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋであり、読み出した状態がＵＰ、また保持ノード情報が０ｘ０ｆｆでありアンキャッシュドでないことから、処理タイプはＣＥ、次状態はＵＰ、保持ノード操作はｄｅｃ、出力するメッセージはなしに決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除は行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０３５４】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＵＰ、保持ノード情報は０ｘ０ｆｅに更新する。また、処理しているメッセージがブロックデータ付きのメッセージでないことから、主メモリ３０への書き込みは行なわない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０３５５】
処理タイプがＣＥであることから（ステップＳ１４３）、コンフリクトキューからの読み出が必要かどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージがＡｃｋであり、処理タイプがＣＥであることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ａｃｋメッセージの処理を終了する。
【０３５６】
ホームアクセス制御部２７は、各ノードＰＥｉからのＡｃｋメッセージを、前記同様に処理していき、ディレクトリメモリ３１の値を読み出し保持ノード情報を「１」引いた値に更新する処理が行われていく。この処理は、読み出した保持ノード情報から「１」引いた値が０ｘ０００でない場合、即ちアンキャッシュドでない場合まで継続される。ただし、アンキャッシュドになる場合、即ち最後の２５５個目のＡｃｋメッセージを受けたときは、次のように動作する。最後の２５５個目のメッセージを受けたホームアクセス制御部２７は次のように動作する。
【０３５７】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれ１、ＵＰ、０ｘ００１に更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋであり、読み出した状態がＵＰ、保持ノード情報が０ｘ００１でありアンキャッシュドであること、また要求元ノード番号０ｘ００２が当該ノードＰＥ１のノード番号０ｘ００１と異なることから、処理タイプはＣＡ、次状態はＭ、保持ノード操作はｓｅｔ、出力するメッセージの種類はＣｍｐ、出力先はリモートバッファ３４に決定する（図１４参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０３５８】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＭ、保持ノード情報は０ｘ００２に更新する。また、処理しているメッセージがブロックデータ付きのメッセージでないことから主メモリ３０への書き込みは行なわない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０３５９】
処理タイプがＣＡであることから（ステップＳ１４３）、Ｃｍｐメッセージ生成情報を生成しリモートバッファ３４に出力する。このＣｍｐメッセージ生成情報は、メッセージの種類をＣｍｐ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２、保持ノード情報を０ｘ００１とする（ステップＳ１４４）。
【０３６０】
コンフリクトキューからメッセージ情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図１６より、コンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージがＡｃｋであり、処理タイプがＣＡであり、トップビットは「０」であることから、ステップＳ１４９でコンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ａｃｋメッセージの処理を終了する。
【０３６１】
前記Ｃｍｐメッセージ生成情報（メッセージの種類はＣｍｐ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２、保持ノード情報は０ｘ００１）を受けたリモートバッファ３４は、宛先ノード番号を０ｘ００２、メッセージの種類をＣｍｐ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２とするメッセージを生成し、メッセージ送信部３５へ出力する。
【０３６２】
このＣｍｐメッセージは、ノードＰＥ１のメッセージ送信部３５、相互結合網１０、ノードＰＥ２のメッセージ受信部３６、リプライバッファ３２を介して、ローカルバッファ２５に出力される。
【０３６３】
Ｃｍｐメッセージ（宛先ノード番号は０ｘ００２、メッセージの種類はＣｍｐ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の１（＝ｍｉｄ）番エントリの情報を読み出す。リクエスト管理テーブル３７に登録されている値は、フェーズ８で設定され、フェーズ９でチェックビットが「１」に変更された値、即ちアクセスの種類はストア、アドレスは０ｘ００４００３００１０、チェックビットは「１」、及びストアデータである（ステップＳ１３１）。
【０３６４】
ブロックデータ付きのメッセージではないので（ステップＳ１３２）、チェックビットの値を調べる（ステップＳ１３３）。リクエスト管理テーブル３７から得たチェックビットの値は「１」であるため、ＢｌｋＲｄＥｘメッセージの生成出力が行われる。このＢｌｋＲｄＥｘメッセージは、宛先ノード番号を０ｘ００１（アドレス０ｘ００４００３００１０の第３９ビット〜第３０ビットまでの１０ビット）、メッセージの種類をＢｌｋＲｄＥｘ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２とするメッセージである（ステップＳ１３４）。以上で、ローカルアクセス制御部２５は、Ｃｍｐメッセージの処理を終了する。
【０３６５】
ＢｌｋＲｄＥｘメッセージに関する動作については次のフェーズ１４で説明する。
【０３６６】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ１の主メモリ３０にのみ存在する状態となる。前フェーズ１２で最新のデータが存在したＰＥ５のキャッシュメモリ２１、ノードＰＥ８０のキャッシュメモリ２１はＩｎｖメッセージにより無効化されている。
【０３６７】
（フェーズ１４）
フェーズ１３において、ノードＰＥ２のローカルアクセス制御部２５で生成されメッセージ送信部に出力されたＢｌｋＲｄＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号を０ｘ００２）は、相互結合網１０、ノードＰＥ１のメッセージ受信部３５を介してノードＰＥ１のホームアクセス制御部２７に送られる。ＢｌｋＲｄＥｘメッセージを受けたホームアクセス制御部２７は次のように動作する。
【０３６８】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００１０の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はフェーズ１３でそれぞれ０、Ｍ、０ｘ００２に更新されており、その値が読み出される。受けたメッセージの種類がＢｌｋＲｄＥｘであり、読み出した状態がＭ、保持ノード情報が０ｘ００２でりアンキャッシュドであること、要求元ノード番号０ｘ００２と当該ノード番号０ｘ００１が一致しないことから、処理タイプはＣＡ、次状態はＭ、保持ノード操作はｓｅｔ、出力するメッセージの種類はＣｍｐＤａｔＥｘ、出力先はリプライバッファ３２に決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０３６９】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＭ、保持ノード情報は０ｘ００２に更新する。また、処理しているメッセージがブロックデータ付きのメッセージでないことから主メモリ３０への書き込みは行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０３７０】
処理タイプがＣＡであることから（ステップＳ１４３）、ＣｍｐＤａｔＥｘメッセージ生成情報を生成しリモートバッファ３４に出力する。このメッセージ生成情報は、メッセージの種類をＣｍｐＤａｔＥｘ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２、保持ノード情報を０ｘ００２とする（ステップＳ１４４）。
【０３７１】
メッセージ生成情報の出力を終えると、コンフリクトキューからの読み出が必要かどうかを検査する（ステップＳ１４８）。図１６より、ステップＳ１４９でコンフリクトキューから読み出したメッセージの処理でなく、処理したメッセージがＢｌｋＲｄＥｘであることから、コンフリクトキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＥｘメッセージの処理を終了する。
【０３７２】
ＣｍｐＤａｔＥｘメッセージ生成情報（メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２、保持ノード情報は０ｘ００２）を受けたリモートバッファ３４は、主メモリ３０の０ｘ０００６０００番地から０ｘ０００６００ｆ番地までの１２８バイトのデータを読み出し、宛先ノード番号を０ｘ００２、メッセージの種類をＣｍｐＤａｔＥｘ、アドレスを０ｘ００４００３００１０、ｍｉｄを「１」、要求元ノード番号を０ｘ００２、ブロックデータを主メモリ３０から読み出したブロックデータとするメッセージを生成し、メッセージ送信部３５へ出力する。このブロックデータは最新のデータである。
【０３７３】
このＣｍｐＤａｔＥｘメッセージは、ノードＰＥ１のメッセージ送信部３５、相互結合網１０、ノードＰＥ２のメッセージ受信部３６、ノードＰＥ２のリプライバッファ３２を介して、ノードＰＥ２のローカルバッファ２５に出力される。
【０３７４】
前記ＣｍｐＤａｔＥｘメッセージ（宛先ノード番号は０ｘ００２、メッセージの種類はＣｍｐＤａｔＥｘ、アドレスは０ｘ００４００３００１０、ｍｉｄは「１」、要求元ノード番号は０ｘ００２、ブロックデータは最新のデータ）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の１（＝ｍｉｄ）番エントリの情報を読みだし、アクセスの種類はストア、アドレスは０ｘ００４００３００１０、チェックビットは「１」という情報、およびストアデータを得る（ステップＳ１３１）。
【０３７５】
ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０３７６】
そして、アクセスタイプがストアであることから（ステップＳ１３６）、キャッシュメモリ２１の０ｘ０６００２番地のデータ６４ビットを、リクエスト管理テーブル３７から得たストアデータに更新する処理を行う。また、リクエスト管理テーブルの１（＝ｍｉｄ）番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリ２２の０ｘ０６００番地のデータを、状態はＤ（図１１参照）、タグアドレスは０ｘ００４００（リクエスト管理テーブルから得たアドレス０ｘ００４００３００１０の第３９ビット〜第２０ビットの２０ビット）に更新する。また、プロセッサへｍｉｄを出力し、ｉｄ＝１のメモリアクセスが完了した旨を通知する（ステップＳ１３７）。以上でローカルアクセス制御部２５は、ＣｍｐＤａｔＥｘメッセージの処理を終了する。
【０３７７】
この段階で０ｘ００４００３００００〜０ｘ００４００３００７ｆ番地までについて、最新のデータはノードＰＥ２のキャッシュメモリ２２にのみ存在する。ノードＰＥ１の主メモリ３０のデータはノードＰＥ２のキャッシュメモリ２２にストアデータが書き込まれた時点で最新のデータではなくなる。
【０３７８】
この実施の形態のマルチプロセッサにおける、プロセッサ２０が行うメモリアクセスから始まる、ノードＰＥｉ間でやり取りされるメッセージのシーケンスを、図１７に示す。
【０３７９】
図１７において、括弧で囲まれたメッセージは生成されない場合が存在することを表す。逆に、括弧で囲まれていないものは必ず生成されることを表している。また、矢印の分岐は、分岐先のメッセージのどれかが出力されることを表している。
【０３８０】
図１７から明らかなように、ノードＰＥｉ間でやり取りされるメッセージのシーケンスにループは存在しない。
【０３８１】
従って、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスを行ってから、その結果を得るまでの処理が無限ループに陥ることがない。このため、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスに対する結果を有限時間内に得ることを保証することができる。
【０３８２】
この実施の形態のマルチプロセッサシステムにおける、メッセージの出力元モジュールと出力先モジュールの関係を図１８に示す。
【０３８３】
ところで、出力先のモジュールがメッセージを受け付けられる状態にならないと、出力元のモジュールはメッセージを出力できず処理が停止してしまう。この依存関係にループができるとデッドロックが発生する可能性がある。
【０３８４】
この実施の形態のマルチプロセッサシステムにおいては、リプライバッファ３２、リクエストバッファ３３、リモートバッファ３４が出力され得る全てのメッセージを受け取れるように構成されている。すなわち、リプライバッファ３２は、受け取るべきメッセージの最大数分のエントリで構成される。リクエストバッファ３３およびリモートバッファ３４は、受け取るべきメッセージの最大数分のエントリからなる領域を主メモリ３０に設け、その領域に一時的にメッセージを退避する手段を有する。
【０３８５】
これにより、デッドロックを考える場合、上記の３つのバッファ３２、３３、３４を出力先モジュールから除くことができる。従って、この実施の形態におけるマルチプロセッサシステムでは、依存関係にループができず、デッドロックの発生を防ぐことができる。
【０３８６】
［第２の実施の形態］
この実施の形態にかかる疎結合型マルチプロセッサシステムの構成は、第１の実施の形態で示したもの（図１）と実質的に同一であるが、後述する一部の点において異なる。
【０３８７】
また、この実施の形態の疎結合型マルチプロセッサシステムにおいては、相互結合網１０を介してノードＰＥｉ間でやり取りされるメッセージの種類及び構成と、ノードＰＥｉ（ｉ＝０〜１０２３）の構成が、第１の実施の形態のものと異なる。
【０３８８】
以下、この実施の形態の疎結合型マルチプロセッサシステムにおいて、相互結合網１０を介してノードＰＥｉ間でやり取りされるメッセージについて、説明する。
【０３８９】
この実施の形態において、メッセージは、第１の実施の形態でも説明したＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒ、Ａｃｋ、ＡｃｋＤａｔａ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの１２種に、ＰｒｃＤａｔＥｘ、ＰｒｃＡｃｋを加えた１４種類からなる。
【０３９０】
この実施の形態において、第１の実施の形態で説明したものに対応するメモリアクセス完了メッセージは、プロセッサ２０に対する応答メッセージと処理完了メッセージに分離することができるものが含まれる。ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘメッセージは、分離されていないメモリアクセス完了メッセージである。ＰｒｃＤａｔＥｘおよびＰｒｃＡｃｋメッセージは、プロセッサ２０に対する応答メッセージであり、Ｃｍｐメッセージは、処理完了メッセージである。ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒ、Ａｃｋ、ＡｃｋＤａｔａ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖについては、第１の実施の形態のものと同一である。
【０３９１】
この実施の形態においても、第１の実施の形態と同様に、メッセージは、基本メッセージとブロックデータ付きメッセージに分類される。ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、Ａｃｋ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、Ｃｍｐ、ＰｒｃＡｃｋの９種は、基本メッセージである。一方、ＢｌｋＷｒ、ＡｃｋＤａｔａ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、ＰｒｃＤａｔＥｘの５種のメッセージは、ブロックデータ付きのメッセージである。
【０３９２】
基本メッセージは、図１９（ａ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（計１４個なので４ビットで表現）、要求元ノード番号（１０ビット）、ｍｉｄ（３ビット）、アドレス（４０ビット）の計６７ビットで構成される。
【０３９３】
ブロックデータ付きメッセージは、図１９（ｂ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（４ビット）、要求元ノード番号（１０ビット）、ｍｉｄ（３ビット）、アドレス（４０ビット）、さらにブロックサイズのデータ（１２８バイト）の計６７ビット＋１２８バイトで構成される。
【０３９４】
メッセージの構成要素のｍｉｄは、第１の実施の形態では２ビットで構成されていたのに対して、この実施の形態では３ビットで構成される。また、この実施の形態では、第１の実施の形態のようにプロセッサ２０がメモリアクセスに付加していたｉｄ（２ビット）をメッセージのｍｉｄに使用するのではなく、後述するローカルアクセス制御部２５が各メモリアクセスを識別するｍｉｄ（３ビット）を、ｉｄとは別に付加している。
【０３９５】
以下、この実施の形態の疎結合型マルチプロセッサシステムにおける各ノードＰＥｉの構成について、説明する。
【０３９６】
図２０は、この実施の形態におけるノードＰＥｉの機能構成を示すブロック図である。図２０に示すノードＰＥｉは、図２に示した第１の実施の形態のものとほぼ同様であるため、以下では、図２０に示すノードＰＥｉについて、第１の実施の形態のものと異なる部分について、説明する。
【０３９７】
プロセッサ２０は、メモリブロック命令を持っている。メモリブロック命令は、以前に発行したメモリアクセスでまだ完了していないメモリアクセスが存在するか、或いはシステム完了信号（リクエスト管理テーブル３７が出力）が「０」の場合には、プロセッサ２０がメモリブロック命令以降のメモリアクセスを実行しないようにするものである。
【０３９８】
メッセージ受信部３６は、第１の実施の形態のものとほぼ同じである。ただし、この実施の形態のメッセージ受信部３６には、ＰｒｃＡｃｋおよびＰｒｃＤａｔＥｘメッセージを受けたとき、これらのメッセージをリプライバッファ３２に出力する機能が追加されている。
【０３９９】
リクエスト管理テーブル３７は、何エントリによって構成されていても構わない。以後の説明においては、リクエスト管理テーブル３７が、８エントリで構成されている場合を示す。なお、メッセージに付加されているｍｉｄ（３ビット）は、リクエスト管理テーブル３７が８エントリであることに対応している。従って、リクエスト管理テーブル３７のエントリ数が異なれば、ｍｉｄのビット数も異なるものとなる。
【０４００】
リクエスト管理テーブル３７の各エントリは、Ｐｒｃビット（１ビット）、Ｓｙｓカウンタ（２ビット）、アクセスの種類（１ビット）、アドレス（４０ビット）、ｉｄ（２ビット）、データ（６４ビット）、チェックビット（１ビット）の計１１１ビットからなる。
【０４０１】
リクエスト管理テーブル３７は、次のような機能を有する。
１）空いているエントリの番号（３ビット）をローカルアクセス制御部２５に出力し、またローカルアクセス制御部２５の指示に従い、その空いているエントリに前記設定データ（前記１１１ビット）の値を書き込む機能。
ここで、エントリが空いているエントリとは、ＰｒｃビットおよびＳｙｓカウンタが両方とも「０」のエントリである。
【０４０２】
２）ローカルアクセス制御部２５が指定するエントリの内容をローカルアクセス制御部２５に対して出力する機能。
【０４０３】
３）ローカルアクセス制御部２５の指示に従い、ローカルアクセス制御部２５が指定するエントリのＰｒｃビットを「０」に更新し、Ｓｙｓカウンタの２ビットをローカルアクセス制御部２５が指定する値に設定する機能。
【０４０４】
４）ローカルバッファ３８が出力するアドレス信号（４０ビット）とエントリの設定データ中のアドレス（４０ビット）とが第１９ビットから第７ビットの１３ビットで一致し、かつＰｒｃビットあるいはＳｙｓカウンタのどちらか一方でも「０」でないエントリが存在する（同一キャッシュブロックに対するメモリアクセスが存在する）場合、あるいは全エントリともＰｒｃビットあるいはＳｙｓビットのどちらか一方でも「０」でない（全エントリが使用中）の場合、ペンディング信号を「１」にして出力する機能。
【０４０５】
５）ローカルアクセス制御部２５の指示に従い、ローカルアクセス制御部２５が出力するアドレス（４０ビット）とエントリのアドレス部（４０ビット）とが第３９ビットから第７ビットまでの上位３３ビットで一致する場合、該当するエントリのチェックビットを「１」に設定する機能。
【０４０６】
６）全エントリのＰｒｃビットおよびＳｙｓカウンタが「０」の場合に、システム完了信号を「１」にして、プロセッサ２０に対して出力する機能。
【０４０７】
リプライバッファ３２は、２０エントリのバッファによって構成される。リプライバッファ３２は、４個のメモリアクセス完了メッセージあるいはプロセッサ２０に対する応答メッセージ（ＰｒｃＡｃｋ、ＰｒｃＤａｔＥｘ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘメッセージ）、および１６個の処理完了メッセージ（Ｃｍｐメッセージ）を受け取り保持することができる。リプライバッファ３２の４エントリは、ブロックデータ付きのメッセージ（６７ビット＋１２８バイト）を保持することができ、残りの１６エントリは、基本メッセージ（６７ビット）を保持することができる。
【０４０８】
リクエストバッファ３３の構成は、第１の実施の形態のものとほぼ同じである。ただし、リクエストバッファ３３が管理する主メモリ３０のリクエスト退避キューのエントリ数は、リクエスト管理テーブルのエントリ数８にノード数１０２４を掛け合わせた８１９２となる。リクエストバッファ３３の各エントリは、基本メッセージ（６７ビット）を保持することができる。
【０４０９】
リモートバッファ３４の構成は、第１の実施の形態のものとほぼ同じである。ただし、リモートバッファ３４が管理する主メモリ３０のリクエスト退避キューのエントリ数は、リクエスト管理テーブルのエントリ数８にノード数１０２４および２を掛け合わせた１６３８４となる。リモートバッファ３４の各エントリは、ホームアクセス制御部２７が出力するメッセージ生成情報、メッセージの種類（４ビット）、アドレス（４０ビット）、要求元ノード番号（１０ビット）、ｍｉｄ（３ビット）およびディレクトリメモリ３１に保持されていた保持ノード情報（１０ビット）、の計６７ビットを保持することができる。
【０４１０】
リモートバッファ３４は、この実施の形態においては、第１の実施の形態で説明した機能に加えて、メッセージ生成情報からＰｒｃＤａｔＥｘおよびＰｒｃＡｃｋの２種のメッセージを生成する機能を有している。
【０４１１】
生成すべきメッセージ情報がＰｒｃＤａｔＥｘの場合、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ同様、不足している情報は宛先ノード番号およびブロックデータである。この場合、宛先ノード番号には要求元ノード番号がそのまま用いられる。ブロックデータには、主メモリ３０から読み出したメッセージ生成情報に付加されているアドレスで指定されるブロックデータを用いる。このとき生成されるメッセージは、このメッセージ一つのみである。
【０４１２】
生成すべきメッセージ情報がＰｒｃＡｃｋの場合、Ｃｍｐ同様、不足している情報は宛先ノード番号のみである。この場合、宛先ノード番号には、要求元ノード番号が使用される。このとき生成されるメッセージはこのメッセージ一つのみである。
【０４１３】
ローカルアクセス制御部２５と、ホームアクセス制御部２７とは、それぞれ第１の実施の形態のものとほぼ同様の機能を有するが、後述する一部の点でその機能及び動作が異なる。ローカルアクセス制御部２５とホームアクセス制御部２７において、第１の実施の形態と異なる部分については、さらに詳しく後述する。
【０４１４】
以下、この実施の形態におけるローカルアクセス制御部２５の動作について、説明する。
【０４１５】
なお、以下の説明においても、第１の実施の形態の場合と同様に、ローカルアクセス制御部２５が、キャッシュメモリ２１或いはタグメモリ２２にアクセスするときは、実際にはキャッシュメモリアクセス制御部２３或いはタグメモリアクセス制御部２４の機能が用いられる。
【０４１６】
ローカルアクセス制御部２５が、メモリアクセスを受け付けて行う処理の流れは、第１の実施の形態におけるものとほぼ同じであり、図６に示すフローチャート及び図７に示すテーブルに従う。ただし、この実施の形態においては、図６のステップＳ１１３、ステップＳ１１５におけるリクエスト管理テーブル３７への登録の処理、およびステップＳ１１３、ステップＳ１１４、ステップＳ１１５におけるメッセージの生成の処理が、第１の実施の形態のものと異なる。
【０４１７】
ステップＳ１１３におけるリクエスト管理テーブル３７への登録では、設定するデータおよび登録するエントリ番号が、第１の実施の形態のものと異なる。リクエスト管理テーブル３７に登録するデータは、Ｐｒｃビットは「１」、Ｓｙｓカウンタは「１」、チェックビットは「０」、アクセスの種類とアドレスとｉｄとデータはメモリアクセスに付加されていたものとなる。また、リクエスト管理テーブル３７に登録するエントリは、リクエスト管理テーブル３７が出力している空きエントリの番号（３ビット）となる。
【０４１８】
ステップＳ１１３、ステップＳ１１４、ステップＳ１１５におけるメッセージの生成の処理では、各メッセージに付加されるｍｉｄ（３ビット）として、リクエスト管理テーブル３７が出力する空きエントリの番号（３ビット）が用いられる。
【０４１９】
以下、ローカルアクセス制御部２５が、リプライバッファ３２が出力するメッセージを受け付けて行う処理のうちの第１の実施の形態と異なる点について、図２１、図２２を参照して説明する。
【０４２０】
この実施の形態では、第１の実施の形態での処理（図１０）に、ステップＳ２１１およびステップＳ２１２が加わっている。第１の実施の形態におけるステップＳ１３４（図１０参照）が、ステップＳ２１３に変更され、リクエスト管理テーブル３７の操作が付け加わっている。また、ステップＳ２１２、ステップＳ２１３、ステップＳ１３７、ステップＳ１３８の処理で操作されるリクエスト管理テーブル３７が、図２２に示すように変更されている。また、この実施の形態のローカルアクセス制御部２５は、さらにＰｒｃＡｃｋおよびＰｒｃＤａｔＥｘの新たに加わった両メッセージを処理できるようになっている。
【０４２１】
リプライバッファ３２から出力されるメッセージの種類は、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐ、ＰｒｃＤａｔＥｘ、ＰｒｃＡｃｋの５種類にかぎられる。
【０４２２】
ローカルアクセス制御部２５は、リプライバッファ３２よりメッセージを受け取ると（ステップＳ１３１）、メッセージに含まれるｍｉｄ（３ビット）をリクエスト管理テーブル３７に出力し、Ｓｙｓカウンタ、アクセスの種類、アドレス、データ（６４ビット）、ｉｄ（２ビット）、チェックビットの情報を得る。
【０４２３】
ステップＳ２１１では、ローカルアクセス制御部２５は、受けたメッセージがＣｍｐメッセージであるかどうかを検査する。ステップＳ２１１での検査結果により受けたメッセージがＣｍｐメッセージである場合は、ステップＳ２１２に進む。そうでない場合ステップＳ１３２に進む。
【０４２４】
ステップＳ２１２では、ローカルアクセス制御部２５は、ステップＳ１３１で読み出したＳｙｓカウンタの値から「１」引いた（ｄｅｃ操作）値に、メッセージに付加されていたｍｉｄで指定されるリクエスト管理テーブル３７のエントリのＳｙｓカウンタの値を更新する。ステップＳ２１２の処理が終了すると、受けたメッセージに関する処理を終了する。
【０４２５】
ステップＳ１３２では、ローカルアクセス制御部２５は、受けたメッセージがデータ付きメッセージかどうか、即ちＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘあるいはＰｒｃＤａｔＥｘであるか、データ付きでないＰｒｃＡｃｋメッセージであるかを検査する。
【０４２６】
ステップＳ１３２での検査の結果、ローカルアクセス制御部２５が受けたメッセージがデータ付きメッセージでない場合は、ステップＳ１３３に進む。ローカルアクセス制御部２５が受けたメッセージがデータ付きメッセージでない場合は、ステップＳ１３５に進む。
【０４２７】
ステップＳ１３３では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られたチェックビットの値を検査する。ステップＳ１３３での検査の結果、チェックビットの値が「１」であった場合には、ステップＳ２１３に進む。ステップＳ１３３での検査の結果、チェックビットの値が「０」であった場合には、ステップＳ１３７に進む。
【０４２８】
ステップＳ２１３では、ローカルアクセス制御部２５は、ＢｌｋＲｄＥｘメッセージを生成し、出力する。この時、要求ノード番号にはリクエスト管理テーブル３７から得たアドレスの第３９ビットから第３０ビットの上位１０ビットが、要求元ノード番号には当該ノードＰＥｉのノード番号が、ｍｉｄには受けたメッセージのｍｉｄが、アドレスにはリクエスト管理テーブル３７から得たアドレスがそれぞれ用いられる。
【０４２９】
ローカルアクセス制御部２５は、生成したメッセージの出力先をメッセージ送信部３５とホームアクセス制御部２７とのいずれにするかは、ステップＳ１１３の場合と同じく宛先ノード番号と当該ノードＰＥｉのノード番号との比較結果によって決定する。ローカルアクセス制御部２５は、また、ステップＳ１３１で読み出したＳｙｓカウンタの値に「１」足した（ｉｎｃ操作）値に、メッセージに付加されていたｍｉｄで指定されるリクエスト管理テーブル３７のエントリのＳｙｓカウンタの値を、更新する。ステップＳ２１３の処理が終了すると、受けたメッセージに関する処理を終了する。
【０４３０】
ステップＳ１３５では、ローカルアクセス制御部２５は、メッセージについていたブロックデータ（１２８バイト）を、キャッシュメモリ２１の該当するブロックに書き込む。このブロックデータが書き込まれるエントリは、リクエスト管理テーブル３７から得られるアドレスの第１９ビットから第７ビットまでの１３ビットに０ｘ０から０ｘｆまで変化する４ビットを下位に付加した１７ビットのインデックス信号で指定される合計１６エントリ（１２８バイト）である。ステップＳ１３５の処理が終了すると、ステップＳ１３６に進む。
【０４３１】
ステップＳ１３６では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られるアクセスの種類を検査する。ステップＳ１３６での検査の結果、アクセスの種類がストアであった場合には、ステップＳ１３７に進む。ステップＳ１３６での検査の結果、アクセスの種類がロードであった場合には、ステップＳ１３８に進む。
【０４３２】
ステップＳ１３７では、ローカルアクセス制御部２５は、リクエスト管理テーブル３７から得られるデータ（６４ビット）を、キャッシュメモリ２１の該当するエントリに書き込む。ここで、データが書き込まれるエントリは、リクエスト管理テーブル３７から得られるアドレスの第１９ビットから第３ビットまでの１７ビットで指定されるエントリ（６４ビット）である。
【０４３３】
ローカルアクセス制御部２５は、また、受けたメッセージのｍｉｄで指定されるリクエスト管理テーブル３７中のエントリのＰｒｃビットおよびＳｙｓカウンタの値を更新する、ここで、Ｐｒｃビット及びＳｙｓカウンタの値をどのような値に更新するかは、図２２に示すテーブルに従って求められる。
【０４３４】
ローカルアクセス制御部２５は、さらにタグメモリ２２の内容を更新する。更新されるエントリは、リクエスト管理テーブル３７より得られるアドレスの第１９ビットから第７ビットまでの１３ビットで特定されるアドレスのものである。更新されるデータは、ブロックの状態およびタグアドレスである。
【０４３５】
ブロックの状態は、アクセスの種類（ここではストア）と受けたメッセージの種類によって、図２２に示すテーブルに従って決められる。ここで、ブロックの状態には、タグアドレスはリクエスト管理テーブル３７から読み出したアドレスの第３９ビットから第２０ビットまでの上位２０ビットが用いられる。
【０４３６】
ローカルアクセス制御部２５は、さらに、プロセッサ２０への完了通知も行う。このとき、リクエスト管理テーブル３７より得られるｉｄ（２ビット）をプロセッサ２０へ出力し、どのメモリアクセスが完了したのかを通知する。ステップＳ１３７の処理が終了すると、受けたメッセージの処理は終了する。
【０４３７】
ステップＳ１３８では、ローカルアクセス制御部２５は、キャッシュメモリ２１からリクエスト管理テーブル３７から得られたアドレスの第１９ビットから第３ビットまでの１７ビットで指定されるエントリの６４ビットデータを読み出し、リクエスト管理テーブル３７から得られるｉｄとともにプロセッサ２０へ渡す。
【０４３８】
ローカルアクセス制御部２５は、さらにリクエスト管理テーブル３７の内容とタグメモリ２２の内容とを更新する。このリクエスト管理テーブル３７の内容の更新の処理と、タグメモリ２２の内容の更新の処理は、ステップＳ１３７におけるそれぞれの処理と同一である。ステップＳ１３８の処理が終了すると、受けたメッセージの処理は終了する。
【０４３９】
以下、この実施の形態におけるホームアクセス制御部２７の動作について、説明する。
【０４４０】
なお、以下の説明においても、第１の実施の形態の場合と同様に、ホームアクセス制御部２７が、主メモリ３０或いはディレクトリメモリ３１にアクセスするときは、実際には主メモリアクセス制御部２８或いはディレクトリメモリアクセス制御部２９の機能が用いられる。
【０４４１】
第１の実施の形態ではステップＳ１４３（図１２参照）で分岐するための処理タイプがＣＡ〜ＣＥの５タイプであったものが、第２の実施の形態においては、図２３に示すように、ＣＦ、ＣＧ、ＣＨの３タイプが加わった８タイプに増加している。また、図２４のテーブルに示すように、ＢｌｋＲｄＥｘあるいはＵｐｇｒａｄｅメッセージを受けた場合の処理タイプや、次状態などが第１の実施の形態のもの（図１４）と異なる。
【０４４２】
図２３のフローチャートに示すように、ステップＳ１４３で処理タイプがＣＦであると判定されたときは、ステップＳ２２１に進む。ステップＳ１４３で処理タイプがＣＧであると判定されたときは、ステップＳ２２２に進む。ステップＳ１４３で処理タイプがＣＨであると判定されたときは、ステップＳ２２３に進む。
【０４４３】
ステップＳ２２１では、ホームアクセス制御部２７は、ステップＳ１４４（図１２）と同様に、メッセージ生成情報の生成およびリモートバッファ３４への出力を行う。ただし、ここで、ホームアクセス制御部２７から生成するメッセージの種類は、ＰｒｃＤａｔＥｘあるいはＰｒｃＡｃｋに限られる。ステップＳ２２１の処理が終わると、ステップＳ２２４に進む。
【０４４４】
ステップＳ２２２では、ホームアクセス制御部２７は、ステップＳ１４５（図１２）と同様に、主メモリ３０からブロックデータを読み出し、その読み出したブロックデータを付加したメッセージを生成し、リプライバッファ３２に出力する。ここで、ホームアクセス制御部２７が生成するメッセージの種類は、ＰｒｃＤａｔＥｘに限られる。ステップＳ２２２の処理が終わると、ステップＳ２２４に進む。
【０４４５】
ステップＳ２２３では、ホームアクセス制御部２７は、ステップＳ１４６（図１２）と同様に、メッセージを生成し、リプライバッファ３２に出力する。ここで、ホームアクセス制御部２７が生成するメッセージの種類は、ＰｒｃＡｃｋに限られる。ステップＳ２２３の処理が終わると、ステップＳ２２４に進む。
【０４４６】
ステップＳ２２４では、ホームアクセス制御部２７は、ステップＳ１４４（図１２）と同様に、メッセージ生成情報の生成及びリモートバッファ３４への出力を行うここで、ホームアクセス情報が生成するメッセージ情報の種類はＩｎｖに限られる。ステップＳ２２４の処理が終わるとステップＳ１４８に進む。
【０４４７】
以降の処理については、第１の実施の形態におけるホームアクセス制御部２７の処理と同一である。
【０４４８】
以下、この実施の形態におけるマルチプロセッサシステムの動作の具体例について、第１の実施の形態と異なる部分について、説明する。
【０４４９】
以降、ノードＰＥ１で、ストアアクセスがｉｄ＝１でアドレス０ｘ００４００３００００に行われた場合の動作を説明する。
【０４５０】
ノードＰＥ１のプロセッサ２０がアドレス０ｘ００４００３００００にｉｄ＝１でストアアクセスを行ったとする。
【０４５１】
プロセッサ２０が行ったメモリアクセスはローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうか、また空いているエントリが存在するかどうかを検査する。
【０４５２】
リクエスト管理テーブル３７は検査した結果をペンディング信号にして出力する（「１」の場合、同一キャッシュブロックに対するリクエストが存在する、あるいは空いているエントリが存在しないことを示す）。ローカルバッファ３８は、ペンディング信号が「１」の場合ローカルリクエスト制御部２５への出力を行わず、ペンディング信号が「０」になるのを待って、ローカルアクセス制御部２５に出力する。
【０４５３】
前記メモリアクセス（アクセスの種類はストア、アドレスは０ｘ００４００３００００、ｉｄ＝１）を受けたローカルアクセス制御部２５は、まず、タグメモリ２２の０ｘ０６００番地（ローカルバッファから得たアドレス０ｘ００４００３００００の第１９ビット〜第７ビットの１３ビット）のデータを読み出す。読み出された状態がＩであった場合、図７より処理タイプはＡＡ、発行するメッセージはＢｌｋＲｄＥｘ、次状態はＩに決定する（ステップＳ１１１）。
【０４５４】
処理タイプがＡＡであることから（ステップＳ１１３）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。またこの時、リクエスト管理テーブル３７からは空いているエントリとして０番が指定されているとする。生成出力するメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」（リクエスト管理テーブルが出力している空きエントリの番号）、要求元ノード番号は０ｘ００１となる。また、宛先ノード番号と要求元ノード番号が両者とも０ｘ００１と一致するので、出力先は当該ノードＰＥ１のホームアクセス制御部２７となる。また、リクエスト管理テーブルの０番エントリに、Ｐｒｃビットは「１」、Ｓｙｓカウンタは「１」、チェックビットは「０」、アクセスの種類はストア、アドレスは０ｘ００４００３００００、ｉｄは「１」、およびストアデータを書き込む（ステップＳ１１３）。
【０４５５】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＩに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。以上で、ローカルアクセス制御部２５は、ストアアクセスの処理を終了する。
【０４５６】
前記ＢｌｋＲｄＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＢｌｋＲｄＥｘ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１）を受けたホームアクセス制御部２７は次のように動作する。
【０４５７】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報が、それぞれ０、Ｃ、０ｘ００３であった場合の動作を説明する。受けたメッセージがＢｌｋＲｄＥｘであり、読み出した状態がＣ、保持ノード情報が０ｘ００３でありアンキャッシュドでなく、要求元ノード番号と当該ノード番号が一致することから、処理タイプはＣＧ、次状態はＵＰ、保持ノード操作はｃｏｕｎｔ、出力するメッセージの種類はＰｒｃＤａｔＥｘとＩｎｖ、出力先はそれぞれリプライバッファ３２とリモートバッファ３４に決定する（図２４参照）。また、コンフリクトキューが空とすると、コンフリクトキューから読み出したメッセージの処理でなく、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０４５８】
これらの情報を元に、ディレクトリメモリ３１のデータを、トップビットは「０」、状態はＵＰ、保持ノード情報は０ｘｆｆに更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込を行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０４５９】
処理タイプがＣＧであることから（ステップＳ１４３）、主メモリ３０の０ｘ０００６０００番地〜０ｘ０００６００ｆ番地までの６４ビット×１６エントリ＝１２８バイトのブロックデータを読み出し、生成するメッセージに付加しリプライバッファ３２に出力する。このメッセージは、宛先ノード番号を０ｘ００１、メッセージの種類をＰｒｃＤａｔＥｘ、アドレスを０ｘ００４００３００００、ｍｉｄを「０」、要求元ノード番号を０ｘ００１、ブロックデータを当該ステップＳ２２２で読み出したブロックデータとするメッセージである（ステップＳ２２２）。
【０４６０】
メッセージの生成出力を終えると、Ｉｎｖメッセージの生成情報を生成し、リモートバッファ３４へ出力する。生成するメッセージ生成情報は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００００、ｍｉｄを「０」、要求元ノード番号を０ｘ００１、保持ノード情報を０ｘ００３とする（ステップＳ２２４）。
【０４６１】
このＩｎｖメッセージ生成情報のリモートバッファ３４への出力を終えると、コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。
【０４６２】
図１６より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＢｌｋＲｄＥｘであるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、ＢｌｋＲｄＥｘメッセージの処理を終了する。
【０４６３】
ＰｒｃＤａｔＥｘメッセージを受け取たリプライバッファ３２は、その情報をローカルアクセス制御部２５へ出力する。
【０４６４】
前記ＰｒｃＤａｔＥｘメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＰｒｃＤａｔＥｘ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１、ブロックデータ）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の０（＝ｍｉｄ）番エントリの情報を読みだし、Ｓｙｓカウンタは「１」、アクセスの種類はストア、アドレスは０ｘ００４００３００００、チェックビットは「０」、ｉｄは「１」という情報を得る（ステップＳ１３１）。
【０４６５】
Ｃｍｐメッセージではなく（ステップＳ２１１）、ブロックデータ付きのメッセージであるから（ステップＳ１３２）、キャッシュメモリ２１の０ｘ０６０００番地から０ｘ０６００ｆ番地に、メッセージに付加されていたブロックデータを書き込む（ステップＳ１３５）。
【０４６６】
そして、アクセスタイプがストアであることから（ステップＳ１３６）、キャッシュメモリ２１の０ｘ０６０００番地のデータ６４ビットを、リクエスト管理テーブル３７から得たストアデータに更新する処理を行う。また、リクエスト管理テーブルの０（＝ｍｉｄ）番エントリのＰｒｃビットを「０」に更新する。
【０４６７】
また、タグメモリ２２の０ｘ０６００番地のデータを、状態はＤ、タグアドレスは０ｘ００４００（リクエスト管理テーブルから得たアドレス０ｘ００４００３０００８の第３９ビット〜第２０ビットの２０ビット）に更新する。
【０４６８】
また、プロセッサへリクエスト管理テーブル３７から得たｉｄを出力し、ｉｄ＝１のメモリアクセスが完了した旨を通知する（ステップＳ１３７）。以上でローカルアクセス制御部２５の処理は終わる。この時、リクエスト管理テーブル３７の０番エントリのＳｙｓカウンタは「１」のままである。そのため、プロセッサ２０に出力しているシステム完了信号は「０」のままとなる。
【０４６９】
この段階で、プロセッサ２０にとって、ｉｄ＝１で行ったストアアクセスは完了しており、また、ｉｄ＝１で別のメモリアクセスを発行することが可能となる。
【０４７０】
リモートバッファ３４に出力された前記Ｉｎｖメッセージ生成情報に関する処理は第１の実施の形態における動作と同じである。宛先ノード番号を０ｘ０００〜０ｘ０ｆｆ（０ｘ００１除く）、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００００、ｍｉｄを「０」、要求元ノード番号を０ｘ００１とする２５５個のメッセージが生成され、相互結合網１０を介して各宛先ノードＰＥｉのローカルアクセス制御部２５に送られる。
【０４７１】
各ノードのローカルアクセス制御部２５では、Ｉｎｖメッセージを処理し、Ａｃｋメッセージを生成する。このＡｃｋメッセージは宛先ノード番号を０ｘ００１、メッセージの種類をＡｃｋ、アドレスを０ｘ００４００３００００、ｍｉｄを「０」、要求元ノード番号を０ｘ００１とするメッセージである。
【０４７２】
これらのメッセージは相互結合網１０を介してノードＰＥ１のホームアクセス制御部２７に送られてくる。これらＡｃｋメッセージを受け取ったホームアクセス制御部は順次処理していき、最後のメッセージを受け取ったときに、ディレクトリメモリ３１のトップビットを「０」、状態をＭ、保持ノード情報を０ｘ００１に更新し、Ｃｍｐメッセージを生成してリプライバッファ３４へ出力する。
【０４７３】
Ｃｍｐメッセージを受け取たリプライバッファ３２はその情報をローカルアクセス制御部２５へ出力する。
【０４７４】
前記Ｃｍｐメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＣｍｐ、アドレスは０ｘ００４００３００００、ｍｉｄは「０」、要求元ノード番号は０ｘ００１）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の０（＝ｍｉｄ）番エントリの情報を読みだし、Ｓｙｓカウンタは「１」、アクセスの種類はストア、アドレスは０ｘ００４００３００００、チェックビットは「０」、ｉｄは「１」という情報を得る（ステップＳ１３１）。
【０４７５】
Ｃｍｐメッセージであるので、リクエスト管理テーブル３７のｍｉｄ＝０番のエントリのＳｙｓカウンタの値を、読み出した値「１」から「１」引いた「０」に更新し（ステップＳ２１１）、処理を終了する。
【０４７６】
ＰｒｃＤａｔＥｘメッセージを受けたときにＰｒｃビットが「０」に変更され、Ｃｍｐメッセージを受けたときにＳｙｓカウンタが「０」に更新される。両方のメッセージを受けて始めて当該エントリが空きエントリとなる。この時、他のエントリも全て空きエントリであればシステム完了信号が１となる。
【０４７７】
この実施の形態のマルチプロセッサにおける、プロセッサ２０が行うメモリアクセスから始まる、ノードＰＥｉ間でやり取りされるメッセージのシーケンスを、図２５に示す。
【０４７８】
図２５において、括弧で囲まれたメッセージは生成されない場合が存在することを表す。逆に、括弧で囲まれていないものは必ず生成されることを表している。また、矢印の分岐は、分岐先のメッセージのどれかが出力されることを表している。
【０４７９】
図２５から明らかなように、ノードＰＥｉ間でやり取りされるメッセージのシーケンスにループは存在しない。
【０４８０】
従って、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスを行ってから、その結果を得るまでの処理が無限ループに陥ることがない。このため、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスに対する結果を有限時間内に得ることを保証することができる。
【０４８１】
この実施の形態のマルチプロセッサシステムにおける、メッセージの出力元モジュールと出力先モジュールの関係は、第１の実施の形態と同様に、図１８に示すものとなる。従って、この実施の形態におけるマルチプロセッサシステムでも、依存関係にループができず、デッドロックの発生を防ぐことができる。
【０４８２】
［第３の実施の形態］
この実施の形態にかかる疎結合型マルチプロセッサシステムの構成は、第１の実施の形態で示したもの（図１）と実質的に同一であるが、後述する一部の点において異なる。
【０４８３】
また、この実施の形態の疎結合型マルチプロセッサシステムにおいては、相互結合網１０を介してノードＰＥｉ間でやり取りされるメッセージの種類及び構成と、ノードＰＥｉ（ｉ＝０〜１０２３）の構成が、第１の実施の形態のものと異なる。
【０４８４】
以下、この実施の形態の疎結合型マルチプロセッサシステムにおいて、相互結合網１０を介してノードＰＥｉ間でやり取りされるメッセージについて、説明する。
【０４８５】
この実施の形態において、メッセージは、第１の実施の形態でも説明したＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒ、Ａｃｋ、ＡｃｋＤａｔａ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、Ｃｍｐの１２種に、ＡｃｋＸ、ＩｎｖＸ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの４種を加えた１６種類のメッセージからなる。
【０４８６】
ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、ＢｌｋＷｒの４種は、メモリアクセスが行われたノードＰＥｉから、主メモリ３０にデータを保持するノードＰＥｉへ送信される要求メッセージである。ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖ、ＩｎｖＸの４種は、主メモリ３０にデータを保持するノードＰＥｉから当該データのコピーをキャッシュメモリ２１に保持するノードＰＥｉへ送信される要求メッセージである。
【０４８７】
ＡｃｋＸは、データのコピーをキャッシュメモリ２１に保持するノードＰＥｉから主メモリ３０にデータを保持するノードＰＥｉへ送信される報告メッセージである。Ａｃｋ、ＡｃｋＤａｔａの２種は、メモリアクセスが行われたノードＰＥｉから主メモリ３０にデータを保持するノードＰＥｉへ送信される報告メッセージである。
【０４８８】
ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘの２種は、主メモリ３０にデータを保持するノードＰＥｉからメモリアクセスが行われたノードＰＥｉへ送信されるメモリアクセス完了メッセージである。Ｃｍｐ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの３種は、データのコピーをキャッシュメモリ２１に保持するノードＰＥｉからメモリアクセスが行われたノードＰＥｉへ送信されるメモリアクセス完了メッセージである。
【０４８９】
この実施の形態において、メッセージは、基本メッセージとブロック付きデータメッセージに加えて、保持ノード数付きメッセージの３種類に分類される。ＢｌｋＲｄＳｈ、ＢｌｋＲｄＥｘ、Ｕｐｇｒａｄｅ、Ａｃｋ、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、ＩｎｖＸ、ＡｃｋＸの８種のメッセージは、基本構成のメッセージである。ＢｌｋＷｒ、ＡｃｋＤａｔａ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの６種のメッセージは、ブロックデータ付きのメッセージである。最後に、Ｉｎｖ、Ｃｍｐの２種のメッセージは、保持ノード数付きのメッセージである。
【０４９０】
基本メッセージは、図２６（ａ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（計１６個なので４ビットで表現）、要求元ノード番号（１０ビット）、ｍｉｄ（２ビット）、アドレス（４０ビット）の計６６ビットで構成される。
【０４９１】
ブロックデータ付きメッセージは、図２６（ｂ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（４ビット）、要求元ノード番号（１０ビット）、ｉｄ（２ビット）、アドレス（４０ビット）に加えて、ブロックサイズのデータ（１２８バイト）の計６６ビット＋１２８バイトで構成される。
【０４９２】
保持ノード数付きメッセージは、図２６（ｃ）に示すように、宛先ノード番号（１０ビット）、メッセージの種類を表すコード（４ビット）、要求元ノード番号（１０ビット）、ｉｄ（２ビット）、アドレス（４０ビット）に加えて、保持ノード数（１０ビット）の計７６ビットで構成される。
【０４９３】
以下、この実施の形態の疎結合型マルチプロセッサシステムにおける各ノードＰＥｉの構成について、説明する。
【０４９４】
図２７は、この実施の形態におけるノードＰＥｉの機能構成を示すブロック図である。図２７に示すノードＰＥｉは、図２に示した第１の実施の形態のものとほぼ同様であるため、以下では、図２７に示すノードＰＥｉについて、第１の実施の形態のものと異なる部分について、説明する。
【０４９５】
メッセージ受信部３６は、第１の実施の形態のものとほぼ同じである。ただし、この実施の形態のメッセージ受信部３６には、ＩｎｖＸ、ＡｃｋＸ、Ｃｍｐ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲメッセージを受けたとき、次のように機能する。
【０４９６】
ＩｎｖＸメッセージを受け取ったときは、メッセージ受信部３６は、そのメッセージをリクエストバッファ３３に出力する。ＡｃｋＸメッセージを受け取ったときは、メッセージ受信部３６は、そのメッセージをホームアクセス制御部２７に出力する。ＣｍｐＤａｔＳｈＲメッセージ或いはＣｍｐＤａｔＤｙＲメッセージを受け取ったときは、メッセージ受信部３６は、これらのメッセージをリプライバッファ３２に出力する。
【０４９７】
Ｃｍｐメッセージの場合、メッセージ受信部は、後述するリクエスト管理テーブル３７のエントリのうちのメッセージに付加されているｍｉｄで指定されるエントリの受信メッセージ数を読み出し、値が「０」の場合、メッセージに付加されている保持ノード数を設定し、「０」でない場合、読み出した値から「１」引いた値を設定する。メッセージ受信部３６は、読み出した値が「１」の場合にのみＣｍｐメッセージをリプライバッファ３２へ出力し、それ以外の場合はＣｍｐメッセージをリプライバッファ３２には出力せず、処理を終了する。
【０４９８】
リプライバッファ３２は、第１の実施の形態で説明したものに対応するＣｍｐ、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘに加え、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの計５種のメッセージを受け取る。ここで、Ｃｍｐメッセージは、保持ノード数付きメッセージであり、ＣｍｐＤａｔＳｈ、ＣｍｐＤａｔＥｘ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの各メッセージは、ブロックデータ付きのメッセージである。
【０４９９】
リプライバッファ３２は、４エントリで構成される。リプライバッファ３２の各エントリは、ブロックデータ付きメッセージ（６６ビット＋１２８バイト）、あるいは保持ノード数付きメッセージ（７６ビット）を保持することができる。
【０５００】
リクエストバッファ３３は、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、Ｉｎｖに加え、ＩｎｖＸの計５種のメッセージを受け取る。ここで、ＩｎｔｖＳｈ、ＩｎｔｖＥｘ、ＩｎｖＸは基本メッセージであり、Ｉｎｖは保持ノード数付きのメッセージである。リクエストバッファ３３の各エントリ、および主メモリ３０に設けたリクエスト退避キューの各エントリは、それぞれ保持ノード数付きのメッセージを受け取ることができるだけのサイズからなる。
【０５０１】
リモートバッファ３４は、第１の実施の形態のものとほぼ同一であるが、ＩｎｖＸメッセージを生成する機能が加わる点と、第１の実施の形態におけるそれとＩｎｖメッセージの生成方法の点で、第１の実施の形態のものと異なる。以下、この実施の形態での、ＩｎｖＸメッセージ生成情報、あるいはＩｎｖメッセージ生成情報を受けた場合におけるリモートバッファ３４によるメッセージの生成方法について、説明する。
【０５０２】
ＩｎｖＸメッセージ生成情報において、メッセージの生成のために不足している情報は、宛先ノード番号のみである。この場合、宛先ノード番号の異なる複数のメッセージが生成される。この宛先ノード番号は、保持ノード情報から生成される。この保持ノード情報はコースベクタ形式であり、この形式で表されている複数のノードＰＥｉ（要求元ノードを除く）に対して宛先の異なる同一のメッセージを生成し出力することとなる。
【０５０３】
例えば、保持ノード情報が“００１１０１００”で要求元ノード番号が“００１００１０１１０”の場合、宛先ノードは、ＰＥ２５６〜ＰＥ３８３、ＰＥ５１２〜ＰＥ８０７となり、合計３８４ノードに対してＩｎｖＸメッセージが送信される。また、例えば、保持ノード情報が“１１００１０１１”で要求元ノード番号が“００１００１０１１０”の場合、宛先ノードは、ＰＥ０〜ＰＥ１４９、ＰＥ１５１〜ＰＥ２５５、ＰＥ３８４〜ＰＥ５１１、ＰＥ８０８〜ＰＥ１０２３となり、合計６７９ノードに対してＩｎｖＸメッセージが送信される。
【０５０４】
Ｉｎｖメッセージ生成情報で、不足している情報は、宛先ノード番号および保持ノード数である。この場合、ＩｎｖＸメッセージ同様、宛先ノード番号の異なる複数のメッセージが生成される。宛先ノード番号の生成方法は、ＩｎｖＸメッセージと同様である。保持ノード数は、メッセージ生成情報に付加されている保持ノード情報から求められる。これは、後述するディレクトリメモリ３１に蓄えられた保持ノード情報に対するホームアクセス制御部２７が行うｃｏｕｎｔ操作と同じであり、受けた保持ノード情報の下位８ビットをコースベクタ形式として求められる。
【０５０５】
ローカルアクセス制御部２５と、ホームアクセス制御部２７とは、それぞれ第１の実施の形態のものとほぼ同様の機能を有するが、後述する一部の点でその機能及び動作が異なる。ローカルアクセス制御部２５とホームアクセス制御部２７において、第１の実施の形態と異なる部分については、さらに詳しく後述する。
【０５０６】
以下、この実施の形態におけるローカルアクセス制御部２５の動作について、説明する。
【０５０７】
なお、以下の説明においても、第１の実施の形態の場合と同様に、ホームアクセス制御部２７が、主メモリ３０或いはディレクトリメモリ３１にアクセスするときは、実際には主メモリアクセス制御部２８或いはディレクトリメモリアクセス制御部２９の機能が用いられる。
【０５０８】
ローカルアクセス制御部２５が、リクエストバッファ３３が出力するメッセージを受けた場合の処理の流れは、第１の実施の形態におけるもの（図８）と同じである。ただし、この実施の形態においては、処理タイプ、出力するメッセージの種類、次状態は、図２８のテーブルに示すものとなる。
【０５０９】
また、ステップＳ１２３およびステップＳ１２４（図８）において、ローカルアクセス制御部２５が生成するメッセージの宛先ノード番号が異なる。また、ローカルアクセス制御部２５が、Ｃｍｐメッセージを生成する場合には、生成されるＣｍｐメッセージに保持ノード数を付加する必要がある。Ｃｍｐメッセージに付加する保持ノード数には、受けたメッセージ（必ずＩｎｖメッセージ）に付加されている保持ノード数が用いられる。
【０５１０】
生成されるメッセージの宛先ノード番号は、出力するメッセージの種類により異なる。Ｃｍｐ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲメッセージの場合、宛先ノード番号には、受けたメッセージの要求元ノード番号が用いられる。ＡｃｋＸメッセージの場合、宛先ノード番号には、受けたメッセージのアドレスの第３９ビットから第３０ビットまでの上位１０ビットが用いられる。
【０５１１】
以下、リプライバッファ３２が出力するメッセージを受けつけた場合に、ローカルアクセス制御部２５が実行する処理について、図２９、図３０を参照しながら説明する。
【０５１２】
この実施の形態では、ローカルアクセス制御部２５は、ステップＳ１３１の後に、ステップＳ３１１でメッセージを出力するかどうかを判定する。ステップＳ３１１でメッセージを出力する必要があると判定されたときは、ローカルアクセス制御部２５は、ステップＳ３１１でメッセージを生成、出力してから、ステップＳ１３２に進む。ステップＳ３１１でメッセージを出力する必要がないと判定されたときは、ステップＳ１３２に進む。
【０５１３】
ステップＳ３１１において、メッセージを出力するかどうかは、図３０のテーブルに示すように、受けたメッセージの種類で決定できる。受けたメッセージの種類がＣｍｐＤａｔＳｈあるいはＣｍｐＤａｔＥｘの場合には、ローカルアクセス制御部２５は、メッセージの出力を行う必要はない。受けたメッセージの種類がＣｍｐ、ＣｍｐＤａｔＳｈＲ、ＣｍｐＤａｔＤｙＲの場合には、ローカルアクセス制御部２５は、受けたメッセージに応じてメッセージを生成し、出力する。
【０５１４】
ステップＳ３１１において生成されるメッセージの宛先ノード番号には、受けたメッセージのアドレスの第３９ビットから第３０ビットまでの上位１０ビットを、メッセージの種類は図３０で求められるものが用いられる。ステップＳ３１１において生成されるメッセージのアドレス、ｍｉｄ、要求元ノード番号には受けたメッセージに付加されていたものが用いられる。
【０５１５】
また、生成されるメッセージがブロックデータ付きのメッセージ（ここでは、ＡｃｋＤａｔａメッセージに限られる）である場合には、ローカルアクセス制御部２５は、受けたメッセージに付加されていたブロックデータを、出力するメッセージに付加する。
【０５１６】
ローカルアクセス制御部２５は、生成したメッセージの出力先がメッセージ送信部３５とホームアクセス制御部２７とのいずれになるかは、ステップＳ１１３（図６）の場合と同様に、宛先ノード番号と当該ノードＰＥｉのノード番号との比較結果によって決定する。
【０５１７】
以降の処理は、第１の実施の形態におけるローカルアクセス制御部２５の動作と同一である。
【０５１８】
以下、この実施の形態におけるホームアクセス制御部２７の動作について、説明する。
【０５１９】
この実施の形態においては、ホームアクセス制御部２７の動作は、第１の実施の形態のもの（図１２）とほぼ同一であるが、Ａｃｋメッセージ、ＡｃｋＸメッセージ、ＡｃｋＤａｔａメッセージを受けた場合の動作が異なる。
【０５２０】
図３１のテーブルは、これらのメッセージを受けた場合に、決定される処理タイプや次状態などを示す。また、ステップＳ１４８（図１２）において、ホームアクセス制御部２７は、コンフリクトキューからの読み出しを行うかどうかを、図３２のテーブルに従って判定する。
【０５２１】
以下、この実施の形態におけるマルチプロセッサシステムの動作の具体例について、第１の実施の形態と異なる部分について、説明する。
【０５２２】
ノードＰＥ１のプロセッサ２０が、アドレス０ｘ００４００３００００に対してストアアクセスをｉｄ＝２で行った場合の動作を説明する。
【０５２３】
プロセッサ２０が行ったメモリアクセスは、ローカルバッファ３８に出力される。メモリアクセスを受けたローカルバッファ３８は、リクエスト管理テーブル３７にアドレス（４０ビット）を出力し、同一キャッシュブロックに対するリクエストが存在するかどうかを検査する。存在しなければローカルアクセス制御部２５に対して出力する。
【０５２４】
前記メモリアクセス（アクセスの種類はストア、アドレスは０ｘ００４００３００００、ｉｄ＝２）を受けたローカルアクセス制御部２５は、まず、タグメモリ２２の０ｘ０６００番地（ローカルバッファから得たアドレス０ｘ００４００３００００の第１９ビット〜第７ビットの１３ビット）のデータを読み出す。ここで、読み出した状態がＳ、タグアドレスが０ｘ００４００の場合、図７より処理タイプはＡＡ、発行するメッセージはＵｐｇｒａｄｅ、次状態はＳに決定する（ステップＳ１１１）。
【０５２５】
処理タイプがＡＡであることから（ステップＳ１１２）、メッセージの生成出力およびリクエスト管理テーブル３７への登録を行う。発行されるメッセージの、宛先ノード番号は０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１となる。また、宛先ノード番号と要求元ノード番号が両者とも０ｘ００１と一致するので、出力先は当該ノードＰＥ１のホームアクセス制御部２７となる。また、この時リクエスト管理テーブルの２（＝ｉｄ）番エントリに、有効ビットは「１」、チェックビットは「０」、アクセスの種類はロード、アドレスは０ｘ００４００３００００、受信メッセージ数は「０」、およびストアデータを書き込む（ステップＳ１１３）。
【０５２６】
タグメモリの０ｘ０６００番地のエントリのデータを、状態はＣに、タグアドレスは０ｘ００４００（アドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する（ステップＳ１１８）。
【０５２７】
前記Ｕｐｇｒａｄｅメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＵｐｇｒａｄｅ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１）を受けたホームアクセス制御部２７は次のように動作する。
【０５２８】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。ここで読み出したトップビット、状態、保持ノード情報が、それぞれ０、Ｃ、０ｘ０ｅｆとする。受けたメッセージの種類がＵｐｇｒａｄｅであり、読み出した状態がＣであることから、処理タイプはＣＡ、次状態はＵＰ、保持ノード操作はｃｏｕｎｔに決定する（図１３参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０５２９】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＵＰ、保持ノード情報は０ｘ３７ｆに更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込を行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０５３０】
処理タイプがＣＡであるので（ステップＳ１４３）、メッセージ生成情報が生成されリモートバッファ３４に出力される。メッセージ生成情報は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００００、ｉｄを「２」、要求元ノード番号を０ｘ００１、保持ノード情報を０ｘ０７ｆとするものである（ステップＳ１４４）。
【０５３１】
メッセージの生成出力を終えると、コンフリクトキューから情報を読み出す必要があるかどうかを検査する（ステップＳ１４８）。図３２より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＵｐｇｒａｄｅであるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ｕｐｇｒａｄｅメッセージの処理を終了する。
【０５３２】
前記Ｉｎｖメッセージ生成情報（種類はＩｎｖ、アドレスは０ｘ００４００３００００、ｉｄは「１」、要求元ノード番号は０ｘ００１、保持ノード情報は０ｘ０７ｆ）を受け取ったリモートバッファ３４は、メッセージの種類をＩｎｖ、アドレスを０ｘ００４００３００００、ｉｄを「１」、要求元ノード番号を０ｘ００１と、保持ノード数を０ｘ３７ｆとし、宛先ノード番号が０ｘ０００〜０ｘ３７ｆの内０ｘ００１を除いた８９６個のメッセージを順次生成しメッセージ送信部３５に出力する。
【０５３３】
これらのＩｎｖメッセージはノードＰＥ１のメッセージ送信部３５、相互結合網、各ノードＰＥ０〜ＰＥ８９５（ＰＥ１除く）のメッセージ受信部３６、リクエストバッファ３３を介してローカルアクセス制御部２５に出力される、
【０５３４】
前記Ｉｎｖメッセージを受けた各ノードＰＥｉ（ｉ＝０、２、３、・・・、８９５）のローカルアクセス制御部２５は次のように動作する。
【０５３５】
Ｉｎｖメッセージ（宛先ノード番号は受けたノードの番号、メッセージの種類はＩｎｖ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１、保持ノード数は０ｘ３７ｆ）を受けたローカルアクセス制御部２５は、タグメモリ２２の０ｘ０６００番地のデータを読みだす。読み出したタグアドレスが０ｘ００４００と一致するかどうか、また状態がなにであるかによって、処理タイプ、出力するメッセージの種類、タグメモリ２２の次状態が決定する（図２８参照）（ステップＳ１２１）。
【０５３６】
この場合必ず処理タイプがＢＡとなり（ステップＳ１２２）、Ｃｍｐメッセージの生成が行われる。このＣｍｐメッセージは、宛先ノード番号を０ｘ００１、メッセージの種類をＣｍｐ、アドレスを０ｘ００４００３０００００、ｉｄを「２」、要求元ノード番号を０ｘ００１、保持ノード数を０ｘ３７ｆとするメッセージである。出力先は宛先ノード番号０ｘ００１と当該ノード番号の比較結果によって決定するが、この場合必ずメッセージ送信部３５となる（ステップＳ１２３）。
【０５３７】
メッセージの生成出力を終えると、タグメモリの更新を行う（ステップＳ１２５）。更新するエントリは先ほど読み出を行った０ｘ０６００番地のエントリであり、状態は図２８から求まる次状態に更新し、タグアドレスは先ほどタグメモリ２２から読み出した値をそのまま書き込む。
【０５３８】
また、リクエスト管理テーブル３７へ、受けたメッセージのアドレス（０ｘ００４００３００００）を出力する。リクエスト管理テーブル３７では、各エントリのアドレスと、ローカルアクセス制御部２５が出力するアドレスの、第３９ビット〜第７ビットが一致するかどうかを検査し、一致するエントリのチェックビットを「１」に更新する。以上でローカルアクセス制御部２５は、Ｉｎｖメッセージの処理を終了する。
【０５３９】
ノードＰＥ０、ノードＰＥ２〜ノードＰＥ８９５からそれぞれＣｍｐメッセージ（宛先ノードは０ｘ００１、種類はＣｍｐ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１、保持ノード数は０ｘ３７ｆ）が相互結合網１０を介してノードＰＥ１に対して送信されてくる。その数は合計で８９５メッセージであり、全て同じメッセージである。
【０５４０】
メッセージを受けたノードＰＥ１のメッセージ受信部３６は次のように動作する。メッセージに付加されているｉｄ＝２で指定されるリクエスト管理テーブル３７のエントリから受信メッセージ数を読み出す。最初のＣｍｐメッセージの場合、その値は「０」であり、リクエスト管理テーブル３７のｉｄ＝２で指定されるエントリの受信メッセージ数の値を、受けたメッセージに付加されている保持ノード数０ｘ３７ｆから１引いた値０ｘ３７ｅに更新する。このＣｍｐメッセージはどのモジュールにも出力せず、以上の処理が終了するとメッセージを破棄する。
【０５４１】
次にＣｍｐメッセージをメッセージ受信部３６が受けると、同じくメッセージに付加されているｉｄ＝２で指定されるリクエスト管理テーブル３７のエントリから受信メッセージ数を読み出す。先ほどこの値は０ｘ３７ｅに更新されており０ではないため、この値から「１」引いた値０ｘ３７ｄに更新する。このＣｍｐメッセージはどのモジュールにも出力せず、以上の処理が終了するとメッセージを破棄する。
【０５４２】
さらに、Ｃｍｐメッセージを順次受け取り、リクエスト管理テーブル３７の２番エントリの受信メッセージ数の値が「１」引かれていく。そして、最後の８９５個目のメッセージを受け取ったとき、次のように動作する。
【０５４３】
メッセージに付加されているｉｄ＝２で指定されるリクエスト管理テーブル３７のエントリから受信メッセージ数を読み出す。この値は０ｘ００１に更新されており０ではないため、この値から「１」引いた値０ｘ０００に、リクエスト管理テーブル３７のｉｄ＝２で指定されるエントリの受信メッセージ数の値を更新する。また、読み出した値が０ｘ００１であることから、リプライバッファ３２に対して受けたＣｍｐメッセージを出力する。
【０５４４】
Ｃｍｐメッセージを受け取ったリプライバッファ３２はその情報をローカルアクセス制御部２５に出力する。
【０５４５】
Ｃｍｐメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＣｍｐ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１）を受けたローカルアクセス制御部２５は、リクエスト管理テーブル３７の２（＝ｉｄ）番エントリの情報を読みだす。ここでは、チェックビットは「０」、アクセスの種類はストア、アドレスは０ｘ００４００３００００、ストアデータを得る（ステップＳ１３１）。
【０５４６】
次に、メッセージの出力が必要かどうかを判定する（ステップＳ３１１）。受けたメッセージがＣｍｐであるため、Ａｃｋメッセージの生成出力を行う。このＡｃｋメッセージは、宛先ノード番号を０ｘ００１（アドレス０ｘ００４００３００００の第３９ビット〜第３０ビットの１０ビット）、メッセージの種類をＣｍｐ、アドレスを０ｘ００４００３００００、ｉｄを「２」、要求元ノード番号を０ｘ００１とするメッセージである。宛先ノード番号と当該ノード番号が一致するので出力先はホームアクセス制御部２７となる（ステップＳ３１１）。
【０５４７】
メッセージの生成出力を終えると、データ付きのメッセージではなく（ステップＳ１３２）、チェックビットの値も「０」であるので（ステップＳ１３３）、キャッシュメモリ２１の０ｘ０６０００番地のデータ６４ビットを、リクエスト管理テーブル３７から得たストアデータに更新する処理を行う。また、リクエスト管理テーブルの２（＝ｉｄ）番エントリに有効ビットを「０」としたデータを書き込み、エントリを削除する。また、タグメモリ２２の０ｘ０６００番地のデータを、状態はＤ（図３０参照）、タグアドレスは０ｘ００４００（リクエスト管理テーブルから得たアドレス０ｘ００４００３００００の第３９ビット〜第２０ビットの２０ビット）に更新する。また、プロセッサへｉｄを出力し、ｉｄ＝２のメモリアクセスが完了した旨を通知する（ステップＳ１３７）。以上でローカルアクセス制御部２５は、Ｃｍｐメッセージの処理を終了する。
【０５４８】
前記Ａｃｋメッセージ（宛先ノード番号は０ｘ００１、メッセージの種類はＡｃｋ、アドレスは０ｘ００４００３００００、ｉｄは「２」、要求元ノード番号は０ｘ００１）を受けとったホームアクセス制御部２７は次のように動作する。
【０５４９】
まず、ディレクトリメモリ３１の０ｘ０００６００（メッセージに付加されていたアドレス０ｘ００４００３００００の第２８ビット〜第７ビットの２２ビット）番地をアクセスし、状態等のデータを読み出す。読み出したトップビット、状態、保持ノード情報はそれぞれ０、ＵＰ、０ｘ３７ｆに更新されており、その値が読み出される。受けたメッセージの種類がＡｃｋであり、読み出した状態がＵＰであることから、処理タイプはＣＥ、次状態はＭ、保持ノード操作はｓｅｔ、出力するメッセージはなしに決定する（図３１参照）。また、コンフリクトキューから読み出したメッセージの処理でなく、キューが空であり、処理タイプがＣＤでないことから、トップビットは読み出した値「０」のままとし、また、コンフリクトキューの先頭エントリの削除を行わないことが決定する（図１５参照）（ステップＳ１４１）。
【０５５０】
これらの情報を元に、ディレクトリメモリ３１の０ｘ０００６００番地のデータを、トップビットは「０」、状態はＭ、保持ノード情報は０ｘ００１に更新する。ここでは、データ付きのメッセージではないので主メモリへのブロックデータの書込を行わない。また、コンフリクトキューの先頭エントリの削除も行わない（ステップＳ１４２）。
【０５５１】
処理タイプがＣＥであることから（ステップＳ１４３）、コンフリクトキューからの読み出しが必要かどうかを検査する（ステップＳ１４８）。図３２より、コンフリクトキューから読み出したメッセージの処理でなく、メッセージの種類はＡｃｋであり、ステップＳ１４１で読み出したトップビットの値が「０」であるので、ステップＳ１４９でキューからの読み出しは行わない。以上で、ホームアクセス制御部２７は、Ａｃｋメッセージの処理を終了する。
【０５５２】
この実施の形態のマルチプロセッサにおける、プロセッサ２０が行うメモリアクセスから始まる、ノードＰＥｉ間でやり取りされるメッセージのシーケンスを、図３３に示す。
図３３において、括弧で囲まれたメッセージは生成されない場合が存在することを表す。逆に、括弧で囲まれていないものは必ず生成されることを表している。また、矢印の分岐は、分岐先のメッセージのどれかが出力されることを表している。
【０５５３】
図３３から明らかなように、ノードＰＥｉ間でやり取りされるメッセージのシーケンスにループは存在しない。
従って、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスを行ってから、その結果を得るまでの処理が無限ループに陥ることがない。このため、この実施の形態のマルチプロセッサシステムでは、プロセッサ２０がメモリアクセスに対する結果を有限時間内に得ることを保証することができる。
【０５５４】
この実施の形態のマルチプロセッサシステムにおける、メッセージの出力元モジュールと出力先モジュールの関係は、第１の実施の形態と同様に、図１８に示すものとなる。従って、この実施の形態におけるマルチプロセッサシステムでも、依存関係にループができず、デッドロックの発生を防ぐことができる。
【０５５５】
［実施の形態の変形］
本発明は、上記の第１〜第３の実施の形態で説明したものに限定されるものではなく、種々の変形が可能である。
以下、上記の第１〜第３の実施の形態の変形態様について、説明する。
【０５５６】
上記の第１〜第３の実施の形態におけるリプライバッファ３２の各エントリは、メッセージ情報を全て保持する必要はなく、少なくともローカルアクセス制御部２５がリプライバッファ３２から受けたメッセージを処理する際に使用している情報を保持していればよい。
【０５５７】
上記の第１、第３の実施の形態におけるリプライバッファ３２の４エントリは、それぞれメッセージの種類（４ビット）、ｍｉｄ（２ビット）、ブロックデータ（１２８バイト）を保持するだけでもよい。
【０５５８】
上記の第２の実施の形態におけるリプライバッファ３２のブロックデータ付きのメッセージを保持する４エントリは、それぞれメッセージの種類（４ビット）、ｍｉｄ（３ビット）、ブロックデータ（１２８バイト）を保持するだけで良い。また、Ｃｍｐメッセージを保持する１６エントリは、それぞれメッセージの種類（４ビット）、ｍｉｄ（３ビット）のみでもよい。
【０５５９】
上記の第１〜第３の実施の形態におけるリクエストバッファ３３の各エントリ、およびリクエストバッファ３３が管理し、主メモリ３０に設けるリクエスト退避キューの各エントリは、メッセージ情報を全て保持する必要はなく、少なくともローカルアクセス制御部２５がリクエストバッファ３３から受けたメッセージを処理する際に使用している情報を保持していればよい。
【０５６０】
上記の第１の実施の形態におけるリクエストバッファ３３の各エントリ、およびリクエスト退避キューの各エントリは、それぞれメッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（２ビット）、要求元ノード番号（１０ビット）を保持するだけでもよい。
【０５６１】
上記の第２の実施の形態におけるリクエストバッファ３３の各エントリ、およびリクエスト退避キューの各エントリは、それぞれメッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（３ビット）、要求元ノード番号（１０ビット）を保持するだけでもよい。
【０５６２】
上記の第３の実施の形態におけるリクエストバッファ３３の各エントリ、およびリクエスト退避キューの各エントリは、それぞれメッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（２ビット）、要求元ノード番号（１０ビット）、保持ノード数（１０ビット）を保持するだけでもよい。
【０５６３】
上記の第１〜第３の実施の形態におけるホームアクセス制御部２７が管理し、主メモリ３０に設けるコンフリクトキューの各エントリは、メッセージ情報を全て保持する必要はなく、少なくともホームアクセス制御部２５がメッセージを処理する際に使用している情報を保持していればよい。
【０５６４】
上記の第１、第３の実施の形態におけるコンフリクトキューの各エントリは、それぞれメッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（２ビット）、要求元ノード番号（１０ビット）を保持するだけでもよい。
【０５６５】
上記の第２の実施の形態におけるコンフリクトキューの各エントリは、それぞれメッセージの種類（４ビット）、アドレス（４０ビット）、ｍｉｄ（３ビット）、要求元ノード番号（１０ビット）を保持するだけでもよい。
【０５６６】
上記の第１〜第３の実施の形態において、ディレクトリメモリ３１およびディレクトリメモリアクセス制御部２９を持たないマルチプロセッサシステムを構成することも可能である。この場合は、ディレクトリメモリ３１に格納されていた情報は、主メモリ３０のある領域（ディレクトリ領域）に格納すればよい。ホームアクセス制御部２７が、ディレクトリメモリアクセス制御部を介して行っていたディレクトリメモリに対するアクセスは、主メモリアクセス制御部２８を介して主メモリ３０のディレクトリ領域をアクセスすることで実現される。
【０５６７】
上記の第１〜第３の実施の形態において、ホームアクセス制御部２７は、Ｕｐｇｒａｄｅメッセージを受け処理し、主メモリ３０に設けたコンフリクトキューに書き込む際にメッセージの種類を変更して書き込んでも良い。その際、メッセージの種類は、ＵｐｇｒａｄｅからＢｌｋＲｄＥｘに変更すればよい。
【０５６８】
上記の第１〜第３の実施の形態のリプライバッファ３２、リクエストバッファ３３、リモートバッファ３４などのエントリ数は、上述したものに限定されるものではない。
【０５６９】
上記の第１〜第３の実施の形態におけるメッセージは、ノードＰＥｉ間での処理要求及び応答を的確に伝えられるものであれば、その種類及び構成を様々に変形することが可能である。また、特に同一ノード間での要求（アクセス要求など）については、メッセージの形態をとらずに、ノード内に設けられた信号線を介して所定の信号を送ることで、その要求を伝える構成としてもよい。
【０５７０】
上記の第１〜第３の実施の形態において、一貫性維持制御部１６に含まれるキャッシュメモリアクセス制御部２３、タグメモリアクセス制御部２４、ローカルアクセス制御部２５、ホームアクセス制御部２７、主メモリアクセス制御部２８及びディレクトリメモリアクセス制御部２９の各機能は、それぞれ次のいずれのによって実現してもよい。
【０５７１】
１）プロセッサ２０による主メモリ３０に格納された処理プログラム（或いは、命令キャッシュに記憶されたプログラム）の実行。
２）プロセッサ２０及び主メモリ３０（或いは命令キャッシュ）とは別個に設けられた、専用のサブプロセッサによる専用のメモリに格納された処理プログラムの実行。
３）それぞれのモジュールの機能を実現するためのロジックに従って構成された専用のハードウェア。
【０５７２】
上記の第１〜第３の実施の形態で示したマルチプロセッサシステムは、１つの相互結合網１０を介して互いに接続された１０２４個のノードＰＥ０〜ＰＥ１０２３によって構成されていた。しかしながら、本発明において、ノード数は任意である。また、相互結合網が複数ある、冗長性のある構成となっていてもよい。この場合は、複数の相互結合網は、システムの障害対策のために用いることができる。
【０５７３】
【発明の効果】
以上説明したように、本発明によれば、主記憶とキャッシュメモリとのデータの一貫性（コヒーレンシー）を維持するための処理において、無限ループに陥ることがない。このため、処理装置によるデータアクセスが有限時間内で完了することを保証することができる。
【０５７４】
また、デッドロックの発生を回避するためにハードウェア（特に、相互結合網）を付加する必要がなく、信頼性が高く、しかも低コストでマルチプロセッサシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態にかかる疎結合型のマルチプロセッサシステムの構成を示すブロック図である。
【図２】本発明の第１の実施の形態におけるノードの機能構成を示すブロック図である。
【図３】（ａ）、（ｂ）は、本発明の第１の実施の形態において、相互結合網を介してノード間でやり取りされるメッセージの構成を示す図であり、（ａ）は基本メッセージの構成を、（ｂ）はブロックデータ付きメッセージの構成をそれぞれ示す。
【図４】本発明の第１の実施の形態におけるリクエストバッファの構成を示すブロック図である。
【図５】本発明の第１の実施の形態におけるリモートバッファの構成を示すブロック図である。
【図６】本発明の第１の実施の形態において、ローカルバッファが出力するメモリアクセスを受け、そのメモリアクセスがロードアクセスであった場合に、ローカルアクセス制御部が実行す処理を示すフローチャートである。
【図７】図６のフローチャートにおける処理で用いられる、アクセスの種類、状態、及びアドレスの第３９ビットから第２０ビットまでの上位２０ビットとタグアドレスが一致するかどうかの３つの情報と処理タイプ、メッセージの種類、次状態の関係を示すテーブルである。
【図８】本発明の第１の実施の形態において、リクエストバッファが出力するメッセージを受け付けた場合に、ローカルアクセス制御部が実行する処理を示すフローチャートである。
【図９】図８のフローチャートの処理で用いられる、メッセージの種類、状態、及びメッセージに付加されていたアドレスの第３９ビットから第２０ビットまでの上位２０ビットとタグアドレスが一致するかどうかの３つの情報と処理タイプ、メッセージの種類、次状態の関係を示すテーブルである。
【図１０】本発明の第１の実施の形態において、リプライバッファが出力するメッセージを受けつけた場合に、ローカルアクセス制御部が実行する処理を示すフローチャートである。
【図１１】図１０のフローチャートの処理で用いられる、アクセスの種類、受けたメッセージの種類、次状態の関係を示すテーブルである。
【図１２】本発明の第１の実施の形態において、ホームアクセス制御部が実行する処理を示すフローチャートである。
【図１３】図１２のフローチャートの処理で用いられる、受けたメッセージの種類、ディレクトリメモリ読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、及び保持ノード情報と当該ノード番号が一致するかどうかの５つの情報と、ディレクトリメモリに格納するブロックの状態、保持ノード情報に対する操作、処理タイプ、メッセージの種類および出力先のバッファとの関係を示すテーブルである。
【図１４】図１２のフローチャートの処理で用いられる、受けたメッセージの種類、ディレクトリメモリから読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、及び保持ノード情報と当該ノード番号が一致するかどうかの５つの情報と、ディレクトリメモリに格納するブロックの状態、保持ノード情報に対する操作、処理タイプ、メッセージの種類および出力先のバッファとの関係を示すテーブルである。
【図１５】コンフリクトキューから読み出したメッセージの処理なのかそうでないのか、コンフリクトキューが空かどうか、及び処理タイプがＣＤかどうかの３つの情報と、トップビットの値及びコンフリクトキューの先頭エントリを削除するかどうかの関係を示すテーブルである。
【図１６】キューから読み出したメッセージの処理であったかどうか、また処理したメッセージの種類、コンフリクトキューが空かどうか、また処理したメッセージの処理タイプが何であったか、及び読み出したトップビットの値が何であったか５つの情報と、決定されるキューの読み出しとの関係を示すテーブルである。
【図１７】本発明の第１の実施の形態において、プロセッサが行うメモリアクセスから始まる、ノード間でやり取りされるメッセージのシーケンスを示す図である。
【図１８】実施の形態のマルチプロセッサシステムにおける、メッセージの出力元モジュールと出力先モジュールの関係を示す図である。
【図１９】（ａ）、（ｂ）は、本発明の第２の実施の形態において、相互結合網を介してノード間でやり取りされるメッセージの構成を示す図であり、（ａ）は基本メッセージの構成を、（ｂ）はブロックデータ付きメッセージの構成をそれぞれ示す。
【図２０】本発明の第２の実施の形態におけるノードの機能構成を示すブロック図である。
【図２１】本発明の第２の実施の形態において、リプライバッファが出力するメッセージを受けつけた場合に、ローカルアクセス制御部が実行する処理を示すフローチャートである。
【図２２】図２１のフローチャートの処理で用いられる、アクセスの種類、受けたメッセージの種類、次状態の関係を示すテーブルである。
【図２３】本発明の第２の実施の形態において、ホームアクセス制御部が実行する処理のうちの第１の実施の形態と異なる部分を示すフローチャートである。
【図２４】図２３のフローチャートの処理で用いられる、受けたメッセージの種類、ディレクトリメモリ読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、及び保持ノード情報と当該ノード番号が一致するかどうかの５つの情報と、ディレクトリメモリに格納するブロックの状態、保持ノード情報に対する操作、処理タイプ、メッセージの種類および出力先のバッファとの関係を示すテーブルである。
【図２５】本発明の第２の実施の形態において、プロセッサが行うメモリアクセスから始まる、ノード間でやり取りされるメッセージのシーケンスを示す図である。
【図２６】（ａ）〜（ｃ）は、本発明の第３の実施の形態において、相互結合網を介してノード間でやり取りされるメッセージの構成を示す図であり、（ａ）は基本メッセージの構成を、（ｂ）はブロックデータ付きメッセージの構成を、（ｃ）は保持ノード数付きメッセージの構成をそれぞれ示す。
【図２７】本発明の第３の実施の形態におけるノードの機能構成を示すブロック図である。
【図２８】本発明の第３の実施の形態において、リクエストバッファが出力するメッセージを受け付けた場合にローカルアクセス制御部が実行する処理で用いられる、メッセージの種類、状態、及びメッセージに付加されていたアドレスの第３９ビットから第２０ビットまでの上位２０ビットとタグアドレスが一致するかどうかの３つの情報と処理タイプ、メッセージの種類、次状態の関係を示すテーブルである。
【図２９】本発明の第３の実施の形態において、リプライバッファが出力するメッセージを受けつけた場合に、ローカルアクセス制御部が実行する処理を示すフローチャートである。
【図３０】図２９のフローチャートの処理で用いられる、アクセスの種類、受けたメッセージの種類、次状態の関係を示すテーブルである。
【図３１】本発明の第３の実施の形態におけるホームアクセス制御部の処理で用いられる、受けたメッセージの種類、ディレクトリメモリ読み出したブロックの状態、保持ノード情報から求めるアンキャッシュド情報、要求ノード番号と当該ノード番号が一致するかどうか、及び保持ノード情報と当該ノード番号が一致するかどうかの５つの情報と、ディレクトリメモリに格納するブロックの状態、保持ノード情報に対する操作、処理タイプ、メッセージの種類および出力先のバッファとの関係を示すテーブルである。
【図３２】本発明の第３の実施の形態におけるホームアクセス制御部の処理で用いられる、キューから読み出したメッセージの処理であったかどうか、また処理したメッセージの種類、コンフリクトキューが空かどうか、また処理したメッセージの処理タイプが何であったか、及び読み出したトップビットの値が何であったか５つの情報と、決定されるキューの読み出しとの関係を示すテーブルである。
【図３３】本発明の第３の実施の形態において、プロセッサが行うメモリアクセスから始まる、ノード間でやり取りされるメッセージのシーケンスを示す図である。
【図３４】従来例の疎結合型のマルチプロセッサシステムの構成、及びノードの機能構成を示すブロック図である。
【符号の説明】
ＰＥ０〜ＰＥｎ−１ ノード
１０ 相互結合網
１６ 一貫性維持制御部
２０ プロセッサ
２１ キャッシュメモリ
２２ タグメモリ
２３ キャッシュメモリアクセス制御部
２４ タグメモリアクセス制御部
２５ ローカルアクセス制御部
２７ ホームアクセス制御部
２８ 主メモリアクセス制御部
２９ ディレクトリメモリアクセス制御部
３０ 主メモリ
３１ ディレクトリメモリ
３２ リプライバッファ
３３ リクエストバッファ
３４ リモートバッファ
３５ メッセージ送信部
３６ メッセージ受信部
３７ リクエスト管理テーブル
３８ ローカルバッファ
１０１ セレクタ
１０２ バッファ
１０３ セレクタ
１０４ バッファ
１１１ バッファ
１１２ セレクタ
１１３ バッファ
１１４ メッセージ生成回路
１１５ データバッファ

Claims (8)

  1. 相互結合網 (10) を介して互いに接続された複数のノード (PEi) から構成されるマルチプロセッサシステムであって、
    前記複数のノード (PEi) は、それぞれ、
    データのアクセス要求を発行するプロセッサ (20) と、
    データが格納される主メモリ (30) と、
    前記プロセッサ (20) がアクセスした主メモリ (30) のデータをブロック単位で一時保持する、前記主メモリ (30) よりも高速アクセスが可能なキャッシュメモリ (21) と、
    前記キャッシュメモリ (21) に記憶されているデータの状態をブロック毎に記憶するタグメモリ (22) と、
    前記主メモリ (30) に格納されているデータの一貫性に関する状態と、一貫性に関する状態の変化を待っているアクセス要求が存在するかどうか、をブロック毎に記憶するディレクトリメモリ (31) と、
    前記プロセッサ (20) が発行したアクセス要求を受けて、キャッシュメモリ (21) とタグメモリ (22) にアクセスして一貫性処理を行い、必要に応じて該当するデータを保持する主メモリ (30) を有するノード (PEi) に対してアクセス要求を通知するローカルアクセス制御部 (25) と、
    前記ローカルアクセス制御部 (25) からアクセス要求を受け、主メモリ (30) およびディレクトリメモリ (31) にアクセスして一貫性処理を行うと共に、必要に応じてアクセス要求をコンフリクトキューに退避するホームアクセス制御部 (27) とを備え、
    前記ホームアクセス制御部 (27) は、
    前記ローカルアクセス制御部 (25) からアクセス要求を受けたとき、該アクセス要求に応じたブロックのディレクトリメモリ (31) が一貫性処理中の状態にあることを示す場合には、該アクセス要求を前記コンフリクトキューに退避し、
    アクセス要求を退避する時に前記コンフリクトキューが空であった場合は、対応するブロックのディレクトリメモリ (31) の内容を一貫性に関する状態の変化を 待っているアクセス要求が存在することを示す値に更新し、
    ディレクトリメモリ (31) の内容が一貫性に関する状態の変化を待っているアクセス要求が存在することを示すブロックに関して、該ブロックの状態が一貫性処理中の状態からそれ以外の状態に更新された場合に、前記コンフリクトキューの先頭のアクセス要求を読み出して一貫性処理を行い、該ブロックのディレクトリメモリ (31) の内容を一貫性に関する状態の変化を持っているアクセス要求が存在しないことを示す値に更新し、
    前記コンフリクトキューから読み出されたアクセス要求を処理し、かつ別のアクセス要求が前記コンフリクトキューに蓄積されている場合、引き続き次のアクセス要求を前記コンフリクトキューから読み出し、
    該当するブロックのディレクトリメモリ (31) の内容が、一貫性処理中であることを示す状態である場合には、前記コンフリクトキューから読み出したアクセス要求の処理を中止し、該ブロックのディレクトリメモリ (31) のエントリの内容を一貫性に関する状態の変化を待っているアクセス要求が存在することを示す値に更新し、
    該当するブロックのディレクトリメモリ (31) の内容が、一貫性処理中でないことを示す状態である場合は、一貫性処理を行い、別のアクセス要求が前記コンフリクトキューにまだ蓄積されている場合は、引き続き次のアクセス要求を前記コンフリクトキューから読み出す
    ことを特徴とするマルチプロセッサシステム。
  2. 前記コンフリクトキューは、前記主メモリ (30) 内に設けられている
    ことを特徴とする請求項 1 記載のマルチプロセッサシステム。
  3. 前記複数のノード (PEi) は、Ｎ個 ( Ｎ＝自然数 ) のノードで構成され、
    前記プロセッサ (20) は、最大ｋ個 ( ｋ＝自然数 ) のアクセス要求を同時に発行する手段を有し、
    前記コンフリクトキューは、Ｎ×ｋ個のエントリで構成される
    ことを特徴とする請求項１または２に記載のマルチプロセッサシステム。
  4. 相互結合網 (10) を介して互いに接続された複数のノード (PEi) から構成されるマルチプロセッサシステムであって、
    前記複数のノード (PEi) は、それぞれ、
    データのアクセス要求を発行するプロセッサ (20) と、
    データが格納される主メモリ (30) と、
    前記プロセッサ (20) がアクセスした主メモリ (30) のデータをブロック単位で一時保持する、前記主メモリ (30) よりも高速アクセスが可能なキャッシュメモリ (21) と、
    前記キャッシュメモリ (21) に記憶されているデータの状態をブロック毎に記憶するタグメモリ (22) と、
    前記主メモリ (30) に記憶されているデータの状態をブロック毎に記憶するディレクトリメモリ (31) と、
    前記プロセッサ (20) が発行したアクセス要求を受けて、キャッシュメモリ (21) とタグメモリ (22) をアクセスして一貫性処理を行い、必要に応じて該当するデータを保持する主メモリ (30) を有するノード (PEi) に対してアクセス要求を通知するローカルアクセス制御部 (25) と、
    前記ローカルアクセス制御部 (25) からアクセス要求を受けて、主メモリ (30) およびディレクトリメモリ (31) をアクセスして一貫性処理を行うホームアクセス制御部 (27) と、
    前記ローカルアクセス制御部 (25) に対する応答を受け取り、該応答を蓄積するリプライバッファ (32) と、
    前記ローカルアクセス制御部 (25) に対する一貫性処理要求を受け取り、該一貫性処理要求を蓄積するリクエストバッファ (33) と、
    前記ホームアクセス制御部 (27) が一貫性処理を行って他のノード (PEi) に送出する一貫性処理要求および応答を生成するための情報を前記ホームアクセス制御部 (27) より受け取り、該情報を蓄積するリモートバッファ (34) と
    を備えることを特徴とするマルチプロセッサシステム。
  5. 前記リクエストバッファ (33) は、前記ローカルアクセス制御部 (25) に対する一貫性処理要求を、前記主メモリ (30) に設けられたリクエスト退避キューに退避する手段と、該リクエスト退避キューに退避した一貫性処理要求を読み出す手段とを有する
    ことを特徴とする請求項４に記載のマルチプロセッサシステム。
  6. 前記リモートバッファ (34) は、前記ホームアクセス制御部 (27) が他のノード (PEi) に送出する一貫性処理要求および応答を生成するための情報を、前記主メモリ (30) に設けられたリモート退避キューに退避する手段と、該リモート退避キューに退避した情報を読み出す手段と、該一貫性処理要求及び応答を生成するための情報から必要に応じて一貫性要求及び応答を生成する手段とを有する
    ことを特徴とする請求項４または５に記載のマルチプロセッサシステム。
  7. 前記複数のノード (PEi) は、Ｎ個 ( Ｎ＝自然数 ) のノードで構成され、
    前記プロセッサ (20) は、最大ｋ個 ( ｋ＝自然数 ) のアクセス要求を同時に発行する手段を有し、
    前記リプライバッファ (32) は、ｋ個のエントリで構成され、
    前記リクエストバッファ (33) は、Ｎ×ｋ個のエントリで構成され、
    前記リモートバッファ (34) は、Ｎ×ｋ個のエントリで構成される
    ことを特徴とする請求項４乃至６のいずれか１項に記載のマルチプロセッサシステム。
  8. 前記ディレクトリメモリ (31) は、さらに、どのノード (PEi) のキャッシュメモリ (21) がデータを保持しているかをブロック毎に記憶し、
    前記一貫性処理要求および応答を生成するための情報には、前記ディレクトリメモリ (31) に格納されている、どのノード (PEi) のキャッシュメモリ (21) がデータを保持しているかを示す情報が含まれる
    ことを特徴とする請求項４乃至７のいずれか１項に記載のマルチプロセッサシステム。
JP02113598A 1998-02-02 1998-02-02 マルチプロセッサシステム Expired - Lifetime JP3751741B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP02113598A JP3751741B2 (ja) 1998-02-02 1998-02-02 マルチプロセッサシステム
US09/241,069 US6408365B1 (en) 1998-02-02 1999-02-01 Multiprocessor system having means for arbitrating between memory access request and coherency maintenance control
DE19904049A DE19904049A1 (de) 1998-02-02 1999-02-02 Mehrprozessorsystem mit einer Einrichtung zum Entscheiden zwischen einer Speicherzugriffanforderung und einer Steuerung zum Aufrechterhalten eines Kohärenzzustands

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP02113598A JP3751741B2 (ja) 1998-02-02 1998-02-02 マルチプロセッサシステム

Publications (2)

Publication Number Publication Date
JPH11219343A JPH11219343A (ja) 1999-08-10
JP3751741B2 true JP3751741B2 (ja) 2006-03-01

Family

ID=12046464

Family Applications (1)

Application Number Title Priority Date Filing Date
JP02113598A Expired - Lifetime JP3751741B2 (ja) 1998-02-02 1998-02-02 マルチプロセッサシステム

Country Status (3)

Country Link
US (1) US6408365B1 (ja)
JP (1) JP3751741B2 (ja)
DE (1) DE19904049A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3772690B2 (ja) 2001-04-25 2006-05-10 日本電気株式会社 サービスシステム及びそれに用いるサービス方法
US7941585B2 (en) * 2004-09-10 2011-05-10 Cavium Networks, Inc. Local scratchpad and data caching system
US7594081B2 (en) 2004-09-10 2009-09-22 Cavium Networks, Inc. Direct access to low-latency memory
WO2006031551A2 (en) 2004-09-10 2006-03-23 Cavium Networks Selective replication of data structure
US7454576B2 (en) * 2004-12-27 2008-11-18 Intel Corporation System and method for cache coherency in a cache with different cache location lengths
JP4572169B2 (ja) 2006-01-26 2010-10-27 エヌイーシーコンピュータテクノ株式会社 マルチプロセッサシステム及びその動作方法
JP5082479B2 (ja) * 2007-02-08 2012-11-28 日本電気株式会社 データ一貫性制御システム及びデータ一貫性制御方法
US7996360B2 (en) * 2008-06-27 2011-08-09 International Business Machines Corporation Coordinating updates to replicated data

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02304666A (ja) 1989-05-19 1990-12-18 Nec Corp ライトスルーキャッシュの一貫性保持方式
JPH0625984B2 (ja) 1990-02-20 1994-04-06 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン マルチプロセツサ・システム
JPH04209053A (ja) 1990-11-30 1992-07-30 Nec Corp キャッシュシステム
JPH0532776A (ja) 1990-12-10 1993-02-09 Teijin Ltd ポリアリールエーテルケトンの製造方法
JPH0535697A (ja) 1991-07-25 1993-02-12 Mitsubishi Electric Corp マルチプロセツサシステム
US5244545A (en) 1991-10-09 1993-09-14 Eastman Kodak Company Process for removing acetone from carbonylation processes
JPH0962580A (ja) 1995-08-30 1997-03-07 Canon Inc マルチプロセッサ装置

Also Published As

Publication number Publication date
JPH11219343A (ja) 1999-08-10
DE19904049A1 (de) 1999-09-09
US6408365B1 (en) 2002-06-18

Similar Documents

Publication Publication Date Title
US5900020A (en) Method and apparatus for maintaining an order of write operations by processors in a multiprocessor computer to maintain memory consistency
US6154816A (en) Low occupancy protocol for managing concurrent transactions with dependencies
US6014690A (en) Employing multiple channels for deadlock avoidance in a cache coherency protocol
JP4700773B2 (ja) スイッチをベースとするマルチプロセッサシステムに使用するための順序サポート機構
US6085276A (en) Multi-processor computer system having a data switch with simultaneous insertion buffers for eliminating arbitration interdependencies
KR100465583B1 (ko) 판독 요청을 원격 처리 노드에 추론적으로 전송하는 비정형 메모리 액세스 데이터 처리 시스템 및 이 시스템에서의 통신 방법
US6108752A (en) Method and apparatus for delaying victim writes in a switch-based multi-processor system to maintain data coherency
US6209065B1 (en) Mechanism for optimizing generation of commit-signals in a distributed shared-memory system
US6094686A (en) Multi-processor system for transferring data without incurring deadlock using hierarchical virtual channels
US6101420A (en) Method and apparatus for disambiguating change-to-dirty commands in a switch based multi-processing system with coarse directories
US20010013089A1 (en) Cache coherence unit for interconnecting multiprocessor nodes having pipelined snoopy protocol
JPH10187470A (ja) スピンロック動作を最適化する装置を含むマルチプロセス・システム
JPH10116253A (ja) 同期動作を実行するマルチプロセス・システム
JP2002304328A (ja) マルチプロセッサシステム用コヒーレンスコントローラ、およびそのようなコントローラを内蔵するモジュールおよびマルチモジュールアーキテクチャマルチプロセッサシステム
JPH10187645A (ja) プロセス・ノードの多数のサブノード内にコヒーレンス状態で格納するように構成されたマルチプロセス・システム
JPH10340227A (ja) ローカル・グローバル・アドレス・スペース及びマルチアクセス・モードを用いたマルチプロセッサ・コンピュータ・システム
US20040255002A1 (en) Methods and apparatus for extended packet communications between multiprocessor clusters
JPH10133917A (ja) コヒーレンシー関連エラー・ロッジング能力を有するマルチプロセス・システム
JPH10171710A (ja) 効果的なブロック・コピー動作を実行するマルチプロセス・システム
JPH10143482A (ja) エフィシェントな書込み動作を実行するマルチプロセッサ・システム
JPH10214230A (ja) 応答カウントを含むコヒーレンシー・プロトコルを採用したマルチプロセッサ・システム
JP2001519565A (ja) キャッシュコヒーレンス共用ディスクコンピュータシステムにおけるｉ／ｏ転送
CN112955876B (zh) 用于在数据处理网络中传输数据的方法和装置
US20050013294A1 (en) Multi-node computer system with active devices employing promise arrays for outstanding transactions
JP3751741B2 (ja) マルチプロセッサシステム

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20050310

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20051208

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091216

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091216

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101216

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101216

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111216

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111216

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121216

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121216

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131216

Year of fee payment: 8

EXPY Cancellation because of completion of term