本質的にアトミックであるatomic<bool>
ため、冗長ではありませんか?bool
bool 値を部分的に変更することはできないと思います。atomic<bool>
の代わりにいつ使用する必要がありbool
ますか?
6 に答える
C++ の型は、std::atomic*
-somethingでない限り、「本質的にアトミック」ではありません。それは、基準がそう言っているからです。
実際には、 を操作するために発行される実際のハードウェア命令はstd::atomic<bool>
、通常の の場合と同じかもしれません (または同じでないかもしれません) が、bool
アトミックであることは、より広い影響 (コンパイラの並べ替えに関する制限など) を伴うより大きな概念です。さらに、一部の操作 (否定など) がアトミック操作でオーバーロードされ、非アトミック変数のネイティブの非アトミック読み取り-変更-書き込みシーケンスとは明らかに異なる命令がハードウェア上に作成されます。
C++ のアトミック型は、3 つの潜在的な問題に対処します。まず、操作に複数のバス操作が必要な場合、読み取りまたは書き込みがタスク スイッチによって中断される可能性があります (実装方法によっては、 に発生する可能bool
性があります)。第 2 に、読み取りまたは書き込みは、操作を実行しているプロセッサに関連付けられたキャッシュのみに影響し、他のプロセッサのキャッシュには異なる値が含まれている可能性があります。第 3 に、結果に影響を与えない場合、コンパイラは操作の順序を並べ替えることができます (制約はもう少し複雑ですが、今のところはこれで十分です)。
You can deal with each of these three problems on your own by making assumptions about how the types you are using are implemented, by explicitly flushing caches, and by using compiler-specific options to prevent reordering (and, no, volatile
doesn't do this unless your compiler documentation says it does).
But why go through all that? atomic
takes care of it for you, and probably does a better job than you can do on your own.
bool
アトミック オペレーションは単なる引き裂かれた値以上のものであるため、引き裂かれる可能性のある環境については認識していないというあなたや他の投稿者の意見には同意しますが、それ以上の問題があります。
ハーブ・サッターがこれについて素晴らしい講演を行いました。オンラインで見ることができます。長くて複雑な話なので注意してください。ハーブサッター、アトミックウェポン。この問題は、結果としてデータ競合を回避することに帰着します。
特定のタイプの原子性は、基盤となるハードウェアにのみ依存します。各プロセッサ アーキテクチャには、特定の操作の原子性に関する保証が異なります。例えば:
Intel486 プロセッサ (およびそれ以降の新しいプロセッサ) では、次の基本的なメモリ操作が常にアトミックに実行されることが保証されています。
- バイトの読み取りまたは書き込み
- 16 ビット境界に整列されたワードの読み取りまたは書き込み
- 32 ビット境界に整列されたダブルワードの読み取りまたは書き込み
他のアーキテクチャには、操作がアトミックであるという異なる仕様があります。
C++ は、基礎となるハードウェアからユーザーを抽象化しようとする高レベルのプログラミング言語です。このため、標準では、このような低レベルの仮定に依存することを許可することはできません。そうしないと、アプリケーションが移植できなくなります。したがって、C++ のすべてのプリミティブ型は、atomic
すぐに使用できる C++11 準拠の標準ライブラリによって対応する型で提供されます。