[過去ﾛｸﾞ] マルチスレッドプログラミング相談室 その３ (978ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
351(8): 339 05/02/09 21:57 AAS
>>349
規格厨ですか？
Sleep()で寝てもいるのにvolatileなフラグの変更を
いつまで経っても読み取れない処理系挙げてみろよ。
なんでヒントって書いたかわかってないだろ？
353(1): 05/02/09 22:08 AAS
>>351
> なんでヒントって書いたかわかってないだろ？
なんで条件変数とかEventオブジェクト使わないの？
355(1): 05/02/09 22:10 AAS
>>351
己の無知を棚に上げて人を規格厨呼ばわりするのはやめておけ。
356(1): 351 05/02/09 22:14 AAS
>>355
ふぅん。なら問題の出る処理系挙げてみ？
ここって規格の話をするスレだっけ？
358: 351 05/02/09 22:28 AAS
>>353
想定したのはProducer/ConsumerのConsumer側スレッドプールの
スレッド数を縮小させる場合などで、ターゲットのスレッドに対して
適当なタイミングで終了させるフラグを実装するような場合。
キューから引っ張ってきたタスクを実行中に止められるはずもなく、
その次のループで確実に終了する必要もない。
この条件でもフラグ見るのに絶対に同期する必要がある？
362: 351 05/02/09 22:59 AAS
んにゃ。別に。
同期しときゃ済む話だし、省いたところでパフォーマンスが特に
上がるわけでもないからどうでもいい。
だけど、更新のある変数を扱う時は*絶*対*に*同期しなきゃ
いけないような論調になってるのが気に食わなかっただけ。
普通はフラグだけで完結するようなものはなくて、厳密な整合性を
必要とする操作のところで同期取ってるはずだから、結局はそこが
Memory Synchronizationになってるから問題ないでしょ？ってことさ。
だから問題がある処理系があるなら、それを挙げろ、と。
365: 05/02/10 00:37 AAS
>>351
C/C++なら、プログラミング言語の処理系レベルの問題ではなく、
アーキテクチャレベルの問題なんだが、それがわかってないようだな。
384(1): 351 05/02/10 11:31 AAS
>>368
今のところ、Singletonで確実に一度しか実行されないことを保証するのに
volatileでは解決にならない、ってことは結論出てるけど、決定的な一貫性を
必要としない、falseがtrueに変化するだけのフラグに使用することに関しては
まだ話題に上がってないと思うんだけど。
391(1): 351 05/02/10 19:49 AAS
>>387
Coherent Cacheだから無問題。
一貫性が崩れるのは他のCPUに伝わるまでのわずかな時間だけ。
さすがにそうじゃないアーキテクチャの場合(あるのか知らないけど)は
重要な前提が崩れるわけで、他でも悲惨なことになるんだろうね。
>もちろんSleep(100)の間に、他スレッド・プロセスの実行によってキャッシュが
>無効になる可能性は十分あるけど。
これは十分というより確実にあるでしょ。CPUがスレッド数より多く、さらに
その場合はOS側でコンテキストスイッチを行わないような実装になって
いればありえるかもしれないけど、そんなの現実的じゃないし。
で、SingletonのDCLの場合は、ひらたく言えば、ある変数の読み取りと
書き込み(+比較)を、必ずしも同期なしでAtomicに行うことができるか？
という命題と捉えていいと思う。
今のフラグの話題に戻ると、DCL問題ほど制約は厳しくなくて、読み取る
タイミングは必ずしも正確である必要はなく、書き込み側では読み取りは
一切無く、1ビット(Cだと1ビットでも立ってればtrue扱い)の書き込みのみ。
Reorderされようが、最終的に1ビット立ってりゃいいだけってこと。
volatileがなければ、ループ前に最適化でレジスタにキャッシュされて、
そのまま永遠に回し続けられる可能性も否定できなくなる。
これでも*絶*対*に*同期しなきゃいけないんだろうか？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s