回答編集履歴
2
追記
test
CHANGED
@@ -35,3 +35,19 @@
|
|
35
35
|
|
36
36
|
|
37
37
|
問題の解決を誤った方法に求めると、より問題が深刻化します(あるいは潜在的な問題に気づけなくなります)。その手の制御は、最適化の有無などという不確かなもので行うのではなく、排他制御で行うのが普通です。buffer_readyとbufferへのアクセスのアトミック性を確保しさえすれば、メモリのアクセス順がどうなろうと問題にはなりません。
|
38
|
+
|
39
|
+
|
40
|
+
|
41
|
+
---
|
42
|
+
|
43
|
+
追記
|
44
|
+
|
45
|
+
|
46
|
+
|
47
|
+
私の経験的な見解としては、一般的なアプリを作る上ではvolatileはほとんど必要性を感じません。パフォーマンスのチューニングをしたいときに作る検証用コードで、最適化によって変数のアクセス回数が減って正しく計測できなくなるのは困る、というときに使う程度です。少なくとも、製品向けのプログラムでvolatileを使ったことはありません。
|
48
|
+
|
49
|
+
|
50
|
+
|
51
|
+
volatileの話題でマルチスレッドの話がよく出てきますが、同期目的で使えるのは、せいぜいフラグ変数程度でしょう。実際には、スレッド間/プロセス間の同期は、プラットフォームが提供する専用のAPIを使うのが最も確実です。製品を作る上では不確実な要素は排除しないといけませんから。
|
52
|
+
|
53
|
+
C++11でスレッドが導入されてからは、プラットフォーム依存のAPIを直接呼び出さなくても済むようになりましたね(標準ライブラリーにない便利な同期オブジェクトは直接API呼び出しすることになりますが)。
|
1
追記
test
CHANGED
@@ -21,3 +21,17 @@
|
|
21
21
|
`volatile`は探して見つけるようなものではありませんし、パターン化された規則によって付けるかどうかを決めるものでもありません。付けるかどうかは「設計上の必要性」に応じて決めます。
|
22
22
|
|
23
23
|
その変数がどのタイミングで誰がアクセスするかは、ちゃんと設計しているなら「当然把握している」はずなので、裏(別スレッドとか割り込みとか)で変更される可能性のあるもので、前述のような最適化をしてほしくない変数にには`volatile`を付けることになります。
|
24
|
+
|
25
|
+
|
26
|
+
|
27
|
+
---
|
28
|
+
|
29
|
+
一応、「_[ここから私の妄想]___________」について追記
|
30
|
+
|
31
|
+
|
32
|
+
|
33
|
+
> buffer_init()そのものを最適化抑止させる機能があると便利ではないでしょうか?
|
34
|
+
|
35
|
+
|
36
|
+
|
37
|
+
問題の解決を誤った方法に求めると、より問題が深刻化します(あるいは潜在的な問題に気づけなくなります)。その手の制御は、最適化の有無などという不確かなもので行うのではなく、排他制御で行うのが普通です。buffer_readyとbufferへのアクセスのアトミック性を確保しさえすれば、メモリのアクセス順がどうなろうと問題にはなりません。
|