- 1 名前：デフォルトの名無しさん mailto:sage [2005/11/03(木) 11:23:05 ]
- マルチスレッドプログラミングについて語るスレ。
OS・言語・環境は問わないが、それゆえ明記すべし。
その１ pc3.2ch.net/test/read.cgi/tech/997345868/
その２ pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ pc8.2ch.net/test/read.cgi/tech/1098268137/
- 932 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 05:06:02 ]
- あ、ちゃんとアラインされている場合の話ね。
- 933 名前：仕様書無しさん mailto:sage [2006/09/09(土) 08:41:48 ]
- >931-932
マルチプロセッサ環境で、あるCPUが内部キャッシュ内に保持しているDWORD
値の一部バイトを書き換えて、ライトバックする前に、ほかのCPUがDWORDの
一部バイトを書き換えるという状態になったらどう動作すんの？
- 934 名前：923 mailto:sage [2006/09/09(土) 09:07:35 ]
- >>932
Interlock系のAPIがマルチプロセッサ環境では32bitアラインを要求しますね。
関連があるのでしょうかね？
>>933
こちらへのレスではありませんが、おっしゃるケース
（一部書き換え）は考えてません。問題にしたいのは
全ビット書き換えた時読み出し時に一部しか書き変わ
っていない状況があるかどうか、なので。
ちょっと動作検証と、ロック有り無しの場合で性能的に
どれほど差が出るのかプログラムを作って試してみたいと思います。
- 935 名前：デフォルトの名無しさん [2006/09/09(土) 09:21:18 ]
- volatile最強！！！
- 936 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 09:41:14 ]
- Interlockとか_MemoryBarrier使わない必要性あるの？
速度が必要ならアルゴリズムとか排他制御の範囲とか無待機アルゴリズムとか
から高速化できないの？
スレッドの優先順位とか、他のプロセスの稼動状況とかでも状況変わるから
動作検証を完全にやることは無理でしょ。
CPUやMBの仕様書をNDA結んで手に入れて調べるぐらいしないと。
- 937 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 09:45:06 ]
- >>933
それは「起こらない」でしょ。
なぜならば、キャッシュ間のコヒーレンシを保つための仕組みを持っているのが
マルチプロセッサシステムだから。
- 938 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 09:51:15 ]
- >>934
特定少数の chip setに限定するとかなら話は別だろうけど,
C コンパイラが LOCK prefix つけて load/store するコードを
吐き出すわけではないし, ハードウェアの作り次第だと思われ...
- 939 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 09:53:31 ]
- >>937の仕組みが外部バス接続のために遅くなり、糞CPUと呼ばれたのがPenD。
- 940 名前：デフォルトの名無しさん [2006/09/09(土) 10:30:49 ]
- ついにvolatileの最強さが証明されるわけだ
>>811
おめでとう
- 941 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 12:02:27 ]
- >>937
何が「起こらない」っと言ってるのか...。
- 942 名前：923 mailto:sage [2006/09/09(土) 12:45:41 ]
- >>936>>938
ロックしないと明らかにまずい状況はもちろんロックしますが、
単純な場合はロック無しでできたらいいという場面もありそうです。
皆さん、スレッド間で共有されるグローバル変数全て、万一の場合に
備えてくまなくロック系API使ってアクセスしてますか？
「書いて」「読んで」その状況において不都合がない場合は、
API通さずに普通のCの文法で書ければ言うことはないじゃないですか。
スレッド系の解説してる本にも、単純なカウンターとかロック系の
API無しでアクセスしてます。ここで問題にしているのはそういう
ごく単純なプリミティブなアクセスの話です。
NDAや「ハードウェアの作り次第」とか、そういう話まで持ち出されるのは
個人や小さい事業所でどうこうするのは不可能ですし、現実的なアクション
とは到底言えないと思います。
要は世に出回っている大抵のWindowsマシンでおかしくならない線を
探せばいいのだと思います。パッケージには全てのマシンで動作保障
するものではありませんとか書いてるソフトもありますし、試せる
範囲でおかしくならなければ（試して失敗が一つも無ければ）、
完全な厳密性までは得られなくても、こちらのスタンスとしてはOKです。
- 943 名前：923 mailto:sage [2006/09/09(土) 12:46:30 ]
-
厳密性を完璧にするなら世の中のマシン全部で試さないといけない
じゃないという話にもなりますし、それはやはり現実味の無い話と
しては上に書いてあることと大差ありません。理論にも実装にも
ミスが無くてもおかしくなる環境は必ずあります。
一応持ってるマシンで検証プログラムを走らせましたがエラーする
ケースは一度も起きませんでした。
性能に関しては、ロック無しを１とした場合、Interlocked系で読み書き
すると５倍、CriticalSectionで排他すると200倍近い速度低下が起きます。
（テストプログラムは極端な例でしょう）
実際の使用状況は置いておき、５倍の負荷は精神的に嫌な感じです。
この辺気にしない人もいるでしょうが、気にしない人は他の場合でも
気にしないでしょうし、積み重なるともっさりしたソフトが出来そう
なので、検証不可能な厳密性よりもこういうほうに労力や気を払いた
いですね。
一応ソース貼っときますので、もし失敗例が実際に観測された人が居たら
教えてください。Windowsシステム上で一つでも反例があれば納得せざる
を得ません。逆にある程度のサンプルで試して一度もエラーが無ければ
それはOKというのが世の中というものでしょう。
- 944 名前：923 mailto:sage [2006/09/09(土) 12:50:44 ]
- #include "stdafx.h"
#include "windows.h"
#include "winbase.h"
#include "process.h"
#include "mmsystem.h"
#pragma comment(lib, "winmm.lib")
#if 1 //ロック無し
#define set_a(n) a = n
#define get_a(v) v = a
#elif 0 //Interlocked系で読み書き
#define set_a(n) InterlockedExchange((long*)&a,n)
#define get_a(v) v = InterlockedExchangeAdd((long*)&a,0)
#else //CRITICAL_SECTION排他
#define _CS
CRITICAL_SECTION cs;
#define set_a(n) {EnterCriticalSection(&cs); a=n; LeaveCriticalSection(&cs);}
#define get_a(v) {EnterCriticalSection(&cs); v=a; LeaveCriticalSection(&cs);}
#endif
続く
- 945 名前：923 mailto:sage [2006/09/09(土) 12:51:29 ]
- volatile int a = 0x00001111;
volatile int t1_ct,t2_ct;
void __cdecl thread1(void *param){
while(1){
set_a(0x00001111);
t1_ct++;
}
}
void __cdecl thread2(void *param){
while(1){
set_a(0x22220000);
t2_ct++;
}
}
続く
- 946 名前：923 mailto:sage [2006/09/09(土) 12:52:50 ]
- int main(int argc, char* argv[])
{
#ifdef _CS
InitializeCriticalSection(&cs);
#endif
unsigned int id1;
HANDLE h1 = (HANDLE)_beginthread(thread1, 0, &id1);
unsigned int id2;
HANDLE h2 = (HANDLE)_beginthread(thread2, 0, &id2);
#if 0
while(1)printf("%08x\n",a);
#else
printf("実行中……\n");
int loop = 0;
int false_ct = 0;
DWORD time = timeGetTime();
while(loop++ < 100000000){
int t; get_a(t);
if(t != 0x00001111 && t != 0x22220000)
printf("不整合発見(%d)：%08x\n",++false_ct,t);
if((loop & 0x7fffff) == 0)
printf("loop:%d……\n",loop);
}
続く
- 947 名前：923 mailto:sage [2006/09/09(土) 12:53:28 ]
- time = timeGetTime() - time;
TerminateThread(h1,0);
TerminateThread(h2,0);
printf("ループ%d回、失敗%d回、実行時間%.3f秒\n",loop-1,false_ct,(double)time / 1000);
printf("スレッド1実行回数%d回\n",t1_ct);
printf("スレッド2実行回数%d回\n",t2_ct);
#ifdef _CS
DeleteCriticalSection(&cs);
#endif
#endif
return 0;
}
- 948 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 12:55:06 ]
- どうせなら、レスの最後を
/* 続く
として、次のレスの頭を
>xxxから */
とでもしてくれたらコピペの(後処理の)手間が減るのだが。
- 949 名前：923 mailto:sage [2006/09/09(土) 12:58:46 ]
- 済みません。あと、TerminateThreadしてるのはご愛嬌ということで。
- 950 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:31:06 ]
- >>943
> 一応持ってるマシンで検証プログラムを走らせましたがエラーする
> ケースは一度も起きませんでした。
じゃ、あなた的には、それでいいんじゃないでしょうか？
> 実際の使用状況は置いておき、５倍の負荷は精神的に嫌な感じです。
> この辺気にしない人もいるでしょうが、気にしない人は他の場合でも
> 気にしないでしょうし、積み重なるともっさりしたソフトが出来そう
> なので、検証不可能な厳密性よりもこういうほうに労力や気を払いた
> いですね。
「いかにして、ロックするべき部分を局所化して、ロックコンディションの
テストする回数を減らすか」
を考えるべきであって、
「ここで動くんだから大丈夫じゃないか、きっとよそでも動く！」
ってな発想はしてはならないと思いますけど。
じっさいに、4CPU程度のマシンで動いていたけど、16CPU程度の NUMA
アーキテクチャのターゲットマシンの持っていった場合、動作しなかった
って前例は何度もみてます。
- 951 名前：923 mailto:sage [2006/09/09(土) 13:50:37 ]
- >>950
ソースを出してるので、失敗した出力を貼って
いただけないでしょうか？ 動作させた環境も
出来たらお願いします。
- 952 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 13:52:15 ]
- もちろん、手持ちのマシンで動けば問題ないし、
たまにクラッシュしてもビジネス上問題ないならそれでいいんじゃ？
950も言ってるが、スレッドで共有する情報の塊に対してロックをかけるべきであって、
１足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。
それとソースだが、何でintrinsic命令使わないの？関数呼び出しコスト余計にかかってるよ。
printfのコストが多すぎだと思うが、計測間違ってない？
あと、そこまで考えるならtimeGetTimeはつかえないでしょ。
精度の設定もしてないし、明らかに少しかじった初心者がやりそうなソースだ。
- 953 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 14:02:55 ]
- だからホビーなんじゃないの？と
- 954 名前：923 mailto:sage [2006/09/09(土) 14:05:31 ]
- >>952
＞１足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。
もちろんです。
＞printfのコストが多すぎだと思うが
？
全て成功するケースでは、１億回のうち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
> ユーザー環境の不具合などです。
そのユーザー環境に「理論か実装」の不具合があるんでしょ。
「全ての環境で試験なんかやってられねー」と言うのは当然至極なんだけど、
理論的な裏づけもなく１万回やったから大丈夫と言うのはちょっと違う気が
する。
もちろん現実的には取りきれないバグをタイミングとかで逃げて１万回テス
トしたから多分大丈夫だよねーと言って出すケースはないわけじゃないけど、
技術屋としてはもやもやが残ってる。
そもそもこの話は「検証不可能な厳密性」じゃないよ。いくつもの論文があ
るし、このスレでも議論されてる。 (まともな意見のみを取り出すのは難しい
が)
> 後、>>957は悪戯じゃないですか？
いたずらなら、２行目は >>957 へのレスだ。
でも、いたずらかどうかにかかわらず１行目はあんたへのレスだよ。
- 963 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 15:34:23 ]
- >>923
提示されたソース読んでないけどさ、
同じ環境で何度ループしようがあまり意味ないんじゃね？
ゲーム開発では、３日３晩デモループさせて検証することだってあるんだよ？
それくらいのレアケースだって見逃せないっていうのは
技術者の自己満足じゃなくて、正しい姿勢なんじゃないか？
少なくとも「オレのマシンで動いてるからＯＫでしょ」って言う人とは
一緒に仕事したくないね。
- 964 名前：923 mailto:sage [2006/09/09(土) 17:02:17 ]
- うざいとか言われつつ書き込んで済みません。
>>963
＞同じ環境で何度ループしようがあまり意味ないんじゃね？
集中的に問題が起きるようなサンプルになってるとは思いますが。
たとえば似たようなケースで、あのサンプルの変数を代入じゃなくて
a++ とかにすれば値が順次増加せずに書き戻されたりするケースは
すぐに出ますので、検証手法としてあながち外れてるとも思えないです。
話はそれますがゲームの検証に関しては良く存じてます。
リリース前は２週間電源入れっぱなしで落ちないかどうか
とかやりますよね。（昔の話です）
＞オレのマシンで動いてるからＯＫでしょ
オレのマシンだけというより、動かせる限りにおいてエラーに
ならなければ、というふうに考えてます。それ以上はやりよう
が無いですし。
こちらも手持ちの環境で複数台のマシンでチェックしても
エラーになるケースは無いので、もし他の方でエラーが実際
出るなら教えてもらえるとありがたいなと思ったしだいです。
- 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
ありがとうございます。
こちらは１億回を１０億回にしても問題出ませんでした。
Pen4の１CPU-HT環境と、Pen3の１CPUです。
ちなみに、類似のプログラムとしてaに加算するケースを
動作させてしっかりエラーになりました。マルチスレッド
でのコンテキスト切り替えとアクセスを検証するプログラム
として動作がある程度的を得ているからだと思います。
また、加算だとPen3ではぜんぜんエラーにならないのも面白いですね。
1CPUなのである程度予想してましたが、コンテキスト切り替えの状況
がHTと違うようです。
>>971
擁護どうもです。970の人？
↓ちなみに加算テストへの変更点ですが、
- 973 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 18:59:32 ]
- ＊ + 巛 ヽ
〒 ! + 。 + 。 ＊ 。
+ 。 | |
＊ + / / イヤッッホォォォオオォオウ！
∧＿∧ / /
（´∀｀ / / + 。 + 。 ＊ 。
,- ｆ
/ ｭﾍ | ＊ + 。 + 。 +
〈＿｝ ） |
/ ! + 。 + + ＊
./ ,ﾍ |
ｶﾞﾀﾝ ||| 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
あたりのうｐろだを使っていただくのが
協力者以外のひとに迷惑かからなくてよろしいかと思います。
- 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 ]
- マルチスレッドを扱い続けて３０年の漏れが断言するが、
>>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 ]
- ヒント：２ｃｈ
- 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 名前：１００１ [Over 1000 Thread]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
|
 |
