マルチプロセッサシステム及び入出力制御装置並びにリクエスト発行方法
【課題】マルチプロセッサシステムにおいて、アドレス一致先行ライトリクエストが存在するか否かを判定するための判定処理によって、後続のリクエストの処理が待たされないようにする。
【解決手段】アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１の入力側において、外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファ２１に登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報２２を登録する。登録処理部２７は、アドレス一致情報が登録されるまで、入力バッファ２１に登録されているリクエストの出力（順序保証バッファ２８への登録）を待ち合わせる。
【解決手段】アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１の入力側において、外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファ２１に登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報２２を登録する。登録処理部２７は、アドレス一致情報が登録されるまで、入力バッファ２１に登録されているリクエストの出力（順序保証バッファ２８への登録）を待ち合わせる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、クロスバーネットワークを介して各ノードと接続される入出力制御装置とを備えたマルチプロセッサシステムに関し、特に、共有メモリの一貫性が保たれるように、入出力制御装置からノードに対して発行するライトリクエスト及びリードリクエストの発行順を制御するリクエスト発行技術に関する。
【背景技術】
【０００２】
従来から、メモリの一貫性を保証するため、入力されたリードリクエストとアクセス先のアドレスを同一にする未完了のライトリクエスト（アドレス一致先行ライトリクエスト）が存在するか否かを判定するということが行われている。その際、従来は、一般に、入力されたリードリクエストを入力バッファに一旦登録し、その後、アドレス一致先行ライトリクエストが存在するか否かを判定するようにしている（例えば、特許文献１参照）。
【０００３】
このような処理は、図１５に示すようなマルチプロセッサシステムにおいても行われている。同図に示すマルチプロセッサシステムは、複数の入出力デバイス１−１〜１−ｎと、各入出力デバイス毎の入出力制御装置２−１〜２−ｎと、クロスバーネットワーク３と、複数のノード４−１〜４−ｍとから構成されている。
【０００４】
各入出力デバイス１−１〜１−ｎは、それぞれ入出力制御装置２−１〜２−ｎを介してクロスバーネットワーク３に接続され、更に、クロスバーネットワーク３を介して各ノード４−１〜４−ｍに接続されている。
【０００５】
ノード４−１〜４−ｍは、それぞれクロスバーネットワーク３に接続されるメモリ制御部４１を備え、メモリ制御部４１は、その配下にプロセッサ４４、４５と、ディレクトリ４２と、各プロセッサ４４、４５によって共有される共有メモリ４３とを備えている。
【０００６】
各入出力デバイス１−１〜１−ｎからのメモリリクエスト（ライトリクエスト及びリードリクエストを含む。単にリクエストという場合もある）は、それぞれ入出力制御装置２−１〜２−ｎ及びクロスバーネットワーク３を介して該当するノードに送られる。入出力制御装置２−１〜２−ｎは、入出力デバイス１−１〜１−ｎからのメモリリクエストをノードに対して発行する際、共有メモリ４３の一貫性が保たれるように、その発行順を制御する機能を有する。即ち、ＰＣＩバス仕様リビジョン２．１等に規定されているように、ライトリクエストに関しては、先行するライトリクエストが完了してから後続のライトリクエストを発行し、リードリクエストに関しては、アクセス先を同じにする未完了のライトリクエスト（アドレス一致先行ライトリクエスト）が存在するか否かを調べ、存在する場合は、アドレス一致先行ライトリクエストが完了してから後続のリードリクエストを発行するようにしている。
【０００７】
図１６は、入出力制御装置２−１の構成例を示すブロック図であり、入出力デバイス１−１から入力されたリードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かの判定処理を、従来一般的に行われているように、リードリクエストを一旦入力バッファに登録してから行うようにした場合の構成を示している。即ち、図１６は、従来の入出力制御装置２−１の構成例を示すブロック図である。
【０００８】
図１６に示した入出力制御装置２−１は、入力バッファ１０１と、アドレス一致先行ライトリクエスト検出処理部１０２と、アドレス一致管理バッファ１０３と、一致判定回路１０５と、順序保証バッファ１０６と、引き抜きポインタ１０８と、ＦＩＦＯポインタ１０９と、ポインタセレクタ１１０と、発行処理部１１１と、リクエストセレクタ１１２と、制御部１１３とを備えている。なお、他の入出力制御装置も入出力制御装置２−１と同様の構成を有している。
【０００９】
〔動作の説明〕
次に、入出力制御装置として図１６に示した構成を有する入出力制御装置を用いた場合の、マルチプロセッサシステムの動作について説明する。
【００１０】
入出力デバイス１−１が発行したメモリリクエストは、一旦、入出力制御装置２−１内の入力バッファに登録される。
【００１１】
入出力制御装置２−１内のアドレス一致先行ライトリクエスト検出処理部１０２は、図１７のフローチャートに示すように、入力バッファ１０１の先頭に登録されているリクエストを入力し、そのリクエストがライトリクエストなのかリードリクエストなのかを判定する（ステップＡ１、Ａ２）。
【００１２】
今、入力バッファ１０１から入力したリクエストがライトリクエストであったとすると（ステップＡ２がＹＥＳ）、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストに含まれているライトアドレスをアドレス一致管理バッファ１０３に登録すると共に、そのライトアドレスに対する有効フラグを「有効」とする（ステップＡ３、Ａ４）。
【００１３】
その後、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストを順序保証バッファ１０６に登録すると共に、そのライトリクエストに対する待ち合わせフラグを「有効」にする（ステップＡ５、Ａ６）。待ち合わせフラグが「有効」になっている間、上記ライトリクエストは、発行を待ち合わされる。
【００１４】
更に、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストの発行許可を受けるために、リクエストセレクタ１１２及びクロスバーネットワーク３を介して該当するノード（例えば、ノード４−１）に対して、ライトアドレスを含むディレクトリ検索要求を発行する（ステップＡ７）。その際、アドレス一致先行ライトリクエスト検出処理部１０２は、制御部１１３に対してセレクタ切り替え要求を送り、制御部１１３から切り替え完了通知が送られてきてからディレクトリ検索要求を発行する。また、制御部１１３は、アドレス一致先行ライトリクエスト検出処理部１０２からセレクタ切り替え要求が送られてくると、リクエストセレクタ１１２を発行処理部１１１を選択する状態からアドレス一致先行ライトリクエスト検出処理部１０２を選択する状態に変更し、その後、切り替え完了通知を返却する。また、制御部１１３は、切り替え完了通知を返却してから所定時間（アドレス一致先行ライトリクエスト検索処理部１０２がディレクトリ検索要求を発行するのに十分な時間）が経過すると、リクエストセレクタ１１２を、発行処理部１１１を選択する状態に戻す。
【００１５】
入出力制御装置２−１からディレクトリ検索要求が送られてきたノード４−１内のメモリ制御部４１は、ディレクトリ４２を参照し、上記ディレクトリ検索要求に含まれているライトアドレスをアクセスすることが可能か否かを判定する。ディレクトリ４２には、例えば、共有メモリ４３の各アドレスがロック状態にあるのか、フリー状態にあるのかを示すロック情報が登録されていおり、上記ライトアドレスに対するロック情報がフリー状態の場合は、アクセス可能であると判定し、ロック状態の場合は、アクセス不能と判定する。
【００１６】
そして、メモリ制御部４１は、アクセス可能と判定した場合は、上記ライトアドレスに対応するロック情報をロック状態にした後、要求元の入出力制御装置２−１に対して発行許可を返却し、アクセス不能と判定した場合は、差戻指示を返却する。
【００１７】
ノード４−１から返却された発行許可、差戻指示は、入出力制御装置２−１内の制御部１１３で受信される。
【００１８】
制御部１１３は、ノード４−１から発行許可が返却された場合は、図１８のフローチャートに示すように、発行許可されたライトリクエストの待ち合わせフラグ１０７を解除し、その値を「有効」から「無効」に変更する（ステップＢ１）。これにより、上記ライトリクエストは、順序保証バッファ１０６から発行可能な状態になる。なお、順序保証バッファ１０６に登録されたリクエストの発行動作は、後で、図２０を用いて説明する。
【００１９】
これに対して、ノード４−１から差戻指示が返却された場合は、図１９のフローチャートに示すように、先ず、引き抜きポインタ１０８が指し示す順序保証バッファ１０６のエントリを、差戻が指示されたライトリクエストが格納されているエントリを指し示すものに変更し（ステップＣ１）、次いで、ポインタセレクタ１１０をＦＩＦＯポインタ１０９を選択する状態から引き抜きポインタ１０８を選択する状態に切り替え（ステップＣ２）、更に、発行処理部１１１に対してディレクトリ検索要求の発行を指示する（ステップＣ３）。その後、制御部１１３は、ポインタセレクタ１１０の状態を、ＦＩＦＯポインタ１０９を選択する状態に戻す（ステップＣ４）。
【００２０】
上記したステップＣ２において、ポインタセレクタ１１０の状態が切り替えられることにより、順序保証バッファ１０６からは、差戻が指示されたライトリクエストが発行処理部１１１に対して出力される。
【００２１】
発行処理部１１１は、順序保証バッファ１０６からリクエストが入力された後、制御部１１３からディレクトリ検索要求の発行が指示された場合は、上記リクエストの代わりに、上記リクエスト中のライトアドレスを含んだディレクトリ検索要求を該当するノードに対して発行する。これに対して、順序保証バッファ１０６からリクエストが入力された後、制御部１１３からディレクトリ検索要求の発行が指示されなかった場合は、上記リクエストをそのまま該当するノード４−１に発行する。この例では、制御部１１３がステップＣ３において、ディレクトリ検索要求の発行を指示しているので、発行処理部１１１は、リクエスト中のライトアドレスを含んだディレクトリ検索要求を該当するノード４−１に対して発行することになる。
【００２２】
アドレス一致先行ライトリクエスト検出処理部１０２が入力バッファ１０１から入力したリクエストがライトリクエストの場合は、上記した処理が行われる。次に、アドレス一致先行ライトリクエスト検出処理部１０２が入力バッファ１０１からリードリクエストを入力した場合の動作について説明する。
【００２３】
図１７のフローチャートに示すように、アドレス一致先行ライトリクエスト検出処理部１０２は、入力バッファ１０１から入力したリクエストがリードリクエストの場合（ステップＡ１、Ａ２がＮＯ）は、先ず、上記リードリクエストに含まれているリードアドレスを一致判定回路１０５に渡す（ステップＡ８）。
【００２４】
一致判定回路１０５は、リードアドレスが渡されると、アドレス一致管理バッファ１０３を検索し、有効フラグ１０４が「有効」となっているライトアドレスの中に、上記リードアドレスと同一のアドレスが存在するか否かを調べる。そして、そのようなアドレスが存在する場合には、アドレス一致先行ライトリクエスト検出処理部１０２に対してアドレス一致先行ライトリクエストが有ることを通知し、そのようなアドレスが存在しない場合は、アドレス一致先行ライトリクエストが無いことを通知する。
【００２５】
アドレス一致先行ライトリクエスト検出処理部１０２は、アドレス一致先行ライトリクエスト無しが通知された場合（ステップＡ９がＮＯ）は、ステップＡ１で入力したリードリクエストを該当するノードに発行する（ステップＡ１２）。その際、ステップＡ７でディレクトリ検索要求を発行した場合と同様に、制御部１１３に対してセレクタ切り替え要求を出力し、制御部１１３から切り替え完了が通知された後、リードリクエストを発行する。
【００２６】
これに対して、アドレス一致先行ライトリクエスト有りが通知された場合（ステップＡ９がＹＥＳ）は、ステップＡ１で入力したリードリクエストを順序保証バッファ１０６に登録すると共に、上記リードリクエストの待ち合わせフラグ１０７を無効にする（ステップＡ１０、Ａ１１）。
【００２７】
次に、順序保証バッファ１０６に登録されているリクエストを発行する場合の動作を、図２０のフローチャートを参照して説明する。
【００２８】
制御部１１３は、順序保証バッファ１０６に登録されているリクエストを、登録順に発行するため、ＦＩＦＯポインタ１０９が指し示している順序保証バッファ１０６のエントリに登録されているリクエストの待ち合わせフラグ１０７が有効になっている場合（ステップＤ１、Ｄ２がＹＥＳ）は、無効に変更されるのを待ち合わせ（ステップＤ２がＮＯとなるのを待ち合わせ）、無効になっている場合（ステップＤ２がＮＯ）は、ＦＩＦＯポインタ１０９によって指し示されているリクエストを順序保証バッファ１０６から読み出す（ステップＤ３）。このリクエストは、発行処理部１１１に入力され、該当するノードに発行される。
【００２９】
その後、制御部１１３は、ステップＤ３で読み出したリクエストがライトリクエストであったか否かを判断し（ステップＤ４）、ライトリクエストであった場合（ステップＤ４がＹＥＳ）は、アドレス一致管理バッファ１０４に登録されている有効フラグ１０４の内の、今回読み出したライトリクエストに対応する有効フラグを「無効」に変更し（ステップＤ５）、その後、ＦＩＦＯポインタ１０９を更新し、次のエントリを指し示すようにする（ステップＤ６）。これに対して、ステップＤ３で読み出したリクエストがリードリクエストであった場合（ステップＤ４がＮＯ）は、ステップＤ５を飛ばしてステップＤ６の処理を行う。ステップＤ６が終了すると、制御手段１１３は、ステップＤ１の処理に戻る。
【００３０】
【特許文献１】特開２００１−３３１３６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００３１】
従来は、上述したように、図１６に示すような入出力制御装置２−１〜２−ｎを用いてメモリの一貫性が保証されるように、リクエストの発行順を制御しているが、次のような問題があった。
【００３２】
第１に、リードリクエストを入力バッファ１０１に一旦登録し、その後、上記リードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを判定するアドレス一致判定処理を行っているため、このアドレス一致判定処理に要する時間だけ、後続のリクエストの処理が遅れてしまうという問題がある。
【００３３】
第２に、入力バッファ１０１で受け付けたリクエストがライトリクエストである場合、アドレス一致先行ライトリクエスト検出処理部１０２が無条件でディレクトリ検索要求を発行しているため、同一のライトアドレスを含むライトリクエストが連続した場合、差戻指示が多発してトラフィックが増加してしまうという問題がある。
【００３４】
第３に、アドレス一致先行ライトリクエストが存在するリードリクエストは一旦順序保証バッファ１０６に登録され、その後、ＦＩＦＯポインタ１０９によってその登録エントリが指し示されるまで、発行が待ち合わされるため、上記アドレス一致先行ライトリクエストと上記リードリクエストとの間に存在する無関係なライトリクエストの発行許可待ちの影響を受けてしまい性能が低下するという問題がある。
【００３５】
第４に、アドレス一致先行ライトリクエストが存在しないリードリクエストは、順序保証バッファ１０６をバイパスさせるが、このときリクエストセレクタ１１２が順序保証バッファ１０６を選択する状態になっていると、上記リードリクエストの発行が待たされるため、後続のリクエストに対する処理が止まってしまうという問題がある。
【００３６】
〔発明の目的〕
そこで、本発明の目的は、マルチプロセッサシステムの処理速度を向上させると共に、トラフィックを低減させることにある。
【課題を解決するための手段】
【００３７】
本発明にかかる第１のマルチプロセッサシステムは、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムであって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする。
【００３８】
本発明にかかる第２のマルチプロセッサシステムは、第１のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする。
【００３９】
本発明にかかる第３のマルチプロセッサシステムは、第２のマルチプロセッサシステムにおいて、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする。
【００４０】
本発明にかかる第４のマルチプロセッサシステムは、第３のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする。
【００４１】
本発明にかかる第５のマルチプロセッサシステムは、第１〜第４のマルチプロセッサシステムにおいて、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする。
【００４２】
本発明にかかる第１の入出力制御装置は、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードとクロスバーネットワークを介して接続され、且つ、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを備えた入出力制御装置であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする。
【００４３】
本発明にかかる第２の入出力制御装置は、第１の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする。
【００４４】
本発明にかかる第３の入出力制御装置は、第２の入出力制御装置において、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする。
【００４５】
本発明にかかる第４の入出力制御装置は、第３の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする。
【００４６】
本発明にかかる第５の入出力制御装置は、第１〜第４の入出力制御装置において、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする。
【００４７】
本発明にかかる第１のリクエスト発行方法は、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムにおけるリクエスト発行方法であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファに対して外部からリクエストが入力されたとき、アドレス一致先行ライトリクエスト検出処理部が、前記リクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録し、
登録処理部が、前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録することを特徴とする。
【００４８】
本発明にかかる第２のリクエスト発行方法は、第１のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行し、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更することを特徴とする。
【００４９】
本発明にかかる第３のリクエスト発行方法は、第２のリクエスト発行方法において、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行することを特徴とする。
【００５０】
本発明にかかる第４のリクエスト発行方法は、第３のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録し、
前記制御部が、前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行することを特徴とする。
【００５１】
〔作用〕
アドレス一致先行ライトリクエスト検出処理部は、入力バッファの入力側において、入力バッファに外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファに登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録する。登録処理部では、アドレス一致情報が登録されるまで、入力バッファからのリクエストの出力（順序保証バッファへの登録）を待ち合わせる。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【００５２】
また、登録処理部は、入力バッファに登録されている最古のリクエストがライトリクエストであっても、上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在する場合には、上記リクエストの発行許可要求は発行せず、アドレス一致先行ライトリクエストが存在しない場合のみ、発行許可要求を発行する。また、制御部は、順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、上記最古のリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が存在する場合は、このアドレス一致後続ライトリクエストの発行許可要求を該当するノードに発行する。これにより、トラフィックの増加を防止することができる。
【００５３】
また、制御部は、順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、順序保証バッファに上記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、そのアドレス一致後続リードリクエストを該当するノードに発行する。これにより、アドレス一致先行ライトリクエストとアドレス一致後続リードリクエストとの間に、他のライトリクエストが存在する場合であっても、アドレス一致後続リードリクエストの発行が待たされることがなくなる。
【００５４】
また、登録処理部は、入力バッファに登録されている最古のリクエストがリードリクエストで、且つ上記リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、上記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを順序保証バッファに登録する。また、制御部は、登録処理部によって順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、そのリードリクエストを該当するノードへ発行する。これにより、入力バッファにおいて、アドレス一致先行ライトリクエストが存在しないリードリクエストによって、後続のリクエストが待たされることがなくなる。
【発明の効果】
【００５５】
本発明によれば、アドレス一致先行ライトリクエストが存在するか否かを判定するための判定処理によって、後続のリクエストの処理が待たされることがないという効果を得ることができる。その理由は、入力バッファの入力側において、外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファに登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、アドレス一致情報が登録されるまで、入力バッファに登録されているリクエストの出力（順序保証バッファへの登録）を待ち合わせる登録処理部とを備えているからである。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【発明を実施するための最良の形態】
【００５６】
次に本発明の実施の形態について図面を参照して詳細に説明する。
【００５７】
〔実施の形態の構成の説明〕
本発明にかかるマルチプロセッサシステムの実施の形態は、図１５に示したマルチプロセッサシステムにおいて、入出力制御装置２−１〜２−ｎとして図１に示す構成を有する入出力制御装置を使用することにより実現される。
【００５８】
図１を参照すると、本実施の形態で使用する入出力制御装置２−１〜２−ｎは、入力バッファ２１と、アドレス一致先行ライトリクエスト検出処理部２３と、アドレス一致管理バッファ２４と、有効フラグ保持部２５と、一致判定回路２６と、登録処理部２７と、順序保証バッファ２８と、引き抜きポインタ３１と、ＦＩＦＯポインタ３２と、ポインタセレクタ３３と、発行処理部３４と、リクエストセレクタ３５と、制御部３６とから構成されている。なお、入出力制御装置２−１〜２−ｎは、同一の構成を有しているため、以下では入出力制御装置２−１を例に挙げて構成を説明する。
【００５９】
入力バッファ２１は、複数のエントリ（例えば、１２８エントリ）を有し、各エントリには、入出力デバイス１−１から発行されたリクエスト（リードリクエスト及びライトリクエストを含む）が登録されると共に、そのリクエストに対するアドレス一致情報２２が登録される。アドレス一致情報２２は、図２に示すように、アドレス一致先行ライトリクエストが存在するか否かを示す有無情報と、アドレス一致先行ライトリクエストを特定する先行リクエスト特定情報とを含んでいる。なお、リクエストの登録時、入力バッファ２１の各エントリは循環的に使用される。即ち、最初のリクエストが入力された場合は、入力バッファ２１の第０番目のエントリにリクエストを登録し、次のリクエストが入力された場合は、第１番目のエントリにリクエストを登録するというように、登録対象エントリを順次変更していき、最後のエントリ（第１２７番目のエントリ）にリクエストを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。
【００６０】
アドレス一致管理バッファ２４は、順序保証バッファ２８と同数のエントリ（例えば、６４エントリ）を有し、最新の６４個分のライトリクエスト中のライトアドレスが登録される。アドレス一致管理バッファ２４のエントリ数が順序保証バッファ２８のエントリ数と同数で良い理由は、入力バッファ２１から或るリクエストが出力されたとき、そのリクエストに対するアドレス一致先行ライトリクエストとなる可能性のあるリクエストは、順序保証バッファ２８にその時点で登録されている６４個のリクエストだけであるからである。
【００６１】
有効フラグ保持部２５は、入力バッファ２１のエントリ数（この例では１２８エントリ）と順序保証バッファ２８のエントリ数（この例では６４エントリ）とを加算した数のエントリ（この例では１９２エントリ）を有しており、各エントリには、アドレス一致管理バッファ２４の対応するエントリに格納されているライトアドレスが有効であるか否かを示す有効フラグが登録されている。有効フラグ保持部２５の第ｊ番目、第（ｊ＋６４）番目、第（ｊ＋１２８）番目のエントリが、アドレス一致管理バッファ２４の第ｊ番目のエントリと対応している。
【００６２】
順序保証バッファ２８は、複数のエントリ（例えば６４エントリ）を有し、各エントリには、登録処理部２７によってリクエストが登録されると共に、そのリクエストに対する待ち合わせフラグ２９およびペンディング情報３０が登録される。なお、待ち合わせフラグ２９は、対応するリクエストの発行を待ち合わせることが必要か否かを示すものであり、ペンディング情報は、それと対応付けて登録されているリクエストにアドレス一致先行ライトリクエストが存在するか否かを示す有無情報と、アドレス一致先行ライトリクエストを特定するための先行リクエスト特定情報とを含んでいる。また、順序保証バッファ２８は、引き抜きポインタ３１、ＦＩＦＯポインタ３２の内の、ポインタセレクタ３３によって選択されているポインタが指し示しているエントリに登録されているリクエスト、待ち合わせフラグ２９及びペンディング情報３０を発行処理部３４に対して出力している。
【００６３】
引き抜きポインタ３１及びＦＩＦＯポインタ３２は、順序保証バッファ２８の読み出し対象エントリを指し示すポインタである。ポインタセレクタ３３は、制御部３６の指示に従って引き抜きポインタ３１、ＦＩＦＯポインタ３２の内の一方を選択するセレクタである。リクエストセレクタ３５は、制御部３６の指示に従って登録処理部２７、発行処理部３４の内の一方を選択するセレクタである。
【００６４】
アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１の入力側に接続されている点、およびリードリクエストだけでなく、ライトリクエストについてもアドレス一致先行ライトリクエストが存在するか否かを調べる点が、図１６に示した従来のアドレス一致先行ライトリクエスト検出処理部１０２との大きな相違点である。このアドレス一致先行ライトリクエスト検出処理部２３が備えている主な機能は次の通りである。
【００６５】
・入力バッファ２１に入力されるリクエストがライトリクエストの場合は、一致判定回路２６を利用して上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べると共に、どのライトリクエストがアドレス一致先行ライトリクエストとなるのかを調べる。その後、調べた結果に基づいてアドレス一致情報２２を作成し、上記ライトリクエストが登録された入力バッファ２１のエントリにアドレス一致情報２２を登録する。更に、上記ライトリクエスト中のライトアドレスを最新のライトアドレスとしてアドレス一致管理バッファ２４に登録すると共に、有効フラグ保持部２５の該当するエントリに有効を示す有効フラグを登録する。
【００６６】
なお、アドレス一致管理バッファ２４にライトアドレスを登録する際、アドレス一致先行ライトリクエスト検出処理部２３は、アドレス一致管理バッファ２４の各エントリを循環的に使用する。即ち、最初のライトアドレスはアドレス一致管理バッファ２４の第０番目のエントリに登録し、次のライトアドレスは、第１番目のエントリに登録するというように順次登録対象エントリを更新していき、最後のエントリ（第６３番目のエントリ）にライトアドレスを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。また、有効フラグ保持部２５に有効フラグを登録する場合、アドレス一致先行ライトアドレス検出処理部２４は、有効フラグ保持部２５の各エントリを循環的に使用する。即ち、アドレス一致管理バッファ２４の第０番目のエントリに最初のライトアドレスを登録した場合は、有効フラグ保持部２５の第０番目のエントリに有効を示す有効フラグを登録し、アドレス一致管理バッファ２４に次のライトアドレスを登録した場合は、有効フラグ保持部２５の第１番目のエントリに有効を示す有効フラグを登録するというように、順次登録対象エントリを更新していき、最後のエントリ（第１９１番目のエントリ）に有効を示す有効フラグを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。
【００６７】
・入力バッファ２１に入力されるリクエストが、リードリクエストの場合、一致判定回路２６を利用して上記リードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べると共に、どのライトリクエストがアドレス一致先行ライトリクエストとなるかを調べる。その後、調べた結果に基づいてアドレス一致情報２２を生成し、上記リードリクエストが登録された入力バッファ２１のエントリにアドレス一致情報２２を登録する。
【００６８】
登録処理部２７は、次のような機能を有する。
【００６９】
・入力バッファ２１の第０番目〜第１２７番目のエントリを順次読み出し対象エントリにし、最後のエントリ（第１２７番目のエントリ）を読み出し対象エントリにしたら、再び第０番目のエントリを読み出し対象エントリにする。読み出し対象エントリに、有効なアドレス一致情報２２が登録されている場合は、読み出し対象エントリからリクエスト及びアドレス一致情報２２を読み出し、アドレス一致情報２２が無効になっている場合は、有効なアドレス一致情報２２が登録されるのを待ってからリクエスト及びアドレス一致情報２２を読み出す。読み出し対象エントリからリクエスト及びアドレス一致情報２２を読み出すと、読み出し対象エントリ中のアドレス一致情報２２を無効にすると共に、入力バッファ２１から読み出したリクエストを順序保証バッファ２８に登録する。リクエストの登録時、登録処理部２７は、順序保証バッファ２８の各エントリを循環的に使用する。
【００７０】
・順序保証バッファ２８に登録したリクエストが、ライトリクエストで、且つそのライトリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが無いことを示している場合は、上記ライトリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグ２９（値が「有効」）を登録すると共に、ペンディング情報３０として「無効」を登録する。更に、上記ライトリクエストに対するディレクトリ検索要求を該当するノードに発行し、その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。このディレクトリ検索要求には、上記ライトリクエスト中のライトアドレスが含まれると共に、上記ライトリクエストを格納した順序保証バッファ２８のエントリを示す情報（エントリ番号）が含まれる。
【００７１】
・順序保証バッファ２８に登録したリクエストが、ライトリクエストで、且つそのライトリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが存在することを示している場合は、上記ライトリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグを登録すると共に、上記アドレス一致情報２２をペンディング情報３０として登録する。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。
【００７２】
・順序保証バッファ２８に登録したリクエストが、リードリクエストで、且つそのリードリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが無いことを示している場合は、上記リードリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが不要なことを示す待ち合わせフラグ２９（値が「無効」）を登録すると共に、ペンディング情報３０として「無効」を登録する。更に、制御部３６に対して、リードリクエスト発行要求を出力し、その後、読み出し対象エントリを次のエントリに更新する。なお、上記リードリクエスト発行要求には、上記リードリクエストを登録したエントリのエントリ番号が含まれている。
【００７３】
・順序保証バッファ２８に登録したリクエストが、リードリクエストで、且つそのリードリクエストに対するアドレス一致情報２２が、アドレス一致先行ライトリクエストが存在することを示している場合は、上記リードリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグ２９を登録すると共に、上記アドレス一致情報２２をペンディング情報３０として登録する。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。
【００７４】
制御部３６は、次のような機能を有する。
【００７５】
・ノード４−ｋ（１≦ｋ≦ｍ）からリクエストの発行許可が返却された場合は、順序保証バッファ２８に登録されているリクエストの内の、発行許可されたリクエストに対応する待ち合わせフラグ２９の値を「無効」に変更し、そのリクエストの発行待ち合わせを解除する。なお、ノード４−ｋからの発行許可には、発行を許可するリクエストが格納されているエントリを示す情報が含まれている。即ち、ノード４−ｋは、入出力制御装置２−１から、ライトアドレス及びエントリ番号を含むディレクトリ検索要求が送られてきたとき、ディレクトリ４２を検索してリクエストの発行を許可するか否かを決定し、リクエストの発行を許可するのであれば、上記エントリ番号を含む発行許可を返却し、許可しないのであれば、上記エントリ番号を含む差戻指示を返却する。
【００７６】
・ノード４−ｋから差戻指示が返却された場合は、引き抜きポインタ３１に上記差戻指示に含まれているエントリ番号を設定すると共に、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態に切り替え、更に、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する。その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。なお、上記ディレクトリ検索要求の発行指示には、上記エントリ番号が含まれている。
【００７７】
・登録処理部２７からリードリクエスト発行要求が入力された場合は、引き抜きポインタ３１に上記リードリクエスト発行要求に含まれているエントリ番号を設定すると共に、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態に切り替え、更に、発行処理部３４に対してリクエストの発行指示を出力する。その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。
【００７８】
・ＦＩＦＯポインタ３２が指し示す順序保証バッファ２８のエントリ（登録時期が最も古い、未発行のリクエストが登録されているエントリ）に登録されている待ち合わせフラグ２９の値が「無効」で、且つ登録されているリクエストがライトリクエストの場合、発行処理部３４に対してリクエストの発行指示を出力し、更に、有効フラグ保持部２５の各エントリに保持されている有効フラグの内の、該当する有効フラグの値を「無効」に変更する。即ち、発行したライトリクエストに対応する有効フラグの値を「無効」にする。
【００７９】
・発行処理部３４に対して発行を指示したライトリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が順序保証バッファ２８に登録されている場合は、引き抜きポインタ３１に上記アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号を設定すると共にポインタセレクタ３３を引き抜きポインタ３１を選択する状態にし、更に、発行処理部３４に対してディレクトリ検索要求の発行指示を出力し、その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。なお、このディレクトリ検索要求の発行指示には、上記アドレス一致後続ライトリクエストが格納されているエントリのエントリ番号が含まれている。
【００８０】
・発行処理部３４に対して発行を指示したライトリクエストをアドレス一致先行ライトリクエストとしているリードリクエスト（アドレス一致後続リードリクエスト）が順序保証バッファ２８に登録されている場合は、引き抜きポインタ３１に上記アドレス一致後続リードリクエストが登録されているエントリのエントリ番号を登録すると共にポインタセレクタ３３を引き抜きポインタ３１を選択する状態にし、更に、発行処理部３４に対してリクエストの発行指示を出力し、その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。
【００８１】
発行処理部３４は、次のような機能を有する。
【００８２】
・制御部３６からディレクトリ検索要求の発行指示が入力された場合は、順序保証バッファ２８から出力されているライトリクエスト中のライトアドレスと上記発行指示中のエントリ番号とを含んだディレクトリ検索要求をリクエストセレクタ３５を介して該当するノードに発行する。
【００８３】
・制御部３６からリクエストの発行指示が入力されている場合は、順序保証バッファ２８から読み出されているリクエスト（リードリクエストの場合もあれば、ライトリクエストの場合もある）をリクエストセレクタ３５を介して該当するノードに発行する。
【００８４】
〔実施の形態の動作の説明〕
次に本実施の形態の動作について詳細に説明する。なお、以下の説明では、入出力デバイス１−１が入出力制御装置２−１に対してリクエストを発行した場合について説明するが、他の入出力デバイス１−２〜１−ｎが入出力制御装置２−２〜２−ｎに対してリクエストを発行した場合も同様の動作が行われる。
【００８５】
入出力デバイス１−１が入出力制御装置２−１に発行したリクエストは、入出力制御装置２−１内の入力バッファ２１及びアドレス一致先行ライトリクエスト検出処理部２３に入力される。
【００８６】
入力バッファ２１は、リクエストが入力されると、自バッファ２１が有している１２８個のエントリの内の、現在登録対象エントリとしているエントリに上記リクエストを登録し、その後、登録対象エントリを次のエントリに変更する。なお、初期状態においては、登録対象エントリは、第０番目のエントリになっている。
【００８７】
一方、アドレス一致先行ライトリクエスト検出処理部２３は、リクエストが入力される毎に、図３のフローチャートに示す処理を行う。
【００８８】
アドレス一致先行ライトリクエスト検出処理部２３は、リクエストが入力されると、先ず、入力されたリクエストがライトリクエストなのか、リードリクエストかを判定する（ステップＳ３１）。
【００８９】
そして、ライトリクエストである場合（ステップＳ３１がＹＥＳ）は、ライトリクエストに含まれているライトアドレスを一致判定回路２６に渡し（ステップＳ３２）、その後、一致判定回路２６からの応答を待つ（ステップＳ３３）。
【００９０】
一致判定回路２６は、ライトアドレスが渡されると、アドレス一致管理バッファ２４に登録されているアドレスの中に、上記ライトアドレスと一致し、且つ有効フラグ保持部２５に保持されている対応する有効フラグが「有効」になっているアドレスが存在するか否かに基づいて、アドレス一致先行ライトリクエストが存在するか否かを判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。なお、アドレス一致先行ライトリクエストが存在すると判定した場合には、判定結果として、どのライトリクエスト（例えば、何個前のライトリクエスト）が、アドレス一致先行ライトリクエストとなるのかもアドレス一致先行ライトリクエスト検出処理部２３に通知する。
【００９１】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６からの通知に従ってアドレス一致情報２２を生成し、入力バッファ２１中の該当するエントリ（今回処理対象にしているライトリクエストが登録されたエントリ）に登録する（ステップＳ３４）。即ち、一致判定回路２６からアドレス一致先行ライトリクエストが存在しないことが通知された場合は、アドレス一致先行ライトリクエストが存在しないことを示す有無情報を含んだアドレス一致情報２２を生成して該当するエントリに登録し、存在することが通知された場合は、アドレス一致先行ライトリクエストが存在することを示す有無情報およびどのライトリクエストがアドレス一致先行ライトリクエストとなるのかを示す先行リクエスト特定情報を含んだアドレス一致情報２２を該当するエントリに登録する（ステップＳ３４）。
【００９２】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、今回処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４のエントリの内の、現在登録対象エントリにしているエントリに登録すると共に、有効フラグ保持部２５の該当するエントリに登録されている有効フラグを「有効」にする（ステップＳ３５、Ｓ３６）。なお、アドレス一致先行ライトリクエスト検出処理部２３は、初期状態においては、アドレス一致管理バッファ２４の第０番目のエントリを登録対象エントリにしており、アドレスを格納する毎に、登録対象エントリを更新する。
【００９３】
これに対して、入力されたリクエストがリードリクエストであると判定した場合（ステップＳ３１がＮＯ）は、上記リードリクエストに含まれているリードアドレスを一致判定回路２６に渡し（ステップＳ３７）、その後、一致判定回路２６からの応答を待つ（ステップＳ３８）。一致判定回路２６は、リードアドレスが渡されると、前述した処理と同様の処理を行い、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これにより、アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１のエントリの内の、今回処理対象にしているリードリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３９）。
【００９４】
次に、アドレス一致先行ライトリクエスト検出処理部２３およびアドレス一致判定回路２６の動作を、具体例を挙げて説明する。
【００９５】
今、有効フラグ保持部２５の第０番目〜第１９１番目のエントリに登録されている有効フラグの値が図４（Ａ）に示すものであるとする。なお、図４では、有効フラグの値「有効」を「１」で表し、「無効」を「０」で表している。
【００９６】
図４（Ａ）に示すように、有効フラグ保持部２５の第０番目〜第７番目のエントリに登録されている有効フラグの値が「有効」になっているときに、ライトリクエスト（初期状態から数えて第８番目のリクエストであるとする。但し、最初のリクエストを第０番目のリクエストとする）が入力されると、アドレス一致先行ライトリクエスト検出処理部２３は、上記ライトリクエスト中のライトアドレスを一致判定回路２６に渡し、待ち状態となる（図３のステップＳ３１がＹＥＳ、Ｓ３２、Ｓ３３）。
【００９７】
一致判定回路２６は、ライトアドレスが渡されると、有効フラグ保持部２５の第０番目〜第７番目のエントリに登録されている有効フラグの値が「有効」となっているので、上記エントリと対応するアドレス一致管理バッファ２４の第０番目〜第７番目のエントリを比較対象エントリにして、上記ライトアドレスと一致するアドレスが登録されているか否かを調べることにより、アドレス一致先行ライトリクエストが存在するか否かを判定する。
【００９８】
なお、前述したように、アドレス一致管理バッファ２４の第ｊ番目のエントリに対応する有効フラグ保持部２５上のエントリは、第ｊ番目、第（ｊ＋６４）番目、第（ｊ＋１２８）番目の計３個のエントリであり、一致判定回路２６は、アドレス一致管理バッファ２４の第ｊ番目のエントリに対応する有効フラグ保持部２５上の３個のエントリの何れかに「有効」を示す有効フラグが登録されていれば、上記第ｊ番目のエントリを比較対象エントリとする。また、一致判定回路２６は、ライトアドレスと一致するアドレスが比較対象エントリ（第０番目〜第７番目のエントリ）に登録されているか否かを調べる際、アドレスの登録時期が最も新しいエントリ（第７番目のエントリ）から最も古いエントリ（第０番目のエントリ）に向かって比較処理を行う。そして、アドレスの登録時期が最も古いエントリまで調べてもライトアドレスと一致するアドレスが格納されているエントリが存在しなかった場合は、アドレス一致先行ライトリクエスト無しと判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これに対して、ライトアドレスと一致するアドレスが登録されているエントリを見つけた場合は、アドレス一致先行ライトリクエスト有りと判定し、アドレス一致先行ライトリクエスト検出処理部２３に判定結果を通知する。このときの判定結果には、何個前のライトリクエストがアドレス一致先行ライトリクエストとなるのかを示す情報も含まれる。なお、アドレス一致先行ライトリクエストとなるライトリクエストが何個前のライトリクエストであるかは、例えば、ライトアドレスと一致するアドレスが登録されているエントリが、比較対象エントリの内の、アドレスの登録時期が新しい方から何番目のエントリであるかを調べることにより求めることができる。
【００９９】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６から判定結果が通知されると、それに基づいてアドレス一致情報２２を生成し、入力バッファ２１の各エントリの内の、現在処理対象としているライトリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３４）。この例の場合、現在処理対象にしているライトリクエストは、初期状態から数えて第８番目のリクエストであり、上記ライトリクエストは、入力バッファ２１の第８番目のエントリに格納されているので、第８番目のエントリにアドレス一致情報２２を登録することになる。
【０１００】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、現在処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４の第８番目のエントリに登録し（ステップＳ３５）、更に、値「有効」が設定されている有効バッファ保持部２５上のエントリの内の、エントリ番号が最も大きいエントリ（第７番目のエントリ）の次のエントリ（第８番目のエントリ）に、値「有効」を登録する（ステップＳ３６）。
【０１０１】
また、図４（Ｂ）に示すように、有効フラグ保持部２５の第３番目〜第１３５番目のエントリに登録されている有効フラグが値が「有効」になっているときにライトリクエスト（初期状態から数えて第１３６番目のリクエストとする）が入力された場合は、アドレス一致先行ライトリクエスト検出処理部２３は、上記ライトリクエスト中のライトアドレスを一致判定回路２６に渡し、待ち状態となる（ステップＳ３１がＹＥＳ、Ｓ３２、Ｓ３３）。
【０１０２】
一致判定回路２６は、ライトアドレスが渡されると、有効フラグ保持部２５の第３番目〜第１３５番目のエントリに登録されている有効フラグの値が「有効」となっているので、上記エントリと対応するアドレス一致管理バッファ２４の第０番目〜第６３番目のエントリを比較対象エントリにして、上記ライトアドレスと一致するアドレスが登録されているか否かを調べることにより、アドレス一致先行ライトリクエストが存在するか否かを判定する。その際、アドレスの登録時期が最も新しいエントリ（第７番目のエントリ）から順番に、比較処理を行うエントリのエントリ番号を順次減少させて比較処理を行う（但し、比較処理を行うエントリのエントリ番号が「０」となった場合は、次に比較処理を行うエントリのエントリ番号を「６３」とする）。そして、アドレスの登録時期が最も古いエントリ（第８番目のエントリ）まで調べてもライトアドレスと一致するアドレスが格納されているエントリが存在しなかった場合は、アドレス一致先行ライトリクエスト無しと判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これに対して、ライトアドレスと一致するアドレスが登録されているエントリを見つけた場合は、アドレス一致先行ライトリクエスト有りと判定し、アドレス一致先行ライトリクエスト検出処理部２３に判定結果を通知する。
【０１０３】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６から判定結果が通知されると、それに基づいてアドレス一致情報２２を生成し、入力バッファ２１の各エントリの内の、現在処理対象としているライトリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３４）。この例の場合、現在処理対象にしているライトリクエストは、初期状態から数えて第１３６番目のリクエストであり、上記ライトリクエストは、入力バッファ２１の第８番目（１３６÷６４＝２余り８）のエントリに格納されているので、第８番目のエントリにアドレス一致情報２２を登録することになる。
【０１０４】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、現在処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４の第８番目のエントリに登録し（ステップＳ３５）、更に、値「有効」が設定されている有効バッファ保持部２５上のエントリの内の、エントリ番号が最も大きいエントリ（第１３５番目のエントリ）の次のエントリ（第１３６番目のエントリ）に、値「有効」を登録する（ステップＳ３６）。
【０１０５】
次に、登録処理部２７の動作について説明する。
【０１０６】
登録処理部２７は、図５のフローチャートに示すように、入力バッファ２１の第０番目〜第１２７番目のエントリの内の、読み出し対象エントリに注目し、そのエントリに有効なアドレス一致情報２２が登録されるのを待つ（ステップＳ５０１、Ｓ５０２）。なお、初期状態においては、第０番目のエントリを読み出し対象エントリにしている。
【０１０７】
そして、読み出し対象エントリに有効なアドレス一致情報が登録されると（ステップＳ５０２がＹＥＳ）、読み出し対象エントリに登録されているリクエスト及びアドレス一致情報２２を入力し、入力したリクエストを順序保証バッファ２８の登録対象エントリに登録し、更に、登録対象エントリを次のエントリに更新する（ステップＳ５０３）。なお、初期状態においては、登録対象エントリは、第０番目のエントリになっている。
【０１０８】
その後、登録処理部２７は、入力バッファ２１から入力したリクエストがライトリクエストなのか、リードリクエストなのかを調べる（ステップＳ５０４）。
【０１０９】
ライトリクエストであった場合（ステップＳ５０４がＹＥＳ）は、ステップＳ５０３で入力したアドレス一致情報２２中の有無情報に基づいて、アドレス一致先行ライトリクエストが存在するか否かを判断する（ステップＳ５０５）。
【０１１０】
そして、アドレス一致先行ライトリクエストが存在しない場合（ステップＳ５０５がＮＯ）は、ステップＳ５０３においてこのライトリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記リクエストが発行待ち合わせ状態となるようにすると共に、ペンディング情報３０を「無効」にして上記ライトリクエストに関するディレクトリ検索要求の発行を許可する（ステップＳ５０６）。その後、発行処理部２７は、制御部３６に対してディレクトリ検索要求の発行許可要求を送り、制御部３６から発行許可を受けたら、上記ライトリクエストに関するディレクトリ検索要求を発行する（ステップＳ５０７）。ディレクトリ検索要求には、上記ライトリクエスト中のライトアドレス及び上記ライトリクエストを登録した順序保証バッファ２８のエントリ番号が含まれており、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードへ送られる。また、登録処理部２７からのディレクトリ検索要求の発行許可要求を受け付けた制御部３６は、リクエストセレクタ３５を登録処理部２７を選択する状態に切り替えた後、登録処理部２７に対して発行許可を与え、更に所定時間後、リクエストセレクタ３５を発行処理部３４を選択する状態に戻す。その後、登録処理部２７は、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再び、ステップＳ５０１の処理を行う。
【０１１１】
これに対して、アドレス一致先行ライトリクエストが存在する場合（ステップＳ５０５がＹＥＳ）は、ステップＳ５０３においてこのライトリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記ライトリクエストが発行待ち合わせ状態になるようにすると共に、ペンディング情報３０としてステップＳ５０３で入力したアドレス一致情報２２を登録し、上記ライトリクエストに関するディレクトリ検索要求が発行待ち合わせ状態になるようにする（ステップＳ５０９）。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再びステップＳ５０１の処理を行う。
【０１１２】
一方、ステップＳ５０３で入力したリクエストがリードリクエストであると判断した場合（ステップＳ５０４がＮＯ）は、ステップＳ５０３で入力したアドレス一致情報２２中の有無情報に基づいて、アドレス一致先行ライトリクエストが存在するか否かを判断する（ステップＳ５１０）。
【０１１３】
そして、アドレス一致先行ライトリクエストが存在しない場合（ステップＳ５１０がＮＯ）は、ステップＳ５０３においてこのリードリクエストを格納した、順序保証バッファ２８のエントリ中の待ち合わせフラグを「無効」にして上記リードリクエストを発行可能状態にすると共に、ペンディング情報３０を「無効」にする（ステップＳ５１１）。次いで、登録処理部２７は、制御部３６に対して上記リードリクエストの発行を要求するリードリクエスト発行要求を出力し（ステップＳ５１２）、その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再び、ステップＳ５０１の処理を行う。なお、リードリクエスト発行要求には、リードリクエストを登録した順序保証バッファ２８のエントリ番号が含まれている。また、制御部３６がリードリクエスト発行要求を受け付けたときの動作は、図６のフローチャートを用いて後で詳しく説明する。
【０１１４】
これに対してアドレス一致先行ライトリクエストが存在する場合（ステップＳ５１０がＹＥＳ）は、ステップＳ５０３においてこのリードリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記リードリクエストを発行待ち合わせ状態にすると共に、ステップＳ５０３で入力したアドレス一致情報２２をペンディング情報３０として登録する（ステップＳ５１３）。その後、登録処理部２７は、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再びステップＳ５０１の処理を行う。
【０１１５】
次に、制御部３６の動作について説明する。
【０１１６】
先ず、登録処理部２７からのリードリクエスト発行要求を受け付けたときの動作を、図６のフローチャートを参照して説明する。
【０１１７】
制御部３６は、登録処理部２７からのリードリクエスト発行要求を受け付けると、先ず、上記要求に含まれているエントリ番号を引き抜きポインタに設定する（ステップＳ６１）。上記エントリ番号は、発行対象にしているリードリクエストが格納されている、順序保証バッファ２８上のエントリを示している。次いで、制御部３６は、ポインタセレクタ３３の状態を、引き抜きポインタ３１を選択する状態に変更する（ステップＳ６２）。これにより、順序保証バッファ２８は、引き抜きポインタ３１が指し示すエントリに登録されているリクエスト（発行対象にしているリードリクエスト）を、発行処理部３４に対して出力する。その後、制御部３６は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ６３）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているリードリクエストを、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。その後、制御部３６は、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ６４）。
【０１１８】
次に、ノード（例えば、ノード４−１）からライトリクエストの発行許可が返却された場合の動作を、図７のフローチャートを参照して説明する。
【０１１９】
制御部３６は、ノード４−１からライトリクエストの発行許可（発行を許可するライトリクエストが登録されているエントリのエントリ番号が含まれている）が送られてくると、順序保証バッファ２８上のエントリの内の、上記発行許可に含まれているエントリ番号のエントリに登録されている待ち合わせフラグ２９の値を「有効」から「無効」に変更し、上記ライトリクエストを発行可能状態にする（ステップＳ７１）。
【０１２０】
次に、ノード（例えば、ノード４−１）から差戻指示が返却された場合の動作を、図８のフローチャートを参照して説明する。
【０１２１】
制御部３６は、ノード４−１から差戻指示（差し戻すライトリクエストが登録されているエントリのエントリ番号を含む）が送られてくると、先ず、引き抜きポインタ３１に、上記差戻指示に含まれているエントリ番号を設定し、その後、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態にする（ステップＳ８１、Ｓ８２）。これにより、順序保証バッファ２８は、引き抜きポインタ３１が指し示すエントリの登録されているライトリクエストを発行処理部３４に対して出力する。その後、制御部３６は、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する（ステップＳ８３）。この発行指示には、差し戻すライトリクエストが登録されているエントリのエントリ番号が含まれている。発行処理部３４は、ディレクトリ検索要求の発行指示が入力されると、順序保証バッファ２８から出力されているライトリクエスト中のライトアドレス及び上記発行指示中のエントリ番号を含んだディレクトリ検索要求を生成し、生成したディレクトリ検索要求を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノード４−１に発行する。その後、制御部３６は、ポインタセレクタ３３の状態を、ＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ８４）。
【０１２２】
次に制御部３６が順序保証バッファ２８に登録されているライトリクエストを登録順に発行するために行っている動作を図９のフローチャートを参照して説明する。
【０１２３】
制御部３６は、ＦＩＦＯポインタ３２が指し示している順序保証バッファ２８のエントリに登録されている待ち合わせフラグ２９が「無効」になるのを待ち合わせており（ステップＳ９０１、Ｓ９０２）、該当する待ち合わせフラグ２９が「無効」となると（ステップＳ９０２がＮＯ）、上記エントリに登録されているリクエストの種別を調べる（ステップＳ９０３）。
【０１２４】
そして、リードリクエストであった場合（ステップＳ９０３がＹＥＳ）は、ＦＩＦＯポインタ３２を更新し、次のエントリを指し示すようにした後（ステップＳ９１８）、再び、ステップＳ９０１の処理を行う。
【０１２５】
これに対して、ライトリクエストであった場合（ステップＳ９０３がＮＯ）は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ９０４）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているライトリクエスト（ＦＩＦＯポインタ３２が指し示すエントリに登録されているリクエスト）を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。
【０１２６】
その後、制御部３６は、有効フラグ保持部２５の各エントリに保持されている有効フラグの内の、今回発行したライトリクエストに対応する有効フラグを「無効」とする（ステップＳ９０５）。
【０１２７】
次に、制御部３６は、今回発行したライトリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が、順序保証バッファ２８に登録されているか否かを調べる（ステップＳ９０６）。この処理は、ペンディング情報３０中の先行リクエスト特定情報を利用して行う。
【０１２８】
そして、アドレス一致後続ライトリクエストが登録されている場合（ステップＳ９０６がＹＥＳ）は、先ず、上記アドレス一致後続ライトリクエストに対応するペンディング情報３０を「無効」にする（ステップＳ９０７）。次いで、引き抜きポインタ３１に、上記アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号を設定し（ステップＳ９０８）、更に、ポインタセレクタ３３を引き抜きポインタ３１を選択する状態にする（ステップＳ９０９）。これにより、順序保証バッファ２８からは、上記アドレス一致後続ライトリクエストが出力される。
【０１２９】
その後、制御部３６は、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する（ステップＳ９１０）。この発行指示には、アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号が含まれている。発行処理部３４は、上記指示を受け付けると、順序保証バッファ２８から出力されているアドレス一致後続ライトリクエスト中のライトアドレスと、上記発行指示中のエントリ番号とを含んだディレクトリ検索要求を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。その後、制御部３６は、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ９１１）。
【０１３０】
これに対して、アドレス一致後続ライトリクエストが登録されていなかった場合（ステップＳ９０６がＮＯ）及びステップＳ９１１の処理が終了した場合、制御部３６は、今回発行したライトリクエストをアドレス一致先行ライトリクエストとしているリードリクエスト（アドレス一致後続リードリクエスト）が、順序保証バッファ２８に登録されているか否かを調べる（ステップＳ９１２）。
【０１３１】
そして、登録されていない場合（ステップＳ９１２がＮＯ）は、ＦＩＦＯポインタ３２が指し示すエントリを次のエントリに更新した後（ステップＳ９１８）、再び、ステップＳ９０１の処理を行う。
【０１３２】
これに対して、アドレス一致後続リードリクエストが登録されている場合（ステップＳ９１２がＹＥＳ）は、先ず、上記アドレス一致後続リードリクエストに対応する待ち合わせフラグ２９、ペンディング情報３０を「無効」にする（ステップＳ９１３）。次いで、引き抜きポインタ３１に上記アドレス一致後続リードリクエストが登録されているエントリのエントリ番号を設定し（ステップＳ９１４）、更に、ポインタセレクタ３３を引き抜きポインタ３１を選択する状態に切り替える（ステップＳ９１５）。これにより、順序保証バッファ２８からは、上記アドレス一致後続リードリクエストが出力される。
【０１３３】
その後、制御部３６は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ９１６）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているアドレス一致後続リードリクエストを、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。
【０１３４】
次いで、制御部３６は、ポインタセレクタ３３を、ＦＩＦＯポインタ３２を選択する状態に戻し（ステップＳ９１７）、その後、ステップＳ９１２の処理を行う。ステップＳ９１２がＮＯとなると、ＦＩＦＯポインタ３２が保持しているエントリ番号をインクリメントし、次のエントリを指し示すようにする（ステップＳ９１８）。その後、制御部３６は、再び、ステップＳ９０１の処理を行う。
【０１３５】
次に、タイミングチャートを用いて本実施の形態および従来技術の動作を説明する。
【０１３６】
図１０は、本実施の形態の動作を示すタイミングチャートであり、本実施の形態の入出力制御装置２−１（図１参照）が、ライトアドレスの異なる３個のライトリクエストＡ、Ｂ、Ｃを受け付けたときの動作を示している。
【０１３７】
各ライトリクエストＡ、Ｂ、Ｃは、それぞれサイクル１、２、３において入力バッファ２１のエントリａ、ｂ、ｃに登録される。また、各ライトリクエストＡ、Ｂ、Ｃのライトアドレスは、アドレス一致先行ライトリクエスト検出処理部２３においてアドレス一致先行ライトリクエストの有無が調べられた後、それぞれサイクル２、３、４においてアドレス一致管理バッファ２４のエントリα、β、γに登録される。
【０１３８】
その後、サイクル３、４、５において、入力バッファ２１からライトリクエストＡ、Ｂ、Ｃが順次読み出され、順序保証バッファ２８のエントリ０、１、２に登録される。ライトリクエストＡ、Ｂ、Ｃは、ライトアドレスが異なるため、アドレス一致先行ライトリクエストは存在しない。従って、各ライトリクエストＡ、Ｂ、Ｃが順序保証バッファ２８に登録されると同時に、サイクル３、４、５において、ライトリクエストＡ、Ｂ、Ｃについてのディレクトリ検索要求Ａ、Ｂ、Ｃがクロスバーネットワーク３を介して該当するノードに発行される。
【０１３９】
ノードにおいて、ディレクトリの検索が行われ、サイクル７においてライトリクエストＡに対する発行許可Ａが送られてくると、ＦＩＦＯポインタ３２が指し示しているエントリ０に登録されているライトリクエストがサイクル８においてリクエストセレクタ３５、クロスバーネットワーク３を介して該当するネットワークに発行される。この後、ＦＩＦＯポインタ３２は、エントリ１を指し示す。
【０１４０】
サイクル９において、ライトリクエストＣに対する発行許可Ｃが送られてくると、ライトリクエストＣは、発行可能な状態になるが、このとき、ＦＩＦＯポインタ３２は、エントリ１を指し示しているので、エントリ２に登録されているライトリクエストＣは、発行されない。
【０１４１】
その後、サイクル１１において、ライトリクエストＢに対する発行許可Ｂが送られてくると、ライトリクエストＢが発行可能な状態となり、サイクル１２において、該当するノードに発行され、その後、ＦＩＦＯポインタ３２が、エントリ２を指し示す。これにより、サイクル１３において、ライトリクエストＣが該当するノードに発行される。
【０１４２】
図１１及び図１２は、それぞれ従来技術及び本実施の形態の動作を示すタイミングチャートであり、ライトアドレスが同一のライトリクエストＡ、Ａ'、Ａ"を、従来技術及び本実施の形態の入出力制御装置２−１（図１６及び図１参照）が受け付けた場合の動作を示している。
【０１４３】
従来技術の動作を示す図１１を参照すると、各ライトリクエストＡ、Ａ'、Ａ"は、それぞれサイクル１、２、３において、入力バッファ１０１のエントリａ、ｂ、ｃに登録される。また、各ライトリクエストＡ、Ａ'、Ａ"のライトアドレスは、それぞれサイクル２、３、４において、アドレス一致管理バッファ２３のエントリα、β、γに登録される。また、従来技術では、ライトリクエストアドレスの一致判定処理を行わないので、サイクル３、４、５において、ライトリクエストＡ、Ａ'、Ａ"が順序保証バッファ１０６のエントリ０、１、２に登録されると同時に、ライトリクエストＡ、Ａ'、Ａ"についてのディレクトリ検索要求Ａ、Ａ'、Ａ"が該当するノードに発行される。
【０１４４】
ノードは、ディレクトリ検索要求Ａ、Ａ'、Ａ"が競合するので、サイクル７、８、９において、ライトリクエストＡの発行許可Ａ、ライトリクエストＡ'、Ａ"の差戻指示Ａ'、Ａ"を返却する。これにより、サイクル８においてライトリクエストＡが該当するノードに発行され、サイクル９、１０において、ライトリクエストＡ'、Ａ"についてのディレクトリ検索要求Ａ'、Ａ"が該当するノードへ発行される。
【０１４５】
ノードは、ディレクトリ検索要求Ａ'、Ａ"が競合するので、サイクル１１、１２において、ライトリクエストＡ'の発行許可Ａ'、ライトリクエストＡ"の差戻指示を返却する。これにより、サイクル１２においてライトリクエストＡ'が該当するノードに発行され、サイクル１３においてライトリクエストＡ"に関するディレクトリ検索要求Ａ"が該当するノードに発行される。
【０１４６】
ノードは、ディレクトリ検索要求Ａ"はアドレス競合しないので、ライトリクエストＡ"に対する発行許可Ａ"を返却する。サイクル１５において、発行許可Ａ"を受信すると、サイクル１６において、ライトリクエストＡ"を該当するノードに対して発行する。
【０１４７】
上記した動作が行われている間にクロスバーネットワーク３上を通過したリクエスト数は１５個となり、要したサイクル数は１６サイクルとなる。
【０１４８】
一方、本実施の形態の動作を示す図１２を参照すると、各ライトリクエストＡ、Ａ'、Ａ"は、それぞれサイクル１、２、３において、入力バッファ２１のエントリａ、ｂ、ｃに登録され、サイクル２、３、４において、アドレス一致管理バッファ２４のエントリα、β、γに登録され、サイクル３、４、５において、順序保証バッファ２８のエントリ０、１、２に登録される。本実施の形態では、ライトアドレスについてもアドレス一致先行ライトリクエストが存在するか否かを判定し、存在しない場合のみ、ディレクトリ検索要求を発行するようにしているので、ライトリクエストＡに関するディレクトリ検索要求Ａは、サイクル３において発行されるが、ライトリクエストＡ'、Ａ"に関するディレクトリ検索要求Ａ'、Ａ"は、アドレス一致先行ライトリクエストＡが存在するため、発行待ち状態となる。
【０１４９】
ノードでは、ディレクトリ検索要求Ａは、アドレス競合がないので、サイクル７において、ライトリクエストＡに対する発行許可Ａを返却する。これより、サイクル８において、ライトリクエストＡが該当するノードに発行される。
【０１５０】
ライトリクエストＡが発行されると、ライトリクエストＡ'に対するアドレス一致先行ライトリクエストが存在しなくなるので、サイクル９において、ライトリクエストＡ'に対するディレクトリ検索要求Ａ'が発行される。ライトリクエストＡ"には、アドレス一致先行ライトリクエストＡ'が存在するので、ディレクトリ検索要求Ａ"の発行は待ち合わされる。
【０１５１】
ノードでは、ディレクトリ検索要求Ａ'には、アドレス競合がないので、サイクル１１において、ライトリクエストＡ'に対する発行許可Ａ'を返却する。これにより、サイクル１２において、ライトリクエストＡ'が該当するノードに発行される。
【０１５２】
ライトリクエストＡ'が発行されると、ライトリクエストＡ"に対するアドレス一致先行ライトリクエストが存在しなくなるので、サイクル１３において、ライトリクエストＡ"に対するディレクトリ検索要求Ａ"が該当するノードに発行される。
【０１５３】
ノードでは、ディレクトリ検索要求Ａ"には、アドレス競合がないので、サイクル１５において、ライトリクエストＡ"に対する発行許可Ａ"を返却する。これにより、サイクル１６において、ライトリクエストＡ"が発行される。
【０１５４】
上記した動作が行われている間にクロスバーネットワーク３上を通過したリクエスト数は９個となり、要したサイクル数は１６サイクルとなる。本実施の形態では、リクエスト数が９個で済むため、リクエスト数が１５個であった従来技術に比較してトラフィックを低減させることができる。
【０１５５】
図１３及び図１４は、それぞれ従来技術及び本実施の形態の動作を示すタイミングチャートであり、ライトリクエストＡ、Ｂ及びリードリクエストＡ、Ｃを、従来技術及び本実施の形態の入出力制御装置２−１（図１６及び図１参照）が受け付けた場合の動作を示している。なお、ライトリクエストＡのライトアドレスと、リードリクエストＡのリードアドレスは同一であるとする。
【０１５６】
従来技術の動作を示す図１３を参照すると、従来技術では、リードリクエストを入力バッファ１０１から読み出した後、アドレス一致判定を行うため、リードリクエストＡのアドレス一致判定の影響でリードリクエストＣのクロスバーネットワーク３への発行が遅れている。また、順序保証バッファ１０６に登録されたリードリクエストＡは、アドレス一致先行ライトリクエストＡが存在するので、ライトリクエストＡの発行を待ち合わせるが、ライトリクエストＡとリードリクエストＡとの間に異なるアドレスのライトリクエストＢがあるため、ライトリクエストＡの発行だけでなく、ライトリクエストＢの発行も待ち合わせなければならない。
【０１５７】
ライトリクエストＡ、Ｂが、サイクル３、４において順序保証バッファ１０６に登録されると同時に、ディレクトリ検索要求Ａ、Ｂがクロスバーネットワーク３を介して該当するノードへ発行される。
【０１５８】
ノードは、ディレクトリ検索要求Ａにはアドレス競合がないので、サイクル７において、ライトリクエストＡの発行許可を返却する。これにより、サイクル８において、順序保証バッファ１０６からライトリクエストＡが発行される。その後、サイクル１１においてノードからライトリクエストＢに対する発行許可が返却されると、サイクル１２において、順序保証バッファ１０６からライトリクエストＢが発行される。その後、サイクル１３において、漸くリードリクエストＡが発行されることになる。この動作の要するサイクル数は１３サイクルである。
【０１５９】
一方、本実施の形態の動作を示す図１４を参照すると、リードリクエストを入力バッファ２１へ登録する時に、アドレス一致判定を行うためアドレス一致判定をパイプライン化でき、リードリクエストＣはリードリクエストＡのアドレス一致判定の影響を受けない。順序保証バッファ２８に登録されたリードリクエストＡは、アドレス一致先行リードリクエストが存在するので、ライトリクエストＡの発行を待ち合わせるが、ライトリクエストＡとリードリクエストＡとの間に異なるアドレスのライトリクエストＢがあっても、引き抜きポインタ３１を利用した引き抜き制御の対象となるので、ライトリクエストＢの発行まで待ち合わせる必要はない。
【０１６０】
ライトリクエストＡ、Ｂが、サイクル３、４において順序保証バッファに登録されると同時に、ディレクトリ検索要求Ａ、Ｂがクロスバーネットワーク３を介して該当するノードへ発行される。
【０１６１】
ノードは、ディレクトリ検索要求Ａには、アドレス競合がないので、サイクル７において、ライトリクエストＡの発行許可を返却する。これにより、サイクル８において順序保証バッファ２８からライトリクエストＡが該当するノードへ発行される。
【０１６２】
リードリクエストＡは、アドレス一致先行ライトリクエストであるライトリクエストＡが、サイクル８において、順序保証バッファ２８から発行されると、ペンディングが解除され、引き抜きポインタ３１を利用した引き抜き制御により、サイクル９において、クロスバーネットワーク３を介して該当するノードに発行される。その後、サイクル１１において、ノードからライトリクエストＢに対する発行許可が返却されると、サイクル１２において、順序保証バッファ２８からライトリクエストＢが発行される。この動作に要するサイクル数は１２サイクルであり、１３サイクル必要であった従来の技術に比較して性能が向上している。
【０１６３】
〔実施の形態の効果〕
本実施の形態によれば、アドレス一致先行ライトリクエストが存在するか否かを判定するための判定処理によって、後続のリクエストの処理が待たされることがないという効果を得ることができる。その理由は、入力バッファ２１の入力側において、入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファ２１に登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報２２を登録するアドレス一致先行ライトリクエスト検出処理部２３と、アドレス一致情報が登録されるまで、入力バッファ２１に登録されているリクエストの出力（順序保証バッファ２８への登録）を待ち合わせる登録処理部２７とを備えているからである。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【０１６４】
また、本実施の形態によれば、トラフィックの増加を防止することができるという効果を得ることができる。その理由は、入力バッファ２１に登録されている最古のライトリクエストがライトリクエストであっても、上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在する場合には、上記リクエストの発行許可要求（ディレクトリ検索要求）は発行せず、アドレス一致先行ライトリクエストが存在しない場合のみ、発行許可要求を発行する登録処理部２７と、順序保証バッファ２８に登録されている最古のリクエストを該当するノードに対して発行した際、上記最古のリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が存在する場合は、このアドレス一致後続ライトリクエストの発行許可要求（ディレクトリ検索要求）を該当するノードに発行する制御部３６とを備えているからである。
【０１６５】
更に、本実施の形態によれば、アドレス一致先行ライトリクエストとアドレス一致後続リードリクエストとの間に、他のライトリクエストが存在する場合であっても、上記アドレス一致後続リードリクエストの発行が待たされることがなくなるという効果を得ることができる。その理由は、順序保証バッファ２８に登録されている最古のリクエストを該当するノードに発行した際、順序保証バッファ２８に上記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、そのアドレス一致後続リードリクエストを該当するノードに発行する制御部３６を備えているからである。
【０１６６】
更に、本実施の形態によれば、入力バッファ２１において、アドレス一致先行ライトリクエストが存在しないリードリクエストによって、後続のリクエストが待たされることがなくなるという効果を得ることができる。その理由は、入力バッファ２１に登録されている最古のリクエストがリードリクエストで、且つ上記リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、上記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを順序保証バッファ２８に登録する登録処理部２７と、登録処理部２７によって順序保証バッファ２８に、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、そのリードリクエストを該当するノードへ発行する制御部３６とを備えているからである。
【産業上の利用可能性】
【０１６７】
本発明は、複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備えたマルチプロセッサシステム等に利用することができる。
【図面の簡単な説明】
【０１６８】
【図１】本発明にかかる入出力制御装置２−１の実施の形態の構成例を示すブロック図である。
【図２】アドレス一致情報の一例を示す図である。
【図３】アドレス一致先行ライトリクエスト検出処理部２３の処理例を示すフローチャートである。
【図４】アドレス一致先行ライトリクエスト検出処理部２３及び一致判定回路２６の動作を説明するための図である。
【図５】登録処理部２７の処理例を示すフローチャートである。
【図６】リードリクエスト発行要求を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図７】ライトリクエストの発行許可を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図８】差戻指示を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図９】リクエストを登録順に発行するときの制御部３６の処理例を示すフローチャートである。
【図１０】実施の形態の動作を示すためのタイミングチャートである。
【図１１】従来技術の動作を説明するためのタイミングチャートである。
【図１２】実施の形態の動作を示すためのタイミングチャートである。
【図１３】従来技術の動作を説明するためのタイミングチャートである。
【図１４】実施の形態の動作を示すためのタイミングチャートである。
【図１５】本発明を適用するマルチプロセッサシステムの構成例を示すブロック図である。
【図１６】従来の入出力制御装置２−１の構成例を示すブロック図である。
【図１７】アドレス一致先行ライトリクエスト検出処理部１０２の処理例を示すフローチャートである。
【図１８】ライトリクエストの発行許可を受け付けたときの制御部１１３の処理例を示すフローチャートである。
【図１９】差戻指示を受け付けたときの制御部１１３の処理例を示すフローチャートである。
【図２０】リクエストを登録順に発行するときの制御部１１３の処理例を示すフローチャートである。
【符号の説明】
【０１６９】
１−１〜１−ｎ…入出力デバイス
２−１〜２−ｎ…入出力制御装置
２１、１０１…入力バッファ
２２…アドレス一致情報
２３、１０２…アドレス一致先行ライトリクエスト検出処理部
２４、１０３…アドレス一致管理バッファ
１０４…有効フラグ
２５…有効フラグ保持部
２６、１０５…一致判定回路
２７…登録処理部
２８、１０６…順序保証バッファ
２９、１０７…待ち合わせフラグ
３０…ペンディング情報
３１、１０８…引き抜きポインタ
３２、１０９…ＦＩＦＯポインタ
３３、１１０…ポインタセレクタ
３４、１１１…発行処理部
３５、１１２…リクエストセレクタ
３６、１１３…制御部
３…クロスバーネットワーク
４−１〜４−ｍ…ノード
４１…メモリ制御部
４２…ディレクトリ
４３…共有メモリ
４４、４５…プロセッサ
【技術分野】
【０００１】
本発明は、複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、クロスバーネットワークを介して各ノードと接続される入出力制御装置とを備えたマルチプロセッサシステムに関し、特に、共有メモリの一貫性が保たれるように、入出力制御装置からノードに対して発行するライトリクエスト及びリードリクエストの発行順を制御するリクエスト発行技術に関する。
【背景技術】
【０００２】
従来から、メモリの一貫性を保証するため、入力されたリードリクエストとアクセス先のアドレスを同一にする未完了のライトリクエスト（アドレス一致先行ライトリクエスト）が存在するか否かを判定するということが行われている。その際、従来は、一般に、入力されたリードリクエストを入力バッファに一旦登録し、その後、アドレス一致先行ライトリクエストが存在するか否かを判定するようにしている（例えば、特許文献１参照）。
【０００３】
このような処理は、図１５に示すようなマルチプロセッサシステムにおいても行われている。同図に示すマルチプロセッサシステムは、複数の入出力デバイス１−１〜１−ｎと、各入出力デバイス毎の入出力制御装置２−１〜２−ｎと、クロスバーネットワーク３と、複数のノード４−１〜４−ｍとから構成されている。
【０００４】
各入出力デバイス１−１〜１−ｎは、それぞれ入出力制御装置２−１〜２−ｎを介してクロスバーネットワーク３に接続され、更に、クロスバーネットワーク３を介して各ノード４−１〜４−ｍに接続されている。
【０００５】
ノード４−１〜４−ｍは、それぞれクロスバーネットワーク３に接続されるメモリ制御部４１を備え、メモリ制御部４１は、その配下にプロセッサ４４、４５と、ディレクトリ４２と、各プロセッサ４４、４５によって共有される共有メモリ４３とを備えている。
【０００６】
各入出力デバイス１−１〜１−ｎからのメモリリクエスト（ライトリクエスト及びリードリクエストを含む。単にリクエストという場合もある）は、それぞれ入出力制御装置２−１〜２−ｎ及びクロスバーネットワーク３を介して該当するノードに送られる。入出力制御装置２−１〜２−ｎは、入出力デバイス１−１〜１−ｎからのメモリリクエストをノードに対して発行する際、共有メモリ４３の一貫性が保たれるように、その発行順を制御する機能を有する。即ち、ＰＣＩバス仕様リビジョン２．１等に規定されているように、ライトリクエストに関しては、先行するライトリクエストが完了してから後続のライトリクエストを発行し、リードリクエストに関しては、アクセス先を同じにする未完了のライトリクエスト（アドレス一致先行ライトリクエスト）が存在するか否かを調べ、存在する場合は、アドレス一致先行ライトリクエストが完了してから後続のリードリクエストを発行するようにしている。
【０００７】
図１６は、入出力制御装置２−１の構成例を示すブロック図であり、入出力デバイス１−１から入力されたリードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かの判定処理を、従来一般的に行われているように、リードリクエストを一旦入力バッファに登録してから行うようにした場合の構成を示している。即ち、図１６は、従来の入出力制御装置２−１の構成例を示すブロック図である。
【０００８】
図１６に示した入出力制御装置２−１は、入力バッファ１０１と、アドレス一致先行ライトリクエスト検出処理部１０２と、アドレス一致管理バッファ１０３と、一致判定回路１０５と、順序保証バッファ１０６と、引き抜きポインタ１０８と、ＦＩＦＯポインタ１０９と、ポインタセレクタ１１０と、発行処理部１１１と、リクエストセレクタ１１２と、制御部１１３とを備えている。なお、他の入出力制御装置も入出力制御装置２−１と同様の構成を有している。
【０００９】
〔動作の説明〕
次に、入出力制御装置として図１６に示した構成を有する入出力制御装置を用いた場合の、マルチプロセッサシステムの動作について説明する。
【００１０】
入出力デバイス１−１が発行したメモリリクエストは、一旦、入出力制御装置２−１内の入力バッファに登録される。
【００１１】
入出力制御装置２−１内のアドレス一致先行ライトリクエスト検出処理部１０２は、図１７のフローチャートに示すように、入力バッファ１０１の先頭に登録されているリクエストを入力し、そのリクエストがライトリクエストなのかリードリクエストなのかを判定する（ステップＡ１、Ａ２）。
【００１２】
今、入力バッファ１０１から入力したリクエストがライトリクエストであったとすると（ステップＡ２がＹＥＳ）、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストに含まれているライトアドレスをアドレス一致管理バッファ１０３に登録すると共に、そのライトアドレスに対する有効フラグを「有効」とする（ステップＡ３、Ａ４）。
【００１３】
その後、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストを順序保証バッファ１０６に登録すると共に、そのライトリクエストに対する待ち合わせフラグを「有効」にする（ステップＡ５、Ａ６）。待ち合わせフラグが「有効」になっている間、上記ライトリクエストは、発行を待ち合わされる。
【００１４】
更に、アドレス一致先行ライトリクエスト検出処理部１０２は、上記ライトリクエストの発行許可を受けるために、リクエストセレクタ１１２及びクロスバーネットワーク３を介して該当するノード（例えば、ノード４−１）に対して、ライトアドレスを含むディレクトリ検索要求を発行する（ステップＡ７）。その際、アドレス一致先行ライトリクエスト検出処理部１０２は、制御部１１３に対してセレクタ切り替え要求を送り、制御部１１３から切り替え完了通知が送られてきてからディレクトリ検索要求を発行する。また、制御部１１３は、アドレス一致先行ライトリクエスト検出処理部１０２からセレクタ切り替え要求が送られてくると、リクエストセレクタ１１２を発行処理部１１１を選択する状態からアドレス一致先行ライトリクエスト検出処理部１０２を選択する状態に変更し、その後、切り替え完了通知を返却する。また、制御部１１３は、切り替え完了通知を返却してから所定時間（アドレス一致先行ライトリクエスト検索処理部１０２がディレクトリ検索要求を発行するのに十分な時間）が経過すると、リクエストセレクタ１１２を、発行処理部１１１を選択する状態に戻す。
【００１５】
入出力制御装置２−１からディレクトリ検索要求が送られてきたノード４−１内のメモリ制御部４１は、ディレクトリ４２を参照し、上記ディレクトリ検索要求に含まれているライトアドレスをアクセスすることが可能か否かを判定する。ディレクトリ４２には、例えば、共有メモリ４３の各アドレスがロック状態にあるのか、フリー状態にあるのかを示すロック情報が登録されていおり、上記ライトアドレスに対するロック情報がフリー状態の場合は、アクセス可能であると判定し、ロック状態の場合は、アクセス不能と判定する。
【００１６】
そして、メモリ制御部４１は、アクセス可能と判定した場合は、上記ライトアドレスに対応するロック情報をロック状態にした後、要求元の入出力制御装置２−１に対して発行許可を返却し、アクセス不能と判定した場合は、差戻指示を返却する。
【００１７】
ノード４−１から返却された発行許可、差戻指示は、入出力制御装置２−１内の制御部１１３で受信される。
【００１８】
制御部１１３は、ノード４−１から発行許可が返却された場合は、図１８のフローチャートに示すように、発行許可されたライトリクエストの待ち合わせフラグ１０７を解除し、その値を「有効」から「無効」に変更する（ステップＢ１）。これにより、上記ライトリクエストは、順序保証バッファ１０６から発行可能な状態になる。なお、順序保証バッファ１０６に登録されたリクエストの発行動作は、後で、図２０を用いて説明する。
【００１９】
これに対して、ノード４−１から差戻指示が返却された場合は、図１９のフローチャートに示すように、先ず、引き抜きポインタ１０８が指し示す順序保証バッファ１０６のエントリを、差戻が指示されたライトリクエストが格納されているエントリを指し示すものに変更し（ステップＣ１）、次いで、ポインタセレクタ１１０をＦＩＦＯポインタ１０９を選択する状態から引き抜きポインタ１０８を選択する状態に切り替え（ステップＣ２）、更に、発行処理部１１１に対してディレクトリ検索要求の発行を指示する（ステップＣ３）。その後、制御部１１３は、ポインタセレクタ１１０の状態を、ＦＩＦＯポインタ１０９を選択する状態に戻す（ステップＣ４）。
【００２０】
上記したステップＣ２において、ポインタセレクタ１１０の状態が切り替えられることにより、順序保証バッファ１０６からは、差戻が指示されたライトリクエストが発行処理部１１１に対して出力される。
【００２１】
発行処理部１１１は、順序保証バッファ１０６からリクエストが入力された後、制御部１１３からディレクトリ検索要求の発行が指示された場合は、上記リクエストの代わりに、上記リクエスト中のライトアドレスを含んだディレクトリ検索要求を該当するノードに対して発行する。これに対して、順序保証バッファ１０６からリクエストが入力された後、制御部１１３からディレクトリ検索要求の発行が指示されなかった場合は、上記リクエストをそのまま該当するノード４−１に発行する。この例では、制御部１１３がステップＣ３において、ディレクトリ検索要求の発行を指示しているので、発行処理部１１１は、リクエスト中のライトアドレスを含んだディレクトリ検索要求を該当するノード４−１に対して発行することになる。
【００２２】
アドレス一致先行ライトリクエスト検出処理部１０２が入力バッファ１０１から入力したリクエストがライトリクエストの場合は、上記した処理が行われる。次に、アドレス一致先行ライトリクエスト検出処理部１０２が入力バッファ１０１からリードリクエストを入力した場合の動作について説明する。
【００２３】
図１７のフローチャートに示すように、アドレス一致先行ライトリクエスト検出処理部１０２は、入力バッファ１０１から入力したリクエストがリードリクエストの場合（ステップＡ１、Ａ２がＮＯ）は、先ず、上記リードリクエストに含まれているリードアドレスを一致判定回路１０５に渡す（ステップＡ８）。
【００２４】
一致判定回路１０５は、リードアドレスが渡されると、アドレス一致管理バッファ１０３を検索し、有効フラグ１０４が「有効」となっているライトアドレスの中に、上記リードアドレスと同一のアドレスが存在するか否かを調べる。そして、そのようなアドレスが存在する場合には、アドレス一致先行ライトリクエスト検出処理部１０２に対してアドレス一致先行ライトリクエストが有ることを通知し、そのようなアドレスが存在しない場合は、アドレス一致先行ライトリクエストが無いことを通知する。
【００２５】
アドレス一致先行ライトリクエスト検出処理部１０２は、アドレス一致先行ライトリクエスト無しが通知された場合（ステップＡ９がＮＯ）は、ステップＡ１で入力したリードリクエストを該当するノードに発行する（ステップＡ１２）。その際、ステップＡ７でディレクトリ検索要求を発行した場合と同様に、制御部１１３に対してセレクタ切り替え要求を出力し、制御部１１３から切り替え完了が通知された後、リードリクエストを発行する。
【００２６】
これに対して、アドレス一致先行ライトリクエスト有りが通知された場合（ステップＡ９がＹＥＳ）は、ステップＡ１で入力したリードリクエストを順序保証バッファ１０６に登録すると共に、上記リードリクエストの待ち合わせフラグ１０７を無効にする（ステップＡ１０、Ａ１１）。
【００２７】
次に、順序保証バッファ１０６に登録されているリクエストを発行する場合の動作を、図２０のフローチャートを参照して説明する。
【００２８】
制御部１１３は、順序保証バッファ１０６に登録されているリクエストを、登録順に発行するため、ＦＩＦＯポインタ１０９が指し示している順序保証バッファ１０６のエントリに登録されているリクエストの待ち合わせフラグ１０７が有効になっている場合（ステップＤ１、Ｄ２がＹＥＳ）は、無効に変更されるのを待ち合わせ（ステップＤ２がＮＯとなるのを待ち合わせ）、無効になっている場合（ステップＤ２がＮＯ）は、ＦＩＦＯポインタ１０９によって指し示されているリクエストを順序保証バッファ１０６から読み出す（ステップＤ３）。このリクエストは、発行処理部１１１に入力され、該当するノードに発行される。
【００２９】
その後、制御部１１３は、ステップＤ３で読み出したリクエストがライトリクエストであったか否かを判断し（ステップＤ４）、ライトリクエストであった場合（ステップＤ４がＹＥＳ）は、アドレス一致管理バッファ１０４に登録されている有効フラグ１０４の内の、今回読み出したライトリクエストに対応する有効フラグを「無効」に変更し（ステップＤ５）、その後、ＦＩＦＯポインタ１０９を更新し、次のエントリを指し示すようにする（ステップＤ６）。これに対して、ステップＤ３で読み出したリクエストがリードリクエストであった場合（ステップＤ４がＮＯ）は、ステップＤ５を飛ばしてステップＤ６の処理を行う。ステップＤ６が終了すると、制御手段１１３は、ステップＤ１の処理に戻る。
【００３０】
【特許文献１】特開２００１−３３１３６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００３１】
従来は、上述したように、図１６に示すような入出力制御装置２−１〜２−ｎを用いてメモリの一貫性が保証されるように、リクエストの発行順を制御しているが、次のような問題があった。
【００３２】
第１に、リードリクエストを入力バッファ１０１に一旦登録し、その後、上記リードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを判定するアドレス一致判定処理を行っているため、このアドレス一致判定処理に要する時間だけ、後続のリクエストの処理が遅れてしまうという問題がある。
【００３３】
第２に、入力バッファ１０１で受け付けたリクエストがライトリクエストである場合、アドレス一致先行ライトリクエスト検出処理部１０２が無条件でディレクトリ検索要求を発行しているため、同一のライトアドレスを含むライトリクエストが連続した場合、差戻指示が多発してトラフィックが増加してしまうという問題がある。
【００３４】
第３に、アドレス一致先行ライトリクエストが存在するリードリクエストは一旦順序保証バッファ１０６に登録され、その後、ＦＩＦＯポインタ１０９によってその登録エントリが指し示されるまで、発行が待ち合わされるため、上記アドレス一致先行ライトリクエストと上記リードリクエストとの間に存在する無関係なライトリクエストの発行許可待ちの影響を受けてしまい性能が低下するという問題がある。
【００３５】
第４に、アドレス一致先行ライトリクエストが存在しないリードリクエストは、順序保証バッファ１０６をバイパスさせるが、このときリクエストセレクタ１１２が順序保証バッファ１０６を選択する状態になっていると、上記リードリクエストの発行が待たされるため、後続のリクエストに対する処理が止まってしまうという問題がある。
【００３６】
〔発明の目的〕
そこで、本発明の目的は、マルチプロセッサシステムの処理速度を向上させると共に、トラフィックを低減させることにある。
【課題を解決するための手段】
【００３７】
本発明にかかる第１のマルチプロセッサシステムは、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムであって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする。
【００３８】
本発明にかかる第２のマルチプロセッサシステムは、第１のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする。
【００３９】
本発明にかかる第３のマルチプロセッサシステムは、第２のマルチプロセッサシステムにおいて、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする。
【００４０】
本発明にかかる第４のマルチプロセッサシステムは、第３のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする。
【００４１】
本発明にかかる第５のマルチプロセッサシステムは、第１〜第４のマルチプロセッサシステムにおいて、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする。
【００４２】
本発明にかかる第１の入出力制御装置は、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードとクロスバーネットワークを介して接続され、且つ、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを備えた入出力制御装置であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする。
【００４３】
本発明にかかる第２の入出力制御装置は、第１の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする。
【００４４】
本発明にかかる第３の入出力制御装置は、第２の入出力制御装置において、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする。
【００４５】
本発明にかかる第４の入出力制御装置は、第３の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする。
【００４６】
本発明にかかる第５の入出力制御装置は、第１〜第４の入出力制御装置において、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする。
【００４７】
本発明にかかる第１のリクエスト発行方法は、
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムにおけるリクエスト発行方法であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファに対して外部からリクエストが入力されたとき、アドレス一致先行ライトリクエスト検出処理部が、前記リクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録し、
登録処理部が、前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録することを特徴とする。
【００４８】
本発明にかかる第２のリクエスト発行方法は、第１のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行し、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更することを特徴とする。
【００４９】
本発明にかかる第３のリクエスト発行方法は、第２のリクエスト発行方法において、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行することを特徴とする。
【００５０】
本発明にかかる第４のリクエスト発行方法は、第３のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録し、
前記制御部が、前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行することを特徴とする。
【００５１】
〔作用〕
アドレス一致先行ライトリクエスト検出処理部は、入力バッファの入力側において、入力バッファに外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファに登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録する。登録処理部では、アドレス一致情報が登録されるまで、入力バッファからのリクエストの出力（順序保証バッファへの登録）を待ち合わせる。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【００５２】
また、登録処理部は、入力バッファに登録されている最古のリクエストがライトリクエストであっても、上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在する場合には、上記リクエストの発行許可要求は発行せず、アドレス一致先行ライトリクエストが存在しない場合のみ、発行許可要求を発行する。また、制御部は、順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、上記最古のリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が存在する場合は、このアドレス一致後続ライトリクエストの発行許可要求を該当するノードに発行する。これにより、トラフィックの増加を防止することができる。
【００５３】
また、制御部は、順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、順序保証バッファに上記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、そのアドレス一致後続リードリクエストを該当するノードに発行する。これにより、アドレス一致先行ライトリクエストとアドレス一致後続リードリクエストとの間に、他のライトリクエストが存在する場合であっても、アドレス一致後続リードリクエストの発行が待たされることがなくなる。
【００５４】
また、登録処理部は、入力バッファに登録されている最古のリクエストがリードリクエストで、且つ上記リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、上記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを順序保証バッファに登録する。また、制御部は、登録処理部によって順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、そのリードリクエストを該当するノードへ発行する。これにより、入力バッファにおいて、アドレス一致先行ライトリクエストが存在しないリードリクエストによって、後続のリクエストが待たされることがなくなる。
【発明の効果】
【００５５】
本発明によれば、アドレス一致先行ライトリクエストが存在するか否かを判定するための判定処理によって、後続のリクエストの処理が待たされることがないという効果を得ることができる。その理由は、入力バッファの入力側において、外部から入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファに登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、アドレス一致情報が登録されるまで、入力バッファに登録されているリクエストの出力（順序保証バッファへの登録）を待ち合わせる登録処理部とを備えているからである。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【発明を実施するための最良の形態】
【００５６】
次に本発明の実施の形態について図面を参照して詳細に説明する。
【００５７】
〔実施の形態の構成の説明〕
本発明にかかるマルチプロセッサシステムの実施の形態は、図１５に示したマルチプロセッサシステムにおいて、入出力制御装置２−１〜２−ｎとして図１に示す構成を有する入出力制御装置を使用することにより実現される。
【００５８】
図１を参照すると、本実施の形態で使用する入出力制御装置２−１〜２−ｎは、入力バッファ２１と、アドレス一致先行ライトリクエスト検出処理部２３と、アドレス一致管理バッファ２４と、有効フラグ保持部２５と、一致判定回路２６と、登録処理部２７と、順序保証バッファ２８と、引き抜きポインタ３１と、ＦＩＦＯポインタ３２と、ポインタセレクタ３３と、発行処理部３４と、リクエストセレクタ３５と、制御部３６とから構成されている。なお、入出力制御装置２−１〜２−ｎは、同一の構成を有しているため、以下では入出力制御装置２−１を例に挙げて構成を説明する。
【００５９】
入力バッファ２１は、複数のエントリ（例えば、１２８エントリ）を有し、各エントリには、入出力デバイス１−１から発行されたリクエスト（リードリクエスト及びライトリクエストを含む）が登録されると共に、そのリクエストに対するアドレス一致情報２２が登録される。アドレス一致情報２２は、図２に示すように、アドレス一致先行ライトリクエストが存在するか否かを示す有無情報と、アドレス一致先行ライトリクエストを特定する先行リクエスト特定情報とを含んでいる。なお、リクエストの登録時、入力バッファ２１の各エントリは循環的に使用される。即ち、最初のリクエストが入力された場合は、入力バッファ２１の第０番目のエントリにリクエストを登録し、次のリクエストが入力された場合は、第１番目のエントリにリクエストを登録するというように、登録対象エントリを順次変更していき、最後のエントリ（第１２７番目のエントリ）にリクエストを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。
【００６０】
アドレス一致管理バッファ２４は、順序保証バッファ２８と同数のエントリ（例えば、６４エントリ）を有し、最新の６４個分のライトリクエスト中のライトアドレスが登録される。アドレス一致管理バッファ２４のエントリ数が順序保証バッファ２８のエントリ数と同数で良い理由は、入力バッファ２１から或るリクエストが出力されたとき、そのリクエストに対するアドレス一致先行ライトリクエストとなる可能性のあるリクエストは、順序保証バッファ２８にその時点で登録されている６４個のリクエストだけであるからである。
【００６１】
有効フラグ保持部２５は、入力バッファ２１のエントリ数（この例では１２８エントリ）と順序保証バッファ２８のエントリ数（この例では６４エントリ）とを加算した数のエントリ（この例では１９２エントリ）を有しており、各エントリには、アドレス一致管理バッファ２４の対応するエントリに格納されているライトアドレスが有効であるか否かを示す有効フラグが登録されている。有効フラグ保持部２５の第ｊ番目、第（ｊ＋６４）番目、第（ｊ＋１２８）番目のエントリが、アドレス一致管理バッファ２４の第ｊ番目のエントリと対応している。
【００６２】
順序保証バッファ２８は、複数のエントリ（例えば６４エントリ）を有し、各エントリには、登録処理部２７によってリクエストが登録されると共に、そのリクエストに対する待ち合わせフラグ２９およびペンディング情報３０が登録される。なお、待ち合わせフラグ２９は、対応するリクエストの発行を待ち合わせることが必要か否かを示すものであり、ペンディング情報は、それと対応付けて登録されているリクエストにアドレス一致先行ライトリクエストが存在するか否かを示す有無情報と、アドレス一致先行ライトリクエストを特定するための先行リクエスト特定情報とを含んでいる。また、順序保証バッファ２８は、引き抜きポインタ３１、ＦＩＦＯポインタ３２の内の、ポインタセレクタ３３によって選択されているポインタが指し示しているエントリに登録されているリクエスト、待ち合わせフラグ２９及びペンディング情報３０を発行処理部３４に対して出力している。
【００６３】
引き抜きポインタ３１及びＦＩＦＯポインタ３２は、順序保証バッファ２８の読み出し対象エントリを指し示すポインタである。ポインタセレクタ３３は、制御部３６の指示に従って引き抜きポインタ３１、ＦＩＦＯポインタ３２の内の一方を選択するセレクタである。リクエストセレクタ３５は、制御部３６の指示に従って登録処理部２７、発行処理部３４の内の一方を選択するセレクタである。
【００６４】
アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１の入力側に接続されている点、およびリードリクエストだけでなく、ライトリクエストについてもアドレス一致先行ライトリクエストが存在するか否かを調べる点が、図１６に示した従来のアドレス一致先行ライトリクエスト検出処理部１０２との大きな相違点である。このアドレス一致先行ライトリクエスト検出処理部２３が備えている主な機能は次の通りである。
【００６５】
・入力バッファ２１に入力されるリクエストがライトリクエストの場合は、一致判定回路２６を利用して上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べると共に、どのライトリクエストがアドレス一致先行ライトリクエストとなるのかを調べる。その後、調べた結果に基づいてアドレス一致情報２２を作成し、上記ライトリクエストが登録された入力バッファ２１のエントリにアドレス一致情報２２を登録する。更に、上記ライトリクエスト中のライトアドレスを最新のライトアドレスとしてアドレス一致管理バッファ２４に登録すると共に、有効フラグ保持部２５の該当するエントリに有効を示す有効フラグを登録する。
【００６６】
なお、アドレス一致管理バッファ２４にライトアドレスを登録する際、アドレス一致先行ライトリクエスト検出処理部２３は、アドレス一致管理バッファ２４の各エントリを循環的に使用する。即ち、最初のライトアドレスはアドレス一致管理バッファ２４の第０番目のエントリに登録し、次のライトアドレスは、第１番目のエントリに登録するというように順次登録対象エントリを更新していき、最後のエントリ（第６３番目のエントリ）にライトアドレスを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。また、有効フラグ保持部２５に有効フラグを登録する場合、アドレス一致先行ライトアドレス検出処理部２４は、有効フラグ保持部２５の各エントリを循環的に使用する。即ち、アドレス一致管理バッファ２４の第０番目のエントリに最初のライトアドレスを登録した場合は、有効フラグ保持部２５の第０番目のエントリに有効を示す有効フラグを登録し、アドレス一致管理バッファ２４に次のライトアドレスを登録した場合は、有効フラグ保持部２５の第１番目のエントリに有効を示す有効フラグを登録するというように、順次登録対象エントリを更新していき、最後のエントリ（第１９１番目のエントリ）に有効を示す有効フラグを登録した場合は、再び、第０番目のエントリを登録対象エントリとする。
【００６７】
・入力バッファ２１に入力されるリクエストが、リードリクエストの場合、一致判定回路２６を利用して上記リードリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べると共に、どのライトリクエストがアドレス一致先行ライトリクエストとなるかを調べる。その後、調べた結果に基づいてアドレス一致情報２２を生成し、上記リードリクエストが登録された入力バッファ２１のエントリにアドレス一致情報２２を登録する。
【００６８】
登録処理部２７は、次のような機能を有する。
【００６９】
・入力バッファ２１の第０番目〜第１２７番目のエントリを順次読み出し対象エントリにし、最後のエントリ（第１２７番目のエントリ）を読み出し対象エントリにしたら、再び第０番目のエントリを読み出し対象エントリにする。読み出し対象エントリに、有効なアドレス一致情報２２が登録されている場合は、読み出し対象エントリからリクエスト及びアドレス一致情報２２を読み出し、アドレス一致情報２２が無効になっている場合は、有効なアドレス一致情報２２が登録されるのを待ってからリクエスト及びアドレス一致情報２２を読み出す。読み出し対象エントリからリクエスト及びアドレス一致情報２２を読み出すと、読み出し対象エントリ中のアドレス一致情報２２を無効にすると共に、入力バッファ２１から読み出したリクエストを順序保証バッファ２８に登録する。リクエストの登録時、登録処理部２７は、順序保証バッファ２８の各エントリを循環的に使用する。
【００７０】
・順序保証バッファ２８に登録したリクエストが、ライトリクエストで、且つそのライトリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが無いことを示している場合は、上記ライトリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグ２９（値が「有効」）を登録すると共に、ペンディング情報３０として「無効」を登録する。更に、上記ライトリクエストに対するディレクトリ検索要求を該当するノードに発行し、その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。このディレクトリ検索要求には、上記ライトリクエスト中のライトアドレスが含まれると共に、上記ライトリクエストを格納した順序保証バッファ２８のエントリを示す情報（エントリ番号）が含まれる。
【００７１】
・順序保証バッファ２８に登録したリクエストが、ライトリクエストで、且つそのライトリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが存在することを示している場合は、上記ライトリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグを登録すると共に、上記アドレス一致情報２２をペンディング情報３０として登録する。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。
【００７２】
・順序保証バッファ２８に登録したリクエストが、リードリクエストで、且つそのリードリクエストに対応するアドレス一致情報２２が、アドレス一致先行ライトリクエストが無いことを示している場合は、上記リードリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが不要なことを示す待ち合わせフラグ２９（値が「無効」）を登録すると共に、ペンディング情報３０として「無効」を登録する。更に、制御部３６に対して、リードリクエスト発行要求を出力し、その後、読み出し対象エントリを次のエントリに更新する。なお、上記リードリクエスト発行要求には、上記リードリクエストを登録したエントリのエントリ番号が含まれている。
【００７３】
・順序保証バッファ２８に登録したリクエストが、リードリクエストで、且つそのリードリクエストに対するアドレス一致情報２２が、アドレス一致先行ライトリクエストが存在することを示している場合は、上記リードリクエストを登録した順序保証バッファ２８のエントリに、待ち合わせが必要なことを示す有効フラグ２９を登録すると共に、上記アドレス一致情報２２をペンディング情報３０として登録する。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新する。
【００７４】
制御部３６は、次のような機能を有する。
【００７５】
・ノード４−ｋ（１≦ｋ≦ｍ）からリクエストの発行許可が返却された場合は、順序保証バッファ２８に登録されているリクエストの内の、発行許可されたリクエストに対応する待ち合わせフラグ２９の値を「無効」に変更し、そのリクエストの発行待ち合わせを解除する。なお、ノード４−ｋからの発行許可には、発行を許可するリクエストが格納されているエントリを示す情報が含まれている。即ち、ノード４−ｋは、入出力制御装置２−１から、ライトアドレス及びエントリ番号を含むディレクトリ検索要求が送られてきたとき、ディレクトリ４２を検索してリクエストの発行を許可するか否かを決定し、リクエストの発行を許可するのであれば、上記エントリ番号を含む発行許可を返却し、許可しないのであれば、上記エントリ番号を含む差戻指示を返却する。
【００７６】
・ノード４−ｋから差戻指示が返却された場合は、引き抜きポインタ３１に上記差戻指示に含まれているエントリ番号を設定すると共に、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態に切り替え、更に、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する。その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。なお、上記ディレクトリ検索要求の発行指示には、上記エントリ番号が含まれている。
【００７７】
・登録処理部２７からリードリクエスト発行要求が入力された場合は、引き抜きポインタ３１に上記リードリクエスト発行要求に含まれているエントリ番号を設定すると共に、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態に切り替え、更に、発行処理部３４に対してリクエストの発行指示を出力する。その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。
【００７８】
・ＦＩＦＯポインタ３２が指し示す順序保証バッファ２８のエントリ（登録時期が最も古い、未発行のリクエストが登録されているエントリ）に登録されている待ち合わせフラグ２９の値が「無効」で、且つ登録されているリクエストがライトリクエストの場合、発行処理部３４に対してリクエストの発行指示を出力し、更に、有効フラグ保持部２５の各エントリに保持されている有効フラグの内の、該当する有効フラグの値を「無効」に変更する。即ち、発行したライトリクエストに対応する有効フラグの値を「無効」にする。
【００７９】
・発行処理部３４に対して発行を指示したライトリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が順序保証バッファ２８に登録されている場合は、引き抜きポインタ３１に上記アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号を設定すると共にポインタセレクタ３３を引き抜きポインタ３１を選択する状態にし、更に、発行処理部３４に対してディレクトリ検索要求の発行指示を出力し、その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。なお、このディレクトリ検索要求の発行指示には、上記アドレス一致後続ライトリクエストが格納されているエントリのエントリ番号が含まれている。
【００８０】
・発行処理部３４に対して発行を指示したライトリクエストをアドレス一致先行ライトリクエストとしているリードリクエスト（アドレス一致後続リードリクエスト）が順序保証バッファ２８に登録されている場合は、引き抜きポインタ３１に上記アドレス一致後続リードリクエストが登録されているエントリのエントリ番号を登録すると共にポインタセレクタ３３を引き抜きポインタ３１を選択する状態にし、更に、発行処理部３４に対してリクエストの発行指示を出力し、その後、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す。
【００８１】
発行処理部３４は、次のような機能を有する。
【００８２】
・制御部３６からディレクトリ検索要求の発行指示が入力された場合は、順序保証バッファ２８から出力されているライトリクエスト中のライトアドレスと上記発行指示中のエントリ番号とを含んだディレクトリ検索要求をリクエストセレクタ３５を介して該当するノードに発行する。
【００８３】
・制御部３６からリクエストの発行指示が入力されている場合は、順序保証バッファ２８から読み出されているリクエスト（リードリクエストの場合もあれば、ライトリクエストの場合もある）をリクエストセレクタ３５を介して該当するノードに発行する。
【００８４】
〔実施の形態の動作の説明〕
次に本実施の形態の動作について詳細に説明する。なお、以下の説明では、入出力デバイス１−１が入出力制御装置２−１に対してリクエストを発行した場合について説明するが、他の入出力デバイス１−２〜１−ｎが入出力制御装置２−２〜２−ｎに対してリクエストを発行した場合も同様の動作が行われる。
【００８５】
入出力デバイス１−１が入出力制御装置２−１に発行したリクエストは、入出力制御装置２−１内の入力バッファ２１及びアドレス一致先行ライトリクエスト検出処理部２３に入力される。
【００８６】
入力バッファ２１は、リクエストが入力されると、自バッファ２１が有している１２８個のエントリの内の、現在登録対象エントリとしているエントリに上記リクエストを登録し、その後、登録対象エントリを次のエントリに変更する。なお、初期状態においては、登録対象エントリは、第０番目のエントリになっている。
【００８７】
一方、アドレス一致先行ライトリクエスト検出処理部２３は、リクエストが入力される毎に、図３のフローチャートに示す処理を行う。
【００８８】
アドレス一致先行ライトリクエスト検出処理部２３は、リクエストが入力されると、先ず、入力されたリクエストがライトリクエストなのか、リードリクエストかを判定する（ステップＳ３１）。
【００８９】
そして、ライトリクエストである場合（ステップＳ３１がＹＥＳ）は、ライトリクエストに含まれているライトアドレスを一致判定回路２６に渡し（ステップＳ３２）、その後、一致判定回路２６からの応答を待つ（ステップＳ３３）。
【００９０】
一致判定回路２６は、ライトアドレスが渡されると、アドレス一致管理バッファ２４に登録されているアドレスの中に、上記ライトアドレスと一致し、且つ有効フラグ保持部２５に保持されている対応する有効フラグが「有効」になっているアドレスが存在するか否かに基づいて、アドレス一致先行ライトリクエストが存在するか否かを判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。なお、アドレス一致先行ライトリクエストが存在すると判定した場合には、判定結果として、どのライトリクエスト（例えば、何個前のライトリクエスト）が、アドレス一致先行ライトリクエストとなるのかもアドレス一致先行ライトリクエスト検出処理部２３に通知する。
【００９１】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６からの通知に従ってアドレス一致情報２２を生成し、入力バッファ２１中の該当するエントリ（今回処理対象にしているライトリクエストが登録されたエントリ）に登録する（ステップＳ３４）。即ち、一致判定回路２６からアドレス一致先行ライトリクエストが存在しないことが通知された場合は、アドレス一致先行ライトリクエストが存在しないことを示す有無情報を含んだアドレス一致情報２２を生成して該当するエントリに登録し、存在することが通知された場合は、アドレス一致先行ライトリクエストが存在することを示す有無情報およびどのライトリクエストがアドレス一致先行ライトリクエストとなるのかを示す先行リクエスト特定情報を含んだアドレス一致情報２２を該当するエントリに登録する（ステップＳ３４）。
【００９２】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、今回処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４のエントリの内の、現在登録対象エントリにしているエントリに登録すると共に、有効フラグ保持部２５の該当するエントリに登録されている有効フラグを「有効」にする（ステップＳ３５、Ｓ３６）。なお、アドレス一致先行ライトリクエスト検出処理部２３は、初期状態においては、アドレス一致管理バッファ２４の第０番目のエントリを登録対象エントリにしており、アドレスを格納する毎に、登録対象エントリを更新する。
【００９３】
これに対して、入力されたリクエストがリードリクエストであると判定した場合（ステップＳ３１がＮＯ）は、上記リードリクエストに含まれているリードアドレスを一致判定回路２６に渡し（ステップＳ３７）、その後、一致判定回路２６からの応答を待つ（ステップＳ３８）。一致判定回路２６は、リードアドレスが渡されると、前述した処理と同様の処理を行い、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これにより、アドレス一致先行ライトリクエスト検出処理部２３は、入力バッファ２１のエントリの内の、今回処理対象にしているリードリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３９）。
【００９４】
次に、アドレス一致先行ライトリクエスト検出処理部２３およびアドレス一致判定回路２６の動作を、具体例を挙げて説明する。
【００９５】
今、有効フラグ保持部２５の第０番目〜第１９１番目のエントリに登録されている有効フラグの値が図４（Ａ）に示すものであるとする。なお、図４では、有効フラグの値「有効」を「１」で表し、「無効」を「０」で表している。
【００９６】
図４（Ａ）に示すように、有効フラグ保持部２５の第０番目〜第７番目のエントリに登録されている有効フラグの値が「有効」になっているときに、ライトリクエスト（初期状態から数えて第８番目のリクエストであるとする。但し、最初のリクエストを第０番目のリクエストとする）が入力されると、アドレス一致先行ライトリクエスト検出処理部２３は、上記ライトリクエスト中のライトアドレスを一致判定回路２６に渡し、待ち状態となる（図３のステップＳ３１がＹＥＳ、Ｓ３２、Ｓ３３）。
【００９７】
一致判定回路２６は、ライトアドレスが渡されると、有効フラグ保持部２５の第０番目〜第７番目のエントリに登録されている有効フラグの値が「有効」となっているので、上記エントリと対応するアドレス一致管理バッファ２４の第０番目〜第７番目のエントリを比較対象エントリにして、上記ライトアドレスと一致するアドレスが登録されているか否かを調べることにより、アドレス一致先行ライトリクエストが存在するか否かを判定する。
【００９８】
なお、前述したように、アドレス一致管理バッファ２４の第ｊ番目のエントリに対応する有効フラグ保持部２５上のエントリは、第ｊ番目、第（ｊ＋６４）番目、第（ｊ＋１２８）番目の計３個のエントリであり、一致判定回路２６は、アドレス一致管理バッファ２４の第ｊ番目のエントリに対応する有効フラグ保持部２５上の３個のエントリの何れかに「有効」を示す有効フラグが登録されていれば、上記第ｊ番目のエントリを比較対象エントリとする。また、一致判定回路２６は、ライトアドレスと一致するアドレスが比較対象エントリ（第０番目〜第７番目のエントリ）に登録されているか否かを調べる際、アドレスの登録時期が最も新しいエントリ（第７番目のエントリ）から最も古いエントリ（第０番目のエントリ）に向かって比較処理を行う。そして、アドレスの登録時期が最も古いエントリまで調べてもライトアドレスと一致するアドレスが格納されているエントリが存在しなかった場合は、アドレス一致先行ライトリクエスト無しと判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これに対して、ライトアドレスと一致するアドレスが登録されているエントリを見つけた場合は、アドレス一致先行ライトリクエスト有りと判定し、アドレス一致先行ライトリクエスト検出処理部２３に判定結果を通知する。このときの判定結果には、何個前のライトリクエストがアドレス一致先行ライトリクエストとなるのかを示す情報も含まれる。なお、アドレス一致先行ライトリクエストとなるライトリクエストが何個前のライトリクエストであるかは、例えば、ライトアドレスと一致するアドレスが登録されているエントリが、比較対象エントリの内の、アドレスの登録時期が新しい方から何番目のエントリであるかを調べることにより求めることができる。
【００９９】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６から判定結果が通知されると、それに基づいてアドレス一致情報２２を生成し、入力バッファ２１の各エントリの内の、現在処理対象としているライトリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３４）。この例の場合、現在処理対象にしているライトリクエストは、初期状態から数えて第８番目のリクエストであり、上記ライトリクエストは、入力バッファ２１の第８番目のエントリに格納されているので、第８番目のエントリにアドレス一致情報２２を登録することになる。
【０１００】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、現在処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４の第８番目のエントリに登録し（ステップＳ３５）、更に、値「有効」が設定されている有効バッファ保持部２５上のエントリの内の、エントリ番号が最も大きいエントリ（第７番目のエントリ）の次のエントリ（第８番目のエントリ）に、値「有効」を登録する（ステップＳ３６）。
【０１０１】
また、図４（Ｂ）に示すように、有効フラグ保持部２５の第３番目〜第１３５番目のエントリに登録されている有効フラグが値が「有効」になっているときにライトリクエスト（初期状態から数えて第１３６番目のリクエストとする）が入力された場合は、アドレス一致先行ライトリクエスト検出処理部２３は、上記ライトリクエスト中のライトアドレスを一致判定回路２６に渡し、待ち状態となる（ステップＳ３１がＹＥＳ、Ｓ３２、Ｓ３３）。
【０１０２】
一致判定回路２６は、ライトアドレスが渡されると、有効フラグ保持部２５の第３番目〜第１３５番目のエントリに登録されている有効フラグの値が「有効」となっているので、上記エントリと対応するアドレス一致管理バッファ２４の第０番目〜第６３番目のエントリを比較対象エントリにして、上記ライトアドレスと一致するアドレスが登録されているか否かを調べることにより、アドレス一致先行ライトリクエストが存在するか否かを判定する。その際、アドレスの登録時期が最も新しいエントリ（第７番目のエントリ）から順番に、比較処理を行うエントリのエントリ番号を順次減少させて比較処理を行う（但し、比較処理を行うエントリのエントリ番号が「０」となった場合は、次に比較処理を行うエントリのエントリ番号を「６３」とする）。そして、アドレスの登録時期が最も古いエントリ（第８番目のエントリ）まで調べてもライトアドレスと一致するアドレスが格納されているエントリが存在しなかった場合は、アドレス一致先行ライトリクエスト無しと判定し、判定結果をアドレス一致先行ライトリクエスト検出処理部２３に通知する。これに対して、ライトアドレスと一致するアドレスが登録されているエントリを見つけた場合は、アドレス一致先行ライトリクエスト有りと判定し、アドレス一致先行ライトリクエスト検出処理部２３に判定結果を通知する。
【０１０３】
アドレス一致先行ライトリクエスト検出処理部２３は、一致判定回路２６から判定結果が通知されると、それに基づいてアドレス一致情報２２を生成し、入力バッファ２１の各エントリの内の、現在処理対象としているライトリクエストが登録されているエントリにアドレス一致情報２２を登録する（ステップＳ３４）。この例の場合、現在処理対象にしているライトリクエストは、初期状態から数えて第１３６番目のリクエストであり、上記ライトリクエストは、入力バッファ２１の第８番目（１３６÷６４＝２余り８）のエントリに格納されているので、第８番目のエントリにアドレス一致情報２２を登録することになる。
【０１０４】
その後、アドレス一致先行ライトリクエスト検出処理部２３は、現在処理対象にしているライトリクエスト中のライトアドレスを、アドレス一致管理バッファ２４の第８番目のエントリに登録し（ステップＳ３５）、更に、値「有効」が設定されている有効バッファ保持部２５上のエントリの内の、エントリ番号が最も大きいエントリ（第１３５番目のエントリ）の次のエントリ（第１３６番目のエントリ）に、値「有効」を登録する（ステップＳ３６）。
【０１０５】
次に、登録処理部２７の動作について説明する。
【０１０６】
登録処理部２７は、図５のフローチャートに示すように、入力バッファ２１の第０番目〜第１２７番目のエントリの内の、読み出し対象エントリに注目し、そのエントリに有効なアドレス一致情報２２が登録されるのを待つ（ステップＳ５０１、Ｓ５０２）。なお、初期状態においては、第０番目のエントリを読み出し対象エントリにしている。
【０１０７】
そして、読み出し対象エントリに有効なアドレス一致情報が登録されると（ステップＳ５０２がＹＥＳ）、読み出し対象エントリに登録されているリクエスト及びアドレス一致情報２２を入力し、入力したリクエストを順序保証バッファ２８の登録対象エントリに登録し、更に、登録対象エントリを次のエントリに更新する（ステップＳ５０３）。なお、初期状態においては、登録対象エントリは、第０番目のエントリになっている。
【０１０８】
その後、登録処理部２７は、入力バッファ２１から入力したリクエストがライトリクエストなのか、リードリクエストなのかを調べる（ステップＳ５０４）。
【０１０９】
ライトリクエストであった場合（ステップＳ５０４がＹＥＳ）は、ステップＳ５０３で入力したアドレス一致情報２２中の有無情報に基づいて、アドレス一致先行ライトリクエストが存在するか否かを判断する（ステップＳ５０５）。
【０１１０】
そして、アドレス一致先行ライトリクエストが存在しない場合（ステップＳ５０５がＮＯ）は、ステップＳ５０３においてこのライトリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記リクエストが発行待ち合わせ状態となるようにすると共に、ペンディング情報３０を「無効」にして上記ライトリクエストに関するディレクトリ検索要求の発行を許可する（ステップＳ５０６）。その後、発行処理部２７は、制御部３６に対してディレクトリ検索要求の発行許可要求を送り、制御部３６から発行許可を受けたら、上記ライトリクエストに関するディレクトリ検索要求を発行する（ステップＳ５０７）。ディレクトリ検索要求には、上記ライトリクエスト中のライトアドレス及び上記ライトリクエストを登録した順序保証バッファ２８のエントリ番号が含まれており、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードへ送られる。また、登録処理部２７からのディレクトリ検索要求の発行許可要求を受け付けた制御部３６は、リクエストセレクタ３５を登録処理部２７を選択する状態に切り替えた後、登録処理部２７に対して発行許可を与え、更に所定時間後、リクエストセレクタ３５を発行処理部３４を選択する状態に戻す。その後、登録処理部２７は、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再び、ステップＳ５０１の処理を行う。
【０１１１】
これに対して、アドレス一致先行ライトリクエストが存在する場合（ステップＳ５０５がＹＥＳ）は、ステップＳ５０３においてこのライトリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記ライトリクエストが発行待ち合わせ状態になるようにすると共に、ペンディング情報３０としてステップＳ５０３で入力したアドレス一致情報２２を登録し、上記ライトリクエストに関するディレクトリ検索要求が発行待ち合わせ状態になるようにする（ステップＳ５０９）。その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再びステップＳ５０１の処理を行う。
【０１１２】
一方、ステップＳ５０３で入力したリクエストがリードリクエストであると判断した場合（ステップＳ５０４がＮＯ）は、ステップＳ５０３で入力したアドレス一致情報２２中の有無情報に基づいて、アドレス一致先行ライトリクエストが存在するか否かを判断する（ステップＳ５１０）。
【０１１３】
そして、アドレス一致先行ライトリクエストが存在しない場合（ステップＳ５１０がＮＯ）は、ステップＳ５０３においてこのリードリクエストを格納した、順序保証バッファ２８のエントリ中の待ち合わせフラグを「無効」にして上記リードリクエストを発行可能状態にすると共に、ペンディング情報３０を「無効」にする（ステップＳ５１１）。次いで、登録処理部２７は、制御部３６に対して上記リードリクエストの発行を要求するリードリクエスト発行要求を出力し（ステップＳ５１２）、その後、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再び、ステップＳ５０１の処理を行う。なお、リードリクエスト発行要求には、リードリクエストを登録した順序保証バッファ２８のエントリ番号が含まれている。また、制御部３６がリードリクエスト発行要求を受け付けたときの動作は、図６のフローチャートを用いて後で詳しく説明する。
【０１１４】
これに対してアドレス一致先行ライトリクエストが存在する場合（ステップＳ５１０がＹＥＳ）は、ステップＳ５０３においてこのリードリクエストを登録した、順序保証バッファ２８のエントリ中の待ち合わせフラグ２９を「有効」にして上記リードリクエストを発行待ち合わせ状態にすると共に、ステップＳ５０３で入力したアドレス一致情報２２をペンディング情報３０として登録する（ステップＳ５１３）。その後、登録処理部２７は、入力バッファ２１の読み出し対象エントリを次のエントリに更新し（ステップＳ５０８）、再びステップＳ５０１の処理を行う。
【０１１５】
次に、制御部３６の動作について説明する。
【０１１６】
先ず、登録処理部２７からのリードリクエスト発行要求を受け付けたときの動作を、図６のフローチャートを参照して説明する。
【０１１７】
制御部３６は、登録処理部２７からのリードリクエスト発行要求を受け付けると、先ず、上記要求に含まれているエントリ番号を引き抜きポインタに設定する（ステップＳ６１）。上記エントリ番号は、発行対象にしているリードリクエストが格納されている、順序保証バッファ２８上のエントリを示している。次いで、制御部３６は、ポインタセレクタ３３の状態を、引き抜きポインタ３１を選択する状態に変更する（ステップＳ６２）。これにより、順序保証バッファ２８は、引き抜きポインタ３１が指し示すエントリに登録されているリクエスト（発行対象にしているリードリクエスト）を、発行処理部３４に対して出力する。その後、制御部３６は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ６３）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているリードリクエストを、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。その後、制御部３６は、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ６４）。
【０１１８】
次に、ノード（例えば、ノード４−１）からライトリクエストの発行許可が返却された場合の動作を、図７のフローチャートを参照して説明する。
【０１１９】
制御部３６は、ノード４−１からライトリクエストの発行許可（発行を許可するライトリクエストが登録されているエントリのエントリ番号が含まれている）が送られてくると、順序保証バッファ２８上のエントリの内の、上記発行許可に含まれているエントリ番号のエントリに登録されている待ち合わせフラグ２９の値を「有効」から「無効」に変更し、上記ライトリクエストを発行可能状態にする（ステップＳ７１）。
【０１２０】
次に、ノード（例えば、ノード４−１）から差戻指示が返却された場合の動作を、図８のフローチャートを参照して説明する。
【０１２１】
制御部３６は、ノード４−１から差戻指示（差し戻すライトリクエストが登録されているエントリのエントリ番号を含む）が送られてくると、先ず、引き抜きポインタ３１に、上記差戻指示に含まれているエントリ番号を設定し、その後、ポインタセレクタ３３の状態を引き抜きポインタ３１を選択する状態にする（ステップＳ８１、Ｓ８２）。これにより、順序保証バッファ２８は、引き抜きポインタ３１が指し示すエントリの登録されているライトリクエストを発行処理部３４に対して出力する。その後、制御部３６は、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する（ステップＳ８３）。この発行指示には、差し戻すライトリクエストが登録されているエントリのエントリ番号が含まれている。発行処理部３４は、ディレクトリ検索要求の発行指示が入力されると、順序保証バッファ２８から出力されているライトリクエスト中のライトアドレス及び上記発行指示中のエントリ番号を含んだディレクトリ検索要求を生成し、生成したディレクトリ検索要求を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノード４−１に発行する。その後、制御部３６は、ポインタセレクタ３３の状態を、ＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ８４）。
【０１２２】
次に制御部３６が順序保証バッファ２８に登録されているライトリクエストを登録順に発行するために行っている動作を図９のフローチャートを参照して説明する。
【０１２３】
制御部３６は、ＦＩＦＯポインタ３２が指し示している順序保証バッファ２８のエントリに登録されている待ち合わせフラグ２９が「無効」になるのを待ち合わせており（ステップＳ９０１、Ｓ９０２）、該当する待ち合わせフラグ２９が「無効」となると（ステップＳ９０２がＮＯ）、上記エントリに登録されているリクエストの種別を調べる（ステップＳ９０３）。
【０１２４】
そして、リードリクエストであった場合（ステップＳ９０３がＹＥＳ）は、ＦＩＦＯポインタ３２を更新し、次のエントリを指し示すようにした後（ステップＳ９１８）、再び、ステップＳ９０１の処理を行う。
【０１２５】
これに対して、ライトリクエストであった場合（ステップＳ９０３がＮＯ）は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ９０４）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているライトリクエスト（ＦＩＦＯポインタ３２が指し示すエントリに登録されているリクエスト）を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。
【０１２６】
その後、制御部３６は、有効フラグ保持部２５の各エントリに保持されている有効フラグの内の、今回発行したライトリクエストに対応する有効フラグを「無効」とする（ステップＳ９０５）。
【０１２７】
次に、制御部３６は、今回発行したライトリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が、順序保証バッファ２８に登録されているか否かを調べる（ステップＳ９０６）。この処理は、ペンディング情報３０中の先行リクエスト特定情報を利用して行う。
【０１２８】
そして、アドレス一致後続ライトリクエストが登録されている場合（ステップＳ９０６がＹＥＳ）は、先ず、上記アドレス一致後続ライトリクエストに対応するペンディング情報３０を「無効」にする（ステップＳ９０７）。次いで、引き抜きポインタ３１に、上記アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号を設定し（ステップＳ９０８）、更に、ポインタセレクタ３３を引き抜きポインタ３１を選択する状態にする（ステップＳ９０９）。これにより、順序保証バッファ２８からは、上記アドレス一致後続ライトリクエストが出力される。
【０１２９】
その後、制御部３６は、発行処理部３４に対してディレクトリ検索要求の発行指示を出力する（ステップＳ９１０）。この発行指示には、アドレス一致後続ライトリクエストが登録されているエントリのエントリ番号が含まれている。発行処理部３４は、上記指示を受け付けると、順序保証バッファ２８から出力されているアドレス一致後続ライトリクエスト中のライトアドレスと、上記発行指示中のエントリ番号とを含んだディレクトリ検索要求を、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。その後、制御部３６は、ポインタセレクタ３３をＦＩＦＯポインタ３２を選択する状態に戻す（ステップＳ９１１）。
【０１３０】
これに対して、アドレス一致後続ライトリクエストが登録されていなかった場合（ステップＳ９０６がＮＯ）及びステップＳ９１１の処理が終了した場合、制御部３６は、今回発行したライトリクエストをアドレス一致先行ライトリクエストとしているリードリクエスト（アドレス一致後続リードリクエスト）が、順序保証バッファ２８に登録されているか否かを調べる（ステップＳ９１２）。
【０１３１】
そして、登録されていない場合（ステップＳ９１２がＮＯ）は、ＦＩＦＯポインタ３２が指し示すエントリを次のエントリに更新した後（ステップＳ９１８）、再び、ステップＳ９０１の処理を行う。
【０１３２】
これに対して、アドレス一致後続リードリクエストが登録されている場合（ステップＳ９１２がＹＥＳ）は、先ず、上記アドレス一致後続リードリクエストに対応する待ち合わせフラグ２９、ペンディング情報３０を「無効」にする（ステップＳ９１３）。次いで、引き抜きポインタ３１に上記アドレス一致後続リードリクエストが登録されているエントリのエントリ番号を設定し（ステップＳ９１４）、更に、ポインタセレクタ３３を引き抜きポインタ３１を選択する状態に切り替える（ステップＳ９１５）。これにより、順序保証バッファ２８からは、上記アドレス一致後続リードリクエストが出力される。
【０１３３】
その後、制御部３６は、発行処理部３４に対してリクエストの発行を指示する（ステップＳ９１６）。これにより、発行処理部３４は、順序保証バッファ２８から出力されているアドレス一致後続リードリクエストを、リクエストセレクタ３５及びクロスバーネットワーク３を介して該当するノードに発行する。
【０１３４】
次いで、制御部３６は、ポインタセレクタ３３を、ＦＩＦＯポインタ３２を選択する状態に戻し（ステップＳ９１７）、その後、ステップＳ９１２の処理を行う。ステップＳ９１２がＮＯとなると、ＦＩＦＯポインタ３２が保持しているエントリ番号をインクリメントし、次のエントリを指し示すようにする（ステップＳ９１８）。その後、制御部３６は、再び、ステップＳ９０１の処理を行う。
【０１３５】
次に、タイミングチャートを用いて本実施の形態および従来技術の動作を説明する。
【０１３６】
図１０は、本実施の形態の動作を示すタイミングチャートであり、本実施の形態の入出力制御装置２−１（図１参照）が、ライトアドレスの異なる３個のライトリクエストＡ、Ｂ、Ｃを受け付けたときの動作を示している。
【０１３７】
各ライトリクエストＡ、Ｂ、Ｃは、それぞれサイクル１、２、３において入力バッファ２１のエントリａ、ｂ、ｃに登録される。また、各ライトリクエストＡ、Ｂ、Ｃのライトアドレスは、アドレス一致先行ライトリクエスト検出処理部２３においてアドレス一致先行ライトリクエストの有無が調べられた後、それぞれサイクル２、３、４においてアドレス一致管理バッファ２４のエントリα、β、γに登録される。
【０１３８】
その後、サイクル３、４、５において、入力バッファ２１からライトリクエストＡ、Ｂ、Ｃが順次読み出され、順序保証バッファ２８のエントリ０、１、２に登録される。ライトリクエストＡ、Ｂ、Ｃは、ライトアドレスが異なるため、アドレス一致先行ライトリクエストは存在しない。従って、各ライトリクエストＡ、Ｂ、Ｃが順序保証バッファ２８に登録されると同時に、サイクル３、４、５において、ライトリクエストＡ、Ｂ、Ｃについてのディレクトリ検索要求Ａ、Ｂ、Ｃがクロスバーネットワーク３を介して該当するノードに発行される。
【０１３９】
ノードにおいて、ディレクトリの検索が行われ、サイクル７においてライトリクエストＡに対する発行許可Ａが送られてくると、ＦＩＦＯポインタ３２が指し示しているエントリ０に登録されているライトリクエストがサイクル８においてリクエストセレクタ３５、クロスバーネットワーク３を介して該当するネットワークに発行される。この後、ＦＩＦＯポインタ３２は、エントリ１を指し示す。
【０１４０】
サイクル９において、ライトリクエストＣに対する発行許可Ｃが送られてくると、ライトリクエストＣは、発行可能な状態になるが、このとき、ＦＩＦＯポインタ３２は、エントリ１を指し示しているので、エントリ２に登録されているライトリクエストＣは、発行されない。
【０１４１】
その後、サイクル１１において、ライトリクエストＢに対する発行許可Ｂが送られてくると、ライトリクエストＢが発行可能な状態となり、サイクル１２において、該当するノードに発行され、その後、ＦＩＦＯポインタ３２が、エントリ２を指し示す。これにより、サイクル１３において、ライトリクエストＣが該当するノードに発行される。
【０１４２】
図１１及び図１２は、それぞれ従来技術及び本実施の形態の動作を示すタイミングチャートであり、ライトアドレスが同一のライトリクエストＡ、Ａ'、Ａ"を、従来技術及び本実施の形態の入出力制御装置２−１（図１６及び図１参照）が受け付けた場合の動作を示している。
【０１４３】
従来技術の動作を示す図１１を参照すると、各ライトリクエストＡ、Ａ'、Ａ"は、それぞれサイクル１、２、３において、入力バッファ１０１のエントリａ、ｂ、ｃに登録される。また、各ライトリクエストＡ、Ａ'、Ａ"のライトアドレスは、それぞれサイクル２、３、４において、アドレス一致管理バッファ２３のエントリα、β、γに登録される。また、従来技術では、ライトリクエストアドレスの一致判定処理を行わないので、サイクル３、４、５において、ライトリクエストＡ、Ａ'、Ａ"が順序保証バッファ１０６のエントリ０、１、２に登録されると同時に、ライトリクエストＡ、Ａ'、Ａ"についてのディレクトリ検索要求Ａ、Ａ'、Ａ"が該当するノードに発行される。
【０１４４】
ノードは、ディレクトリ検索要求Ａ、Ａ'、Ａ"が競合するので、サイクル７、８、９において、ライトリクエストＡの発行許可Ａ、ライトリクエストＡ'、Ａ"の差戻指示Ａ'、Ａ"を返却する。これにより、サイクル８においてライトリクエストＡが該当するノードに発行され、サイクル９、１０において、ライトリクエストＡ'、Ａ"についてのディレクトリ検索要求Ａ'、Ａ"が該当するノードへ発行される。
【０１４５】
ノードは、ディレクトリ検索要求Ａ'、Ａ"が競合するので、サイクル１１、１２において、ライトリクエストＡ'の発行許可Ａ'、ライトリクエストＡ"の差戻指示を返却する。これにより、サイクル１２においてライトリクエストＡ'が該当するノードに発行され、サイクル１３においてライトリクエストＡ"に関するディレクトリ検索要求Ａ"が該当するノードに発行される。
【０１４６】
ノードは、ディレクトリ検索要求Ａ"はアドレス競合しないので、ライトリクエストＡ"に対する発行許可Ａ"を返却する。サイクル１５において、発行許可Ａ"を受信すると、サイクル１６において、ライトリクエストＡ"を該当するノードに対して発行する。
【０１４７】
上記した動作が行われている間にクロスバーネットワーク３上を通過したリクエスト数は１５個となり、要したサイクル数は１６サイクルとなる。
【０１４８】
一方、本実施の形態の動作を示す図１２を参照すると、各ライトリクエストＡ、Ａ'、Ａ"は、それぞれサイクル１、２、３において、入力バッファ２１のエントリａ、ｂ、ｃに登録され、サイクル２、３、４において、アドレス一致管理バッファ２４のエントリα、β、γに登録され、サイクル３、４、５において、順序保証バッファ２８のエントリ０、１、２に登録される。本実施の形態では、ライトアドレスについてもアドレス一致先行ライトリクエストが存在するか否かを判定し、存在しない場合のみ、ディレクトリ検索要求を発行するようにしているので、ライトリクエストＡに関するディレクトリ検索要求Ａは、サイクル３において発行されるが、ライトリクエストＡ'、Ａ"に関するディレクトリ検索要求Ａ'、Ａ"は、アドレス一致先行ライトリクエストＡが存在するため、発行待ち状態となる。
【０１４９】
ノードでは、ディレクトリ検索要求Ａは、アドレス競合がないので、サイクル７において、ライトリクエストＡに対する発行許可Ａを返却する。これより、サイクル８において、ライトリクエストＡが該当するノードに発行される。
【０１５０】
ライトリクエストＡが発行されると、ライトリクエストＡ'に対するアドレス一致先行ライトリクエストが存在しなくなるので、サイクル９において、ライトリクエストＡ'に対するディレクトリ検索要求Ａ'が発行される。ライトリクエストＡ"には、アドレス一致先行ライトリクエストＡ'が存在するので、ディレクトリ検索要求Ａ"の発行は待ち合わされる。
【０１５１】
ノードでは、ディレクトリ検索要求Ａ'には、アドレス競合がないので、サイクル１１において、ライトリクエストＡ'に対する発行許可Ａ'を返却する。これにより、サイクル１２において、ライトリクエストＡ'が該当するノードに発行される。
【０１５２】
ライトリクエストＡ'が発行されると、ライトリクエストＡ"に対するアドレス一致先行ライトリクエストが存在しなくなるので、サイクル１３において、ライトリクエストＡ"に対するディレクトリ検索要求Ａ"が該当するノードに発行される。
【０１５３】
ノードでは、ディレクトリ検索要求Ａ"には、アドレス競合がないので、サイクル１５において、ライトリクエストＡ"に対する発行許可Ａ"を返却する。これにより、サイクル１６において、ライトリクエストＡ"が発行される。
【０１５４】
上記した動作が行われている間にクロスバーネットワーク３上を通過したリクエスト数は９個となり、要したサイクル数は１６サイクルとなる。本実施の形態では、リクエスト数が９個で済むため、リクエスト数が１５個であった従来技術に比較してトラフィックを低減させることができる。
【０１５５】
図１３及び図１４は、それぞれ従来技術及び本実施の形態の動作を示すタイミングチャートであり、ライトリクエストＡ、Ｂ及びリードリクエストＡ、Ｃを、従来技術及び本実施の形態の入出力制御装置２−１（図１６及び図１参照）が受け付けた場合の動作を示している。なお、ライトリクエストＡのライトアドレスと、リードリクエストＡのリードアドレスは同一であるとする。
【０１５６】
従来技術の動作を示す図１３を参照すると、従来技術では、リードリクエストを入力バッファ１０１から読み出した後、アドレス一致判定を行うため、リードリクエストＡのアドレス一致判定の影響でリードリクエストＣのクロスバーネットワーク３への発行が遅れている。また、順序保証バッファ１０６に登録されたリードリクエストＡは、アドレス一致先行ライトリクエストＡが存在するので、ライトリクエストＡの発行を待ち合わせるが、ライトリクエストＡとリードリクエストＡとの間に異なるアドレスのライトリクエストＢがあるため、ライトリクエストＡの発行だけでなく、ライトリクエストＢの発行も待ち合わせなければならない。
【０１５７】
ライトリクエストＡ、Ｂが、サイクル３、４において順序保証バッファ１０６に登録されると同時に、ディレクトリ検索要求Ａ、Ｂがクロスバーネットワーク３を介して該当するノードへ発行される。
【０１５８】
ノードは、ディレクトリ検索要求Ａにはアドレス競合がないので、サイクル７において、ライトリクエストＡの発行許可を返却する。これにより、サイクル８において、順序保証バッファ１０６からライトリクエストＡが発行される。その後、サイクル１１においてノードからライトリクエストＢに対する発行許可が返却されると、サイクル１２において、順序保証バッファ１０６からライトリクエストＢが発行される。その後、サイクル１３において、漸くリードリクエストＡが発行されることになる。この動作の要するサイクル数は１３サイクルである。
【０１５９】
一方、本実施の形態の動作を示す図１４を参照すると、リードリクエストを入力バッファ２１へ登録する時に、アドレス一致判定を行うためアドレス一致判定をパイプライン化でき、リードリクエストＣはリードリクエストＡのアドレス一致判定の影響を受けない。順序保証バッファ２８に登録されたリードリクエストＡは、アドレス一致先行リードリクエストが存在するので、ライトリクエストＡの発行を待ち合わせるが、ライトリクエストＡとリードリクエストＡとの間に異なるアドレスのライトリクエストＢがあっても、引き抜きポインタ３１を利用した引き抜き制御の対象となるので、ライトリクエストＢの発行まで待ち合わせる必要はない。
【０１６０】
ライトリクエストＡ、Ｂが、サイクル３、４において順序保証バッファに登録されると同時に、ディレクトリ検索要求Ａ、Ｂがクロスバーネットワーク３を介して該当するノードへ発行される。
【０１６１】
ノードは、ディレクトリ検索要求Ａには、アドレス競合がないので、サイクル７において、ライトリクエストＡの発行許可を返却する。これにより、サイクル８において順序保証バッファ２８からライトリクエストＡが該当するノードへ発行される。
【０１６２】
リードリクエストＡは、アドレス一致先行ライトリクエストであるライトリクエストＡが、サイクル８において、順序保証バッファ２８から発行されると、ペンディングが解除され、引き抜きポインタ３１を利用した引き抜き制御により、サイクル９において、クロスバーネットワーク３を介して該当するノードに発行される。その後、サイクル１１において、ノードからライトリクエストＢに対する発行許可が返却されると、サイクル１２において、順序保証バッファ２８からライトリクエストＢが発行される。この動作に要するサイクル数は１２サイクルであり、１３サイクル必要であった従来の技術に比較して性能が向上している。
【０１６３】
〔実施の形態の効果〕
本実施の形態によれば、アドレス一致先行ライトリクエストが存在するか否かを判定するための判定処理によって、後続のリクエストの処理が待たされることがないという効果を得ることができる。その理由は、入力バッファ２１の入力側において、入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、入力バッファ２１に登録された上記リクエストに対応付けて、アドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報２２を登録するアドレス一致先行ライトリクエスト検出処理部２３と、アドレス一致情報が登録されるまで、入力バッファ２１に登録されているリクエストの出力（順序保証バッファ２８への登録）を待ち合わせる登録処理部２７とを備えているからである。即ち、アドレス一致先行ライトリクエストが存在するか否かの判定処理がパイプライン化されるため、後続のリクエストの処理が待たされることがなくなる。
【０１６４】
また、本実施の形態によれば、トラフィックの増加を防止することができるという効果を得ることができる。その理由は、入力バッファ２１に登録されている最古のライトリクエストがライトリクエストであっても、上記ライトリクエストに対するアドレス一致先行ライトリクエストが存在する場合には、上記リクエストの発行許可要求（ディレクトリ検索要求）は発行せず、アドレス一致先行ライトリクエストが存在しない場合のみ、発行許可要求を発行する登録処理部２７と、順序保証バッファ２８に登録されている最古のリクエストを該当するノードに対して発行した際、上記最古のリクエストをアドレス一致先行ライトリクエストとしているライトリクエスト（アドレス一致後続ライトリクエスト）が存在する場合は、このアドレス一致後続ライトリクエストの発行許可要求（ディレクトリ検索要求）を該当するノードに発行する制御部３６とを備えているからである。
【０１６５】
更に、本実施の形態によれば、アドレス一致先行ライトリクエストとアドレス一致後続リードリクエストとの間に、他のライトリクエストが存在する場合であっても、上記アドレス一致後続リードリクエストの発行が待たされることがなくなるという効果を得ることができる。その理由は、順序保証バッファ２８に登録されている最古のリクエストを該当するノードに発行した際、順序保証バッファ２８に上記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、そのアドレス一致後続リードリクエストを該当するノードに発行する制御部３６を備えているからである。
【０１６６】
更に、本実施の形態によれば、入力バッファ２１において、アドレス一致先行ライトリクエストが存在しないリードリクエストによって、後続のリクエストが待たされることがなくなるという効果を得ることができる。その理由は、入力バッファ２１に登録されている最古のリクエストがリードリクエストで、且つ上記リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、上記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを順序保証バッファ２８に登録する登録処理部２７と、登録処理部２７によって順序保証バッファ２８に、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、そのリードリクエストを該当するノードへ発行する制御部３６とを備えているからである。
【産業上の利用可能性】
【０１６７】
本発明は、複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備えたマルチプロセッサシステム等に利用することができる。
【図面の簡単な説明】
【０１６８】
【図１】本発明にかかる入出力制御装置２−１の実施の形態の構成例を示すブロック図である。
【図２】アドレス一致情報の一例を示す図である。
【図３】アドレス一致先行ライトリクエスト検出処理部２３の処理例を示すフローチャートである。
【図４】アドレス一致先行ライトリクエスト検出処理部２３及び一致判定回路２６の動作を説明するための図である。
【図５】登録処理部２７の処理例を示すフローチャートである。
【図６】リードリクエスト発行要求を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図７】ライトリクエストの発行許可を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図８】差戻指示を受け付けたときの制御部３６の処理例を示すフローチャートである。
【図９】リクエストを登録順に発行するときの制御部３６の処理例を示すフローチャートである。
【図１０】実施の形態の動作を示すためのタイミングチャートである。
【図１１】従来技術の動作を説明するためのタイミングチャートである。
【図１２】実施の形態の動作を示すためのタイミングチャートである。
【図１３】従来技術の動作を説明するためのタイミングチャートである。
【図１４】実施の形態の動作を示すためのタイミングチャートである。
【図１５】本発明を適用するマルチプロセッサシステムの構成例を示すブロック図である。
【図１６】従来の入出力制御装置２−１の構成例を示すブロック図である。
【図１７】アドレス一致先行ライトリクエスト検出処理部１０２の処理例を示すフローチャートである。
【図１８】ライトリクエストの発行許可を受け付けたときの制御部１１３の処理例を示すフローチャートである。
【図１９】差戻指示を受け付けたときの制御部１１３の処理例を示すフローチャートである。
【図２０】リクエストを登録順に発行するときの制御部１１３の処理例を示すフローチャートである。
【符号の説明】
【０１６９】
１−１〜１−ｎ…入出力デバイス
２−１〜２−ｎ…入出力制御装置
２１、１０１…入力バッファ
２２…アドレス一致情報
２３、１０２…アドレス一致先行ライトリクエスト検出処理部
２４、１０３…アドレス一致管理バッファ
１０４…有効フラグ
２５…有効フラグ保持部
２６、１０５…一致判定回路
２７…登録処理部
２８、１０６…順序保証バッファ
２９、１０７…待ち合わせフラグ
３０…ペンディング情報
３１、１０８…引き抜きポインタ
３２、１０９…ＦＩＦＯポインタ
３３、１１０…ポインタセレクタ
３４、１１１…発行処理部
３５、１１２…リクエストセレクタ
３６、１１３…制御部
３…クロスバーネットワーク
４−１〜４−ｍ…ノード
４１…メモリ制御部
４２…ディレクトリ
４３…共有メモリ
４４、４５…プロセッサ
【特許請求の範囲】
【請求項１】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムであって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とするマルチプロセッサシステム。
【請求項２】
請求項１記載のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とするマルチプロセッサシステム。
【請求項３】
請求項２記載のマルチプロセッサシステムにおいて、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とするマルチプロセッサシステム。
【請求項４】
請求項３記載のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とするマルチプロセッサシステム。
【請求項５】
請求項１乃至４の何れか１項に記載したマルチプロセッサシステムにおいて、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とするマルチプロセッサシステム。
【請求項６】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードとクロスバーネットワークを介して接続され、且つ、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを備えた入出力制御装置であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする入出力制御装置。
【請求項７】
請求項６記載の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする入出力制御装置。
【請求項８】
請求項７記載の入出力制御装置において、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする入出力制御装置。
【請求項９】
請求項８記載の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする入出力制御装置。
【請求項１０】
請求項６乃至９の何れか１項に記載した入出力制御装置において、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする入出力制御装置。
【請求項１１】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムにおけるリクエスト発行方法であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファに対して外部からリクエストが入力されたとき、アドレス一致先行ライトリクエスト検出処理部が、前記リクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録し、
登録処理部が、前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録することを特徴とするリクエスト発行方法。
【請求項１２】
請求項１１記載のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行し、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更することを特徴とするリクエスト発行方法。
【請求項１３】
請求項１２記載のリクエスト発行方法において、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行することを特徴とするリクエスト発行方法。
【請求項１４】
請求項１３記載のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録し、
前記制御部が、前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行することを特徴とするリクエスト発行方法。
【請求項１】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムであって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とするマルチプロセッサシステム。
【請求項２】
請求項１記載のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とするマルチプロセッサシステム。
【請求項３】
請求項２記載のマルチプロセッサシステムにおいて、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とするマルチプロセッサシステム。
【請求項４】
請求項３記載のマルチプロセッサシステムにおいて、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とするマルチプロセッサシステム。
【請求項５】
請求項１乃至４の何れか１項に記載したマルチプロセッサシステムにおいて、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し、
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とするマルチプロセッサシステム。
【請求項６】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードとクロスバーネットワークを介して接続され、且つ、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを備えた入出力制御装置であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファと、
該入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録するアドレス一致先行ライトリクエスト検出処理部と、
前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録する登録処理部とを備えたことを特徴とする入出力制御装置。
【請求項７】
請求項６記載の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行する構成を有し、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更する構成を有することを特徴とする入出力制御装置。
【請求項８】
請求項７記載の入出力制御装置において、
前記制御部が、
前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行する構成を有することを特徴とする入出力制御装置。
【請求項９】
請求項８記載の入出力制御装置において、
前記登録処理部が、
前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録する構成を有し、
前記制御部が、
前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行する構成を有することを特徴とする入出力制御装置。
【請求項１０】
請求項６乃至９の何れか１項に記載した入出力制御装置において、
前記順序保証バッファのエントリ数と同数のエントリを有するアドレス一致管理バッファと、
前記入力バッファのエントリ数と前記順序保証バッファのエントリ数とを加算した数の有効フラグを保持する有効フラグ保持部とを備え、且つ、
前記アドレス一致先行ライトリクエスト検出処理部が、
前記入力バッファに入力されるリクエストに対するアドレス一致先行ライトリクエストが存在するか否かを、前記アドレス一致管理バッファに登録されているアドレスの中に、前記リクエスト中のアドレスと一致し、且つ対応する有効フラグが有効になっているアドレスが存在するか否かに基づいて判定する構成と、
前記入力バッファに入力されるリクエストがライトリクエストの場合、該ライトリクエストに含まれているアドレスを前記アドレス一致管理バッファに登録すると共に、前記有効フラグ保持部に保持されている有効フラグの内の、前回有効にした有効フラグの次の有効フラグを有効にする構成とを有し
前記制御部が、
前記順序保証バッファからライトリクエストが発行されたとき、前記有効フラグ保持部に保持されている有効フラグの内の、有効にされた時期が最も古い有効フラグを無効に変更する構成を有することを特徴とする入出力制御装置。
【請求項１１】
複数のプロセッサ及びそれらによって共有される共有メモリを有する複数のノードと、該各ノードとクロスバーネットワークを介して接続された入出力制御装置とを備え、前記入出力制御装置が、リクエストが登録されると共に該登録されたリクエストの発行を待ち合わせることが必要か否かを示す待ち合わせフラグが登録される順序保証バッファと、該順序保証バッファに登録されている待ち合わせフラグの内の、ノードから発行許可されたリクエストに対応する待ち合わせフラグを待ち合わせ不要を示すものに変更し、前記順序保証バッファに登録されている最古のリクエストに対応する待ち合わせフラグが待ち合わせ不要を示している場合、前記最古のリクエストを該当するノードに発行する制御部とを有するマルチプロセッサシステムにおけるリクエスト発行方法であって、
外部から入力されたリクエストが登録されると共に、該リクエストに対するアドレス一致情報が登録される入力バッファに対して外部からリクエストが入力されたとき、アドレス一致先行ライトリクエスト検出処理部が、前記リクエストに対するアドレス一致先行ライトリクエストが存在するか否かを調べ、前記入力バッファに登録された前記リクエストに対応付けてアドレス一致先行ライトリクエストが存在するか否かを示すアドレス一致情報を登録し、
登録処理部が、前記入力バッファに登録されている最古のリクエストに対応付けてアドレス一致情報が登録されていることを条件にして、前記最古のリクエストと待ち合わせ必要を示す待ち合わせフラグとを前記順序保証バッファに登録することを特徴とするリクエスト発行方法。
【請求項１２】
請求項１１記載のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがライトリクエストで、且つ該ライトリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記最古のリクエストの発行許可要求を該当するノードに対して発行し、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに対して発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続ライトリクエストが登録されている場合は、該アドレス一致後続ライトリクエストの発行許可要求を該当するノードに対して発行し、該発行許可要求に応答してノードから発行許可が返却された場合は、前記アドレス一致後続ライトリクエストの待ち合わせフラグを待ち合わせ不要を示すものに変更することを特徴とするリクエスト発行方法。
【請求項１３】
請求項１２記載のリクエスト発行方法において、
前記制御部が、前記順序保証バッファに登録されている最古のリクエストを該当するノードに発行した際、前記順序保証バッファに、前記最古のリクエストに対するアドレス一致後続リードリクエストが登録されている場合は、該アドレス一致後続リードリクエストを該当するノードに発行することを特徴とするリクエスト発行方法。
【請求項１４】
請求項１３記載のリクエスト発行方法において、
前記登録処理部が、前記入力バッファに登録されている最古のリクエストがリードリクエストで、且つ該リードリクエストに対応するアドレス一致情報がアドレス一致先行ライトアドレスが存在しないことを示している場合、前記リードリクエストと待ち合わせ不要を示す待ち合わせフラグとを前記順序保証バッファに登録し、
前記制御部が、前記登録処理部によって前記順序保証バッファに、待ち合わせフラグが待ち合わせ不要となっているリードリクエストが登録されたとき、該リードリクエストを該当するノードへ発行することを特徴とするリクエスト発行方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００７−１４８５０７（Ｐ２００７−１４８５０７Ａ）
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００５−３３８４８４（Ｐ２００５−３３８４８４）
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
[ Back to top ]