マルチスレッドプログラミング相談室その４

マルチスレッドプログ ..

970:デフォルトの名無しさん
06/09/09 18:15:35
>>923
とりあえず4CPUのマシンでも異常なしで動きましたのでご報告します。

971:デフォルトの名無しさん
06/09/09 18:29:14
>>969
>検証プログラムで現象が出ないからと言ってプログラムが正しいと考える

>>923 さんはそんなこと言ってないと思いますよ。

少なくとも検証プログラムですぐに問題が出るなら使い物にならない
と考えてるだけでは？

972:923
06/09/09 18:57:46
>>970
ありがとうございます。
こちらは１億回を１０億回にしても問題出ませんでした。
Pen4の１CPU-HT環境と、Pen3の１CPUです。

ちなみに、類似のプログラムとしてaに加算するケースを
動作させてしっかりエラーになりました。マルチスレッド
でのコンテキスト切り替えとアクセスを検証するプログラム
として動作がある程度的を得ているからだと思います。

また、加算だとPen3ではぜんぜんエラーにならないのも面白いですね。
1CPUなのである程度予想してましたが、コンテキスト切り替えの状況
がHTと違うようです。

>>971
擁護どうもです。970の人？

↓ちなみに加算テストへの変更点ですが、

973:デフォルトの名無しさん
06/09/09 18:59:32
　＊　　　　+　　　　巛ヽ
　　　　　　　　　　　　〒　!　　　+　　　　。　　　　　+　　　　。　　　　　＊　　　　。
　　　　　+　　　　。　 | 　|
　　　＊　　　　+　　 /　/　　　イヤッッホォォォオオォオウ！
　　　　　　 ∧＿∧ /　/
　　　　　　（´∀｀　/　/　+　　　　。　　　　　+　　　　。　　　＊　　　　。
　　　　　　,-　　　　　ｆ
　　　　　 / ｭﾍ　　　　| ＊　　　　+　　　　。　　　　　+　　　。　+
　　　　　〈＿｝）　　　|　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　 /　　　　! +　　　　。　　　　　+　　　　+　　　　　＊　
　　　　　　 ./　　,ﾍ　 |
　ｶﾞﾀﾝ　||| j　　/　|　 | |||
――――――

974:923
06/09/09 18:59:57
#elif 1 //インクリメントテスト
#define _INC
#define set_a(n) a++
#define get_a(v) v = a
int max = 0; //これはmain内のローカル変数でも良い
#elif 0 //Interlockedでインクリメントテスト
#define _INC
#define set_a(n) InterlockedExchangeAdd((long*)&a,1)
#define get_a(v) v = InterlockedExchangeAdd((long*)&a,0)
int max = 0;
:
:
と、以下がループ内抜粋
int t; get_a(t);
#ifndef _INC
if(t != 0x00001111 && t != 0x22220000)
printf("不整合発見(%d)：%08x\n",++false_ct,t);
#else
if(max < t){
max = t;
}
if(max > t){
printf("不整合発見(%d)%d,max:%d\n",++false_ct,t,max);
}
#endif

です。HTマシンではInterlockedしないと一瞬でエラー続発です。

975:デフォルトの名無しさん
06/09/09 19:25:16
面倒なので代入と加算とそれぞれのロックありなしの場合を
すべて同時にテストできるプログラムにしていただけませんか？
あと、レポートも不具合ありなしだけじゃなくて、使用CPU構成や
OSバージョンなども表示されると素敵ですね。
それから、ソースはここの数レス消費する貼り方せずに
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
あたりのうｐろだを使っていただくのが
協力者以外のひとに迷惑かからなくてよろしいかと思います。

976:デフォルトの名無しさん
06/09/09 19:27:00
お前用の検証スレじゃないんだけど。

もう言いたいことは言ったろ

うざいからwikiでも立ててそっちでやってくんね？

977:デフォルトの名無しさん
06/09/09 19:39:54
どうしても書き込みたいならコテハンかトリップたのむ。

978:デフォルトの名無しさん
06/09/09 19:49:57
>>976 みたいな馬鹿はおいといて
2chの住民に検証協力してくれというなら
>>975 くらいの準備はしても良いと思う

979:デフォルトの名無しさん
06/09/09 20:15:39
結果報告なんかをここでやらないならいいよ
正直つまんないのでウンザリしてる

980:デフォルトの名無しさん
06/09/09 20:27:34
>978

>975 は遠回しに断ってるんじゃないかな。

981:デフォルトの名無しさん
06/09/09 22:33:50
>>943
根本的なところが馬鹿っぽいのに、
とても流暢に(内容的に脱力な)文章を書ける才能に感嘆する。

982:デフォルトの名無しさん
06/09/09 22:49:03
>>975
どうせならワームとして世界中のPCにばら撒いて
宿主PC上の実行結果を自分宛てにレポートさせるように
実行させれば良いのでは？

983:デフォルトの名無しさん
06/09/09 22:56:43
前々スレくらいでvolatile厨を繁殖させた者です。

この話題って、あの時のフラグ変化の検出の話題と凄く似ていると思う。
あの時は単なるフラグで、1ビットでも変化している事を検出できれば
良かったから、不必要にややこしくしそうで触れなかったんだけど。

前の時のポイントは、

1. メモリから読み込んだ値を利用(計算)した結果を書き込むのではなく、
　完全に新規な値をメモリに書き込む。
2. 更新前の古い値を他のプロセッサがキャッシュの関係で読み込んでも、
　伝搬されて更新された値を近いうちに読み込めればよい。

という前提において、

必ずしも同期を取らなくても動作に支障はないが、最適化による
レジスタへの張り付きを防止するためにvolatileは必要となる。

今回も似たようなもので、更新前のメモリの内容に依存しないので、
ワード境界に整列されたワード単位のメモリ転送命令がアトミックに
行われるかどうかを確認するだけで解決できるんじゃないの？

984:983
06/09/09 22:57:37
ついでに、OS依存、アーキテクチャ依存だって言う必要もないのでは？
C言語から見たら、スレッドの存在そのものが環境依存なわけだし。

>IA-32 Intel® Architecture Software Developer's Manual,
>Volume 3A: System Programming Guide
>7.1.1 Guaranteed Atomic Operations

これを見ると、
>basic memory operations will always be carried out atomically
なわけで、少なくともワード境界に整列されたワード転送なら
アトミックに行われる事が保証されているように読めるのだが。

985:デフォルトの名無しさん
06/09/09 23:17:13
次スレ立ってる？

986:デフォルトの名無しさん
06/09/10 00:10:02
立てるわ

987:デフォルトの名無しさん
06/09/10 00:20:09
立てた

ｽﾚﾘﾝｸ(tech板)l50

988:デフォルトの名無しさん
06/09/10 00:29:26
>>983
> という前提において、

そういう前提かどうかは明らかにされていない

>>984
> ついでに、OS依存、アーキテクチャ依存だって言う必要もないのでは？

「世に出回っている大抵のWindowsマシンでおかしくならない線」
というあいまいな線引きしかなされていない

つーかさ、
spec等から確認できることもせずに、いきなり検証コード持ち出して
「ホラ、動いてるから問題ないじゃん」
なんて言われてもさ、そのコード・やり方を信用する人っているのかね。

仮に確認できても、前提を考えれば、いかに狭い範囲でしか使えないかが
すぐに分かると思うんだが、それをしない理由はなんだろうね。

もう少しアタマ使えないかな。

989:デフォルトの名無しさん
06/09/10 00:36:28
>>988
>spec等から確認できることもせずに、いきなり検証コード持ち出して
>「ホラ、動いてるから問題ないじゃん」
>なんて言われてもさ、そのコード・やり方を信用する人っているのかね。

悲しいけど現実にはかなり沢山いると思う
実際事故は多発してるでしょ？

990:983
06/09/10 01:08:03
>>988

>「世に出回っている大抵のWindowsマシンでおかしくならない線」
>というあいまいな線引きしかなされていない

これが微妙な線引きだと言いたいのもわかるけど、
世の中のPC～WSクラスでSMP/Multi Coreが可能なCPUの
大半はIA-32なアーキテクチャなんじゃないの？

>そういう前提かどうかは明らかにされていない

まず、>>923のコードではaから読み出した結果を利用して
aに再代入しているわけではないので、1.の前提は成り立つ。

で、「0x0000ffffか0xffff0000以外の数字が表示されるか」から、
aの更新が他のプロセッサに即時に伝搬される必要もないし、
どちらかの値になれば良くて、読み出し結果が0xffffffffの
ように混ざり合わなければいいだけなので、2.も成り立つ。

＃とりあえず、初期値が延々表示される、、ってのは置いといて…。

少なくとも、今のところはこの考え方がまずい、
って証拠も誰も示していないんだよね。

991:983
06/09/10 01:23:24
この辺のところはDCLみたいに覆されることもあるかもしれない。

で、DCLにも気になっているところがあって、

Singletonを保証するためのDCLは危険なのは解るんだけど、
100%のSingletonであることに依存しているわけではなくて、
運悪く初期化時に複数インスタンスが生成されてしまっても
許容できる状況でもDCLは使っちゃいけないのかな？

生成にそれなりに時間かかるからキャッシュ目的でSingletonに
してるけど、複数回生成されて違うオブジェクトを返そうが、
単なるキャッシュだから実害はないっていうような場合とかで。

992:デフォルトの名無しさん
06/09/10 01:26:06
マルチスレッドを扱い続けて３０年の漏れが断言するが、
>>923 のコードでは絶対に「0x0000ffff か 0xffff0000 以外の数字」は表示されない！

これで勘弁してもらえないか？

993:デフォルトの名無しさん
06/09/10 02:50:37
CPUによる

994:デフォルトの名無しさん
06/09/10 03:03:58
俺なんかマルチスレッドと暮らし始めて60年だぜ

995:デフォルトの名無しさん
06/09/10 03:56:28
うめようよ

996:デフォルトの名無しさん
06/09/10 09:01:19
2chを見続けて10年の俺が断言するが、
>>992の言うことに間違いはない！

997:デフォルトの名無しさん
06/09/10 09:06:40
>>988
＞なんて言われてもさ、そのコード・やり方を信用する人っているのかね。
顔が見えないのをいいことに、著しく礼儀を欠いた発言をする人間も信用できないが

998:デフォルトの名無しさん
06/09/10 09:16:58
ヒント：２ｃｈ

999:デフォルトの名無しさん
06/09/10 09:57:14
>>997
いるよ。
うちの新人はWebで調べたコードは絶対間違いないって言い張る。
そういえば、去年までいた中国人も同じ事いってたよ。

1000:デフォルトの名無しさん
06/09/10 10:14:33
pthread_join( ｽﾚﾘﾝｸ(tech板) , NULL);

1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。