ディレクトリベースのコヒーレンスは、分散共有メモリ(DSM)、別名非均一メモリアクセス(NUMA)におけるキャッシュコヒーレンスの問題を処理するメカニズムです。もう 1 つの一般的な方法は、すべてのノード間で「共有バス」(別名システムバス) として特殊なタイプのコンピュータバスを使用することです。[ 1 ]ディレクトリベースのコヒーレンスは、バスベースのコヒーレンス プロトコルの共有バスの代わりに、特別なディレクトリを使用します。これらの設計はどちらも、対応する媒体 (ディレクトリまたはバス) をツールとして使用して、異なるノード間の通信を容易にし、通信するすべてのノードでコヒーレンス プロトコルが正しく動作することを保証します。ディレクトリベースのキャッシュ コヒーレンスでは、このディレクトリを使用してすべてのキャッシュブロックの状態を追跡することでこれを実現します。各ブロックの状態には、そのブロックがどのキャッシュ コヒーレンス「状態」にあるか、その時点でどのノードがそのブロックを共有しているかが含まれます。これにより、すべての信号をすべてのノードにブロードキャストする必要がなくなり、この単一のブロックに関心のあるノードにのみ送信できます。
ディレクトリベースのキャッシュコヒーレンスプロトコルの利点と欠点をいくつか以下に示します。
上記の議論から、比較的小規模なシステムではバスベースのシステムを使用する方が魅力的であることがわかります。しかし、システムがスケールアップし、ノード数が増えると、ディレクトリベースのシステムが重要になります。したがって、バスベースとディレクトリベースのキャッシュコヒーレンス設計を比較すると、シンプルさとスケーラビリティの間にはトレードオフが存在します。[ 1 ]
ディレクトリベースのキャッシュコヒーレンス システムのアイデアは、ずっと昔に始まりました。DASH (Directory Architecture for Shared-Memory) のアイデアは、1970年代半ばにCK Tang [ 2 ] によって初めて提案されました。しかし、それをキャッシュコヒーレンスに適用することは、数年後の 1978 年にスタンフォード大学の研究者が、このコヒーレンスシステムの最初のバージョンであるStanford DASHを論文[ 3 ]で提案し、その論文では、このような設計に関連する困難と改善とともにシステムを説明しています。このアプローチの他に、スケーラブルなシステムを提供するためのいくつかの試みが行われました。たとえば、 1985 年に発表されたBBN Butterfly [ 4 ]や、1987 年に発表された IBM PR3 [ 5 ]は、スケーラブルなマルチプロセッサ システムの例です。ただし、これらのシステムにはどちらも欠点があります。たとえば、BBN Butterfly にはキャッシュがありません。同様に、IBM PR3 はハードウェア キャッシュ コヒーレンスを提供しないため、特に高性能プロセッサを使用する場合、これら両方の設計のパフォーマンスが制限されます。[ 6 ]
他の競合システムの制約により、キャッシュコヒーレンスシステムやキャッシュベースのノードでスケーラビリティを必要とする他のシステムを設計する際に、DASHベースのシステムが選ばれやすくなりました。1985年、ワシントン大学のJames Archibald [ 7 ]とJean-Loup Baerは、設計におけるハードウェア使用の観点から、「グローバルディレクトリ」アプローチのより経済的で拡張可能かつモジュール化されたバリエーションを提案する論文[ 8 ]を発表しました。
1992年、スタンフォード大学のダニエル・レノスキーは、ディレクトリベースのシステム向けキャッシュコヒーレンスプロトコルの進歩を提案する論文[ 9 ]を発表した。1996年の論文[ 10 ]では、ディレクトリベースのキャッシュコヒーレンスを採用したサーバコンピュータのファミリーであるSGI Origin 2000の設計を紹介した。その後継機種であるOrigin 3000 [ 11 ]は2000年7月に発表された。
スヌーピーコヒーレンスプロトコルとは異なり、ディレクトリベースのコヒーレンス方式では、どのキャッシュがブロックのコピーを持っているかという情報は、ディレクトリと呼ばれる構造で保持されます。ディレクトリベースの方式では、参加するキャッシュは、キャッシュされたコピーを見つけるために、ブロックを共有する他のすべてのキャッシュにリクエストをブロードキャストするのではなく、ディレクトリに問い合わせて、どのブロックがキャッシュされたコピーを持っているかという情報を取得し、それらの特定のプロセッサにのみ送信します。そのため、スヌーピープロトコルと比較してトラフィックが大幅に削減されます。最適化されたアプリケーションでは、ほとんどのデータ共有は読み取り専用のデータのみで行われ、頻繁に読み書きされるデータの共有はほとんどありません。このようなアプリケーションでは、ディレクトリ方式は、ブロードキャスト/スヌーピー方式と比較して、トラフィックを大幅に削減できます。

データフロー図に示すように、ディレクトリベースのコヒーレンスプロトコルを実装する分散共有メモリシステムに関与するアクターは次のとおりです。

リクエスターノードとオーナーノードは、 MESIプロトコルなどのスヌーピーコヒーレンスプロトコルと同様に、状態遷移を維持します。ただし、ノードが共通バスを使用して通信するバスベースの実装とは異なり、ディレクトリベースの実装では、キャッシュコヒーレンスを維持するために必要な情報を交換するためにメッセージパッシングモデルを使用します。
ディレクトリノードはシリアル化ポイントとして機能し、すべての通信はこのノードを経由して行われることで、データの正確性が維持されます。
ディレクトリノードは、すべてのプロセッサのキャッシュシステム全体におけるキャッシュブロックの全体的な状態を追跡します。ディレクトリノードは、次の3つの状態をとることができます 。
ディレクトリ状態遷移有限状態機械の説明(図1参照)を以下の表にまとめました。
キャッシュの状態に加えて、ディレクトリは共有状態にあるときにどのプロセッサがデータを持っているかを追跡する必要があります。これは、共有状態のキャッシュブロックを持つ個々のプロセッサキャッシュに無効化要求と介入要求を送信するために必要です。一般的な実装方法には次のようなものがあります。
上記で説明したプロトコルは基本的な実装であり、ディレクトリとキャッシュの同期がずれたり、プロセッサ間のメッセージが重複したりする可能性があるため、競合状態が発生する可能性があります。複数の状態を持つスケーラブルコヒーレントインターフェース( SCI)など、より複雑な実装も利用可能です。
DASH [ 3 ]キャッシュコヒーレンスプロトコルは、ディレクトリベースのコヒーレンス方式を使用する別のプロトコルです。DASH プロトコルはクラスタ方式を採用しており、クラスタ内のプロセッサはバスベースのスヌーピング方式を使用してコヒーレントに保たれ、クラスタはディレクトリ方式で接続されます。さまざまなプロトコルがキャッシュブロックの追跡に異なる実装を使用していますが、ディレクトリの概念は同じです。