私はプログラムを設計していますが、暗黙的なキャッシュの一貫性を仮定すると、設計がはるかに簡単になることがわかりました。たとえば、単一のライター (常に同じスレッド) 複数のリーダー (常に他のスレッド) のシナリオでは、ミューテックスを使用していません。
現在の Intel CPU では問題ありません。しかし、私はこのプログラムが少なくとも今後 10 年間 (ソフトウェアにとっては短い期間) 収入を生み出すことを望んでいるので、これが将来の CPU アーキテクチャにとって問題になる可能性があると思いますか?
私たちはすでにそこにいます。コンピューターはキャッシュの一貫性を主張しますが、同時に書き込み用の一時的なストア バッファーを持ち、キャッシュの代わりにこのバッファーを介して読み取りを完了することができます (つまり、ストア バッファーは一貫性のないキャッシュになりました)。無効化要求もキューに入れられ、プロセッサ古くなったことがわかっているキャッシュラインを一時的に使用します。
X86 では、これらの手法の多くは使用されませんが、一部は使用されます。メモリが CPU よりも大幅に遅いままである限り、これらの手法や、まだ考案された他の手法が使用されることが予想されます。そのまま失敗した Itanium でさえ、これらのアイデアの多くを使用しているため、Intel が時間の経過とともにそれらを x86 に移行することを期待してください。
ロックの回避などに関しては、インターネットに関する人々の専門知識のレベルを判断するのは常に難しいため、機能すると思われるものに誤った方向に進んでいるか、ロックフリープログラミングの最先端にいる. わかりにくい。
MESI プロトコル、メモリバリア、および可視性を理解していますか? ポール・マッケニーなどの記事を読みましたか?
将来の CPU 世代でも、キャッシュの一貫性を処理できると思います。これがなければ、ほとんどの主流のプログラミング方法論は失敗します。今後 10 年間に広く使用される CPU アーキテクチャが、現在のプログラミング モデルを無効にすることはないと思います。拡張することはできますが、広く想定されているものを削除することは困難です。
そうは言っても、暗黙的なキャッシュの一貫性を前提としたプログラミングは、必ずしも良い考えではありません。誤った共有には、意図的にデータを分離しようとすれば簡単に回避できる多くの問題があります。これを適切に処理すると、現在の世代の CPU でパフォーマンスが大幅に向上します (むしろ、パフォーマンスが大幅に低下することはありません)。確かに、それは設計の作業が増えますが、多くの場合必要になります。
それ自体はわかりません。しかし、非キャッシュ コヒーレント モードへの傾向を見たいと思います。
概念的なマインド シフトは重要です (メソッド呼び出しでデータを渡すだけではなく、キューを介して非同期メソッドに渡す必要があります) が、とにかくマルチコアの世界にますます移行するにつれて必要になります。メモリ バンクごとに 1 つのプロセッサに近づくほど、より良い結果が得られます。ネットワーク メッセージ ルーティングの世界で作業しているため、静かにデータを処理できるスレッドではなく、データを利用できないためです。
ただし、Reed Copsey が指摘しているように、x86 コンピューティングの世界全体は、キャッシュの一貫性 (Microsoft の市場シェアよりもさらに大きい) を前提として構築されています。だから、すぐには消えません！
これは、コンピュータ アーキテクチャ分野の著名な著者による論文で、キャッシュの一貫性は今後も維持されると主張しています。
http://acg.cis.upenn.edu/papers/cacm12_why_coherence.pdf
「オンチップ キャッシュ コヒーレンスが定着する理由」 - Martin、Hill、Sorin 共著
あなたは奇妙な要求をしています。あなたは、将来の CPU アーキテクチャに関する私たち(SO コミュニティ) の仮定を求めています。これは非常に危険な提案です。私たちの口にあなたのお金を入れても構わないと思いますか? 私たちが間違っていて、あなたのアプリケーションが失敗した場合、それはあなたがお金を稼いでいないことになるからです..
いずれにせよ、シングル スレッド実行用に記述されたすべてのレガシー コードのため、物事がそれほど劇的に変化することはないと思いますが、それは単なる私の意見です。
その質問は私には誤解を招くようです。CPU アーキテクチャはそれほど重要ではありません。重要なのは、使用しているプラットフォームのメモリ モデルです。
アプリケーションを開発しているのは、いくつかの定義されたメモリモデルを備えた環境です。たとえば、現在 x86 をターゲットにしている場合、x86 コードを実行しているときに、将来のプラットフォームが同じメモリ モデルを実装することはほぼ間違いありません。同じことが、Java または .NET VM およびその他の実行プラットフォームにも当てはまります。
現在のアプリケーションを他のプラットフォームに移植する予定がある場合、プラットフォームのメモリ モデルが異なる場合は、それに合わせて調整する必要があります。やれ。ただし、これは現在のプラットフォームでも当てはまります。たとえば、PowerPC メモリ モデルでは、x86 メモリ モデルよりもはるかに多くの並べ替えが可能です。