コンパイラはなぜ連続するアトミック書き込みをマージしないのでしょうか?

冗長アトミック書き込みの最適化

なぜコンパイラは単一のアトミック変数への同じ値の連続書き込みをマージしないのですか?この問題を詳しく調べて、根本的な理由を明らかにしましょう。

「As-If」ルール

C 標準によれば、コンパイラは複数のアトミック書き込みを結合することが許可されています。単一の操作にまとめられます。これらの書き込みに異なる値が含まれる場合でも、結果として生じる動作は「as-if」ルールに従うことが許可されます。このルールは、最適化されたコードの実行が元の一連の書き込みと同じ観察可能な効果をもたらすことを意味します。

コンパイラーの動作とハードウェア制約

理論的には可能であるにもかかわらず, コンパイラは通常、実際にはこの最適化を実行しません。この主な理由は、実際のハードウェアをターゲットとする場合のパフォーマンスと動作への望ましくない影響を避けるためです。

進行状況バーとその他の例

進行状況バーの例を考えてみましょう。 1 つの操作に対する複数のアトミック書き込みを最適化すると、進行状況バーが 0 に留まり、その後突然 100% に跳ね上がる状況が発生し、ユーザーを誤解させる可能性があります。このような最適化が問題となる他のシナリオには、ループ内での無駄なshared_ptr参照カウントの増加と減少の回避が含まれます。

最小驚きの原則

プログラマはアトミック書き込みが次のように現れることを期待しています。すべてのソースストア操作用のメモリ。複数の書き込みを結合すると、この期待に反し、潜在的な混乱や誤った動作が発生します。

実装の品質の問題

コンパイラーは、いつアトミックを最適化しても安全かを判断するのが困難です。順序付けルールに違反せず、他の側面に影響を与えることなく書き込みます。 Program.

将来の最適化と API 拡張

std::atomic API を拡張し、プログラマーが最適化をより細かく制御できるようにするための議論が C ワーキング グループ内で進行中です。これにより、コンパイラは、プログラム動作の整合性と明確性を確保しながら、必要に応じて最適化を実行できるようになります。

それまでの間、volatile atomic<> を使用します。または、shared_ptr_unsynchronized<> などの代替実装を検討すると、望ましくない最適化効果を回避できます。

以上がコンパイラはなぜ連続するアトミック書き込みをマージしないのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。