[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 06/04 17:21 / Filesize : 278 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2005/11/03(木) 11:23:05 ]
マルチスレッドプログラミングについて語るスレ。
OS・言語・環境は問わないが、それゆえ明記すべし。

その1 pc3.2ch.net/test/read.cgi/tech/997345868/
その2 pc5.2ch.net/test/read.cgi/tech/1037636153/
その3 pc8.2ch.net/test/read.cgi/tech/1098268137/

950 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:31:06 ]
>>943
> 一応持ってるマシンで検証プログラムを走らせましたがエラーする
> ケースは一度も起きませんでした。

じゃ、あなた的には、それでいいんじゃないでしょうか?

> 実際の使用状況は置いておき、5倍の負荷は精神的に嫌な感じです。
> この辺気にしない人もいるでしょうが、気にしない人は他の場合でも
> 気にしないでしょうし、積み重なるともっさりしたソフトが出来そう
> なので、検証不可能な厳密性よりもこういうほうに労力や気を払いた
> いですね。

「いかにして、ロックするべき部分を局所化して、ロックコンディションの
テストする回数を減らすか」
を考えるべきであって、
「ここで動くんだから大丈夫じゃないか、きっとよそでも動く!」
ってな発想はしてはならないと思いますけど。

じっさいに、4CPU程度のマシンで動いていたけど、16CPU程度の NUMA
アーキテクチャのターゲットマシンの持っていった場合、動作しなかった
って前例は何度もみてます。


951 名前:923 mailto:sage [2006/09/09(土) 13:50:37 ]
>>950
ソースを出してるので、失敗した出力を貼って
いただけないでしょうか? 動作させた環境も
出来たらお願いします。

952 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:52:15 ]
もちろん、手持ちのマシンで動けば問題ないし、
たまにクラッシュしてもビジネス上問題ないならそれでいいんじゃ?

950も言ってるが、スレッドで共有する情報の塊に対してロックをかけるべきであって、
1足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。

それとソースだが、何でintrinsic命令使わないの?関数呼び出しコスト余計にかかってるよ。
printfのコストが多すぎだと思うが、計測間違ってない?
あと、そこまで考えるならtimeGetTimeはつかえないでしょ。
精度の設定もしてないし、明らかに少しかじった初心者がやりそうなソースだ。


953 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:02:55 ]
だからホビーなんじゃないの?と

954 名前:923 mailto:sage [2006/09/09(土) 14:05:31 ]
>>952
>1足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。
もちろんです。

>printfのコストが多すぎだと思うが


全て成功するケースでは、1億回のうちprintfは11回だけです。
無視しても問題ないと思いますが。
(途中経過のprintfが無しでも、ストップウオッチ計測で
十分優位な差が得られるほど負荷が変化するのはわかりますし、
なんなら途中経過のprintfは取ってください)

計測ループの中ではロック系のAPI以外の呼び出しは上記の
途中経過表示の微々たるprintf以外無いですよ。

>timeGetTimeはつかえないでしょ。
動作が秒単位に対してtimeGetTimeは10msオーダーです。
精度としては十分じゃないのですか? もし不足だと感じたら、
パフォーマンスカウンターでも使って書きなおしてください。


955 名前:923 mailto:sage [2006/09/09(土) 14:07:51 ]
補足、
>十分優位な差が得られるほど負荷が変化する
ロックするしないを切り替えたときの負荷の変化です。

956 名前:923 mailto:sage [2006/09/09(土) 14:13:30 ]
後、今回の趣旨は、読み出し失敗があるかどうかなので、
そちらに関してお話ください。

レスを見ていると相当な環境の方もいるようですし、
ロック無しでの書き込みや読み出しがそれほど使用に
耐えないほどの不具合があるものなら、簡単に失敗の
ケースが出ると思います。

失敗した状況が貼られれば何より説得力がありますので、
よろしくお願い致します。

957 名前:923 mailto:sage [2006/09/09(土) 14:15:05 ]
あと、失敗しない限り発言しないでください。

失敗しなければ問題ありませんので。

958 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:19:42 ]
>>942
> 要は世に出回っている大抵のWindowsマシンでおかしくならない線を
> 探せばいいのだと思います。

最近の風潮か?
製品事故が多くなった理由が垣間見えるようだ...。

>>943
> 理論にも実装にもミスが無くてもおかしくなる環境は必ずあります。

技術屋として見過ごせないんだけど、「ある」と言い切れる理由は?

>>957
> あと、失敗しない限り発言しないでください。

ここは、お前の検証スレじゃない。
そういう発言したいなら、自前の掲示板でも作れ。



959 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:23:05 ]
intrinsicはスルーか。ソースまともに読むわけ無いだろ金ももらってないのに。
失敗する環境探したいなら、自分でマシン買ってやってろ。

960 名前:923 mailto:sage [2006/09/09(土) 14:27:21 ]
>>958
>製品事故が多くなった理由が垣間見えるようだ...。
どうもすみません(^^;)

>技術屋として見過ごせないんだけど、「ある」と言い切れる理由は?
話がそれたかもしれません。済みません。ユーザー環境の
不具合などです。完全な検証が出来ない以上、分る範囲で
調べることしか出来ないと思うので、完全完全を言われると
身動き取れなくなってしまうといいたかったのです。

後、>>957は悪戯じゃないですか?

961 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:30:24 ]
>>923
うぜえ、消えろ('A`)

962 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 15:23:18 ]
>>960
> ユーザー環境の不具合などです。

そのユーザー環境に「理論か実装」の不具合があるんでしょ。

「全ての環境で試験なんかやってられねー」と言うのは当然至極なんだけど、
理論的な裏づけもなく1万回やったから大丈夫と言うのはちょっと違う気が
する。

もちろん現実的には取りきれないバグをタイミングとかで逃げて1万回テス
トしたから多分大丈夫だよねーと言って出すケースはないわけじゃないけど、
技術屋としてはもやもやが残ってる。

そもそもこの話は「検証不可能な厳密性」じゃないよ。いくつもの論文があ
るし、このスレでも議論されてる。 (まともな意見のみを取り出すのは難しい
が)

> 後、>>957は悪戯じゃないですか?
いたずらなら、2行目は >>957 へのレスだ。
でも、いたずらかどうかにかかわらず1行目はあんたへのレスだよ。

963 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 15:34:23 ]
>>923
提示されたソース読んでないけどさ、
同じ環境で何度ループしようがあまり意味ないんじゃね?

ゲーム開発では、3日3晩デモループさせて検証することだってあるんだよ?
それくらいのレアケースだって見逃せないっていうのは
技術者の自己満足じゃなくて、正しい姿勢なんじゃないか?

少なくとも「オレのマシンで動いてるからOKでしょ」って言う人とは
一緒に仕事したくないね。


964 名前:923 mailto:sage [2006/09/09(土) 17:02:17 ]
うざいとか言われつつ書き込んで済みません。

>>963
>同じ環境で何度ループしようがあまり意味ないんじゃね?
集中的に問題が起きるようなサンプルになってるとは思いますが。

たとえば似たようなケースで、あのサンプルの変数を代入じゃなくて
a++ とかにすれば値が順次増加せずに書き戻されたりするケースは
すぐに出ますので、検証手法としてあながち外れてるとも思えないです。

話はそれますがゲームの検証に関しては良く存じてます。
リリース前は2週間電源入れっぱなしで落ちないかどうか
とかやりますよね。(昔の話です)

>オレのマシンで動いてるからOKでしょ
オレのマシンだけというより、動かせる限りにおいてエラーに
ならなければ、というふうに考えてます。それ以上はやりよう
が無いですし。

こちらも手持ちの環境で複数台のマシンでチェックしても
エラーになるケースは無いので、もし他の方でエラーが実際
出るなら教えてもらえるとありがたいなと思ったしだいです。



965 名前:923 mailto:sage [2006/09/09(土) 17:20:22 ]
>>962
>このスレでも議論されてる
結論はどうだったのでしょう? 以下、各行が別スレッドで動くとして、

a=0x00001111;
a=0x22220000;
b=a;

で、bが0x22221111になるケースがあったのでしょうか?あまり対象を
広げても大変ですし、身近なWindows環境で。

たとえば68000CPUとかでアライメントを知らない人が、奇数アドレスに
byteより大きな単位でアクセスして落ちたりすると面食らうじゃ
ないですか。

PC互換機上で0x22221111のケースって、アライメント違反ほどに顕著な
現象じゃないですよね? で、実際のアプリでも、検証プログラムでも
不具合を(少なくとも当方は)見たことが無いとなると、Windowsアプリでは
「汎用レジスタから奇数アドレスへのアクセスが(遅いけど)許可されて」
いるように0x22221111のようなことは起こりえないものとしてプログラムを書いて
もいいんじゃないかと思ったのです。Windows依存だといわれればその通りです。

PC互換機の設計図やWindowsアプリの構築方法にやったらイカン
と明示してあれば従うのにやぶさかじゃないですけどそういうソースって
このスレで議論されたという中で、もし出てきたのならお教えください。

もしくは、現象が簡単に再現するプログラムの書き方があれば反例
として文句をつける余地はありません。

>理論的な裏づけもなく
もし検証プログラムに理論的なミスがあれば指摘してください。


966 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 17:29:33 ]
>>923
>int a;
>void thread1(){
> while(1)a=0x0000ffff;
>}
>void thread2(){
> while(1)a=0xffff0000;
>}
>void thread3(){
> while(1)printf("%08x\n",a);
>}
>
>このとき、thread3で0x0000ffffか0xffff0000以外の数字が
>表示される可能性はありますか?

概出だと思いますが
CPU/ハードウェア(メモリの実装方法とか)/OSによって違うでしょう。
それ以上でもそれ以下でもありません。

967 名前:923 mailto:sage [2006/09/09(土) 17:29:41 ]
>>959
>intrinsicはスルーか。
済みません、仰りたいことの意味が良く分りませんでした。
このプログラムの要点は、

volatile long a = 0x00001111;
void thread1(){
 while(1)a=0x00001111;
}
void thread2(){
 while(1)a=0x22220000;
}
void main(){
_beginthread(thread1);
_beginthread(thread2);
 while(1)if(a != 0x00001111 && a != 0x22220000)エラー;
}

です。組み込み命令云々の余地があるのでしょうか?


968 名前:923 mailto:sage [2006/09/09(土) 17:41:20 ]
>>966
>CPU/ハードウェア(メモリの実装方法とか)/OSによって違うでしょう。
どうも。

Windowsでどうなのかが知りたいのです。
こちらとしてはWindowsアプリで問題ないという裏が取れればOKです。

このマザーボードだと駄目だ、とか言うのがあれば使えないですよね。



969 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 17:50:27 ]
>>965
> 結論はどうだったのでしょう?

自分で読もうと言う気はないのか?

> もしくは、現象が簡単に再現するプログラムの書き方があれば反例
> として文句をつける余地はありません。

そんなもんがあったら苦労はしない。

> もし検証プログラムに理論的なミスがあれば指摘してください。

検証プログラムで現象が出ないからと言ってプログラムが正しいと考える
お前の思考。


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

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

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

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

972 名前:923 mailto:sage [2006/09/09(土) 18:57:46 ]
>>970
ありがとうございます。
こちらは1億回を10億回にしても問題出ませんでした。
Pen4の1CPU-HT環境と、Pen3の1CPUです。

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

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

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

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

973 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 18:59:32 ]
 *     +    巛 ヽ
            〒 !   +    。     +    。     *     。
      +    。  |  |
   *     +   / /   イヤッッホォォォオオォオウ!
       ∧_∧ / /
      (´∀` / / +    。     +    。   *     。
      ,-     f
      / ュヘ    | *     +    。     +   。 +
     〈_} )   |                        
        /    ! +    。     +    +     * 
       ./  ,ヘ  |
 ガタン ||| j  / |  | |||
――――――――――――


974 名前:923 mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 19:25:16 ]
面倒なので代入と加算とそれぞれのロックありなしの場合を
すべて同時にテストできるプログラムにしていただけませんか?
あと、レポートも不具合ありなしだけじゃなくて、使用CPU構成や
OSバージョンなども表示されると素敵ですね。
それから、ソースはここの数レス消費する貼り方せずに
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/joyful.htm
あたりのうpろだを使っていただくのが
協力者以外のひとに迷惑かからなくてよろしいかと思います。


976 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 19:27:00 ]
お前用の検証スレじゃないんだけど。

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

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

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

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



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

980 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 20:27:34 ]
>978

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

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


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


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

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

前の時のポイントは、

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

という前提において、

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

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

984 名前:983 mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/09/09(土) 23:17:13 ]
次スレ立ってる?

986 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 00:10:02 ]
立てるわ

987 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 00:20:09 ]
立てた

pc8.2ch.net/test/read.cgi/tech/1157814833/l50

988 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 00:29:26 ]
>>983
> という前提において、

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

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

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

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

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

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



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

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


990 名前:983 mailto:sage [2006/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 mailto:sage [2006/09/10(日) 01:23:24 ]
この辺のところはDCLみたいに覆されることもあるかもしれない。

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

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

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

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












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

993 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 02:50:37 ]
CPUによる

994 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 03:03:58 ]
俺なんかマルチスレッドと暮らし始めて60年だぜ



995 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 03:56:28 ]
うめようよ

996 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 09:01:19 ]
2chを見続けて10年の俺が断言するが、
>>992の言うことに間違いはない!

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

998 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 09:16:58 ]
ヒント:2ch



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

1000 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 10:14:33 ]
pthread_join( pc8.2ch.net/test/read.cgi/tech/1157814833/ , NULL);

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






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<278KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef