JP5941168B2 - 第１および第２のプロトコルドメインを有するデータ処理装置およびデータ処理装置に関する方法 - Google Patents

Description

本発明はデータ処理の分野に関する。具体的には、本発明は書き込み要求およびスヌープ(snoop)要求を取り扱うための異なるプロトコルを有する、第１および第２のプロトコルドメインを備えるデータ処理装置に関する。

データ処理装置は、多数の場所において、同一データの異なるバージョンを記憶し得る。例えば、２つのデバイスはそれぞれがローカルキャッシュを有し得、そして各キャッシュはメモリ内の同一アドレスに関連付けられたデータの各バージョンを同時に保持し得る。一貫性プロトコル（例えば、ＭＥＳＩプロトコル）は、同一データの多数のバージョンの一貫性（consistency）を確保するために使用され得る。一貫性プロトコルは、一貫性を維持するために書き込み要求およびスヌープ要求を使用し得る。例えば、データ値のローカルバージョンを記憶するデバイスは、ローカルバージョンがメモリ等の別の場所に書き込まれることを要求するために、書き込み要求を発行し得る。他のデバイスは、次に、他の場所から更新されたローカルバージョンにアクセス可能である。代替的に、デバイスが特定データ値に対するアクセスを必要とする場合には、デバイスがデータのローカルバージョンを記憶しているかどうかをチェックするために、他のデバイスに対してスヌープ要求を発行し得、そしてもしそうであれば、ローカルバージョンへのアクセスを要求する。この故に、書き込み要求およびスヌープ要求を使用して、データの一貫性を維持することが可能である。

１つの態様から見ると、本発明はデータ処理装置を提供し、本データ処理装置は、
第１のプロトコルドメインおよび第２のプロトコルドメインであって、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行し、そしてスヌープ対象アドレスと関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るように構成された少なくとも１つのデバイスをそれぞれが備える、第１のプロトコルドメインおよび第２のプロトコルドメインと、
前記第１のプロトコルドメインと前記第２のプロトコルドメインとの間で前記書き込み要求および前記スヌープ要求を転送するように構成されたブリッジと、を備え、
前記第１のプロトコルドメインが書き込み進行プロトコルの下で動作するように構成され、書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求のための前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止(block)され、
前記第２のプロトコルドメインがスヌープ進行プロトコルの下で動作するように構成され、スヌープ進行プロトコルの下で、未解決(pending)書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は、前記未解決スヌープ要求が（service）されるまで阻止され、
前記ブリッジは、前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求に関する前記書き込み対象アドレスは、前記第２のプロトコルドメインから前記第１のプロトコルドメインへと発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するように構成され、
前記ブリッジは、選択された要求がサービスされるのを待つことなく、前記選択された要求に対して、前記デッドロック条件の検出時に、早期応答を発行するように構成され、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期書き込み応答は、前記選択された要求がサービスされたことを、前記選択された要求を発行した前記発行プロトコルドメインに対して示す。

スヌープ要求および書き込み要求が同一対象アドレスに対して未解決の場合には、スヌープ要求によってアクセスされるデータの状態は、スヌープ要求をサービスする時点で書き込み要求がすでにサービスされていたかどうかに依存して、異なることがあり得る。それ故、書き込み要求およびスヌープ要求のどちらが最初にサービスされるかを判定するために、異なるプロトコルは異なる規則を規定し得る。スヌープ進行プロトコルにおいて、未解決書き込み要求は未解決スヌープ要求がサービスされるまでは足止め(stall)させられ、一方、書き込み進行プロトコルにおいては、未解決スヌープ要求は書き込み要求がサービスされるまで足止めさせられる。

本技法は、書き込み進行プロトコルを使用する第１のプロトコルドメインおよびスヌープ進行プロトコルを使用する第２のプロトコルドメインを有する装置において、デッドロック条件が発生する可能性のあることを認識する。第１のプロトコルドメインから第２のプロトコルドメインに発行された未解決書き込み要求の書き込み対象アドレスが、第１のプロトコルドメインへ第２の処理によって発行された未解決スヌープ要求のスヌープ対象アドレスと同一である場合には、デッドロック条件が発生する。この状態においては、第１のプロトコルドメインは、書き込み進行プロトコルに従い、未解決書き込み要求がサービスされるまでは未解決スヌープ要求を足止めさせる。しかしながら、スヌープ進行プロトコルに従い、未解決スヌープ要求がサービスされるまで第２のプロトコルドメインは未解決書き込み要求を足止めするため、未解決書き込み要求はサービスされることができない。この故に、各プロトコルドメインは他のプロトコルドメインを待ち、未解決書き込み要求および未解決スヌープ要求の両方がサービスされるのを妨げる。

この問題に取り組むため、第１および第２のプロトコルドメインを接続するブリッジは、デッドロック条件が生じたかどうかを検出し得る。デッドロック条件が検出された場合は、ブリッジは、要求がサービスされるのを待たずに、未解決書き込み要求または未解決スヌープ要求に対する早期応答を発行し得る（早期応答が発行された要求は「選択された要求」として参照される）。早期書き込み応答は、選択された要求を発行した発行プロトコルドメインに対し、たとえ選択された要求が実際にはサービスされていなくても、選択された要求がサービスされたことを示す。選択された要求は発行プロトコルドメインからみるとサービスされたように見えるため、未解決書き込み要求および未解決スヌープ要求の他方はもはや阻止されず、従って、発行プロトコルドメインは現在は他の要求にサービスすることが可能である。この故に、デッドロックは解決されることが可能である。

書き込み要求は、書き戻し要求または書き込みクリーン要求を含み得る。書き戻し要求を発行するデバイスは、別の場所に書き戻されているデータのローカルバージョンを無効化する。故に、デバイスはデータに対する排他的アクセスをもはや有せず、他のデバイスがデバイスのチェックなしでデータに今やアクセスし得る。

他方、書き込みクリーン要求を発行するデバイスは、他の場所に書き戻されているデータに対する排他的アクセスを保有し得る。データのローカルバージョンは、書き込みクリーン要求を発行したデバイスによってしばしば保有され得る。しかしながら、いくつかの機会においては、デバイスはキャッシュ内のデータを無効化し、別のデバイスがデータの対応するバージョンを記憶しているかどうかをチェックするためにスヌープ要求を発行する必要なく、データがキャッシュに再び取り込まれる（re-fetched）のを許可する排他的アクセスを保有しても良い。デバイスが排他的アクセスを保有する一方、別のデバイスがデータのローカルバージョンを記憶することを希望する場合には、他のデバイスはデータへのアクセスを要求するために、そのデバイスに対してスヌープ要求を発行するであろう。

ブリッジがデッドロックの阻止解除を行うために早期応答を発行した後、発行プロトコルドメインは、そのために早期応答が発行された選択された要求と同一の対象アドレスを対象とする別の選択された要求を発行することが可能である。例えば、選択された要求が未解決書き込み要求である場合には、第１のプロトコルドメインは同一の対象アドレスに関する別の書き込み要求を発行可能であり、そして選択された要求が未解決スヌープ要求である場合には、第２のプロトコルドメインが同一の対象アドレスに関する別のスヌープ要求を発行できる。別の選択された要求を発行された場合には、新しく選択された要求は、デッドロック条件の再発生の原因となるもう一度の他の要求の処理を阻止する。これは書き込みクリーン要求およびスヌープ要求については特に問題である。何故ならば書き込みクリーン要求またはスヌープ要求を発行するデバイスは、書き戻し要求を発行するデバイスよりも、同じ対象アドレスに対してさらなる書き込み要求を発行する可能性が高いからである。

この問題を解決するために、ブリッジは、選択された要求に対する早期応答を発行した後、別の選択された要求が発行プロトコルドメインによって発行されたかどうかを検出し、そしてもしそうであれば、発行プロトコルドメインに対して別の早期応答を発行し得る。ブリッジは、発行プロトコルドメインが同一対象アドレスに関する別の選択された要求を発行するごとに、早期応答を発行し続けることができ、他の要求が他のプロトコルドメインによってサービスされうることを保証する。

発行プロトコルドメインは、同一アドレスを標的とする最大Ｍ個（Ｍは整数）の連続した選択された要求を発行するように構成され得る。それ故、結局は、発行プロトコルドメインは同一対象アドレスを対象とする別の選択された要求の発行を停止し、他の要求が他のプロトコルドメインによってサービスされるのを許可する。

選択された要求が未解決書き込み要求の場合には、検出されているデッドロックに対する応答として、ブリッジは第１のプロトコルドメインに早期書き込み応答を発行し、書き込み要求が第２のプロトコルドメインにおいてサービスされたことを示し、スヌープ要求が第１のプロトコルドメインにおいてサービスされることを許可する。一旦スヌープ要求がサービスされると、第２のプロトコルドメインはスヌープデータを含むスヌープ応答を発行し得る。スヌープ応答を受け取ると、ブリッジはスヌープ応答と関連付けられたスヌープデータと未解決書き込み要求と関連付けられた書き込みデータを合併し、そして合併されたデータを第２のプロトコルドメインへ送信し得る。書き込みデータをスヌープデータと合併することにより、スヌープ応答を使用して書き込み要求に応答して書き込まれたであろうデータを取得可能であり、したがって、第２のプロトコルドメインが、デッドロック条件の原因となる未解決書き込み要求を別々に処理する必要はない。これは、デッドロックの解決に続き、第２のプロトコルドメインにおいて他の要求の取り扱いをスピードアップさせる。

選択された要求は、デッドロックが検出された未解決書き込み要求または未解決スヌープ要求のいずれかであり得る。いくつかの実施形態では、ブリッジは、デッドロック条件が検出されるごとに、選択された要求の新しい選択を行い得る。

例えば、ブリッジは、ブリッジによって選択された要求として最も後で検出された未解決書き込み要求および未解決スヌープ要求の１つを選択し得る。この手法は、後の要求の発行はより早期の要求の取り扱われ方に影響することができないことを意味する。何故ならばより後の要求に対する早期応答は、より後の要求に対してより早い要求のために道を譲るように強いるからであり、より早い要求が正常に処理されることを許可する。

他の実施形態では、選択された要求は、デッドロックが検出された未解決スヌープ要求および未解決書き込み要求の事前決定された１つであり得る。例えば、ブリッジは、デッドロックを解決して未解決スヌープ要求が第１のプロトコルドメインによってサービスされることを許可するために、第１のプロトコルドメインに対する早期書き込み応答を常に発行し、または、未解決書き込み要求が第２のプロトコルドメインによってサービスされることを許可するために、第２のプロトコルドメインに対して早期スヌープ応答を常に発行しても良い。

デッドロック条件の検出は、多数のやり方で達成し得る。例えば、ブリッジそれ自身は、第２のプロトコルドメインから発行されたスヌープ要求および第１のプロトコルドメインから発行された書き込み要求の対象アドレスを監視し、そしてアドレス一致が発見されたときはデッドロック条件をトリガー（trigger）することによってデッドロックを検出し得る。

代わりに、第１および第２のプロトコルドメインのうちの１つはデッドロック条件を検出し、そして、デッドロック条件が検出された場合には、信号をブリッジに対して発行してもよい。信号に応答して、ブリッジはデッドロック条件を検出し、そして選択された要求に対して早期応答を発行する。この故に、ブリッジ自体がスヌープ要求のアドレスと書き込み要求のアドレスとの間の衝突を実際に同定することは必須ではない。用語「検出する」は、ブリッジが別のデバイスからデッドロックが生じたことを示す信号を受け取ることを包含し得る。

ブリッジは、第２のプロトコルドメインから第１のプロトコルドメインに対して発行された未解決スヌープ要求を待ち行列に入れるためのスヌープ待ち行列を維持し得る。いくつかのシステムでは、第１および第２のプロトコルドメインの少なくとも１つは発行された順番で未解決スヌープ要求にサービスする。そのようなシステムでは、スヌープ待ち行列内の最も古い未処理スヌープ要求が阻止された場合には、他のスヌープ要求は、それより後のスヌープ要求に関連付けられた対象アドレスがたとえ未解決書き込み要求によってデッドロックとならない場合であってもサービスされえない。この故に、ブリッジはスヌープ待ち行列内の最も古い未処理スヌープ要求に関連付けられたデッドロック条件の解決を優先させ得る。例えば、スヌープ待ち行列が複数の未解決スヌープ要求を含む場合には、ブリッジはまだスヌープ応答を受け取っていないスヌープ待ち行列内の最も古いスヌープ要求に関するデッドロック条件の検出のみに対する早期応答を発行する（早期応答は、どの要求が選択された要求であるかに基づき、最も古いスヌープ要求に応答して、あるいは最も古いスヌープ要求と衝突する書き込み要求に応答して発行されるであろう）。

ブリッジは、第１のプロトコルドメインから第２のプロトコルドメインへ発行された未解決書き込み要求をバッファリングするための書き込みバッファを有し得る（いくつかの実施形態では、バッファは反対方向に移動している書き込み要求もバッファリングし得る）。いくつかの例では、バッファは実際に未解決書き込み要求を記憶し、一方他の例では、バッファは、実際に要求を記憶することなく、未解決書き込み要求を追跡するためのデータを記憶しても良い。

未解決書き込み要求に対して早期応答を発行した後、同一書き込み対象アドレスに関するさらなる書き込み要求が第１のプロトコルドメインによって発行され、そして書き込みバッファは新規書き込み要求をバッファリングするための十分なスペースを有しない場合には、問題が発生する可能性がある。例えば、早期書き込み応答をトリガーした未解決書き込み要求は、バッファ内の最後の入手可能スペースを使用した可能性がある。この事例では、バッファスペースの不足は、さらなる書き込み要求が第１のプロトコルドメインから受付けられることを妨げる可能性があり、したがって、第１のプロトコルドメインの書き込み進行プロトコルは、さらなる書き込み要求が書き込みバッファに受付けられるまで、第１のプロトコルドメインが未解決スヌープ要求の阻止を継続するようにする。

この問題に取り組むために、ブリッジはさらなる書き込み要求を同一の対象アドレスに関して未解決書き込み要求と合併させ、両方の書き込み要求がバッファリングされることを許可し得る。合併された書き込み要求は、合併された要求と関連付けられたデータがもともとの未解決書き込み要求とさらなる書き込み要求とを順番に実行することによるデータと同一となり得る。同一アドレスを対象とする書き込み要求を合併することにより、さらなる書き込み要求はブリッジによって受付けられることが可能性であり、したがって、さらなる書き込み要求に関する早期書き込み応答を受け取った第１のプロトコルドメインは、未解決スヌープ要求をサービスすることが可能であり、デッドロックを解決する。

書き込みバッファは、衝突(conflicting)未解決スヌープ要求に対するスヌープ応答が第１のプロトコルドメインから受け取られるまで、デッドロック条件が検出された未解決書き込み要求を保有するように準備され得る。このようにして、デッドロックを生じさせた未解決書き込み要求は、スヌープ要求がサービスされるまで、第１のプロトコルドメインによって発行された後の書き込み要求との合併のために有用であり続ける。

書き込み要求の合併は、デッドロック条件が対象アドレスに関して同定されたかどうかにかかわらず、同一対象書き込みアドレスに関する反復書き込み要求を取り扱うように、書き込みバッファによっても使用され得る。第１のプロトコルドメインが同一書き込み対象アドレスに関して２つの連続する書き込み要求を発行する場合は、それらはバッファ内のスペースを節約するために合併されることが可能である。

第１のプロトコルドメインは第２のプロトコルドメインに対して発行された最大Ｎ個の整数の未解決書き込み要求を取り扱うように構成され得、書き込みバッファは第１のプロトコルドメインから第２のプロトコルドメインへ発行された少なくともＮ個の未解決書き込み要求をバッファリングするための容量を有しても良く、Ｎは整数である。少なくとも第１のプロトコルドメインによって一度に取り扱われることが可能な数の書き込み要求に関するバッファ容量を提供することにより、バッファはブリッジが入来(incoming)スヌープ要求のスヌープ対象アドレスを、デッドロック条件を検出するために、第１のプロトコルドメインから発行された各未解決書き込み要求の書き込み対象アドレスと比較できるようにする。

いくつかの例では、装置はブリッジと第１のプロトコルドメインとの間に連結された書き込みステージングバッファを備え得る。書き込みステージングバッファは、第１のプロトコルドメインによって発行された書き込み要求を受け取り得、そして書き込み要求を、書き込みバッファ内に書き込み要求をバッファリングするためのスペースが存在する場合には、ブリッジに渡す。これは、メッセージがブリッジにおいて受け取られることが可能であるがどうかを判定するために、ブリッジと第１のプロトコルドメインとの間で必要とされるハンドシェイク信号伝達の量を削減可能である。

デッドロック条件が検出され、早期書き込み応答が発行されると（すなわち、選択された要求が未解決書き込み要求）、ブリッジは、デッドロックをトリガーさせた未解決書き込み要求を取り消し得る。第２のプロトコルドメインは、書き込み要求を取り扱うために処理資源（例えばバッファエントリ）を予約したかもしれず、したがって、書き込み要求の取り消しはそれらの資源が別の要求に対して再配分されることを可能とし、一方デッドロックは未解決のまま残る。取り消された書き込み要求は、書き込みデータを前述のようにスヌープ応答と合併することによって依然として効果的にサービスされることが可能である。

取り消された書き込み要求は、未解決スヌープ要求に対するスヌープ応答が第１のプロトコルドメインから受け取られるまで、書き込みバッファ内に保持され得、前述のように後の書き込み要求との合併を許可する。

いくつかの実施形態では、ブリッジは第１および第２のプロトコルドメインに対して別の実体であるが、他の実施形態では、ブリッジは、第１または第２のプロトコルドメイン内において、デバイスの一部として実装され得ることが認識されるであろう。

別の態様から見た場合、本発明はデータ処理装置を提供し、本データ処理装置は、
データ処理を実施するための第１のプロトコルドメイン手段および第２のプロトコルドメイン手段であって、それぞれが、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行するための、そしてスヌープ対象アドレスと関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るための、少なくとも１つのデバイス手段を備える、第１のプロトコルドメイン手段および第２のプロトコルドメイン手段と、
前記書き込み要求および前記スヌープ要求を、前記第１のプロトコルドメイン手段と前記第２のプロトコルドメイン手段との間で転送するためのブリッジ手段と、を備え、
前記第１のプロトコルドメイン手段は書き込み進行プロトコルの下で動作するように構成され、書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止され、
前記第２のプロトコルドメイン手段は、スヌープ進行プロトコルの下で動作するように構成され、スヌープ進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は前記未解決スヌープ要求がサービスされるまで阻止され、
前記ブリッジ手段は、前記第１のプロトコルドメイン手段から前記第２のプロトコルドメイン手段へ発行された未解決書き込み要求に関する前記書き込み対象アドレスが、前記第２のプロトコルドメイン手段から前記第１のプロトコルドメイン手段へ発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するように構成され、
前記ブリッジ手段は、前記デッドロック条件の検出時、前記選択された要求がサービスされるのを待つことなく、選択された要求に対する早期応答を発行するように構成され、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期応答は、前記選択された要求を発行した発行プロトコルドメイン手段に対し、前記選択された要求がサービスされたことを示す。

さらなる態様から見た場合、本発明は、第１のプロトコルドメインおよび第２のプロトコルドメインを備え、それぞれが、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行し、そしてスヌープ対象アドレスに関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るように構成された少なくとも１つのデバイスを備える装置のための方法を提供し、前記第１のプロトコルドメインは書き込み進行プロトコルの下で動作し、書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止され、前記第２のプロトコルドメインはスヌープ進行プロトコルの下で動作し、スヌープ進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は前記未解決スヌープ要求がサービスされるまで阻止され、
前記方法は、
前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求に関する前記書き込み対象アドレスが、前記第２のプロトコルドメインから前記第１のプロトコルドメインへ発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するステップと、
前記デッドロック条件の検出時に、前記選択された要求がサービスされるのを待つことなく、選択された要求に対する早期応答を発行するステップであって、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期応答は、前記選択された要求を発行した前記発行プロトコルドメインに対し、前記選択された要求がサービスされたことを示す、ステップと、を含む。

本発明のさらなる特定のおよび好ましい態様は、付属独立項および従属項に提示される。従属項の特徴は適する場合には独立項の特徴と組み合され得、特許請求の範囲に明示的に提示されたもの以外の組み合わせもある。

第１および第２のプロトコルドメインを有するデータ処理装置を模式的に図解する。 第１および第２のプロトコルドメインの書き込み進行プロトコルの例を図解する。 第２のプロトコルドメインのスヌープ進行プロトコルの例を図解する。 デッドロック条件の例を図解する。 デッドロック条件を解決するための技法の例を図解する。 検出されるのが最後となる未解決書き込み要求および未解決スヌープ要求の１つに対する早期応答を発行することによってデッドロック条件が解決される例を図解する。 検出されるのが最後となる未解決書き込み要求および未解決スヌープ要求の１つに対する早期応答を発行することによってデッドロック条件が解決される例を図解する。 デッドロック条件を解決する方法を図解する。 書き込みバッファがすでに一杯のときに、デッドロック条件が検出された未解決書き込み要求と同じ対象アドレスに関し、第１のプロトコルドメインが別の書き込み要求を発行した場合に発生し得る問題を図解する。 同じ対象アドレスに関して、他の書き込み要求を未解決要求と合併することにより、図８に示される問題を解決するための技法例を図解する。 図９の例に従って、デッドロック条件を解決する方法を図解する。

図１は、第１のプロトコルドメインＡ、第２のプロトコルドメインＢ、および２つのドメインをリンクするブリッジ４を備えるデータ処理装置２を図解する。各プロトコルドメインＡ、Ｂは、バス８を介して互いに通信し合ういくつかのデバイス６を備える。デバイス６は、任意の種類の処理デバイスまたは記憶デバイスを備え得、そして主デバイスおよび従属デバイスを含み得る。各ドメインＡ、Ｂは、データ値のローカルバージョンを書くための書き込み要求を別の場所に発行し、データのローカルバージョンに対するアクセスを要求するためのスヌープ要求を受け取ることができる、少なくとも１つのデバイスを含み得る。書き込み要求およびスヌープ要求は、同一プロトコルドメインＡ、Ｂ内または異なるプロトコルドメイン内のデバイス間で交換され得る。

ブリッジ４は、１つのドメイン内のデバイスから他のドメイン内のデバイスへ発行されたスヌープ要求を待ち行列に入れるためのスヌープ待ち行列１０、１つのドメイン内のデバイスから他のドメイン内のデバイスへ発行される書き込み要求をバッファリングするための書き込み要求バッファ１２、そして書き込み要求バッファ１２内にバッファリングされる書き込み要求と関連付けられたデータを記憶するための書き込みデータバッファ１４を含む。書き込みステージングバッファ１６もドメインＡ、Ｂの少なくとも１つとブリッジ４との間に、書き込み要求バッファ１２によって受付けられることが可能となる前に書き込み要求をステージング(staging)するために提供される。

ブリッジ４は図１において処理ドメインＡおよび処理ドメインＢから離れているものとして図解されるが、いくつかの実施形態では、ブリッジ４の機能はドメインＡ、Ｂの内の１つの中のデバイス６を使用して実装され得ることが認識されるであろう。

第１のプロトコルドメインＡは、書き込み進行プロトコルの下で動作する。書き込み進行プロトコルにおいて、書き込み要求が書き込み対象アドレスに関して未解決であり、またスヌープ要求も同一の対象アドレスに関して未解決である場合には、未解決スヌープ要求は、書き込み要求がサービスされるまで阻止される。図２は、書き込み進行プロトコルの下で動作しているドメインＡのデバイスの例を示す。デバイスは２つの主デバイス（例えば、プロセッサ）、ならびに従属(slave)デバイスであり得る（例えば、メモリ）一貫性ポイント（ＰＯＣ：point of coherency）、要求が従属デバイスに対して経路決めされるところの相互接続またはバスを含む（いくつかのシステムでは、相互接続またはバスはデータの一貫性管理に関して責任があり−この事例では、相互接続／バスは主デバイスにとっては従属デバイスと見え得る）。

図２において、主デバイス０は、一貫性ポイントに対し、対象アドレスＡに関連付けられたローカルデータ値を、一貫性ポイントを介してアクセス可能な対象場所へ書き込むための、書き戻し（ＷＢ：Write Back）または書き込みクリーン（ＷＣ: Write Clean）要求を発行する。一方、別の主デバイス１からの読み取り要求に応答して、一貫性ポイントは、主デバイス０に対し、同一対象アドレスＡに関連付けられたスヌープ要求を発行する。書き込み要求は対象アドレスＡに関してすでに応答待ちであるため、スヌープ要求は、書き込みが処理されたことを示す書き込み応答信号が一貫性ポイントから受け取られるまで、主デバイス０によって阻止される。書き込みが処理された後、スヌープ要求は阻止解除され、スヌープ応答が一貫性ポイントに発行され、これは次にスヌープされたデータを主１に送る。

対照的に、第２のプロトコルドメインＢはスヌープ進行プロトコルの下で動作し、この場合、スヌープ要求が未解決のときは、スヌープ要求と同じ対象アドレスを対象とする書き込み要求は、スヌープ要求がサービスされるまで停止される。図３は、スヌープ進行プロトコルの下で動作しているドメインＢ内のデバイスの例を示す。スヌープ要求は、対象アドレスＢと関連付けられたデータのローカルバージョンへのアクセスを要求するために、主デバイス０へ発行される。また、主デバイス０は、同一対象アドレスＢに関連付けられたデータの点で、一貫性ポイントへ書き込み要求を発行する。スヌープ進行プロトコルに従い、書き込み要求は、アドレスＢに関するスヌープ要求が未解決であるため、サービスされることができない。それ故、一貫性ポイントは、スヌープ応答が、主デバイス０によって主デバイス１に対して発行されるまで、書き込みデータに関する要求を延期し得る。主デバイス０は、データ要求が一貫性ポイントから受け取られるまで、書き込みデータを発行することができない。この故に、書き込み要求は、スヌープ要求がサービスされるまで、サービスされることができない。

異なるプロトコルが書き込み要求およびスヌープ要求への異なる対処方法を規定することが認識されるであろう。例えば、書き込み応答、書き込み準備完了、およびスヌープ応答の信号の使用は、異なるプロトコルにおいて異なり得る。本発明の目的に関しては、１つのドメインが書き込み進行プロトコルで動作し、他のドメインがスヌープ進行プロトコルで動作する場合においては、各プロトコルが書き込み要求およびスヌープ要求を取り扱うやり方の正確な詳細は重要ではない。

また、常に書き込み進行プロトコルまたはスヌープ進行プロトコルとして働くプロトコルがいくつかあるが、他のプロトコルは常にこのようには働かず、また例えば、一定の状態の下では書き込み進行プロトコルまたはスヌープ進行プロトコルとしてのみ動作し得る。その様なプロトコルにおいては、本技法は、１つのプロトコルが書き込み進行プロトコルとして働き、他のプロトコルがスヌープ進行プロトコルとして働いているときは、時々適用されることが可能であり、他のときには適用されないかもしれない。それ故、用語「スヌープ／書き込み進行プロトコルの下で動作するように構成される」は、プロトコルドメインは、スヌープ／書き込み進行プロトコルの下で常に動作しなければならないことをほのめかすものではない。

図４は、書き込み進行プロトコルの下で動作している第１のプロトコルドメインＡ内のデバイスとスヌープ進行プロトコルの下で動作している第２のプロトコルドメインＢ内のデバイスとの間の通信中に発生する可能性のあるデッドロック条件の例を示す。図４に示されるように、第１のプロトコルドメインＡが第２のプロトコルドメインＢに対して書き込み要求を発行し、第２のプロトコルドメインＢが第１のプロトコルドメインＡに対しスヌープ要求を発行する場合は、各ドメインは受け取られた要求を阻止する。ドメインＡ内のデバイスは、同一対象アドレスＸに関する発行された書き込み要求がサービスされていないので、書き込み進行プロトコルに従って対象アドレスＸに関する受け取られたスヌープ要求を阻止する。ドメインＢ内のデバイスは、同一対象アドレスＸに関する発行されたスヌープ要求がサービスされていないので、スヌープ進行プロトコルに従って、対象アドレスＸに関する受け取られた書き込み要求を阻止する。この故に、ドメインＡおよびＢの両方はそれ自身の処理を実施する前に先へ進むのを互いに待ち、デッドロックを生じる。

図５は、デッドロックがどのようにして解決可能であるかの例を示す。ブリッジ４は、スヌープ要求のアドレスおよび書き込み要求それ自身を調べることによって、あるいはデッドロック条件が存在することを示す、プロトコルドメインＡ、Ｂの１つからの信号を受け取ることによって、デッドロック条件の存在を検出することができる。デッドロックを検出すると、ブリッジ４は未解決書き込みおよびスヌープ要求の１つに対する早期応答を発行し、対応する要求がサービスされたことを示す。図５の例では、早期書き込み応答が第１のプロトコルドメインＡに送られ、書き込み要求が第２のプロトコルドメインＢによって実際にはサービスされていないが、対象アドレスＸに関する未解決書き込み要求がサービスされたことを示す。第１のプロトコルドメインＡの観点からは、書き込みはもはやサービスされ、したがって、これはスヌープ要求を阻止解除する。スヌープ要求はもはや第１のプロトコルドメインＡによってサービスされることが可能である。スヌープ応答が生成され、そしてブリッジ４を介して第２のプロトコルドメインＢへ送られる。スヌープ応答は対象アドレスＸに対応する最新データを典型的に含むので（これはデッドロックを生じさせた未解決書き込み要求に応答して書き戻されたであろう）、この書き込み要求を実行することはもはや必要ない。未解決書き込み要求の書き込みデータがスヌープ応答に含まれないデータを含む場合には、ブリッジは、応答を第２のプロトコルドメインＢに送る前に、書き込みデータをスヌープ応答のスヌープデータと合併させることが可能である。

この故に、早期応答を書き込み要求に対して発行することはデッドロックが解決されることを可能とし、衝突している一貫性プロトコルの下で動作するドメイン間の互換性通信を可能とする。

同様に、デッドロックは、早期スヌープ応答を第２のプロトコルドメインＢに発行することによっても、スヌープ要求が第１のプロトコルドメインＡ内でサービスされたことを示し、解決され得、未解決書き込み要求が第２のプロトコルドメインＢ内で処理されることを可能とする。

デッドロック条件を阻止解除し、他の要求が継続することを可能とするために、ブリッジ４は、いくつかの実施形態では、常に早期書き込み応答を書き込み要求に対して送り、または常に早期スヌープ応答をスヌープ要求に対して送り得る。そのような実施形態では、どの要求が早期応答を受け取るかは事前決定され、ブリッジによってどの要求が最初に受け取られるかは問題にはならない。

しかしながら、図６Ａおよび６Ｂに示されるように、他の実施形態においては、ブリッジ４はブリッジ４によって最後に検出される未解決スヌープ要求および未解決書き込み要求の１つに対して早期応答を発行し得る。デッドロックが検出された最新の要求に対して早期応答を送ることにより、より早期の要求が阻止解除され、正常な方法で処理され得る。この手法はより後の要求は、より早い要求がサービスされる方法に影響をおよぼすことができないことを意味する。

図６Ａに示されるように、第１のプロトコルドメインＡからの未解決書き込み要求ＷＢが、第２のプロトコルドメインＢからのスヌープ要求Ｓｎｐと衝突する前に、ブリッジ４に遭遇した場合には、早期スヌープ応答が第２のプロトコルドメインＢに対して発行され、スヌープ要求が第１のプロトコルドメインＡ内でサービスされたことを示す。これは書き込み要求を阻止解除し、書き込み要求が第２のプロトコルドメインＢによって取り扱われることを可能にする。

しかしながら、図６Ａに示されるように、第２のプロトコルドメインＢは同一アドレスを対象とする別のスヌープ要求Ｓｎｐを発行することは可能であり、これはもう一度未解決書き込み要求ＷＢを阻止する。この問題を解決するために、ブリッジ４は、第２のプロトコルドメインが同一アドレスを対象とする別のスヌープ要求を発行する度に、別の早期スヌープ応答を発行することができる。結果的に、第２のプロトコルドメインＢは同一アドレスを対象とするスヌープ要求の発行を停止し、したがって、もはや未解決書き込み要求を取り扱う準備ができる。第２のプロトコルドメインＢは、ブリッジ４に対して書き込み応答を発行し、書き込み要求に関連付けられた書き込みデータを受け取る準備ができたことを示す。ブリッジ４は、次に、書き込み応答Ｂを第１のプロトコルドメインに送り、それに応答して、第１のプロトコルドメインＡは書き込み認識信号ＷＡＣＫをブリッジ４に送る。書き込み認識信号ＷＡＣＫに応答して、ブリッジ４は書き込みデータを第２のプロトコルドメインＢに転送する。

他方、図６Ｂは第２のプロトコルドメインＢからのスヌープ要求Ｓｎｐが、第１のプロトコルドメインＡからの書き込み要求ＷＢの前に、ブリッジ４によって検出される例を示す。書き込み要求ＷＢが最後に検出されたものであったので、ブリッジ４は早期書き込み応答Ｂを第１のプロトコルドメインＡに対して発行し、書き込み要求ＷＢが第２のプロトコルドメインＢ内でサービスされたことを示す（例え書き込み要求ＷＢがサービスされていなくても）。これはスヌープ要求Ｓｎｐを阻止解除し、したがって、第１のプロトコルドメインＡは次にスヌープ応答Ｒｓｐをブリッジに送る。また、早期書き込み応答Ｂに応答して、第１のプロトコルドメインＡは書き込み認識信号ＷＡＣＫをブリッジ４に対して発行する。ブリッジが、早期書き込み応答Ｂが発行された書き込み要求に関する書き込み認識信号ＷＡＣＫを受け取ったとき、ブリッジ４は書き込みデータバッファ１４内の対応する書き込みデータを、スヌープ応答Ｒｓｐに関連付けられたスヌープデータと合併し、第２のプロトコルドメインＢへ送信される合併された書き込み／スヌープデータを生成する。合併されたデータは、書き込みデータおよびスヌープデータが対象場所へ首尾よく書き込まれた場合に発生するデータである。データをこのようにして合併することにより、書き込み要求およびスヌープ要求の両方は、別の要求を発行する必要なく、サービスされることが可能である。

図７は、図６Ａおよび６Ｂの実施形態に従い、デッドロック条件を解決する方法を図解する。ステップ２０において、デッドロック条件は、第１のプロトコルドメインＡから第２のプロトコルドメインＢへ発行された書き込み要求、および第２のプロトコルドメインＢから第１のプロトコルドメインＡに発行されたスヌープ要求、両方の要求とも同一アドレスを対象としている、について検出される。ステップ２２において、ブリッジ４は、スヌープ要求および書き込み要求のどちらが最初に検出されたかを判定する。２番目に検出された要求が、早期応答が発行された選択された要求である。

書き込み要求が最初に検出された場合（図６Ａに示される事例）、ステップ２４において、早期スヌープ応答が、第２のプロトコルドメインＢに対して発行される。ステップ２６において、ブリッジ４は、早期応答が発行されたスヌープ要求と同じ対象アドレスに関して、第２のプロトコルドメインＢによって別のスヌープ要求が発行されたかどうかを検出する。そうである場合には、方法はステップ２４に戻り、別の早期スヌープ応答が第２のプロトコルドメインＢに対して発行される。

第２のプロトコルドメインＢが同一対象アドレスに関して別のスヌープを発行するごとに、第２のプロトコルドメインＢが同一アドレスに関して別のスヌープ要求を結果的に発行しなくなるまで、別の早期スヌープ応答が発行される。この時点において、未解決書き込み要求はもはや阻止されず、したがって、第２のプロトコルドメインＢは準備完了信号をブリッジ４に発行し、第２のプロトコルドメインＢが書き込みデータを受け取る準備ができていることを示す。準備完了信号に応答して、ステップ２８においては、ブリッジ４は書き込み応答を第１のプロトコルドメインＡに対して発行する。書き込み認識信号ＷＡＣＫが第１のプロトコルドメインＡから受け取られると、ステップ３０において、ブリッジ４は、第２のプロトコルドメインＢに対し、未解決書き込み要求と関連付けられた書き込みデータバッファ１４からの書き込みデータＤａｔａ＿Ｉを送信する。対象アドレスと関連付けられたデータがもはや第２のプロトコルドメインＢに対して提供されたので、早期応答が発行されたスヌープ要求に対してサービスする必要はもはやない。

他方、ステップ２２において、書き込み要求の前にスヌープ要求が検出されたと判定された場合（図６Ｂに示される事例）、書き込み要求は選択された要求であり、そしてステップ３２において、ブリッジ４は早期書き込み応答を第１のプロトコルドメインＡに対して発行し、書き込み要求が第２のプロトコルドメインＢにおいてサービスされたことを示す（たとえ書き込み要求が実際にサービスされない場合であっても）。ステップ３４において、ブリッジ４は同一アドレスに対する別の書き込みが受け取られたかどうかを判定する。もしそうであれば、ステップ３６において、新しい書き込み要求が書き込み要求バッファ１２内で古い書き込み要求と合併され、そして任意の関連書き込みデータも書き込みデータバッファ１４内で合併され、その後ステップ３２において、別の早期書き込み応答が第１のプロトコルドメインＡに対して発行され、未解決スヌープ要求がもう一度阻止解除されることを許可する。

結果的に、第１のプロトコルドメインＡは同一アドレスを対象とするさらなる書き込み要求を発行せず、スヌープ応答を未解決スヌープ要求に対して発行する。第１のプロトコルドメインＡも、早期書き込み応答に応答して書き込み認識信号ＷＡＣＫ（write acknowledge signal）を発行し、書き込み要求と関連付けられた書き込みデータバッファ１４内のデータがもはや第２のプロトコルドメインＢへ送信可能であることを示す。スヌープ応答および書き込み認識信号が受け取られると、ステップ３８において、ブリッジ４はスヌープ応答データとデッドロックを生じさせた未解決書き込み要求に関する書き込みデータを合併させる。ステップ４０において、合併されたデータを含むスヌープ応答は、第２のプロトコルドメインＢに送られる。データをこのようにして合併することにより、スヌープ要求が必要とされたデータを第２のプロトコルドメインＢに運搬したため、早期応答が発行された書き込み要求に対してサービスする必要はない。

この故に、デッドロックが検出されたスヌープおよび書き込み要求の１つに対して早期応答を発行することにより、デッドロックは解決されることが可能であり、処理の継続を許可する。

図８は、ブリッジ４の書き込み要求バッファ１２および書き込みデータバッファ１４が一杯になったときに発生し得る問題の例を図解する。バッファ１２、１４は有限数の書き込み要求のための容量を有する（図８はバッファが４つの要求を収容可能である例を示すが、実際に書き込みバッファ１２、１４はより大きくあり得ることが認識されるであろう）。図８に示されるように、第１のプロトコルドメインＡが４つの対象アドレスＡ、Ｂ、Ｃ、Ｄに関して４つの書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａ〜ＷｒｉｔｅＣｌｅａｎ−Ｄを発行した後、バッファは一杯となり、そしてさらなる書き込み要求は受付不可能である。アドレスＡ、Ｂ、ＣおよびＤは同一アドレスあるいは異なるアドレスであり得る。

図８に示されるように、ドメインＢは次に、スヌープ対象アドレスＡに関し、スヌープ要求Ｓｎｐ−Ａを発行し得る。アドレスＡを対象とする未解決書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａが存在するため、デッドロック条件は検出され、そしてブリッジ４は早期書き込み応答Ｂ−Ａを第１のプロトコルドメインＡに対して発行し得、デッドロック条件の解決を試みる（この例では、書き込み要求は選択された要求である）。

しかしながら、書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａがサービスされたことを示す早期書き込み応答Ｂ−Ａを受け取ると、第１のプロトコルドメインＡは同一アドレスＡに関し、別の書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａを発行し得ることは可能である。この事例では、スヌープ要求Ｓｎｐ−Ａは、ドメインＡの書き込み進行プロトコルに従って、新しい書き込み要求によって阻止されるため、依然として処理されることは不可能である。さらに、ブリッジ４内の書き込みバッファ１２はすでに一杯であるので、番号５で表示される新規書き込み要求は書き込みステージングバッファ１６を超えて渡らない。それ故、プロトコルドメインＡはこの要求がサービスされていないと判定し、従って、同一対象アドレスを対象とするスヌープ要求Ｓｎｐ−Ａの阻止を続ける。

この問題は、ブリッジ４が新規書き込み要求を同一アドレスに関して旧書き込み要求と合併することを許可することにより、解決されることが可能である。合併された書き込みは、より古い書き込み要求とより新しい書き込み要求とが順に実施された場合に、対象場所に帰結するデータと同等の書き込みデータにより生成されることが可能である。要求を合併することにより、より後の書き込み要求はバッファ内に受付けられることが可能である。ブリッジ４は、次に、別の早期書き込み応答を第１のプロトコルドメインＡに対して発行し、より後の書き込み要求がサービスされたことを示す（ここでも、第２のプロトコルドメインＢが実際上この書き込み応答をサービスしていない場合であっても）。第１のプロトコルドメインＡのデバイスは、同一書き込み対象アドレスを対象アドレスとする限定数のみの連続書き込み要求を発行し得る。それ故、同一対象アドレスに関する別の書き込み要求が発行される毎に、第１のプロトコルドメインＡに対して早期応答メッセージを継続して発行することにより、そして各書き込み要求をバッファ内の同一アドレスに関する早期要求と合併することにより、結果的に、第１のプロトコルドメインＡは、異なる対象アドレスに関する新規書き込み要求を発行し、このようにして、デッドロックが検出されたスヌープ要求を阻止解除する。スヌープ要求は次にサービスされることが可能である。

図９は、図８に示される問題が解決されることが可能なやり方の例を示す。図９は、丸で囲まれた文字に関して以下に表示され、記述された多くの動作を示す。図９において動作が記述され、図解される順番は、必ずしも動作が実際に実行される時間的順序ではなく、一部の動作は平行して、または異なる順番で実施され得ることが認識されるであろう。
Ｈ：第２のプロトコルドメインＢ内のデバイスは、それぞれ対象アドレスＡおよびＥを指定する２つの読み取り動作Ｒｄ−Ａ、Ｒｄ−Ｅを発行する。アドレスＡおよびＥと関連付けられたデータのバージョンはデバイスによって第１のプロトコルドメイン内に記憶され得るため、読み取り動作Ｒｄ−Ａ、Ｒｄ−Ｅはスヌープ要求Ｓｎｐ−Ａ、Ｓｎｐ−Ｅが第２のドメインＢから第１のドメインＡへ発行されるようにトリガーする。
Ｉ：第１のプロトコルドメインＡは、４つの書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａ〜ＷｒｉｔｅＣｌｅａｎ−Ｄを発行し、それぞれ対象アドレスＡ、Ｂ、Ｃ、Ｄを指定する。ここでも、アドレスＡ、Ｂ、Ｃ、Ｄは、同一アドレスまたは異なるアドレスであり得る。アドレスＢ、Ｃ、ＤがアドレスＡとは異なる場合、書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ｂ〜ＷｒｉｔｅＣｌｅａｎ−Ｄは、デッドロックがこれらの要求に関して検出されないため、第２のドメインＢによってサービスされることが可能である。アドレスＢ、Ｃ、ＤのいずれかがアドレスＡと同一である場合は、アドレスＡに関する未解決スヌープ要求が存在するため、対応する書き込み要求はサービスされることができない。
Ｊ：第２のプロトコルドメインＢは、デッドロック条件は、同一対象アドレスＡを指定する書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａとスヌープ要求Ｓｎｐ−Ａとの間で発生することを検出し、そして信号Ｃａｎｃｅｌ−Ａをブリッジ４に発行する。
Ｋ：信号Ｃａｎｃｅｌ−Ａを第２のプロトコルドメインＢから受け取ると、ブリッジ４はデッドロック条件を検出し、書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａを取り消し、したがって、もはやサービスされることはない（必須ではないが、書き込み要求の取り消しは、他の要求をサービスするために、第２のプロトコルドメインＢ内の資源を解放することができる）。しかしながら、取り消された書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａはバッファ内に保有され、必要に応じてその後の要求との合併を許可する。
Ｌ：デッドロック条件の検出をすると、ブリッジ４は早期書き込み応答Ｂ−Ａを書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａに対して発行する。早期書き込み応答Ｂ−Ａを受け取ると、第１のドメインＡは書き込みが第２のドメインＢにおいてサービスされたと判定する。
早期書き込み応答Ｂ−Ａを受け取ると、第１のプロトコルドメインＡは、デッドロックを生じさせた書き込み要求と同一の対象アドレスＡを指定する別の書き込み要求を発行（図９における事例Ｍ）、異なる対象アドレスを指定する別の書き込み要求を発行（図９における事例Ｐ）、または未解決スヌープ要求をサービスし得る（図９における事例Ｑ）。
Ｍ：早期書き込み応答Ｂ−Ａに応答して、第１のプロトコルドメインＡが、デッドロックが検出されたアドレスと同一の対象アドレスＡを対象とする別の書き込み要求を発行する場合は、
Ｎ：ブリッジ４は、新規書き込み要求を同一対象アドレスＡに関する直前書き込み要求と合併する。書き込みデータバッファ１４内の合併されたデータは、元の書き込み要求とその後の書き込み要求が順番に実施された場合に帰結するであろうデータに対応する。
Ｏ：ブリッジ４は、別の早期書き込み応答Ｂ−Ａを第１のプロトコルドメインＡに送る。この故に、第１のプロトコルドメインＡは書き込みがサービスされたと判定し、そして再び、同一対象アドレスに関する別の書き込み要求を発行（図９における事例Ｍ）、異なる対象アドレスに関する書き込み要求を発行（事例Ｐ）、またはスヌープ要求の取り扱い（事例Ｑ）、を選択し得る。
Ｐ：ドメインＡが、デッドロック条件を生じさせた未解決書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａの対象アドレスとは異なる対象アドレスを指定する書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ｅを発行する場合は、対象アドレスＡに関するデッドロックは、もはやそのアドレスＡを対象とする未解決書き込み要求が存在しないために解決される。この故に、第１のプロトコルドメインＡは、もはやスヌープ応答に対してサービスすることは自由である（図９において示される文字Ｑ）。
Ｑ：プロトコルドメインＡは、結果的に、スヌープ要求Ｓｎｐ−Ａに応答してスヌープ応答ＣＲＤＡＴＡ−Ａを発行する。スヌープ応答は、第１のプロトコルドメインＡ内に維持されるアドレスＡと関連付けられたデータのローカルバージョンの値、ならびにローカルバージョンの一貫性状態に関する情報を含む。
Ｒ：ブリッジ４はスヌープ応答を受け取り、スヌープ応答に関連付けられたスヌープデータを対象アドレスＡに関する合併された書き込み要求に関連付けられたデータと合併する。
Ｓ：ブリッジ４は、合併された応答データ（スヌープされたデータ−Ａ）を第２のプロトコルドメインＢに送る。
Ｔ：第２のプロトコルドメインＢは、受け取ったスヌープデータを使用して読み取り要求Ｒｄ−Ａをサービスする。元のデッドロックを生じさせた書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａ、または同一対象アドレスを指定する任意の介入書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａをもはや実行する必要はない。何故ならば、これらの要求に関連付けられた書き込みデータはスヌープデータと合併されたからである。

図９はデッドロックが解決される前に２つの早期書き込み応答Ｂ−Ａのみが必要とされる例を示すが、他の機会においては、第１のプロトコルドメインＡは、デッドロックを生じさせた書き込み要求と同一の対象アドレスを対象とするさらなる書き込み要求を繰り返し発行し得る（すなわち、図９の事例Ｍは数回連続して生じる）ことが認識されるであろう。この事例では、ブリッジ４は同一アドレス（文字Ｎ）に関して各新規書き込み要求を直前書き込み要求と合併することを継続し、結果的に第１のプロトコルドメインＡが異なるアドレス（事例Ｐ）を対象とする書き込み要求を発行するか、スヌープ要求（事例Ｑ）を処理するまで、早期書き込み応答（文字Ｏ）を発行するであろう。

また、図９の例においては、文字Ｐにおける対象アドレスＥに関する書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ｅの発行は、文字Ｈにおける対象アドレスＥに関して発行されたスヌープ要求Ｓｎｐ−Ｅをサービスすることを阻止する。この故に、別のデッドロック条件がアドレスＥに関して検出され、従って、アドレスＡに関する、図９ に示されると同一の動作もアドレスＥに関して使用されるであろう。デッドロック条件が２つ以上のアドレスに関して検出された場合、ブリッジ４は一度に１つデッドロックを解決し得るが、スヌープ待ち行列１０の先頭にあるスヌープ要求と関連付けられたデッドロックから開始する。これは、いくつかのプロトコルにおいては、スヌープ待ち行列１０における最も古い選択の阻止は、その後のスヌープ要求も阻止されることを生じ得るからである。そのように状況では、ブリッジ４はスヌープ待ち行列の先頭におけるスヌープについて同定されたデッドロック条件の解決に焦点を合わせ得る。この故に、後のスヌープの状態およびそれらの後のスヌープに関してデッドロックがあるかどうかに関わらず、ブリッジ４はスヌープ待ち行列１０の先頭におけるスヌープに関するデッドロックを検出可能であり、デッドロックが最も古いスヌープ要求に関して検出された場合にのみ早期書き込み応答を発行する。

図６Ａおよび６Ｂに示される例とは異なり、図９は選択された要求が未解決書き込み要求であるように事前決定される例を示し、したがって、早期応答が、未解決書き込み要求および未解決スヌープ要求のどちらが最初にブリッジ４に到着するかに関わらず、未解決書き込み要求に応答して第１のプロトコルドメインに対して発行される。

図９は、デッドロック条件は第２のプロトコルドメインＢによって同定され、ブリッジ４はブリッジ４によって発行される取り消し信号Ｃａｎｃｅｌ−Ａに応答してデッドロック条件を検出する例を示す。しかしながら別の実施形態では、ブリッジ４はデッドロック条件それ自体を検出し、第２のプロトコルドメインＢからの信号を受け取らずに、デッドロック条件の検出時に書き込み要求ＷｒｉｔｅＣｌｅａｎ−Ａを取り消す。ブリッジ４は、次に信号を第２のプロトコルドメインＢに対して発行し得、書き込みが取り消されることを示す。

図１０は、図９の例に従う、デッドロック条件の検出および解決方法を示す。ステップ５０において、デッドロック条件が対象アドレスＸを対象とする書き込み要求および同一対象アドレスＸを対象とするスヌープ要求に関してデッドロック条件が検出されるが、書き込みは第１のプロトコルドメインＡから第２のプロトコルドメインＢに対して発行され、スヌープは第２のプロトコルドメインＢから第１のプロトコルドメインＡに対して発行される。デッドロック条件は、プロトコルドメインＡ、Ｂのいずれかからの信号に応答して、ブリッジ４によって直接またはブリッジ４によって間接的に検出され得る。

デッドロック条件が検出された場合、ステップ６０において、対象アドレスＸに関する書き込みはブリッジ４によって取り消される。また、ステップ７０において、対象アドレスＸに関する書き込み要求に対する早期書き込み応答がプロトコルドメインＡに対して発行される。

ステップ８０において、ブリッジ４は対象アドレスＸに関するスヌープ応答が受け取られたかどうかを判定する。受け取られなかった場合には、ステップ９０において、ブリッジは別の書き込み要求が第１のプロトコルドメインＡから受け取られたかどうかを判定する。別の書き込み要求が受け取られた場合には、ステップ１００において、ブリッジ４は他の書き込み要求に関する対象アドレスが、デッドロックが検出された対象アドレスＸと同一であるかどうかを判定する。対象アドレスがアドレスＸと同一でない場合、あるいは、ステップ９０において書き込みが受け取られていなかった場合は、ブリッジ４はステップ８０においてスヌープ応答の待ちを続ける。

しかしながら、ステップ１００において、他の書き込み要求に関する対象アドレスが、デッドロックが検出された対象アドレスＸと同一であると判定された場合には、ステップ１１０において、ブリッジ４は他の書き込み要求を対象アドレスＸに関する未解決書き込み要求と合併し、バッファがすでに一杯であっても、新規書き込みはバッファ内に受入れられる。ステップ１２０において、ブリッジ４は別の早期書き込み応答を対象アドレスＸに関する新規書き込み要求に対して発行し、書き込み要求がサービスされたことを第１のプロトコルドメインＡに示す（たとえそれが第２のプロトコルドメインＢにおいて実際にはサービスされなかった場合でも）。方法は今やステップ８０に戻り、ブリッジは再び第１のプロトコルドメインＡからのスヌープ応答を待つ。同一対象アドレスＸに関する新規要求が受け取られる毎に（ステップ９０および１００）、新規要求は、同一アドレスを対象とするより早い書き込み要求と合併され、そして早期書き込み応答が再び送られる（ステップ１１０ および１２０）。

ステップ１００において、他の書き込み要求が未解決書き込み要求と同一の対象アドレスＸを指定しないことが発見された場合には、未解決スヌープ要求と同一アドレスを対象とする未解決書き込み要求がもはや存在しないので、デッドロックは破られる。それ故、第１のプロトコルドメインＡは今やスヌープ要求を処理し得る。

スヌープ応答がステップ８０において受け取られると、ステップ１３０において、ブリッジ４はスヌープ応答で受け取られたスヌープデータを、対象アドレスＸに関する未解決書き込み要求に関するバッファリングされた書き込みデータと合併する。ステップ１４０において、合併されたデータは第２のプロトコルドメインＢに送られる。ステップ１５０において、未解決書き込み要求に関するバッファ配分が他の要求による使用のために解放される。

特定の実施形態が本明細書中で記述されてきたが、本発明はそれに限定されず、またそれに対する多くの修正および追加が本発明の範囲内においてなされ得ることが認識されるであろう。例えば、本発明の範囲から逸脱することなく、以下の従属請求項の特徴と独立請求項の特徴との様々な組み合わせがなされることが可能である。

Claims (20)

1. データ処理装置であって、
   第１のプロトコルドメインおよび第２のプロトコルドメインであって、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行し、そしてスヌープ対象アドレスと関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るように構成された少なくとも１つのデバイスをそれぞれが備える、第１のプロトコルドメインおよび第２のプロトコルドメインと、
   前記第１のプロトコルドメインと前記第２のプロトコルドメインとの間で前記書き込み要求および前記スヌープ要求を転送するように構成されたブリッジと、を備え、
   前記第１のプロトコルドメインが書き込み進行プロトコルの下で動作するように構成され、前記書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止され、
   前記第２のプロトコルドメインがスヌープ進行プロトコルの下で動作するように構成され、前記スヌープ進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は、前記未解決スヌープ要求がサービスされるまで阻止され、
   前記ブリッジは、前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求に関する前記書き込み対象アドレスが、前記第２のプロトコルドメインから前記第１のプロトコルドメインへと発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するように構成され、
   前記ブリッジは、前記デッドロック条件の検出時に、選択された要求がサービスされるのを待つことなく、前記選択された要求に対して早期応答を発行するように構成され、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期応答は、前記選択された要求がサービスされたことを、前記選択された要求を発行した発行プロトコルドメインに対して示す、データ処理装置。
2. 前記書き込み要求は書き戻し要求を含み、書き戻し要求を発行する前記デバイスは、前記ローカルバージョンを前記別の場所に書き込んだ後に、前記書き込み対象アドレスと関連付けられた前記データの前記ローカルバージョンを無効化するように構成される、請求項１に記載のデータ処理装置。
3. 前記書き込み要求は書き込みクリーン要求を含み、書き込みクリーン要求を発行する前記デバイスは、前記データの前記ローカルバージョンを前記別の場所に書き込んだ後、前記書き込み対象アドレスに関連付けられた前記データへの排他的アクセスを維持することを許可される、請求項１および２のいずれかに記載のデータ処理装置。
4. 前記ブリッジは、前記選択された要求に対して前記早期応答を発行した後、前記発行プロトコルドメインが、前記早期応答が発行された前記選択された要求と同一の対象アドレスに関する別の選択された要求を発行したかどうかを検出し、そうであれば、前記発行プロトコルドメインに対し、前記別の選択された要求に対する早期応答を発行するように構成される、請求項１〜３のいずれかに記載のデータ処理装置。
5. 前記発行プロトコルドメインは、前記同一対象アドレスを対象とする最大Ｍ個の連続した選択された要求を発行するように構成され、Ｍが整数である、請求項４に記載のデータ処理装置。
6. 前記選択された要求が前記第１のプロトコルドメインによって発行された前記未解決書き込み要求である場合には、前記未解決書き込み要求に対する前記早期応答を発行した後、前記第１のプロトコルドメインから前記未解決スヌープ要求に対するスヌープ応答を受け取ると、前記ブリッジは、前記スヌープ応答に関連付けられたスヌープデータを前記未解決書き込み要求に関連付けられた書き込みデータと合併し、前記合併データを前記第２のプロトコルドメインに送信するように構成される、請求項１〜５のいずれかに記載のデータ処理装置。
7. 前記選択された要求は、前記ブリッジによって最後に検出された前記未解決書き込み要求および前記未解決スヌープ要求のうちの１つを含む、請求項１〜６のいずれかに記載のデータ処理装置。
8. 前記選択された要求は、前記未解決書き込み要求および前記未解決スヌープ要求のうちの事前決定された１つを含む、請求項１〜６のいずれかに記載のデータ処理装置。
9. 前記第１および第２のプロトコルドメインのうちの１つは、前記デッドロック条件を検出し、前記デッドロック条件が検出された場合には、前記ブリッジに対して信号を発行するように構成され、前記ブリッジは前記信号の受け取りに応答して前記デッドロック条件を検出するように構成される、請求項１〜８のいずれかに記載のデータ処理装置。
10. 前記ブリッジは、前記第２のプロトコルドメインから前記第１のプロトコルドメインへ発行された未解決スヌープ要求を待ち行列に入れるためのスヌープ待ち行列を維持するように構成される、請求項１〜の９いずれかに記載のデータ処理装置。
11. 前記スヌープ待ち行列が複数の未解決スヌープ要求を含む場合には、前記ブリッジは、デッドロック条件が前記スヌープ待ち行列内の最も古い未処理スヌープ要求に関して検出されたときにのみ、前記選択された要求に対する前記早期応答を発行するように構成される、請求項１０に記載のデータ処理装置。
12. 前記ブリッジは、前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求をバッファリングするように構成された書き込みバッファを備える、請求項１〜１１のいずれかに記載のデータ処理装置。
13. 前記書き込みバッファ内でバッファリングされる未解決書き込み要求と同一の対象書き込みアドレスを有する前記第１のプロトコルドメインからさらなる書き込み要求を受け取ると、前記ブリッジは前記さらなる書き込み要求を前記未解決書き込み要求と合併するように構成される、請求項１２に記載のデータ処理装置。
14. 前記書き込みバッファは、前記未解決スヌープ要求に対するスヌープ応答が前記第１のプロトコルドメインから受け取られるまで、前記デッドロック条件が検出された前記未解決書き込み要求を保有するように構成される、請求項１２および１３のいずれかに記載のデータ処理装置。
15. 前記第１のプロトコルドメインは、最大Ｎ個の整数の未解決書き込み要求を取り扱うように構成され、前記書き込みバッファは前記第１のプロトコルドメインから発行された少なくともＮ個の未解決書き込み要求をバッファリングするための容量を有し、Ｎが整数である、請求項１２〜１４のいずれかに記載のデータ処理装置。
16. 前記ブリッジと前記第１のプロトコルドメインとの間に連結される書き込みステージングバッファを備え、前記書き込みステージングバッファは前記第１のプロトコルドメインによって発行された書き込み要求を受け取り、前記書き込みバッファ内に前記書き込み要求をバッファリングするためのスペースがある場合には、前記書き込み要求を前記ブリッジに渡すように構成される、請求項１２〜１５のいずれかに記載のデータ処理装置。
17. 前記選択された要求が、前記デッドロック条件が検出された前記未解決書き込み要求であり、そして前記ブリッジが、前記未解決書き込み要求に対する前記早期応答の発行時に前記未解決書き込み要求を取り消すように構成される、請求項１〜１６のいずれかに記載のデータ処理装置。
18. 前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求をバッファリングするように構成された書き込みバッファを備え、前記書き込みバッファは、前記未解決スヌープ要求に対するスヌープ応答が前記第１のプロトコルドメインから受け取られるまで、前記取り消された未解決書き込み要求を保有するように構成される、請求項１７に記載のデータ処理装置。
19. データ処理装置であって、
    データ処理を実施するための第１のプロトコルドメイン手段および第２のプロトコルドメイン手段であって、それぞれが、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行するための、そしてスヌープ対象アドレスと関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るための、少なくとも１つのデバイス手段を備える、第１のプロトコルドメイン手段および第２のプロトコルドメイン手段と、
    前記書き込み要求および前記スヌープ要求を、前記第１のプロトコルドメイン手段と前記第２のプロトコルドメイン手段との間で転送するためのブリッジ手段と、を備え、
    前記第１のプロトコルドメイン手段は書き込み進行プロトコルの下で動作するように構成され、前記書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止され、
    前記第２のプロトコルドメイン手段は、スヌープ進行プロトコルの下で動作するように構成され、前記スヌープ進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は前記未解決スヌープ要求がサービスされるまで阻止され、
    前記ブリッジ手段は、前記第１のプロトコルドメイン手段から前記第２のプロトコルドメイン手段へ発行された未解決書き込み要求に関する前記書き込み対象アドレスが、前記第２のプロトコルドメイン手段から前記第１のプロトコルドメイン手段へ発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するように構成され、
    前記ブリッジ手段は、前記デッドロック条件の検出時、選択された要求が処理されるのを待つことなく、前記選択された要求に対する早期応答を発行するように構成され、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期応答は、前記選択された要求を発行した発行プロトコルドメインに対し、前記選択された要求がサービスされたことを示す、データ処理装置。
20. 第１のプロトコルドメインおよび第２のプロトコルドメインを備え、それぞれが、書き込み対象アドレスと関連付けられたデータのローカルバージョンが別の場所に書き込まれることを要求するための書き込み要求を発行し、そしてスヌープ対象アドレスに関連付けられたデータのローカルバージョンへのアクセスを要求するためのスヌープ要求を受け取るように構成された少なくとも１つのデバイスを備える装置のための方法であって、前記第１のプロトコルドメインは書き込み進行プロトコルの下で動作し、前記書き込み進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決スヌープ要求は、前記未解決書き込み要求がサービスされるまで阻止され、前記第２のプロトコルドメインはスヌープ進行プロトコルの下で動作し、前記スヌープ進行プロトコルの下で、未解決書き込み要求に関する前記書き込み対象アドレスが未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である場合には、前記未解決書き込み要求は前記未解決スヌープ要求がサービスされるまで阻止され、
    前記方法は、
    前記第１のプロトコルドメインから前記第２のプロトコルドメインへ発行された未解決書き込み要求に関する前記書き込み対象アドレスが、前記第２のプロトコルドメインから前記第１のプロトコルドメインへ発行された未解決スヌープ要求に関する前記スヌープ対象アドレスと同一である、デッドロック条件を検出するステップと、
    前記デッドロック条件の検出時に、選択された要求が処理されるのを待つことなく、前記選択された要求に対する早期応答を発行するステップであって、前記選択された要求は前記未解決書き込み要求または前記未解決スヌープ要求を含み、前記早期応答は、前記選択された要求を発行した発行プロトコルドメインに対し、前記選択された要求がサービスされたことを示す、ステップと、
    を含む、方法。