[過去ﾛｸﾞ] マルチスレッドプログラミング相談室 (986ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
451(1): 442 02/09/01 03:01 AAS
>>444
どうもありがとうございます。
おかげ様で大変よくわかりました。感謝感謝です。
今度は
>>448の
volatile宣言の必要がないというのがわかりません。
(444さんと同じ考えですが) volatileが無いと、
lock とunlock が通常の関数呼び出しとして実装されている
なら大丈夫としても、
仮にこれらがインライン展開される関数やマクロだった場合に、
・lockの直後のif文で G がメモリから再ロードされるかどうか
・更新後の Gの値がunlockの前でメモリに書き込まれるかどうか
が保証されないのでは？ と思えます。
452(4): 02/09/01 23:27 AAS
>>451
たとえば
mutex L;
int data;
として、スレッドAで
lock(L);
dataに代入; // …(1)
unlock(L);
とした後、スレッドBで
lock(L);
dataの利用; // …(2)
unlock(L);
ってしたとき、たとえvolatile宣言がなかったとしても
(2)において(1)の変更が見えないのはマズイ。
だから、
> 仮にこれらがインライン展開される関数やマクロだった場合に、
> ・lockの直後のif文で G がメモリから再ロードされるかどうか
> ・更新後の Gの値がunlockの前でメモリに書き込まれるかどうか
> が保証されない
なんてことがあったら、それはスレッドライブラリ側のバグ。
さらに、緩いメモリモデルをとっているアーキテクチャ上の
スレッドライブラリではlock, unlockの際に適切なメモリバリア命令を
実行していたりもする。
IA-32ではメモリ書き込み順やキャッシュ一貫性の保証があるんで
こういう話とはほとんど無縁だけど、pthreadの本とかでは
ここらへんが重要な話として載ってるよ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.035s