これは逐次一貫性よりも若干弱いものです。書き込みの後に読み込みが続く場合は、それが期待通りの順序で見えることは保証されません。以下の例を考えてみてください。相互排他のためのデッカーのアルゴリズムの一部です。処理中であることを示すというものです。セットされているか調べます。クリティカルセクションへの排他アクセスを得たと安全に仮定できます。同様のことを行います。公平性を保証するためのターン取得アルゴリズムが使われます。)逐次一貫性のあるマシンでは、これは正しく動作します。異なる順序で「見える」場合があります。それが起きた場合は、実際には以下の順序で実行されたように見えます。両方のスレッドが同時にクリティカルセクションを実行してしまいます。キャッシュについて少し知る必要があります。キャッシュの動作これはこれ自体で結構大きな話題です。以下で述べるのは非常に大雑把な要約です。システムがそのように動作するのかを理解してもらうことです。それ以上のキャッシュがあります。「遠い」ことを表します。キャッシュメモリはハードウェアのサイズとコストを増加させ、また消費電力も増加させます。はまったく無いか、あってもわずかなものです。キャッシュへの値の読み書きは非常に高速です。可能な限りキャッシュを使い倒そうとします。領域を使い切っていずれかのエントリを空ける必要が生じるまで待ちます。その書き込み命令を超えて次の命令の実行を続けます。その書き込みがメインメモリ上で見えるまでの間に数十もの命令を実行することもあるでしょう。書き込みが終わるまで待つわけではありません。そのキャッシュの動作がこの議論に関連してきます。単純なモデルでは、それらのキャッシュは、お互いに直接通信する手段はありません。キャッシュと共有しておらず、見ることができません。メインメモリへの読み書きだけが共有の手段です。メモリアクセスのレイテンシは長いため、スレッド間の通信は非常に低速です。そのため、キャッシュ間にデータを共有する手段を設けると、役に立ちます。よってそのルールが定義されます。これを頭に置いて、デッカーの例に戻りましょう。キャッシュにその値が書き込まれます。キャッシュから読み込まれます。キャッシュにある可能性があります。書き込んだ値は見えません。書き込みを他のコアに伝える必要があります)。これでは、あらゆる書き込み操作に、性能上のペナルティーを課すことになってしまいます。書き込みの後に読み込みが続く場合の順序について、ルールをいくらか緩めれば、性能を上げられます。ソフトウェア開発者には負担がかかります。それらは比較的低コストなものです。その書き込みが行われたのと同じ順序でそれを他のコアに公開するだけで済みます。次の書き込みの開始を待つ必要はありません。最初の公開が完了する前に次の公開が完了しなければいいだけです。これにより性能上の障害を回避できます。プログラマの期待通りにコードが動作しない機会もさらに増えます。キャッシュは個々のバイト単位で動作するわけではありません。単位で読み書きされます。メインメモリのある場所からデータを読み込むと、その付近にあるデータも同様に読み込まれます。データを書き込むと、そのキャッシュラインがメモリから読み込まれ、そして更新されます。不思議な現象が起きるわけです。先へ進む前に、読み書きが「見える」の意味をもう少し厳密に定義した方がいいかもしれません。