質問の歴史。 C++20以前は、既存の非原子的オブジェクトに原子的操作を適用するには面倒な方法が必要でした。なぜなら、std::atomicはオブジェクトが最初から原子的に構築されることを強制するからです。プログラマは、単純なオブジェクトを原子として扱うために危険なreinterpret_cast操作を試みることが多く、厳密なエイリアシングルールに違反し、オブジェクトのライフタイムの不一致から未定義の動作を引き起こしていました。C++20でのstd::atomic_refの導入により、このギャップが解消され、ストレージタイプやライフタイムを変更することなく、既存のオブジェクトに一時的に原子的セマンティクスを与える非所有ビューが提供されました。
問題。 std::atomicは、ロックフリーのビットフラグや内部ミューテックスなど、特定の表現要件を課します。これにより、通常、オブジェクトのサイズやアラインメントが基になるタイプTと比較して変更されます。したがって、タイプintのオブジェクトは**std::atomic<int>とレイアウト互換性がなく、ポインタのパニングが不可能になります。さらに、std::atomic_refは参照されるオブジェクトが厳しいアラインメント制約を満たす必要があり、具体的にはオブジェクトのアドレスが少なくともalignof(std::atomic_ref<T>)に整列されている必要があります。これが多くのプラットフォームでalignof(T)**と等しいが、ハードウェア固有の原子的命令にはより大きい場合があります。このアラインメント前提条件に違反すると、未定義の動作が発生し、厳密なアーキテクチャ（例：ARM）上でトルンリードやハードウェア例外を引き起こす可能性があります。
解決策。 std::atomic_refは、ターゲットオブジェクトへのポインタを保持する軽量ラッパーとして機能し、コンパイラのイントリンシックやハードウェアの命令を適用して、ストレージがstd::atomicインスタンスであることを想定せずに原子性を強制します。操作の期間中、std::atomicと同じメモリ順序保証を提供しながら、既存のオブジェクトのライフタイムを尊重します。安全に使用するために、開発者はオブジェクトが適切に整列されていることを確認する必要があります。通常は、alignas指定子を使用するか、std::atomic_ref<T>::required_alignmentが満たされているか確認することにより、ロックフリーのコンカレントアクセスをレガシーデータ構造やC互換レイアウトに可能にします。
#include <atomic> #include <cstdint> #include <iostream> struct alignas(alignof(std::atomic_ref<std::uint64_t>)) Data { std::uint64_t value; }; int main() { Data d{42}; std::atomic_ref<std::uint64_t> ref(d.value); ref.fetch_add(8, std::memory_order_relaxed); std::cout << d.value << " "; // 出力: 50 }
問題の説明。 高頻度取引アプリケーションで、レガシーC構造体がマーケットフィードパケットのレイアウトを定義し、ネットワークスレッドからの原子的な更新が必要なdouble価格フィールドを含んでいました。取引所は正確なバイナリ互換性を要求し、構造体を**std::atomic<double>**を使用するように変更することを防ぎ、レイテンシ要件はミューテックスロックやメモリコピーを禁止しました。私たちは、専門的な更新時に部分的な書き込みが原因で、戦略スレッドが高ボラティリティスパイク中に壊れた「ゴースト」値を読み取るというデータレースに直面しました。
考慮された異なる解決策。 最初のアプローチは、std::atomic<bool>フラグを使用してダブルバッファリングを行い、構造体の2つのコピーを保持し、ポインタを原子的に切り替えるものでした。ロックフリーでしたが、メモリ消費が2倍になり、NUMAノード間でキャッシュラインバウンシングが発生し、マイクロベンチマークで約15％パフォーマンスが低下しました。二番目のアプローチは、ローカルstd::atomic<double>変数にstd::memcpyを考慮しましたが、追加のコピーのためにリアルタイム制約に違反し、また、更新中にメモリコピーが発生した場合はトルンリードの問題が残りました。三番目の解決策は、std::atomic_refを使用してC構造体内の価格フィールドに直接参照を持ち、構造体のレイアウトを変更することなくハードウェアのCAS（Compare-And-Swap）命令を利用しました。
どの解決策が選ばれ、なぜか。 私たちはstd::atomic_refを選びました。なぜなら、それは真のゼロオーバーヘッドの抽象化を提供したからです: x86-64で生成されたアセンブリは手書きのlock cmpxchg命令と同一で、追加の割り当てや間接参照はありませんでした。ダブルバッファリングアプローチとは異なり、ホットデータの単一キャッシュラインの在留を維持し、マイクロ秒単位のレイテンシに重要なL1キャッシュのローカリティを維持しました。重要なことに、外部CライブラリのABI制約を尊重し、ハードウェアで強制された原子性によりデータレースを排除しました。
結果。 実装後、システムはサブマイクロ秒のレイテンシで一貫したロックフリーの更新を達成し、ThreadSanitizerの実行を通じて確認されたゴースト値の異常を排除しました。アラインメントの検証（alignas）により、コードの変更なしにARM64サーバーへの移植性が保証され、キャッシュ圧力が軽減されたため、ダブルバッファリングのベースラインと比較してスループットが12％向上しました。
なぜ非原子的ポインタをstd::atomic<T>*にキャストすると未定義の動作を引き起こし、std::atomic_refが安全であるのか？
reinterpret_castによるキャストは、std::atomic<T>タイプのオブジェクトへのポインタを作成しますが、ストレージには実際にはTタイプのオブジェクトが含まれています。これは、**C++**オブジェクトモデルの厳格なエイリアシングルールとライフタイム要件に違反します。なぜなら、std::atomic<T>は、Tとは異なるサイズ、アラインメント、または内部状態（スピンロックなど）を持つ可能性があるからです。std::atomic_refは明示的にTオブジェクトを参照する別個のリファレンスタイプとして設計されており、ストレージが異なるタイプであるふりをせずに、実装特有のインストリンシックを通じてその上で原子的操作を適用するため、元のオブジェクトのライフタイムとレイアウトを保持します。
は、std::atomic_refは参照しているオブジェクトの構築と同期しますか？
いいえ。std::atomic_refは、これを通じて実行される操作に対して原子性を提供しますが、参照されるオブジェクトのコンストラクタとの間に発生前の関係を確立しません。もしスレッドAがオブジェクトを構築し、スレッドBがそれに即座にstd::atomic_refを作成した場合、スレッドBはスレッドAがリリース操作（例：std::atomic<bool>へのストレージ）を行い、スレッドBがatomic_refにアクセスする前に取得操作を行わない限り、初期化されていないメモリを見ることがあります。atomic_refは、オブジェクトがすでに生存していてアクセス可能であることを想定していますが、構築中の並行非原子的書き込みは外部の同期なしにはデータレースのままとなります。
constオブジェクトでstd::atomic_refを使用できるか、制限は何ですか？**
はい、std::atomic_ref<const T>は有効で、constとして宣言されたオブジェクトに対して原子的な読み取り操作（loadなど）を行うことを許可します。ただし、オブジェクトがコンパイラの最適化によりレジスタに値をキャッシュできるようにconstとして最初から宣言されていない限りです。しかし、const T&からstd::atomic_ref<T>（非const）を構築することはできません。これは、constの正当性を侵害するためです。また、atomic_ref<const T>を使用する場合でも、基になるオブジェクトは読み取り専用メモリ（例：.rodataセクション）にあってはならず、ハードウェア原子的命令は読み取り操作でも書き込み可能なキャッシュラインを必要とするためです。