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

[過去ﾛｸﾞ] マルチスレッドプログラミング相談室その４ (1001ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

1(3): 2005/11/03(木)11:23 AAS
マルチスレッドプログラミングについて語るスレ。
OS・言語・環境は問わないが、それゆえ明記すべし。

その１ 2chｽﾚ:tech
その２ 2chｽﾚ:tech
その３ 2chｽﾚ:tech

875: 2006/08/26(土)09:33 AAS
MyThread()とダイアログクラスの結びつきが強いのなら、クラスメンバにしておけばいいんでない?
要は、スレッドよりも長寿命ならいいわけだから。
#ダイアログクラスよりもスレッドの方が長寿ならこの手は使えないのは当然だけど。

876: 874 2006/08/26(土)10:20 AAS
そうですね。ぐぐって探してみましたがクラスメンバにしているサンプルがありました
とりあえずこの方法でやってみます。ありがとうございました

877(2): 2006/08/26(土)10:26 AAS
>>874
あんたの心配は正しい。

領域を渡して後はスレッド側でよろしことする以外にも...

・スレッド側で (コピーしておくとして) そのパラメータを
　使わなくなるまで親を待たせる。

・領域を静的に確保する。

・スレッドが起動してからパイプとかでパラメータをもらう。
省1

878(1): 2006/08/26(土)19:08 AAS
volatileですべて解決します。

グローバル変数にvolatile属性を付けて置く。

これ最強。

879: 2006/08/26(土)19:17 AAS
>>878
　>>877
　＞・領域を静的に確保する。

880: 2006/08/26(土)20:26 AAS
何でvolatileネタって流行ってるの？
とくに引っ張って面白いネタとも思えないけど

881: 2006/08/26(土)21:25 AAS
sizeof(int)以下ならvolatileでいいですよね？
排他は重いからやりたくないんですが・・・

という馬鹿が一時期沸いた

882: 2006/08/26(土)21:28 AAS
すごいな
全く意味のわからん質問だ

883: 2006/08/27(日)16:59 AAS
マルチスレッドなんか使わなければ解決

884(2): 2006/08/27(日)19:58 AAS
>>877
スレッドを越えてのnew / deleteは止めとけ。
つーか、調べると分かるが、状況によって手痛いしっぺ返しを喰らうぞ。

885: 2006/08/27(日)21:05 AAS
アホ発見 >>884

状況を具体的に説明してみろよ

886(1): 2006/08/27(日)21:34 AAS
>>884
それは874に宛てるべき内容だ。

呼ぶ側がdeleteするか、呼ばれた側がdeleteするかは統一するべきだとは思う。
呼ばれた側がdeleteする場合は、浅いコピーをして使い回す場合に対応できないからオススメできない。

887: 2006/08/27(日)23:06 AAS
>>886
> 呼ばれた側がdeleteする場合は、浅いコピーをして使い回す場合に
> 対応できないからオススメできない。

kwsk

888(1): 2006/08/28(月)00:21 AAS
シャローコピーで参照を共用してる場合
データレースが起きるよヤバイよって事じゃないの？

そんなもん別スレッドに渡すなよと思うけど

889: 888 2006/08/28(月)00:23 AAS
なんか違うな
忘れてくれ

890: 2006/08/28(月)00:41 AAS
しったかぶりっこ

891: 2006/08/28(月)01:49 AAS
参照ってもスレッドに渡す前に参照カウント１アゲるだろ

892: 2006/08/28(月)01:50 AAS
ぶるぶるぶりっこ

893: 2006/08/28(月)02:58 AAS
一体何の話をしてるのだろう？

894: 2006/08/28(月)05:08 AAS
ぶりっ子ロックンロール / 紅麗威甦

895(8): 2006/08/28(月)20:39 AAS
AA省

896: 2006/08/28(月)21:25 AAS
中断フラグを作って、メイン側で Window を閉じる時に
フラグを On にする。

スレッド側は中断フラグを一行毎にチェックしてて、
On になったら、速やかに終了する。

通常のディスクファイル相手ならこれでいいと思う。

ネットワークファイルとかで一行の読み出しにすごく時
間がかかる場合があるならその読み出し処理自体を中断
する必要があると思う。

897(1): 2006/08/28(月)21:52 AAS
ていうか、「Windowが閉じられたら」とか「スレッドを破棄」とか書いてるけど
普通は、閉じるボタンが押されたら、フラグなりイベントなりでスレッドに対して終了を通知して
ワーカースレッドは自分で後始末をしてから終了する、
GUIスレッドはワーカースレッドが終了するまで待機する
っていうふうに作るのが普通だろ。

898(1): 895 2006/08/28(月)21:54 AAS
どもです。
中断フラグをONするメソッド作って、中はMutexで排他処理、
スレッドのexecute()の方はSendMessage()をMutexで排他処理
しておけば、1行ごとにチェックまではしなくてよいかな？
あと、スレッドの中でSleep()呼ばないと、このスレッドに完全に制御が移ってしまい、
スレッドが終了するまでWindowが固まってしまいます。
これはそういうもんでしょうか？
マルチスレッドって、どこで処理が割り込むかわからないものだと思っていたのですが。

899: 895 2006/08/28(月)21:55 AAS
>>897
書き込み中にレスが。
ええ、その「普通はこうだ」ってのが聞きたかったんです。
なにぶん素人なのもので・・・

900: 2006/08/28(月)22:05 AAS
固まらなねーよ。
プライオリティとかいじってなきゃな。

901: 895 2006/08/28(月)22:25 AAS
_beginthread()呼んでるだけで、プライオリティはいじってないですね。
ActiveX内で、やってるからかなぁ。

902: 2006/08/28(月)23:06 AAS
>>895
>解放されないのですよね。
そもそも、なんで new で割り当ててんの？

903(1): 2006/08/29(火)04:29 AAS
>>898
> あと、スレッドの中でSleep()呼ばないと、このスレッドに完全に制御が移ってしまい、
> スレッドが終了するまでWindowが固まってしまいます。

SendMessage()のせいじゃね？

904: 895 2006/08/29(火)14:19 AAS
>>903
その通りでした。SendMessageは使わない方がよさそうですね。
スレッドがデータ格納するバッファは、Window側でタイマーで定期的に監視。
スレッドがバッファに格納するときと、Windowがバッファから取得するときは、
mutexで排他処理かましておくと良いかな。

905: 2006/08/29(火)16:46 AAS
PostMessage（）使ってみたら？

906: 2006/08/29(火)20:26 AAS
タイマーで監視しなくても、PostMessage()で合図送ればいんじゃね？

907(1): 895 2006/08/29(火)21:41 AAS
PostMessageだと、ちょっと不安があってやめたんです。
たとえば、スレッドからPostMessageを呼んだ直後に、
Windowのスレッドがアクティブになって、Windowを閉じる処理をした場合、
Windowのハンドルが無効になった後に、メッセージを飛んできて、
死亡したりしませんかね？

908: 2006/08/29(火)21:42 AAS
誰が死亡するの？

909(1): 895 2006/08/29(火)21:50 AAS
ｵｻｰﾝのプログラム。無効なウィンドウハンドルに投げようとして
ハングしたりしないかなと。

910: 2006/08/29(火)21:51 AAS
AA省

911: 2006/08/29(火)22:29 AAS
>>907
> メッセージを飛んできて、
> 死亡したりしませんかね？

メッセージを割り込みみたいなもんと勘違いしてないか？

912: 895 2006/08/29(火)22:58 AAS
いや、それはないです。
PostMessageも当然、中でいろいろやってますよね。
PostMessageで実際にキューにメッセージ入れる直前に、
Windowのスレッドに切り替わることってないんですかね？

913: 2006/08/29(火)23:09 AAS
そろそろスレ違い

914(1): 2006/08/30(水)00:04 AAS
>>909
無効なハンドル次第では、デスクトップの再描画とか起こるかも。

915: 2006/08/30(水)00:26 AAS
>>914
909じゃないけど詳しく教えてください

916: 2006/09/05(火)22:30 AAS
そりゃロックしたままSendMessageしたらデッドロックだろうよ

917(3): 2006/09/06(水)21:28 AAS
居なくなった人のプログラムを押し付けられたんだけど、
CreateThread()した後、即CloseHandle()している。
どうして即CloseHandle()するのか、
Thread関数内のExitThread()直前に呼べばいいんじゃないのか、
そもそもCloseHandle()しなくてもExitThread()するんだから要らないんじゃないのか
と思うんですが、誰も（？？）
そのままにしておけばいいんでしょうか。

918: 2006/09/06(水)21:53 AAS
>>917
MSDN の CreateThread あたりに理由は書いてあると思ったけど、
調べてみた? 推測はほどほどにして、ちゃんと確認したほうがいいよ。

919: 2006/09/07(木)01:04 AAS
>>917
> Thread関数内のExitThread()直前に呼べばいいんじゃないのか、

ハンドルの話じゃないけど…

マルチスレッドプログラミングにおいて、「～の直前だから大丈夫」
なんてこと考えてたらはまるよ。

920: 2006/09/07(木)13:24 AAS
>>917
CreateThread - ExitThread - CloseHandleするのがここでのならわし。
盲目的にこうしてればいいよ。

921: 2006/09/07(木)15:03 AAS
ぉぃぉぃ

922: 2006/09/08(金)00:47 AAS
いやmmapしないとダメ

923(30): 2006/09/08(金)12:38 AAS
ロックしないでグローバル変数に（intなど機械語１命令で読み書き可能な
サイズという条件で）アクセスするケースを考えます。

int a;
void thread1(){
　while(1)a=0x0000ffff;
}
void thread2(){
　while(1)a=0xffff0000;
}
void thread3(){
省4

924: 923 2006/09/08(金)12:40 AAS
補足ですが、シングルプロセッサとマルチプロセッサ両方の
ケースでどうなのか知りたいです。環境はWindows2000以降の
x86アーキテクチャを想定しています。

925(1): 2006/09/08(金)13:17 AAS
aの初期値が延々と表示される可能性すらあるな

926(1): 2006/09/08(金)22:28 AAS
volatile厨臭いな
釣りか？
釣られたのか？

927(1): 2006/09/08(金)23:08 AAS
>>923
メモリーバスが CPU のバストランザクションをソフトの都合に会わせて
実行する保証はどこにもないんだから

バスサイズ 8 bit のシステムで
1 on cpu0
2 on cpu1
3 on cpu2
ってシチュエーション考えれば何でもありじゃん

928: 2006/09/08(金)23:34 AAS
あっそう

929: 923 2006/09/09(土)02:25 AAS
>>925 >>926
すみません。初期値の部分は、

volatile int a = 0xffff0000;

とさせてください。後付申し訳ないです。この辺はあまり捻らないで（^^;）

>>927
＞ってシチュエーション考えれば何でもありじゃん

実際問題として、Windowsのマルチプロセッサ環境で失敗する
例を容易に確認できますでしょうか？　ハード環境を簡単に
用意するわけにも行かないので、いろんな人が見ているここに
尋ねてみました。
省2

930: 2006/09/09(土)04:21 AAS
前スレでまったく同じ議論があったよ
保証されるかどうかはアーキテクチャに強く依存する
それこそIntelとAMD、Intel内でもその世代により異なる

>シングルプロセッサ

マルチコア時代にそういう括りはやめたがいい
HTもキャッシュ絡みでerattaがあった

ひとつ聞いとこう、趣味？仕事？

931(1): 2006/09/09(土)05:04 AAS
386SX以外の32bitx86は
メモリバス(システムバスでもHTバスでも)は32bit同時に読み書きするだろ。
キャッシュが反映されないとか関係ない。
全部(全bit)書き込まれるか、全部書き込まれないかどちらか。

932(2): 2006/09/09(土)05:06 AAS
あ、ちゃんとアラインされている場合の話ね。

933(2): 仕様書無しさん 2006/09/09(土)08:41 AAS
>931-932
マルチプロセッサ環境で、あるCPUが内部キャッシュ内に保持しているDWORD
値の一部バイトを書き換えて、ライトバックする前に、ほかのCPUがDWORDの
一部バイトを書き換えるという状態になったらどう動作すんの？

934(1): 923 2006/09/09(土)09:07 AAS
>>932
Interlock系のAPIがマルチプロセッサ環境では32bitアラインを要求しますね。
関連があるのでしょうかね？

>>933
こちらへのレスではありませんが、おっしゃるケース
（一部書き換え）は考えてません。問題にしたいのは
全ビット書き換えた時読み出し時に一部しか書き変わ
っていない状況があるかどうか、なので。

ちょっと動作検証と、ロック有り無しの場合で性能的に
どれほど差が出るのかプログラムを作って試してみたいと思います。

935: 2006/09/09(土)09:21 AAS
volatile最強！！！

936(1): 2006/09/09(土)09:41 AAS
Interlockとか_MemoryBarrier使わない必要性あるの？
速度が必要ならアルゴリズムとか排他制御の範囲とか無待機アルゴリズムとか
から高速化できないの？
スレッドの優先順位とか、他のプロセスの稼動状況とかでも状況変わるから
動作検証を完全にやることは無理でしょ。
CPUやMBの仕様書をNDA結んで手に入れて調べるぐらいしないと。

937(2): 2006/09/09(土)09:45 AAS
>>933
それは「起こらない」でしょ。
なぜならば、キャッシュ間のコヒーレンシを保つための仕組みを持っているのが
マルチプロセッサシステムだから。

938(1): 2006/09/09(土)09:51 AAS
>>934
特定少数の chip setに限定するとかなら話は別だろうけど,
C コンパイラが LOCK prefix つけて load/store するコードを
吐き出すわけではないし, ハードウェアの作り次第だと思われ...

939: 2006/09/09(土)09:53 AAS
>>937の仕組みが外部バス接続のために遅くなり、糞CPUと呼ばれたのがPenD。

940: 2006/09/09(土)10:30 AAS
ついにvolatileの最強さが証明されるわけだ

>>811

おめでとう

941: 2006/09/09(土)12:02 AAS
>>937
何が「起こらない」っと言ってるのか...。

942(1): 923 2006/09/09(土)12:45 AAS
>>936 >>938
ロックしないと明らかにまずい状況はもちろんロックしますが、
単純な場合はロック無しでできたらいいという場面もありそうです。

皆さん、スレッド間で共有されるグローバル変数全て、万一の場合に
備えてくまなくロック系API使ってアクセスしてますか？

「書いて」「読んで」その状況において不都合がない場合は、
API通さずに普通のCの文法で書ければ言うことはないじゃないですか。

スレッド系の解説してる本にも、単純なカウンターとかロック系の
API無しでアクセスしてます。ここで問題にしているのはそういう
ごく単純なプリミティブなアクセスの話です。
省8

943(3): 923 2006/09/09(土)12:46 AAS
厳密性を完璧にするなら世の中のマシン全部で試さないといけない
じゃないという話にもなりますし、それはやはり現実味の無い話と
しては上に書いてあることと大差ありません。理論にも実装にも
ミスが無くてもおかしくなる環境は必ずあります。

一応持ってるマシンで検証プログラムを走らせましたがエラーする
ケースは一度も起きませんでした。

性能に関しては、ロック無しを１とした場合、Interlocked系で読み書き
すると５倍、CriticalSectionで排他すると200倍近い速度低下が起きます。
（テストプログラムは極端な例でしょう）
省9

944: 923 2006/09/09(土)12:50 AAS
#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系で読み書き
省9

945: 923 2006/09/09(土)12:51 AAS
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){
省5

946: 923 2006/09/09(土)12:52 AAS
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
省14

947: 923 2006/09/09(土)12:53 AAS
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
省2

948: 2006/09/09(土)12:55 AAS
どうせなら、レスの最後を
/* 続く
として、次のレスの頭を
>xxxから */
とでもしてくれたらコピペの(後処理の)手間が減るのだが。

949: 923 2006/09/09(土)12:58 AAS
済みません。あと、TerminateThreadしてるのはご愛嬌ということで。

950(1): 2006/09/09(土)13:31 AAS
>>943
> 一応持ってるマシンで検証プログラムを走らせましたがエラーする
> ケースは一度も起きませんでした。

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

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

「いかにして、ロックするべき部分を局所化して、ロックコンディションの
省7

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

952(1): 2006/09/09(土)13:52 AAS
もちろん、手持ちのマシンで動けば問題ないし、
たまにクラッシュしてもビジネス上問題ないならそれでいいんじゃ？

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

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

953: 2006/09/09(土)14:02 AAS
だからホビーなんじゃないの？と

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

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

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

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

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

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

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

957(3): 923 2006/09/09(土)14:15 AAS
あと、失敗しない限り発言しないでください。

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

958(1): 2006/09/09(土)14:19 AAS
>>942
> 要は世に出回っている大抵のWindowsマシンでおかしくならない線を
> 探せばいいのだと思います。

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

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

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

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

959(1): 2006/09/09(土)14:23 AAS
intrinsicはスルーか。ソースまともに読むわけ無いだろ金ももらってないのに。
失敗する環境探したいなら、自分でマシン買ってやってろ。

960(1): 923 2006/09/09(土)14:27 AAS
>>958
＞製品事故が多くなった理由が垣間見えるようだ...。
どうもすみません（^^;）

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

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

961: 2006/09/09(土)14:30 AAS
>>923
うぜえ、消えろ('A`)

962(1): 2006/09/09(土)15:23 AAS
>>960
> ユーザー環境の不具合などです。

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

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

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

そもそもこの話は「検証不可能な厳密性」じゃないよ。いくつもの論文があ
省5

963(1): 2006/09/09(土)15:34 AAS
>>923
提示されたソース読んでないけどさ、
同じ環境で何度ループしようがあまり意味ないんじゃね？

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

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

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

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

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

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

965(1): 923 2006/09/09(土)17:20 AAS
>>962
＞このスレでも議論されてる
結論はどうだったのでしょう？　以下、各行が別スレッドで動くとして、

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

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

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

966(1): 2006/09/09(土)17:29 AAS
>>923
>int a;
>void thread1(){
>　while(1)a=0x0000ffff;
>}
>void thread2(){
>　while(1)a=0xffff0000;
>}
>void thread3(){
>　while(1)printf("%08x\n",a);
省7

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

volatile long a = 0x00001111;
void thread1(){
　while(1)a=0x00001111;
}
void thread2(){
　while(1)a=0x22220000;
省7

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

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

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

969(1): 2006/09/09(土)17:50 AAS
>>965
> 結論はどうだったのでしょう？

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

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

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

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

970(1): 2006/09/09(土)18:15 AAS
>>923
とりあえず4CPUのマシンでも異常なしで動きましたのでご報告します。

971(1): 2006/09/09(土)18:29 AAS
>>969
>検証プログラムで現象が出ないからと言ってプログラムが正しいと考える

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

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

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

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

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

973: 2006/09/09(土)18:59 AAS
AA省

974: 923 2006/09/09(土)18:59 AAS
#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;
省16

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

976(1): 2006/09/09(土)19:27 AAS
お前用の検証スレじゃないんだけど。

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

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

977: 2006/09/09(土)19:39 AAS
どうしても書き込みたいならコテハンかトリップたのむ。

978(1): 2006/09/09(土)19:49 AAS
>>976 みたいな馬鹿はおいといて
2chの住民に検証協力してくれというなら
>>975 くらいの準備はしても良いと思う

979: 2006/09/09(土)20:15 AAS
結果報告なんかをここでやらないならいいよ
正直つまんないのでウンザリしてる

980: 2006/09/09(土)20:27 AAS
>978

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

981: 2006/09/09(土)22:33 AAS
>>943
根本的なところが馬鹿っぽいのに、
とても流暢に(内容的に脱力な)文章を書ける才能に感嘆する。

982: 2006/09/09(土)22:49 AAS
>>975
どうせならワームとして世界中のPCにばら撒いて
宿主PC上の実行結果を自分宛てにレポートさせるように
実行させれば良いのでは？

983(4): 2006/09/09(土)22:56 AAS
前々スレくらいでvolatile厨を繁殖させた者です。

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

前の時のポイントは、

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

という前提において、
省5

984(1): 983 2006/09/09(土)22:57 AAS
ついでに、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: 2006/09/09(土)23:17 AAS
次スレ立ってる？

986: 2006/09/10(日)00:10 AAS
立てるわ

987: 2006/09/10(日)00:20 AAS
立てた

2chｽﾚ:tech

988(3): 2006/09/10(日)00:29 AAS
>>983
> という前提において、

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

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

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

つーかさ、
spec等から確認できることもせずに、いきなり検証コード持ち出して
「ホラ、動いてるから問題ないじゃん」
省4

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

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

990: 983 2006/09/10(日)01:08 AAS
>>988

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

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

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

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

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

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

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

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

992(1): 2006/09/10(日)01:26 AAS
マルチスレッドを扱い続けて３０年の漏れが断言するが、
>>923 のコードでは絶対に「0x0000ffff か 0xffff0000 以外の数字」は表示されない！

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

993: 2006/09/10(日)02:50 AAS
CPUによる

994: 2006/09/10(日)03:03 AAS
俺なんかマルチスレッドと暮らし始めて60年だぜ

995: 2006/09/10(日)03:56 AAS
うめようよ

996: 2006/09/10(日)09:01 AAS
2chを見続けて10年の俺が断言するが、
>>992の言うことに間違いはない！

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

998: 2006/09/10(日)09:16 AAS
ヒント：２ｃｈ

999: 2006/09/10(日)09:57 AAS
>>997
いるよ。
うちの新人はWebで調べたコードは絶対間違いないって言い張る。
そういえば、去年までいた中国人も同じ事いってたよ。

1000(1): 2006/09/10(日)10:14 AAS
pthread_join( 2chｽﾚ:tech , NULL);

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

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.291s*