06/08/04 22:56:05
「メモリなどの外部デバイスに対して複数の入出力をatomicに行うには同時にやるしかない。ロックしないならば」
という文章があったとします。
この文章の最後を無視して
『メモリなどの外部デバイスに対して複数の入出力をatomicに行うには同時にやるしかない』
だけを引用して
「ロックすればいいじゃん。バカじゃねーの？」
と書き込むのは、とても恥ずかしいですね。
では、前半部も無視して
『atomicに行うには同時にやるしかない』
だけを引用し、
「同時とatomicは違うだろ。バカじゃねーの？」
と書き込むのは、どのくらい恥ずかしいことなんでしょうかね。
まあ夏休みだから、「こくご」の能力がちょっと不足している人が現れるのも
仕方ないかもしれませんが。
797:デフォルトの名無しさん
06/08/04 23:29:16
746 名前：デフォルトの名無しさん：2006/08/03(木) 23:05:44
アセンブラまで降りる必要は必ずしも無いとは思うが
メモリの読み込みと書き出しを同時(atomic)に行うことは
(普通は)出来ないということくらいは知っておく必要がある。
798:デフォルトの名無しさん
06/08/04 23:34:11
>>797
ロックすれば、読み込みと書き出しを同時に行わなくてもatomicに実行できるよ
799:デフォルトの名無しさん
06/08/04 23:43:27
>>795
D-RAM は、読んだらデータが壊れるから再書き込みするけど、
あれは読んだデータを後から書き込んでるから同時じゃない。
正解を教えてくれ >>755
>>796
> という文章があったとします。
どこに？ 君の脳内？
ちょっと頭冷やせよ。
800:デフォルトの名無しさん
06/08/04 23:45:22
そんなの基礎知識でしょ
801:デフォルトの名無しさん
06/08/04 23:47:39
文脈や前提を無視して言葉尻をとらえるのが大好きな方がいらっしゃるようで。
802:デフォルトの名無しさん
06/08/04 23:48:16
で、そういう人には揶揄や皮肉は通用しませんね。
803:デフォルトの名無しさん
06/08/05 00:15:01
746 名前：デフォルトの名無しさん：2006/08/03(木) 23:05:44
アセンブラまで降りる必要は必ずしも無いとは思うが
メモリの読み込みと書き出しを同時(atomic)に行うことは
(普通は)出来ないということくらいは知っておく必要がある。
804:デフォルトの名無しさん
06/08/05 00:28:38
>>787
排他だけなら、アセンブラとか、asm文とか使えばいいけど、
CPUを離すのは、API使わないと無理。
# というか使った方がいい。
# ユーザランドだけで実装されたマルチスレッドライブラリもあるけどさ。
805:デフォルトの名無しさん
06/08/05 00:31:32
破壊読み出しなのは、コアメモリもそう
806:デフォルトの名無しさん
06/08/05 01:45:45
>>803
もちろん、プロセッサはそのための命令を(普通は)用意しているが
コストがかかるため、普通にソースを書いた場合
コンパイラはその命令を使ったコードは出力しない。
807:デフォルトの名無しさん
06/08/05 02:10:07
（ ﾟдﾟ）ﾎﾟｶｰﾝ
808:デフォルトの名無しさん
06/08/05 02:18:37
急に暑くなったからな。
そっとしておいてやれ。
809:デフォルトの名無しさん
06/08/05 02:23:40
最近近くに引っ越してきたvolatile asmというものですが何か?
810:デフォルトの名無しさん
06/08/05 02:31:33
>>746
811:デフォルトの名無しさん
06/08/05 09:44:05
volatile最高！！！
無駄にmutexしてる奴、馬鹿杉ｗｗｗ
sizeof(int)以下ならlockなんて不要ｗｗｗ
812:デフォルトの名無しさん
06/08/05 09:54:47
本気で言ってんの？
だからvolatileと排他のロック概念は関係ないっつーの。
volatileは他のコンテキストや割り込みで変更される可能性
があることをコンパイラに知らせて最適化を抑制するだけ。
＞sizeof(int)以下ならlockなんて不要ｗｗｗ
大抵はうまく行くだろうが、時たま失敗するだろう。
以下を沢山のスレッドつくって呼び出しまくってみな。
volatile int a,b;
void foo(){
a++;
InterlockedIncrement(&b);
}
しばらく走らせていたらaとbが一緒になるか？
813:デフォルトの名無しさん
06/08/05 10:14:01
>>811
本気で言っているとしたら
知らない人が知らないところで働いていることを理解できないようですね
814:デフォルトの名無しさん
06/08/05 10:18:41
>>812
この人なんかずれてる…
815:デフォルトの名無しさん
06/08/05 10:30:47
どの辺がすれてるのかkwsk
816:デフォルトの名無しさん
06/08/05 10:33:19
字下げが
817:デフォルトの名無しさん
06/08/05 12:49:28
オチがよろしいようで
818:デフォルトの名無しさん
06/08/05 14:56:34
>>815
>>811は書き込みの話はしていない、ってことじゃ？
データバスサイズのリードの話に限定するなら、
普通はバスレベルでも割り込まれることはないから
わざわざバスロックする必要はないと。
「無駄にmutex」がツボだと思うんだけど、ちとエスパーすぎるかな。
819:デフォルトの名無しさん
06/08/05 15:16:29
やさしすぎだと思う。
820:デフォルトの名無しさん
06/08/05 16:42:27
そもそもCではvolatile参照の意味は処理系定義だ。
参照時にlock/unlockする処理系もありうるし、volatile参照を最適化で
削除してしまう処理系もある（マニュアルに書かれている）。
Javaのvolatileはまた違う意味を持っているし。
821:デフォルトの名無しさん
06/08/05 19:31:21
ここ読め。
1.8 Program execution [intro.execution]
822:デフォルトの名無しさん
06/08/05 21:02:19
>820でFA?
823:デフォルトの名無しさん
06/08/05 22:17:01
>>820
volatile 参照の削除はできないだろ。
824:デフォルトの名無しさん
06/08/05 22:25:56
>>823
820が言うとおりvolatile参照は処理系定義。
某組み込み向けコンパイラでは、マニュアルに「sequence pointを含まない
式中のvolatile参照は削除されうる」と定義されていたりする。
825:デフォルトの名無しさん
06/08/05 22:47:47
>>824
それって、ふたつのシーケンスポイントの間で同じ volatile オブジェクトを複数回
参照する場合、１回にまとめられることがある、ってことだよね？
826:デフォルトの名無しさん
06/08/05 23:07:40
>>825
yes
827:デフォルトの名無しさん
06/08/06 10:53:58
sequence pointウンヌンが書いてないから、
>820でFA?
はありえない。>>821の示しているものには詳しく書いてある。
そこのところをそのまま理解するのがFA。
828:デフォルトの名無しさん
06/08/06 11:14:29
要はvolatileでokかngかは言語及び処理系依存ってこと。
それを無視して擁護する奴も批判する奴も間違っている。
829:デフォルトの名無しさん
06/08/06 11:17:05
処理系定義の範囲は？
volatile参照に対してハードディスクをフォーマットするコードを出すのもありなのか？
830:デフォルトの名無しさん
06/08/06 11:23:23
>>828
「volatileでokかngか」
こういういい加減な設問の立て方はやめれ
831:デフォルトの名無しさん
06/08/06 11:24:07
>>829
それを処理系定義動作として明記していれば、それはANSI準拠なコンパイラとして正しい。
そんなコンパイラは売れないだろうが。
832:デフォルトの名無しさん
06/08/06 11:30:01
じゃあvolatile参照の前後でlock/unlockするANSI Cコンパイラ作ったら売れるかな？
833:デフォルトの名無しさん
06/08/06 11:56:47
>>832
自分で lock/unlock すればいい。そんな奇怪な動作をするコンパイラは要らない。
834:デフォルトの名無しさん
06/08/06 16:58:08
じゃあvolatile参照の前後でミサイル発射するANSI Cコンパイラ作ったら売れるかな？
835:デフォルトの名無しさん
06/08/06 17:09:29
自分で面白いと思って書いてるんだったら相当やばい。
836:デフォルトの名無しさん
06/08/06 17:11:32
>>834
自分で発射すればいい。そんな奇怪な動作をするコンパイラは要らない。
837:デフォルトの名無しさん
06/08/06 17:15:21
ていうかコンパイラだけでミサイル発射できるならしてみろｗ
838:デフォルトの名無しさん
06/08/06 17:23:34
はいはい
続きはここでやれな
ｽﾚﾘﾝｸ(tech板)
839:デフォルトの名無しさん
06/08/09 00:24:50
突然ですが非同期をするメリットって何でしょうか？
840:デフォルトの名無しさん
06/08/09 00:38:57
シャンプー
841:デフォルトの名無しさん
06/08/09 00:51:16
いや、メリットは同期してると思うが
842:デフォルトの名無しさん
06/08/09 01:07:53
>>839
スレッド、プロセス、タスクはただ待たせとくには、
もったいなさ過ぎるリソースなんじゃ！
スレッドプールでぐぐれ！
843:デフォルトの名無しさん
06/08/09 01:08:25
リンスも利いてるし?
844:デフォルトの名無しさん
06/08/09 07:28:17
ZPt
845:デフォルトの名無しさん
06/08/09 10:19:08
ちゃん・りん・しゃん、という選択肢
846:デフォルトの名無しさん
06/08/09 10:23:33
>>842
スレッドプールの中のスレッドはほとんど待ってるだけだぞｗ
847:842
06/08/09 11:11:59
>>846
プールとか書いたんは、俺なりの「サプライズ」や。
色んな意見があるのはわかっとるし、好きに言うたらええ。
俺はまた覚えたての言葉使って、レスしていくだけや。
848:デフォルトの名無しさん
06/08/09 11:54:36
んまあ、I/Oとか凍り付いて待ってる間に他の仕事が出来るのがメリットだわね。
多くの場合、他の仕事っていうのは、ユーザに対して「やってますよ、生きてますよ」っていう
アピールをすることだったりするけどｗ
849:デフォルトの名無しさん
06/08/09 12:49:31
>>846
馬鹿？
850:デフォルトの名無しさん
06/08/09 13:14:16
だっておまい、単純なスレッドプールなら、
例えばプールにスレッドが10個あってタスクが2個だったら8つは待ってるだけじゃんか。
まあ、忙しさに合わせてスレッド数を適当に増減させるような実装も可能だけど。
851:デフォルトの名無しさん
06/08/09 13:17:55
スレッドプールの利点
・タスクが200個あるけど、同時に動くのは最大10個
・スレッド生成が頻発な場合、生成のボトルネックを消す
…
852:デフォルトの名無しさん
06/08/09 13:24:35
スレッド数の上限を制御したいときも使うわね
ていうかすみませんでしたよ。
軽い気持ちで書いただけなんですよごめんなさい。
853:デフォルトの名無しさん
06/08/09 15:55:01
大したテクニックじゃない気がするんだが…。
854:デフォルトの名無しさん
06/08/09 19:20:00
大したテクニックじゃないといけないのか？
855:デフォルトの名無しさん
06/08/09 20:09:24
>>850
そんなの実装に依存。
議論するだけ無駄だなｗ
pool状態のthreadはqueueに入れないから、待つことはないって場合もあるだろうし。
856:デフォルトの名無しさん
06/08/09 22:11:11
>>855
スレッド、プロセス、タスクはただ待たせとくには、
もったいなさ過ぎるリソースなんじゃ！
スレッドプールでぐぐれ！
857:デフォルトの名無しさん
06/08/09 22:46:54
非同期のメリットは何かと聞かれてスレッドプールでググれって言われてもアレだな
858:デフォルトの名無しさん
06/08/10 00:56:12
このエディタは非同期でテキスト入力してるっていわれたんだけど
じゃあ入力以外に何か処理やってるのかな？
859:デフォルトの名無しさん
06/08/10 00:57:44
個人情報の流出
860:デフォルトの名無しさん
06/08/10 07:40:47
仁義無きエディタ
861:デフォルトの名無しさん
06/08/10 08:46:31
キー入力拾うのと、バッファに突っ込むのが非同期なんじゃね？
862:デフォルトの名無しさん
06/08/10 09:39:08
>>858
GUIのエディタだと、
ウィンドウサイズ変えられるのに対応したり、
マウスで指定された範囲を反転表示したり。
863:デフォルトの名無しさん
06/08/10 10:35:09
しながら同時にテキスト入力できるのか！
864:デフォルトの名無しさん
06/08/10 10:39:46
>>858
画面出力とか。
865:デフォルトの名無しさん
06/08/11 22:57:19
どこまでがマジレスなのか…
866:デフォルトの名無しさん
06/08/14 21:40:21
みんなスレッドプールって最大数超えた場合どうしてる？
867:デフォルトの名無しさん
06/08/16 01:06:17
再起動
868:デフォルトの名無しさん
06/08/16 08:42:10
海に行く
869:デフォルトの名無しさん
06/08/16 18:56:59
オレは泳がないから
870:デフォルトの名無しさん
06/08/18 00:26:11
眺めてるだけでも心和むじゃまいか
871:デフォルトの名無しさん
06/08/18 07:41:37
潜りてー
あの不要な音が聞こえない感覚が良いんじゃー
872:デフォルトの名無しさん
06/08/18 14:51:42
>>866
＠IT：連載：.NETマルチスレッド・プログラミング入門 第4回
www.atmarkit.co.jp/fdotnet/mthread/mthread04/mthread04_01.html - 53k - キャッシュ - 関連ページ
スレッドプールのカスタマイズ
www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=27266&forum=12&3 - 26k - キャッシュ - 関連ページ
[ 他、www.atmarkit.co.jp内のページ ]
スレッドプール 最大数 の検索結果 約 1,440 件中 1 - 50 件目 (0.59 秒)
873:デフォルトの名無しさん
06/08/18 19:28:16
大阪には株式会社モータープールがあり、東京には株式会社月極がある。
874:デフォルトの名無しさん
06/08/26 09:06:17
MFCでマルチスレッドのプログラムを作成していますが、引数の受け渡しのところで悩んでいます
struct ThreadParams{
int a;
int b;
int c;
};
BOOL MyApplicationDlg::OnInitDialog()
{
…
struct ThreadParams tParams;
tParams.a = 1; tParams.b = 2; tParams.c = 3;
AfxBeginThread(MyThread, (LPVOID)&tParams, THREAD_PRIORITY_NORMAL);
return TRUE;
}
UINT MyApplicationDlg::MyThread(void * param)
{
struct ThreadParams tParams = (struct ThreadParams)(*param); ←ここで既に呼び出し元のtParamsが消えているかも？
/* tParamsを使っていろいろ処理 */
return 0;
}
上のようなコードを書いたのですが、OnInitDialog中のtParams変数のスコープは関数内だけなので
MyThread関数でtParamsを受け取ろうとしたときには既に消えている可能性があるのではないかと思いました。
こういう場合には呼び出し元で new してスレッドの方で delete するとかで対処するのでしょうか？
他に何かよい方法があればアドバイスをお願いします。
875:デフォルトの名無しさん
06/08/26 09:33:15
MyThread()とダイアログクラスの結びつきが強いのなら、クラスメンバにしておけばいいんでない?
要は、スレッドよりも長寿命ならいいわけだから。
#ダイアログクラスよりもスレッドの方が長寿ならこの手は使えないのは当然だけど。
876:874
06/08/26 10:20:36
そうですね。ぐぐって探してみましたがクラスメンバにしているサンプルがありました
とりあえずこの方法でやってみます。ありがとうございました
877:デフォルトの名無しさん
06/08/26 10:26:12
>>874
あんたの心配は正しい。
領域を渡して後はスレッド側でよろしことする以外にも...
・スレッド側で (コピーしておくとして) そのパラメータを
使わなくなるまで親を待たせる。
・領域を静的に確保する。
・スレッドが起動してからパイプとかでパラメータをもらう。
等等。個人的には new / delete を使うことが多い。
878:デフォルトの名無しさん
06/08/26 19:08:33
volatileですべて解決します。
グローバル変数にvolatile属性を付けて置く。
これ最強。
879:デフォルトの名無しさん
06/08/26 19:17:49
>>878
>>877
＞・領域を静的に確保する。
880:デフォルトの名無しさん
06/08/26 20:26:54
何でvolatileネタって流行ってるの？
とくに引っ張って面白いネタとも思えないけど
881:デフォルトの名無しさん
06/08/26 21:25:02
sizeof(int)以下ならvolatileでいいですよね？
排他は重いからやりたくないんですが・・・
という馬鹿が一時期沸いた
882:デフォルトの名無しさん
06/08/26 21:28:54
すごいな
全く意味のわからん質問だ
883:デフォルトの名無しさん
06/08/27 16:59:50
マルチスレッドなんか使わなければ解決
884:デフォルトの名無しさん
06/08/27 19:58:38
>>877
スレッドを越えてのnew / deleteは止めとけ。
つーか、調べると分かるが、状況によって手痛いしっぺ返しを喰らうぞ。
885:デフォルトの名無しさん
06/08/27 21:05:30
アホ発見 >>884
状況を具体的に説明してみろよ
886:デフォルトの名無しさん
06/08/27 21:34:42
>>884
それは874に宛てるべき内容だ。
呼ぶ側がdeleteするか、呼ばれた側がdeleteするかは統一するべきだとは思う。
呼ばれた側がdeleteする場合は、浅いコピーをして使い回す場合に対応できないからオススメできない。
887:デフォルトの名無しさん
06/08/27 23:06:55
>>886
> 呼ばれた側がdeleteする場合は、浅いコピーをして使い回す場合に
> 対応できないからオススメできない。
kwsk
888:デフォルトの名無しさん
06/08/28 00:21:30
シャローコピーで参照を共用してる場合
データレースが起きるよヤバイよって事じゃないの？
そんなもん別スレッドに渡すなよと思うけど
889:888
06/08/28 00:23:33
なんか違うな
忘れてくれ
890:デフォルトの名無しさん
06/08/28 00:41:46
しったかぶりっこ
891:デフォルトの名無しさん
06/08/28 01:49:18
参照ってもスレッドに渡す前に参照カウント１アゲるだろ
892:デフォルトの名無しさん
06/08/28 01:50:45
ぶるぶるぶりっこ
893:デフォルトの名無しさん
06/08/28 02:58:49
一体何の話をしてるのだろう？
894:デフォルトの名無しさん
06/08/28 05:08:03
ぶりっ子ロックンロール / 紅麗威甦
895:デフォルトの名無しさん
06/08/28 20:39:11
環境はWindowsです。
メインスレッドで生成されたWindowから、別スレッドを起動します。
このスレッドは、ファイルを1行づつ読み、
vector<string>に50件溜まったら、Windowへ通知します。
とりあえず下のような感じで組んだのですが、
Windowsが閉じられた場合、このスレッドを破棄しないといけません。
もしスレッドを破棄したらNetFileReaderのオブジェクトって、
解放されないのですよね。
こういうプログラムって、どうやって組むのが良いでしょう？
static vector<string> text;
void NetwordThread::execute(void* pData) {
MyWindow* win = (MyWindow*)pData;
NetFileReader* reader = new NetFileReader("hoge.txt");
string* line;
while ((line = reader->readLine()) != NULL) {
text.push_back(*line);
if (text.size() > 50) {
SendMessage(win->m_hWnd, WM_MY_MESSAGE, NULL, (LPARAM)&text);
text.clear();
Sleep(10);
}
SendMessage(win->m_hWnd, WM_MY_MESSAGE, NULL, (LPARAM)&text);
text.clear();
_endthread();
}
896:デフォルトの名無しさん
06/08/28 21:25:26
中断フラグを作って、メイン側で Window を閉じる時に
フラグを On にする。
スレッド側は中断フラグを一行毎にチェックしてて、
On になったら、速やかに終了する。
通常のディスクファイル相手ならこれでいいと思う。
ネットワークファイルとかで一行の読み出しにすごく時
間がかかる場合があるならその読み出し処理自体を中断
する必要があると思う。
897:デフォルトの名無しさん
06/08/28 21:52:15
ていうか、「Windowが閉じられたら」とか「スレッドを破棄」とか書いてるけど
普通は、閉じるボタンが押されたら、フラグなりイベントなりでスレッドに対して終了を通知して
ワーカースレッドは自分で後始末をしてから終了する、
GUIスレッドはワーカースレッドが終了するまで待機する
っていうふうに作るのが普通だろ。
898:895
06/08/28 21:54:13
どもです。
中断フラグをONするメソッド作って、中はMutexで排他処理、
スレッドのexecute()の方はSendMessage()をMutexで排他処理
しておけば、1行ごとにチェックまではしなくてよいかな？
あと、スレッドの中でSleep()呼ばないと、このスレッドに完全に制御が移ってしまい、
スレッドが終了するまでWindowが固まってしまいます。
これはそういうもんでしょうか？
マルチスレッドって、どこで処理が割り込むかわからないものだと思っていたのですが。
899:895
06/08/28 21:55:29
>>897
書き込み中にレスが。
ええ、その「普通はこうだ」ってのが聞きたかったんです。
なにぶん素人なのもので・・・
900:デフォルトの名無しさん
06/08/28 22:05:09
固まらなねーよ。
プライオリティとかいじってなきゃな。
901:895
06/08/28 22:25:55
_beginthread()呼んでるだけで、プライオリティはいじってないですね。
ActiveX内で、やってるからかなぁ。
902:デフォルトの名無しさん
06/08/28 23:06:40
>>895
>解放されないのですよね。
そもそも、なんで new で割り当ててんの？
903:デフォルトの名無しさん
06/08/29 04:29:53
>>898
> あと、スレッドの中でSleep()呼ばないと、このスレッドに完全に制御が移ってしまい、
> スレッドが終了するまでWindowが固まってしまいます。
SendMessage()のせいじゃね？
904:895
06/08/29 14:19:52
>>903
その通りでした。SendMessageは使わない方がよさそうですね。
スレッドがデータ格納するバッファは、Window側でタイマーで定期的に監視。
スレッドがバッファに格納するときと、Windowがバッファから取得するときは、
mutexで排他処理かましておくと良いかな。
905:デフォルトの名無しさん
06/08/29 16:46:22
PostMessage（）使ってみたら？
906:デフォルトの名無しさん
06/08/29 20:26:56
タイマーで監視しなくても、PostMessage()で合図送ればいんじゃね？
907:895
06/08/29 21:41:10
PostMessageだと、ちょっと不安があってやめたんです。
たとえば、スレッドからPostMessageを呼んだ直後に、
Windowのスレッドがアクティブになって、Windowを閉じる処理をした場合、
Windowのハンドルが無効になった後に、メッセージを飛んできて、
死亡したりしませんかね？
908:デフォルトの名無しさん
06/08/29 21:42:23
誰が死亡するの？
909:895
06/08/29 21:50:03
ｵｻｰﾝのプログラム。無効なウィンドウハンドルに投げようとして
ハングしたりしないかなと。
910:デフォルトの名無しさん
06/08/29 21:51:47
,､‐ "￣:::ﾞ:丶､
,r::::l3ﾞ::::::::/ﾊヽ:ヽ::::､:ヽ
{::://:::::::// ヽ＼ﾄ､:::::::!
ヾ l:::::::/ 丶 ｀ヾ ｨ､:::|
|;:r::| Ｏ` 'Ｏ ﾞﾊ| ＜ ないない
ヽﾊ :.:. :.: ﾚ
´＼ r‐--‐､,ノ
r､ r､／ヾ￣下ヘ
ヽヾ 三 |:l1､＿ヽ/__ .ィヽ
＼>ヽ/ |｀ ｝ n_n| |
ﾍ lノ `'ｿ lﾟωﾟ| |
/´ / ￣|. |
＼. ｨ ＿＿＿ | |
| ﾉ l | |
| | i:| |
911:デフォルトの名無しさん
06/08/29 22:29:31
>>907
> メッセージを飛んできて、
> 死亡したりしませんかね？
メッセージを割り込みみたいなもんと勘違いしてないか？
912:895
06/08/29 22:58:03
いや、それはないです。
PostMessageも当然、中でいろいろやってますよね。
PostMessageで実際にキューにメッセージ入れる直前に、
Windowのスレッドに切り替わることってないんですかね？
913:デフォルトの名無しさん
06/08/29 23:09:22
そろそろスレ違い
914:デフォルトの名無しさん
06/08/30 00:04:27
>>909
無効なハンドル次第では、デスクトップの再描画とか起こるかも。
915:デフォルトの名無しさん
06/08/30 00:26:29
>>914
909じゃないけど詳しく教えてください
916:デフォルトの名無しさん
06/09/05 22:30:07
そりゃロックしたままSendMessageしたらデッドロックだろうよ
917:デフォルトの名無しさん
06/09/06 21:28:12
居なくなった人のプログラムを押し付けられたんだけど、
CreateThread()した後、即CloseHandle()している。
どうして即CloseHandle()するのか、
Thread関数内のExitThread()直前に呼べばいいんじゃないのか、
そもそもCloseHandle()しなくてもExitThread()するんだから要らないんじゃないのか
と思うんですが、誰も（？？）
そのままにしておけばいいんでしょうか。
918:デフォルトの名無しさん
06/09/06 21:53:38
>>917
MSDN の CreateThread あたりに理由は書いてあると思ったけど、
調べてみた? 推測はほどほどにして、ちゃんと確認したほうがいいよ。
919:デフォルトの名無しさん
06/09/07 01:04:39
>>917
> Thread関数内のExitThread()直前に呼べばいいんじゃないのか、
ハンドルの話じゃないけど…
マルチスレッドプログラミングにおいて、「～の直前だから大丈夫」
なんてこと考えてたらはまるよ。
920:デフォルトの名無しさん
06/09/07 13:24:51
>>917
CreateThread - ExitThread - CloseHandleするのがここでのならわし。
盲目的にこうしてればいいよ。
921:デフォルトの名無しさん
06/09/07 15:03:17
ぉぃぉぃ
922:デフォルトの名無しさん
06/09/08 00:47:23
いやmmapしないとダメ
923:デフォルトの名無しさん
06/09/08 12:38:24
ロックしないでグローバル変数に（intなど機械語１命令で読み書き可能な
サイズという条件で）アクセスするケースを考えます。
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以外の数字が
表示される可能性はありますか？
924:923
06/09/08 12:40:49
補足ですが、シングルプロセッサとマルチプロセッサ両方の
ケースでどうなのか知りたいです。環境はWindows2000以降の
x86アーキテクチャを想定しています。
925:デフォルトの名無しさん
06/09/08 13:17:47
aの初期値が延々と表示される可能性すらあるな
926:デフォルトの名無しさん
06/09/08 22:28:47
volatile厨臭いな
釣りか？
釣られたのか？
927:デフォルトの名無しさん
06/09/08 23:08:48
>>923
メモリーバスが CPU のバストランザクションをソフトの都合に会わせて
実行する保証はどこにもないんだから
バスサイズ 8 bit のシステムで
1 on cpu0
2 on cpu1
3 on cpu2
ってシチュエーション考えれば何でもありじゃん
928:デフォルトの名無しさん
06/09/08 23:34:45
あっそう
929:923
06/09/09 02:25:04
>>925>>926
すみません。初期値の部分は、
volatile int a = 0xffff0000;
とさせてください。後付申し訳ないです。この辺はあまり捻らないで（^^;）
>>927
＞ってシチュエーション考えれば何でもありじゃん
実際問題として、Windowsのマルチプロセッサ環境で失敗する
例を容易に確認できますでしょうか？ ハード環境を簡単に
用意するわけにも行かないので、いろんな人が見ているここに
尋ねてみました。
シングルプロセッサでは失敗するケースはこれまでの経験上無い
ものと思われますが…（こちらは失敗するケースを見たことないです）
930:デフォルトの名無しさん
06/09/09 04:21:21
前スレでまったく同じ議論があったよ
保証されるかどうかはアーキテクチャに強く依存する
それこそIntelとAMD、Intel内でもその世代により異なる
>シングルプロセッサ
マルチコア時代にそういう括りはやめたがいい
HTもキャッシュ絡みでerattaがあった
ひとつ聞いとこう、趣味？仕事？
931:デフォルトの名無しさん
06/09/09 05:04:16
386SX以外の32bitx86は
メモリバス(システムバスでもHTバスでも)は32bit同時に読み書きするだろ。
キャッシュが反映されないとか関係ない。
全部(全bit)書き込まれるか、全部書き込まれないかどちらか。
932:デフォルトの名無しさん
06/09/09 05:06:02
あ、ちゃんとアラインされている場合の話ね。
933:仕様書無しさん
06/09/09 08:41:48
>931-932
マルチプロセッサ環境で、あるCPUが内部キャッシュ内に保持しているDWORD
値の一部バイトを書き換えて、ライトバックする前に、ほかのCPUがDWORDの
一部バイトを書き換えるという状態になったらどう動作すんの？
934:923
06/09/09 09:07:35
>>932
Interlock系のAPIがマルチプロセッサ環境では32bitアラインを要求しますね。
関連があるのでしょうかね？
>>933
こちらへのレスではありませんが、おっしゃるケース
（一部書き換え）は考えてません。問題にしたいのは
全ビット書き換えた時読み出し時に一部しか書き変わ
っていない状況があるかどうか、なので。
ちょっと動作検証と、ロック有り無しの場合で性能的に
どれほど差が出るのかプログラムを作って試してみたいと思います。
935:デフォルトの名無しさん
06/09/09 09:21:18
volatile最強！！！
936:デフォルトの名無しさん
06/09/09 09:41:14
Interlockとか_MemoryBarrier使わない必要性あるの？
速度が必要ならアルゴリズムとか排他制御の範囲とか無待機アルゴリズムとか
から高速化できないの？
スレッドの優先順位とか、他のプロセスの稼動状況とかでも状況変わるから
動作検証を完全にやることは無理でしょ。
CPUやMBの仕様書をNDA結んで手に入れて調べるぐらいしないと。
937:デフォルトの名無しさん
06/09/09 09:45:06
>>933
それは「起こらない」でしょ。
なぜならば、キャッシュ間のコヒーレンシを保つための仕組みを持っているのが
マルチプロセッサシステムだから。
938:デフォルトの名無しさん
06/09/09 09:51:15
>>934
特定少数の chip setに限定するとかなら話は別だろうけど,
C コンパイラが LOCK prefix つけて load/store するコードを
吐き出すわけではないし, ハードウェアの作り次第だと思われ...
939:デフォルトの名無しさん
06/09/09 09:53:31
>>937の仕組みが外部バス接続のために遅くなり、糞CPUと呼ばれたのがPenD。
940:デフォルトの名無しさん
06/09/09 10:30:49
ついにvolatileの最強さが証明されるわけだ
>>811
おめでとう
941:デフォルトの名無しさん
06/09/09 12:02:27
>>937
何が「起こらない」っと言ってるのか...。
942:923
06/09/09 12:45:41
>>936>>938
ロックしないと明らかにまずい状況はもちろんロックしますが、
単純な場合はロック無しでできたらいいという場面もありそうです。
皆さん、スレッド間で共有されるグローバル変数全て、万一の場合に
備えてくまなくロック系API使ってアクセスしてますか？
「書いて」「読んで」その状況において不都合がない場合は、
API通さずに普通のCの文法で書ければ言うことはないじゃないですか。
スレッド系の解説してる本にも、単純なカウンターとかロック系の
API無しでアクセスしてます。ここで問題にしているのはそういう
ごく単純なプリミティブなアクセスの話です。
NDAや「ハードウェアの作り次第」とか、そういう話まで持ち出されるのは
個人や小さい事業所でどうこうするのは不可能ですし、現実的なアクション
とは到底言えないと思います。
要は世に出回っている大抵のWindowsマシンでおかしくならない線を
探せばいいのだと思います。パッケージには全てのマシンで動作保障
するものではありませんとか書いてるソフトもありますし、試せる
範囲でおかしくならなければ（試して失敗が一つも無ければ）、
完全な厳密性までは得られなくても、こちらのスタンスとしてはOKです。
943:923
06/09/09 12:46:30
厳密性を完璧にするなら世の中のマシン全部で試さないといけない
じゃないという話にもなりますし、それはやはり現実味の無い話と
しては上に書いてあることと大差ありません。理論にも実装にも
ミスが無くてもおかしくなる環境は必ずあります。
一応持ってるマシンで検証プログラムを走らせましたがエラーする
ケースは一度も起きませんでした。
性能に関しては、ロック無しを１とした場合、Interlocked系で読み書き
すると５倍、CriticalSectionで排他すると200倍近い速度低下が起きます。
（テストプログラムは極端な例でしょう）
実際の使用状況は置いておき、５倍の負荷は精神的に嫌な感じです。
この辺気にしない人もいるでしょうが、気にしない人は他の場合でも
気にしないでしょうし、積み重なるともっさりしたソフトが出来そう
なので、検証不可能な厳密性よりもこういうほうに労力や気を払いた
いですね。
一応ソース貼っときますので、もし失敗例が実際に観測された人が居たら
教えてください。Windowsシステム上で一つでも反例があれば納得せざる
を得ません。逆にある程度のサンプルで試して一度もエラーが無ければ
それはOKというのが世の中というものでしょう。
944:923
06/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
06/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
06/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
06/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:デフォルトの名無しさん
06/09/09 12:55:06
どうせなら、レスの最後を
/* 続く
として、次のレスの頭を
>xxxから */
とでもしてくれたらコピペの(後処理の)手間が減るのだが。
949:923
06/09/09 12:58:46
済みません。あと、TerminateThreadしてるのはご愛嬌ということで。
950:デフォルトの名無しさん
06/09/09 13:31:06
>>943
> 一応持ってるマシンで検証プログラムを走らせましたがエラーする
> ケースは一度も起きませんでした。
じゃ、あなた的には、それでいいんじゃないでしょうか？
> 実際の使用状況は置いておき、５倍の負荷は精神的に嫌な感じです。
> この辺気にしない人もいるでしょうが、気にしない人は他の場合でも
> 気にしないでしょうし、積み重なるともっさりしたソフトが出来そう
> なので、検証不可能な厳密性よりもこういうほうに労力や気を払いた
> いですね。
「いかにして、ロックするべき部分を局所化して、ロックコンディションの
テストする回数を減らすか」
を考えるべきであって、
「ここで動くんだから大丈夫じゃないか、きっとよそでも動く！」
ってな発想はしてはならないと思いますけど。
じっさいに、4CPU程度のマシンで動いていたけど、16CPU程度の NUMA
アーキテクチャのターゲットマシンの持っていった場合、動作しなかった
って前例は何度もみてます。
951:923
06/09/09 13:50:37
>>950
ソースを出してるので、失敗した出力を貼って
いただけないでしょうか？ 動作させた環境も
出来たらお願いします。
952:デフォルトの名無しさん
06/09/09 13:52:15
もちろん、手持ちのマシンで動けば問題ないし、
たまにクラッシュしてもビジネス上問題ないならそれでいいんじゃ？
950も言ってるが、スレッドで共有する情報の塊に対してロックをかけるべきであって、
１足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。
それとソースだが、何でintrinsic命令使わないの？関数呼び出しコスト余計にかかってるよ。
printfのコストが多すぎだと思うが、計測間違ってない？
あと、そこまで考えるならtimeGetTimeはつかえないでしょ。
精度の設定もしてないし、明らかに少しかじった初心者がやりそうなソースだ。
953:デフォルトの名無しさん
06/09/09 14:02:55
だからホビーなんじゃないの？と
954:923
06/09/09 14:05:31
>>952
＞１足すとか状態を読んでそれに対する処理を行いさらに書くことはできないと思っておいたほうがいい。
もちろんです。
＞printfのコストが多すぎだと思うが
？
全て成功するケースでは、１億回のうちprintfは11回だけです。
無視しても問題ないと思いますが。
（途中経過のprintfが無しでも、ストップウオッチ計測で
十分優位な差が得られるほど負荷が変化するのはわかりますし、
なんなら途中経過のprintfは取ってください）
計測ループの中ではロック系のAPI以外の呼び出しは上記の
途中経過表示の微々たるprintf以外無いですよ。
＞timeGetTimeはつかえないでしょ。
動作が秒単位に対してtimeGetTimeは10msオーダーです。
精度としては十分じゃないのですか？ もし不足だと感じたら、
パフォーマンスカウンターでも使って書きなおしてください。
955:923
06/09/09 14:07:51
補足、
＞十分優位な差が得られるほど負荷が変化する
ロックするしないを切り替えたときの負荷の変化です。
956:923
06/09/09 14:13:30
後、今回の趣旨は、読み出し失敗があるかどうかなので、
そちらに関してお話ください。
レスを見ていると相当な環境の方もいるようですし、
ロック無しでの書き込みや読み出しがそれほど使用に
耐えないほどの不具合があるものなら、簡単に失敗の
ケースが出ると思います。
失敗した状況が貼られれば何より説得力がありますので、
よろしくお願い致します。
957:923
06/09/09 14:15:05
あと、失敗しない限り発言しないでください。
失敗しなければ問題ありませんので。
958:デフォルトの名無しさん
06/09/09 14:19:42
>>942
> 要は世に出回っている大抵のWindowsマシンでおかしくならない線を
> 探せばいいのだと思います。
最近の風潮か？
製品事故が多くなった理由が垣間見えるようだ...。
>>943
> 理論にも実装にもミスが無くてもおかしくなる環境は必ずあります。
技術屋として見過ごせないんだけど、「ある」と言い切れる理由は？
>>957
> あと、失敗しない限り発言しないでください。
ここは、お前の検証スレじゃない。
そういう発言したいなら、自前の掲示板でも作れ。
959:デフォルトの名無しさん
06/09/09 14:23:05
intrinsicはスルーか。ソースまともに読むわけ無いだろ金ももらってないのに。
失敗する環境探したいなら、自分でマシン買ってやってろ。
960:923
06/09/09 14:27:21
>>958
＞製品事故が多くなった理由が垣間見えるようだ...。
どうもすみません（^^;）
＞技術屋として見過ごせないんだけど、「ある」と言い切れる理由は？
話がそれたかもしれません。済みません。ユーザー環境の
不具合などです。完全な検証が出来ない以上、分る範囲で
調べることしか出来ないと思うので、完全完全を言われると
身動き取れなくなってしまうといいたかったのです。
後、>>957は悪戯じゃないですか？
961:デフォルトの名無しさん
06/09/09 14:30:24
>>923
うぜえ、消えろ('A`)
962:デフォルトの名無しさん
06/09/09 15:23:18
>>960
> ユーザー環境の不具合などです。
そのユーザー環境に「理論か実装」の不具合があるんでしょ。
「全ての環境で試験なんかやってられねー」と言うのは当然至極なんだけど、
理論的な裏づけもなく１万回やったから大丈夫と言うのはちょっと違う気が
する。
もちろん現実的には取りきれないバグをタイミングとかで逃げて１万回テス
トしたから多分大丈夫だよねーと言って出すケースはないわけじゃないけど、
技術屋としてはもやもやが残ってる。
そもそもこの話は「検証不可能な厳密性」じゃないよ。いくつもの論文があ
るし、このスレでも議論されてる。 (まともな意見のみを取り出すのは難しい
が)
> 後、>>957は悪戯じゃないですか？
いたずらなら、２行目は >>957 へのレスだ。
でも、いたずらかどうかにかかわらず１行目はあんたへのレスだよ。
963:デフォルトの名無しさん
06/09/09 15:34:23
>>923
提示されたソース読んでないけどさ、
同じ環境で何度ループしようがあまり意味ないんじゃね？
ゲーム開発では、３日３晩デモループさせて検証することだってあるんだよ？
それくらいのレアケースだって見逃せないっていうのは
技術者の自己満足じゃなくて、正しい姿勢なんじゃないか？
少なくとも「オレのマシンで動いてるからＯＫでしょ」って言う人とは
一緒に仕事したくないね。
964:923
06/09/09 17:02:17
うざいとか言われつつ書き込んで済みません。
>>963
＞同じ環境で何度ループしようがあまり意味ないんじゃね？
集中的に問題が起きるようなサンプルになってるとは思いますが。
たとえば似たようなケースで、あのサンプルの変数を代入じゃなくて
a++ とかにすれば値が順次増加せずに書き戻されたりするケースは
すぐに出ますので、検証手法としてあながち外れてるとも思えないです。
話はそれますがゲームの検証に関しては良く存じてます。
リリース前は２週間電源入れっぱなしで落ちないかどうか
とかやりますよね。（昔の話です）
＞オレのマシンで動いてるからＯＫでしょ
オレのマシンだけというより、動かせる限りにおいてエラーに
ならなければ、というふうに考えてます。それ以上はやりよう
が無いですし。
こちらも手持ちの環境で複数台のマシンでチェックしても
エラーになるケースは無いので、もし他の方でエラーが実際
出るなら教えてもらえるとありがたいなと思ったしだいです。
965:923
06/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:デフォルトの名無しさん
06/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
06/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
06/09/09 17:41:20
>>966
＞CPU/ハードウェア(メモリの実装方法とか)/OSによって違うでしょう。
どうも。
Windowsでどうなのかが知りたいのです。
こちらとしてはWindowsアプリで問題ないという裏が取れればOKです。
このマザーボードだと駄目だ、とか言うのがあれば使えないですよね。
969:デフォルトの名無しさん
06/09/09 17:50:27
>>965
> 結論はどうだったのでしょう？
自分で読もうと言う気はないのか？
> もしくは、現象が簡単に再現するプログラムの書き方があれば反例
> として文句をつける余地はありません。
そんなもんがあったら苦労はしない。
> もし検証プログラムに理論的なミスがあれば指摘してください。
検証プログラムで現象が出ないからと言ってプログラムが正しいと考える
お前の思考。
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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。