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

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

577:デフォルトの名無しさん
06/06/29 16:29:46
>>575
いや、絡んでるつもりは全くなかったんだ、すまん。
つまり、同期I/Oを他のスレッドで実行することによって擬似非同期I/Oの
ような使い方をしたときに、そのAPIの実行をキャンセルすることができる
ようになったということだな。
同期/非同期とはそういうことだったのか。勉強になった。

578:デフォルトの名無しさん
06/06/29 16:30:17
s/>>575/>>576/

579:デフォルトの名無しさん
06/07/01 17:16:56
Linuxのカーネル層でマルチスレッドのような
設計が必要になっているんですが、
Aという関数が終わったらBの関数で
止めていたところが動き出すような設計って
どうやったら良いもんですか？

セマフォを使った排他処理ってデータに
対する排他処理になると思うんだけど、
そういう形で発想の転換をしないと駄目なのかな？

580:デフォルトの名無しさん
06/07/01 19:10:53
待ちたいところでスピンロックでもasm WAITでもなんでもしておけばいいだろう

581:デフォルトの名無しさん
06/07/01 21:33:47
>>579
condは適当に初期化。

A() {
～;
pthread_cond_signal(&cond);
return;
}

B () {
pthread_cond_wait(&cond);
～;
return;
}

582:デフォルトの名無しさん
06/07/01 22:07:31
>>581
参考になります。

これってAのreturnの直前でBが動き出す
ということですよね？
Aが終わってからってのはやっぱり難しいのかな。

583:デフォルトの名無しさん
06/07/01 22:20:08
>>582
AA() {
A();
pthread_cond_signal(&cond);
return;
}

584:デフォルトの名無しさん
06/07/01 22:23:13
>>522
昔の奴へのレスで恐縮なんだがWindowsのSleepってそんな精度悪かったっけ？
::timeBeginPeriodとか使っても駄目？

585:デフォルトの名無しさん
06/07/01 22:49:29
他に忙しく仕事をする連中が居なければ、だいたいは大丈夫かもね。

586:デフォルトの名無しさん
06/07/01 23:26:40
>>585
なるほど
まあそれほど信用できないってことか。

587:デフォルトの名無しさん
06/07/02 00:04:19
スレッドの教科書ってどんなのあるの？
アルゴリズム系に強いやつが欲しい

588:デフォルトの名無しさん
06/07/02 00:14:48
OSによって違うな。
pthreadなら>>1->>9辺り見て。

589:デフォルトの名無しさん
06/07/02 00:18:29
Lamport's bakery algorithmとかさこんな古典的なやつから
今の新しいアルゴリズムまで載ってるのないのか.....

590:デフォルトの名無しさん
06/07/02 00:49:51
>>583
AAは別の人のソースなので手を加えられないのです。
でも参考になりますた。
ありがとうございますた。

591:デフォルトの名無しさん
06/07/03 06:53:31
windows には win32 API で色々なイベントを使えるようになってますが、
UNIXではpthreadのイベントを使う以外にないのでしょうか？

592:デフォルトの名無しさん
06/07/03 07:26:25
>>591
例えばこういう奴?
URLﾘﾝｸ(www.monkey.org)

どの UNIX を対象にしているかで答えも変わるけど、大抵はググれば色々出て来る。

593:デフォルトの名無しさん
06/07/05 10:16:26
Winsock、_beginthreadで起動して、
グローバル変数で終了要求するような、
簡単なスレッド書いているのですが、、、。

スレッド内でrecv()のような、
ブロックするような関数を呼びたくなりました。
これを終了するにはどうしたらよいでしょう。

594:デフォルトの名無しさん
06/07/05 10:30:57
ソケットオプションでノンブロッキングにすればいいんでない？

595:デフォルトの名無しさん
06/07/05 11:33:24
594>
ありがとう、そうします。

一般的にはどうでしょ？
ブロッキングするような関数をスレッドで呼んではいけない？

596:デフォルトの名無しさん
06/07/05 11:51:06
ブロッキングするべき状況と、そうでない状況がある。
前者ならブロックさせとけばいいし、そうでなければ非同期APIを使うか、
別個にスレッドを作ればいい。

597:デフォルトの名無しさん
06/07/05 11:59:52
>>593
recv()呼ぶ前にMSG_PEEKしておくなりしとかんとあかんよ。
#つーか、TCP受信処理を途中で終わらせると言う仕様そのものが如何なものかと。

598:デフォルトの名無しさん
06/07/05 13:48:39
>>595
一般的かどうかは知らないけど、普通はselect使うんじゃないかな。

599:593
06/07/05 13:49:40
>>596
「強制終了」以外は普通にブロックして、データが届いたときだけ
処理してくれればいいんだけど。って状況でした。
非同期っていうと、WSAEventSelect, WSAAsyncSelectで、通知を待つって
ことでよいですよね？

>>597
ちょっとわかんないのですが、
MSG_PEEKで、受信データが無いときはどうやって次の受信データを待つのが綺麗？
あと、途中で終わらないとしたら、どうやって終わるのがよいですか？

600:デフォルトの名無しさん
06/07/05 18:14:11
>>599
WSAAsyncSelect(s, hwnd, 0, 0);
shutdown(s, 1);
while (recv(s, buf, buflen, 0) != 0) {}
closesocket(s);

601:デフォルトの名無しさん
06/07/05 19:33:20
>>600
それ先方がデータ送ってくれないとCPU100%のビジーループ。
サーバアプリでは非常によろしくないコーディング。

602:デフォルトの名無しさん
06/07/05 19:50:55
recvって、ブロックするんじゃないの？

603:デフォルトの名無しさん
06/07/05 19:54:13
スマソ。ノンブロッキングのソケットと勘違いしてた。

604:デフォルトの名無しさん
06/07/05 20:35:06
WSAAsyncSelectした時点でノンブロックになる

605:593
06/07/06 17:50:25
任意のタイミングで終了させたいスレッド内では、ブロックする関数は呼ぶな。
socketはデフォルト非同期で。
で理解しました。ありがとう。

606:デフォルトの名無しさん
06/07/06 19:44:58
>>605
そう理解したんならそれでもいいが・・・

607:デフォルトの名無しさん
06/07/06 22:55:34
ソケットを任意のタイミングで終了させると再起動したときにわややがな。

608:593
06/07/06 23:34:44
>>607
どゆこと？
例えばサーバ的なアプリで、その受信用スレッドを、サーバ的なアプリ
のユーザ都合でブチっとしたくなった場合、、、
受信処理を終了させて、クローズなり何なりをしたい。
そんな場合ですが、再起動とは、ここでサーバ的なアプリを再度起動して
受信を始めようとした場合になにかが起こるってことですか？

609:デフォルトの名無しさん
06/07/07 00:34:15
下の層が受信しているのにアプリが落ちたら、次に起動するときにbindErrorになる。

610:デフォルトの名無しさん
06/07/07 00:43:27
つかさ、断片的な情報を積み重ねて信頼性のないアプリ作るよりさ、
ばしっとWinsock Programmer's FAQとか、Winsock関連書籍を読み
とおして、きちっとしたアプリを作ろうとは思わんのかね。

611:デフォルトの名無しさん
06/07/07 01:07:01
>>609
アドバイスするなら、その前にFAQくらい読んどけよ。
知識足りなさ過ぎ。

612:593
06/07/07 10:11:03
>>610
終了するときは、shutdown(sock, 1) をスレッドの外から呼べ、
そうするとrecvが0返すので、スレッドを抜けろ。
で、理解しました。ありがとう。

613:デフォルトの名無しさん
06/07/07 11:42:52
>>609
100％賛成して同意して応援します。
他人のいう事に惑わされたりマニュアルやFAQを読んだりせず、
先方が送信を続けている間は終了できないプログラムを作り続けてください。

614:デフォルトの名無しさん
06/07/07 11:56:22
>>593
fcntl(s, F_SETFL, O_NONBLOCK); って使えない?
(Windowsだとこれはないのかな?)
>>595
select() 使う場合は他のスレッドが同じソケットから読まないように
作る必要がある。recv() ではあまりないかも知れないが、サーバ用に
bind() した一つのソケットに対して複数のスレッドから accept()
する場合にselect()使うとハマる(2つ以上のスレッドがselect()を通過
した場合に一つのスレッド以外がブロックする)。防止するには上に
書いたような fcntl() で O_NONBLOCK セットして accept() で止まら
ないようにする。
>>609
最初に setsockopt() で SO_REUSEADDR をセットしとけばいいんじゃないか?

615:デフォルトの名無しさん
06/07/08 02:08:08
volatile最強

616:デフォルトの名無しさん
06/07/08 10:36:46
メモリモデル勉強しる

617:593
06/07/09 20:09:28
最後にもひとつ。
一般的に、マルチスレッドで使われることを前提にした、受信待ちのような
ブロックする関数を提供しようとした場合は、それと一緒に受信を中断
して安全に返るための、他のスレッドから呼ばれる関数(socketの場合のshutdown)
を提供すればよい。
ですか？
他に綺麗な方法あったら教えてください。

618:デフォルトの名無しさん
06/07/09 20:26:23
一般的には、recvでブロックさせるのではなく
select系でブロックさせて
selectをブレークさせる方法を使うだろ。

つまり「外部から解除できないブロッキング関数ではブロックさせない」と。

619:デフォルトの名無しさん
06/07/09 20:28:20
selectってキャンセル可能だっけ

620:デフォルトの名無しさん
06/07/09 20:36:02
selectで同時にパイプを待ったり
WSAEventSelectで同時にEventを待ったり
というやり方のこと。

621:デフォルトの名無しさん
06/07/09 20:39:08
selectでtimeout設定すればいいと思うけど
それとももっと高度な制御がしたいの？

622:デフォルトの名無しさん
06/07/10 00:20:40
>>621
timeout 値の設定がめんどい。

仕方なく >>620 の WSAEventSelect 使ってるけど、
これはこれでめんどい。

623:デフォルトの名無しさん
06/07/10 03:56:03
pselect

624:593
06/07/10 10:22:26
>> 618
なるほど。
Linuxでは、読み込むものは全部ファイル(ファイルデスクリプタ)で、
中断など例外的な処理は全部シグナル。と思ってpselectで綺麗にい
けていたんだけれど、
Winにいったら、いろんな方法がありそうだけれど、どれもいまいちに見えて。。
WSAEventSelectは、socket以外にも汎用的に使ったりする？

625:デフォルトの名無しさん
06/07/10 11:23:05
>>617
スレッド(タスク)開始、実行状況（実行結果）の取得、完了待ち、中断のための関数を
それぞれ提供するのが一般的だと思います。
あと場合によっては先方のスレッドでコールバックされる実行状況の通知のための
コールバック関数なんかも設定できると UI 作るときには便利（プログレスバーとか）。

>>624
個人的な意見だけど、Windows では(ソケットなら WSAEventSelect等も使って)
(Msg)WaitForMultipleObjectExで待機、何かあれば処理するというのがマルチ
スレッドの場合の定石だと思います。
ソケットだけ相手にするなら単にclosesocketしてしまうというのもアリだと思うけど。

＞WSAEventSelectは、socket以外にも汎用的に使ったりする？
ソケットを相手にしないのにWSA～を使う局面は無いと思う。

626:デフォルトの名無しさん
06/07/11 00:19:53
>>624

Winでも sock をファイルとして扱えるよ。

627:デフォルトの名無しさん
06/07/18 19:03:35
Linux (Kernel 2.6.17) で、pthread_create() で複数スレッドを作り、
そのスレッド全てが同一の bind(), listen() されたソケットに対して
accept() を行うプログラムを作ったのですが(O_NONBLOCKなソケット
ですが)、クライアントプログラムから複数 connect() すると、
accept() が同じ値のファイルディスクリプタを返して来ます。処理を
単純に書くとこんな感じです。

for(;;) {
　int cs = accept(...); // ここで cs が別スレッドと同じ値になる。
　if (cs == -1) {
　　if (errno == EAGAIN) {
　　　usleep(50000);
　　　continue;
　　} else {
　　　break; // error
　　}
　} else {
　　proc(cs); // cs を使った処理。
　　close(cs);
　}
}

accept() の前後に pthread_mutex_lock(), pthread_mutex_unlock() で
ロック、アンロックをしても同じでした。

これって Linux のバグなんでしょうか?
これを回避するにはやはり accept() をするスレッドを一つにしないと
駄目ですか?

628:デフォルトの名無しさん
06/07/18 19:04:29
すいません。質問なのに age 忘れました。age ておきます。よろしくお願いします。

629:デフォルトの名無しさん
06/07/18 19:32:26
わざわざageんなよ

630:デフォルトの名無しさん
06/07/18 22:10:43
コンパイル・リンク時のコマンドライン見せろ

631:デフォルトの名無しさん
06/07/19 01:14:42
>>627
> accept() の前後に pthread_mutex_lock(), pthread_mutex_unlock() で
> ロック、アンロックをしても同じでした。

この時点でプログラミングの問題じゃないことに気付け。

632:デフォルトの名無しさん
06/07/19 01:56:34
>>627
>これって Linux のバグなんでしょうか?
つかその前に、どこで習ったんだそんな阿呆な手順。

633:デフォルトの名無しさん
06/07/19 02:07:07
acceptしてからthreadおこせ

634:デフォルトの名無しさん
06/07/19 03:17:38
>>627
よく知らんけど、下記のApache のディレクティブの存在なんかを見ると
accept は直列化 (同時に1つのプロセス・スレッドからのみ呼ぶ）するのが
普通なんじゃないかと思うが・・・

URLﾘﾝｸ(httpd.apache.org)

635:デフォルトの名無しさん
06/07/19 09:14:39
>>630
gcc hoge.c -lpthread

>>631
どういう意味ですか? 同時に複数のスレッドが accept() しないように
しただけですが?

>>632
これは阿呆な手段ですか? 何故? その辺詳しく教えてもらえますか?
どこで習ったかは記憶にありません。ただ昔 Java で似たようなものを
作った時はちゃんと動いたと思いました。

>>633
それはつまり accept() は親(?)スレッド一つでやるということですね。

636:デフォルトの名無しさん
06/07/19 10:02:36
accept()を排他しても、
そのプログラムがまともにうごかん事に疑問はないのか?

他の部分がおかしいだけではないのか?

637:デフォルトの名無しさん
06/07/19 11:14:26
>>636
そこが疑問ですよ。なんで既に取得してオープンされているファイル
ディスクリプタと同じ値のファイルディスクリプタが返って来るのか
という点がね。

気になるのは Linux の場合スレッドは clone() システムコールで作った
特殊な別プロセスであるということです。別プロセスだから複数スレッドで
accept() した時に同一ファイルディスクリプタが取れてしまうんじゃない
かな、とは思ったんですが、確証がなかったので質問したんです。
(Linux板の方で質問した方がよかったかな? でも他のOSではこういうのは
できないのかも少し気になる)。

で、その後、accept() を一つのスレッドでだけやって、他のスレッドは
待機させておいて、accept() 成功後にファイルディスクリプタを待機
スレッドに渡すように作り替えたらちゃんと動くプログラムは作れました。
理由はどうあれこういう風にするか、あるいは accept() 成功後にスレッド
作るように書かないと駄目なようですね。

638:デフォルトの名無しさん
06/07/19 11:25:03
>>627
＞　int cs = accept(...); // ここで cs が別スレッドと同じ値になる。
本当にこれと同じ書き方だったんだな？
csが大域変数だったってオチがありそうだ。

639:デフォルトの名無しさん
06/07/19 11:30:07
>>638
いいえ。大域ではありません。autoです。

640:デフォルトの名無しさん
06/07/19 12:26:13
生半可な学習しないで、ファイルディスクリプタについてちゃんと勉強したら?

641:デフォルトの名無しさん
06/07/19 13:35:02
>>637
>スレッドは clone() システムコールで作った
ちょｗｗｗｗおまｗｗｗｗｗ帰れｗｗｗｗｗ

642:デフォルトの名無しさん
06/07/19 13:56:58
げ、pthread_createで作ってんじゃないのか・・・!!!

643:デフォルトの名無しさん
06/07/19 14:24:08
>>640
生半可? どの辺がですか?

>>641-642
pthread_create() で作ってますよ。clone() は内部動作の話です。

644:デフォルトの名無しさん
06/07/19 14:29:47
こいつむかつく～☆

645:デフォルトの名無しさん
06/07/19 14:36:37
>>643
コンパイルオプションとかはどうだろう・・・ -pthread とか付け忘れありませんか？

646:デフォルトの名無しさん
06/07/19 14:42:25
>>645
>>635

647:デフォルトの名無しさん
06/07/19 14:48:29
>>643
続きは以下で。
ネットワークプログラミング相談室 Port17
ｽﾚﾘﾝｸ(tech板)

648:デフォルトの名無しさん
06/07/19 14:59:44
>>646
-lpthread だけ指定して -pthread を指定していないのではないか、といっているのだが。

649:デフォルトの名無しさん
06/07/19 15:38:16
>>648
-pthread は指定していませんでしたが、man ページや info 見ると
Linux では関係ないようですよ。

念のため指定してテストしてみましたが、同じ動作になりました。

650:デフォルトの名無しさん
06/07/19 15:45:45
いい加減、誰かファイルディスクリプタの説明してやれよｗ

651:デフォルトの名無しさん
06/07/19 15:47:52
>>647
そっちの方がいいですか?
スレッドとネットワークと Linux が混ざった疑問なのでどこがいいのか迷ったんですが。

652:デフォルトの名無しさん
06/07/19 16:00:17
>>640 >>650
pthread_createで作ったスレッド間では、ファイルディスクプリタは共有されます。
すなわち、同じ数値＝同じソケット端点。
何がいいたのか知らんがこれでいいか？

653:デフォルトの名無しさん
06/07/19 16:06:07
>>651
どっちがいいのかはわからんけど、このスレじゃ解決できなさそうじゃん。

654:デフォルトの名無しさん
06/07/19 16:20:45
Linuxのスレッドが特別なプロセスだったのは、2.4より前の話だよ。
# 例えばpidやsignalの扱いなど。
>>627は、2.6.17だから関係ない。

655:デフォルトの名無しさん
06/07/19 16:21:59
>>637
> accept() 成功後にスレッド作るように書かないと駄目なようですね。

そんなことはない。

656:デフォルトの名無しさん
06/07/19 16:22:13
>>652
それは知ってますよ。だからこそOSがおかしいんじゃないかと思ったんですから。

元々の質問を要約すると、まだ close() されていないファイル
ディスクリプタの値を accept() が返して来るのは何故かです。
一つのスレッドが accept() で 5 を受け取ったとして、それが
close() される前にもう一つのスレッドが行った accept() が
受け取ったファイルディスクリプタの値も 5 だったということです。
これ、accept() を一つのスレッドでしかやらなければ当然 6 などの
違う値が返って来ます。

>>653
今のところそんな感じしますね。

657:デフォルトの名無しさん
06/07/19 16:24:17
>>654-655
そうですか…。じゃあ何でだろう?

658:デフォルトの名無しさん
06/07/19 16:26:01
こっちの方がいいかも。
UNIX板 pthread地獄
ｽﾚﾘﾝｸ(unix板)
読んでる人はこの板と重複がかなりあるかもだけど。

659:デフォルトの名無しさん
06/07/19 16:34:42
>>658
そこはたしかに近いこと話し合われてたスレですね。
じゃあそこに移転します。

こちらのスレのみなさまありがとうございました。

660:636
06/07/19 23:13:46
な?

661:デフォルトの名無しさん
06/07/20 01:05:07
うはｗｗｗ
ボッコボコｗｗｗ
しかも自分のミスｗｗｗ

662:デフォルトの名無しさん
06/07/20 12:50:33
>>640 >>650
お前等も黙ってないで「ファイルディスクリプタの説明」してくれよｗ

663:デフォルトの名無しさん
06/07/20 13:12:28
File Disk Riptor 略して FDR である

664:デフォルトの名無しさん
06/07/20 14:35:46
なんか車の駆動方式っぽい略称だな。

665:627
06/07/20 16:04:12
申し訳ありません。私がバグっておりました。

accept() 後の処理を別関数でやっていたのですが、その中で
fdopen() を使って accept() で受け取ったファイルディスク
リプタから FILE * を作って fgets() や fprintf() を使って
いました。それでその関数から返る直前に fclose() をして
いますが、そうすると当然元となったソケットも close()
されます。

このことをすっかり忘れていたためこの別関数から戻って
来ても accept() で取ったファイルディスクリプタは
オープンしたままだと思い込み、別関数から帰って来てから
close() までの間に別スレッドで accept() した時の
ファイルディスクリプタと同じ値になることがあったため、
今回の疑問に繋がっていました。

ということでお騒がせしました。
Linux でも複数スレッドからの accept() は問題無くできます。

666:デフォルトの名無しさん
06/07/20 16:25:36
まあせいぜい地雷原を走り抜けてくれ

667:デフォルトの名無しさん
06/07/21 20:41:07
Javaだと複数のスレッドがacceptでブロックしてても動いたと思う。
URLﾘﾝｸ(www.amazon.co.jp) の例の1つにあったと思う。

個人的にはとても気持ち悪いし、他の人にコードを見せると頭を抱えるし、
特にメリットも思いつかないので、
自分はJavaでもacceptは1つのスレッドで実行してる。

668:デフォルトの名無しさん
06/07/21 20:54:45
この人の場合、さらに non-blocking にしてあって、ブロックしないでポーリングしてるらしいよｗ

669:デフォルトの名無しさん
06/07/21 21:16:04
>>667
> 特にメリットも思いつかないので、

はあ

670:デフォルトの名無しさん
06/07/22 00:47:01
試したことはないが、
複数のThreadがServerSocket#accept()でブロックされてるとき、
ブロック解除で起こされるThreadはたぶん唯1つなのがメリットじゃないかな。
単一のThreadがaccept()待ち→ブロック解除→Queueに放り込んでWorker Threadを
たたき起こすパターンだと、Queueを監視する複数のWorker Threadがいったん
たたき起こされるから。

671:デフォルトの名無しさん
06/07/23 09:39:44
pThreadsについての書籍を探してるのですが、以下のもの読まれてる方
感想はどうですか？良書ですかね？

URLﾘﾝｸ(www.amazon.com)

URLﾘﾝｸ(www.amazon.com)

672:デフォルトの名無しさん
06/07/26 17:24:59
お世話になります。
識者のご意見ください。

以下のような状況です。(環境はVC6のWin32API)

メインスレッドＡと、待機スレッドＢがあります。
ＢはSuspend状態です。

あるタイミングでＡがＢに仕事を投げてResumeしました。
Ｂは仕事が終わったら自分でSuspend状態になりたいのです。

Ｂは自分のHANDLEをSuspendThreadしちゃってもいいものでしょうか？
ＡがＢのフラグを見てSuspendしてやるというのはちょっと効率が
悪い気がします。

以前はＢを待機スレッドではなく、その都度生成して自殺させていました。
が、この方法だとデバッグウインドウに生成と消滅のメッセージが
出まくるのと、やはりCreateThreadの負荷が気になります。

こういう場合の常套手段など、ご教示ください。
待機スレッドがCPUを食わないようにするために、Suspend状態に
しておく、という風に考えるのは変でしょうか？

よろしくお願い致します。

673:デフォルトの名無しさん
06/07/26 17:36:12
>>672
ただのワーカースレッドでええんちゃうかと
マイクロスレッドのようなものを考えてるなら、ファイバでも使えばいい

674:デフォルトの名無しさん
06/07/26 17:36:23
>>672
自分をSuspendするのは悪くない。というか、それが唯一のSuspendThreadの正しい使い方。
基本的には自スレッド以外をSuspendThreadしてはいけない。

ただし、普通はautoresetのイベントハンドルを用意して WaitForSingleObject で待たせておき、
SetEventで起こす。これはAがBをResumeThreadで起こすのが難しいから。

具体的には、SuspendThread/ResumeThreadで待機を実現しようとすると、
ResumeThreadするときに、ちょうどBが何かの仕事を終えてSuspendThreadする
直前だったりするとResumeしても即Suspendしてしまうので、これを避けるために
クリティカルセクションとフラグが1つ余分に必要になってしまって効率も悪いし
コードもムダに複雑になる。

675:デフォルトの名無しさん
06/07/26 18:07:51
みなさん、レス有難うございます。

>>674
＞autoresetのイベントハンドルを用意して WaitForSingleObject で待たせておき

こんな感じでしょうか？

スレッドＢ{
while(1){
WaitForSingleObject(XXX);
何か仕事（Ｂ＊）
}
}

スレッドＡ{
while(1){
何か仕事の準備（実行中のＢ＊の部分を触らない配慮はしている）
SetEvent(XXX);
}
}

＞直前だったりするとResumeしても即Suspendしてしまうので
なんとなく現象の心当たりがあります。

676:デフォルトの名無しさん
06/07/26 18:21:59
>>675
Bが待機するところはそんな感じです。

あとまぁよく使うパターンとしては
(1) AがBの仕事の完了を待たずににいくつもの仕事を投げておけるようにQueueに仕事を登録して SetEvent する。Bは起こされたら、Queueにある仕事を全て実行してからWaitする。
(2a) 「仕事終わったよイベント（初期値はON）」ってのも用意して、Bが仕事を終えたらSetEventする。Aは仕事終わったよイベントを待ってからBを起こす
(2b) CreateSemaphoreでMaxCount 1 のセマフォを作って、AはWait,→仕事の準備→ReleaseSemaphore、
　　BはWait→仕事を取り出して実行→ReleaseSemaphore とする。

仕事が終わったかどうか知りたくなることも多いので、漏れは2aのパターンを多用します。
殆ど等価な 2b でもいいのかも知れない。

677:デフォルトの名無しさん
06/07/26 19:36:15
>>676
Suspend,Resumeでやってたところを待機オブジェクトにしました。
すっきりした感じがします。
＞(2a)
なんとなくこれっぽいことはやっていました。
どうもありがとうございました。

678:デフォルトの名無しさん
06/07/26 21:47:50
lock-freeについて調べている内に
CAS(CompareAndSwap)という概念にたどりついたのですが
ちょっと教えてください。
/* 関数内の処理はatomicに処理されると仮定*/
bool CAS(void*addr,int expval,int newval){
if(*addr == expval){
*addr = newval;return true;
}
return false;
}
*addr=0;
while(!CAS(addr,0,*addr + 1)){
//※ここでコンテキストスイッチ
}
//アトミックにインクリメント成功?
例えば※の部分で別スレッドがaddrの値を5に変更→0に変更
という動きをした場合、*addr == expvalが成り立ってしまい、
インクリメント成功とみなされてしまう気がするのですが・・・
何か回避策等あるんでしょうか。それとも俺の理解不足なんでしょうか

679:デフォルトの名無しさん
06/07/26 23:07:03
>>678
「アトミックなインクリメント」というものを理解していないような気がする。
過去に5だったかどうかはさておき、他のスレッドで0にされたものが1に
なるのだから成功している。
というか5で放置されてて6になってもやはり成功。

*addr=0;
IntgerlockedIncrement(&addr);　←APIによるアトミックなインクリメント
などとしたところで、この2行の間に*addrが5になって0になることもある。

「アトミックなインクリメントに失敗」というのは、2つのスレッドで1度ずつ
アトミックなインクリメント操作が行われたにも関わらず2増えないことを言う。
これは正しい実装では決して起きない。

680:デフォルトの名無しさん
06/07/26 23:07:59
追記：
CASによるアトミックなインクリメントの実装は、正しくは↓

while (!CAS(addr, *addr, *addr+1) {}

681:678
06/07/27 21:49:17
>>679
>>680
ありがとうございます。

addr=&val;
while(!CAS(addr,*addr,*addr + 1)){
//※ここでコンテキストスイッチ
}
でも問題が起きそうな気がするんですが・・

とここまで書いて
URLﾘﾝｸ(www-06.ibm.com)
に似たような事が書いてありました
ABA問題というらしいですが

もうちょっと勉強してでなおしてきます・・

682:デフォルトの名無しさん
06/07/27 23:41:31
とりあえず、CAS(xxx, *addr, *addr+1)
なんて書いている奴は氏んでいいよ。

atomic_inc(int *addr)は
do {
　int var = *addr;
} while (!CAS(addr, var, var+1));
にしないと。

まあ、複数のスレッドで勝手に値をセットするような変数を
特定の個所だけatomic_incを使っても意味は無いがね。

683:デフォルトの名無しさん
06/07/28 00:03:12
終わった話題についてなにを得意げに語ってるんだろう…。

684:デフォルトの名無しさん
06/07/28 00:20:12
>>682
それC言語的にやばいやん。

685:デフォルトの名無しさん
06/07/28 00:31:47
つまり、「ほんと、バカしかいないんだね」ってことか。

686:デフォルトの名無しさん
06/07/28 00:43:19
やーい
ばかー

687:デフォルトの名無しさん
06/07/28 07:26:02
volatileですべて解決！

688:デフォルトの名無しさん
06/07/28 12:24:47
>>682
バカは喪前のほうだと思うが・・・
なぜ自分がバカなのかが知りたかったら、
元のコードの問題点を書いてご覧よ。
書いてるうちにわかるだろ。

689:デフォルトの名無しさん
06/07/28 17:51:17
元のコードの問題点は関係なくて
*addrを２度読み出して同じ値が取れると思っているのがバカだって事だろ。

690:デフォルトの名無しさん
06/07/28 17:53:25
しかも、この手のバグは非常に表面化しにくく
再現性が低い(デバッグが難しい)。

691:デフォルトの名無しさん
06/07/29 15:08:13
volatileですべて解決するという忠告がみえないのか？

692:デフォルトの名無しさん
06/07/29 16:14:19
別CPUから発言が見えるようになるまでには時間がかかります

693:デフォルトの名無しさん
06/07/29 18:15:53
VC++とMFCでマルチスレッドなサーバープログラムを書いています。
サーバープログラムを終了する時、ソケットが走ってるスレッドを終了させないといけませんが、
スレッドに終了を通知する手段が分かりません。
どのように終了を通知するのか教えていただけないでしょうか。

よろしくお願いします。

694:デフォルトの名無しさん
06/07/29 19:01:50
ソケットをどういう風に使ってるかによると思うけど、イベントとか単なるフラグとか。

695:デフォルトの名無しさん
06/07/29 19:36:20
>>693
ExitProcessで自殺すればおｋ

696:693
06/07/29 19:49:37
CAsyncSocketを継承して作ったUDPのソケットです。
クライアントからやってくるパケットをRecvFromで受けて、データに応じてSendToしているだけです。

現在、スレッドを閉じるのにdeleteでデストラクタを呼び、強制的に終了させているのですが
デバッガで追っかけていくとCAsyncSocketの中でエラーが発生します。
詳細は不明ですがおそらくソケットを閉じずに終了したためではないかと思います。

Win32APIでマルチスレッドなプログラムを組んだときはPostThreadMessageで終了メッセージを
送って、WaitForSingleObjectでスレッドが落ちるのを待っていたのですが、MFCで
そのような手順を踏んだ終了の仕方は(強制終了じゃないやり方)ないのでしょうか？

697:デフォルトの名無しさん
06/07/29 20:28:56
CAsyncSocketて使ったことないから知らないけど、
非同期に通信してるなら終わりにするかどうか判断する機会はあるんじゃないの？

698:デフォルトの名無しさん
06/07/29 20:48:34
CAsyncSocketのデストラクタが動けば万事OKみたいなことMSDNには書いてあるけど。
スレッドを強制終了するから、そのスタックにあるCAsyncSocketがリークしてるとか、
そういうこと？

699:693
06/07/29 21:12:35
>>697
複数台の設備との通信をするサーバープログラムなのですが、設備のON/OFFとサーバーのON/OFFは
必ずしもリンクしていません。一応作業標準として順序だてることは可能ですが、予想外のトラブル(瞬停など)を
考えると何かのパケットが来たらソケットを閉じてもいいとはできません。
サーバープログラムを閉じる作業中にソケットが走っているスレッドに終了を通知できればいいのですが
その方法がわからないのです。

>>698
>そのスタックにあるCAsyncSocketがリークしてるとか
そのとおりです。

700:デフォルトの名無しさん
06/07/29 21:18:08
スレッドが終了する時のイベントハンドラで
CAsyncSocketをdeleteじゃダメって事？

701:デフォルトの名無しさん
06/07/29 21:24:23
>>700
今はスレッドのデストラクタでCAsyncSocketをdeleteしていますが、その中でエラーになります。

702:デフォルトの名無しさん
06/07/29 21:38:00
ねぇ。マルチスレッドって何？

703:デフォルトの名無しさん
06/07/29 21:40:39
multi 【名-1】（複数｛ふくすう｝の色調｛しきちょう｝からなる）縞模様｛しまもよう｝【名-2】マルチビタミン（錠剤｛じょうざい｝）
thread 【名-1】（繊維を束ねた）糸、より糸【名-2】糸［繊維］状のもの、細い筋状のもの【名-3】（全体をつなぎ止める）筋、（話などの）脈絡｛みゃくらく｝

704:デフォルトの名無しさん
06/07/29 21:53:15
縞模様の筋ですか？

705:デフォルトの名無しさん
06/07/29 21:55:30
筋肉のことですか？

706:デフォルトの名無しさん
06/07/29 22:29:03
>>691
まさかとは思うけど、本気で言ってるわけじゃないよね？

707:デフォルトの名無しさん
06/07/30 00:24:25
>>689
だって別に同じ値じゃなくても問題ないんだよ。
単にその1度のCAS呼び出しがfalseになるだけ。

708:デフォルトの名無しさん
06/07/30 00:32:23
>>707
第３引数の *addr + 1 を評価した後に別スレッドによって *addr の値が変更され、
その後に第２引数の *addr が評価されるとアウト。

709:デフォルトの名無しさん
06/07/30 09:43:28
>>701
スレッドを強制終了させないで、外部から何かきっかけを与えて自分で終わるようにすればいいだけじゃん。

710:デフォルトの名無しさん
06/07/30 15:36:23
>>691 >>707
>>708の言うように、
「CASの第2引数の値」と「CAS呼び出し時に*addrに入っている値」
これが違うのは問題ないが
「CASの第2引数と第3引数の値の差」が１でない場合に誤動作する。

コンパイラの最適化で読み出しが１回になるケースもあるだろうが
最適化オプションで動作が異なるのはデバッグを難しくするだけ。

volatileを使えば、読み出しが２回になることが保証されるだけ。

711:デフォルトの名無しさん
06/07/31 13:37:43
一般的な双方向リストをマルチスレッドで使うとまずいですか?

new -> next = next;
/* ここでスレッドが切り替わるとか? */
new -> prev = next -> prev;

みたいな事が起きるとうまく繋げないような気がします。
WinAPI を使ってオブジェクトかなにか?を作って排他制御する
必要があるのでしょうか?

712:デフォルトの名無しさん
06/07/31 13:41:09
問題ないw

713:デフォルトの名無しさん
06/07/31 15:11:21
>>711
まずい。複数スレッドからappendすると、ノードが行方不明になったりする。
ただ、スレッドセーフな双方向リストにするより、
外部の同期オブジェクトを使ってそのリストへのアクセスを同期化する方が
柔軟。

714:デフォルトの名無しさん
06/08/01 06:53:40
volatileですべて解決！！！

715:デフォルトの名無しさん
06/08/01 10:44:44
この話では無理ｗ

716:デフォルトの名無しさん
06/08/01 11:20:51
>>711
問題ない
関数内ではスレッドの切り替えは起こらない

717:デフォルトの名無しさん
06/08/01 11:51:13
preemption はいつでも起こりうるでしょ

718:716
06/08/01 12:39:23
起こらないでしょ

719:デフォルトの名無しさん
06/08/01 12:43:33
>>716
何を根拠に言ってんの？

720:デフォルトの名無しさん
06/08/01 12:51:51
ようやくWindowsのメッセージディスパッチのことを理解したばかりのヒトが
それをマルチスレッドだと思い込んでるんでしょう。

721:デフォルトの名無しさん
06/08/01 13:19:11
>>716 は、ユーザレベルスレッドしか使った事無い人なんでしょうかね。

722:デフォルトの名無しさん
06/08/01 13:23:44
>>716はWin3.1ユーザー

723:デフォルトの名無しさん
06/08/01 13:24:48
実装がユーザレベルかカーネルレベルかと、プリエンプティブかコ・オペレーティブかは関係ないだろ。

724:デフォルトの名無しさん
06/08/01 13:33:14
関数内では起こらないってのもすごいよな。
普通は全てmainの関数内なんだが。
まあWndProcはまた別だが、それもWinMain内ででGetMessageしてるわけだし。

725:716
06/08/01 14:35:50
反省^^

726:デフォルトの名無しさん
06/08/01 22:51:18
>>723
そこに異論は無いけど、言いたい事は分かるでしょ。

727:デフォルトの名無しさん
06/08/02 08:14:08
まあ、あれだ。がんがりたまえ（笑）

728:デフォルトの名無しさん
06/08/02 12:46:56
一般的なのはミューティックスを作る方法なの?

729:デフォルトの名無しさん
06/08/02 13:49:28
ディスクトップでディスクリプタをミューティックスで保護することを考察

730:デフォルトの名無しさん
06/08/02 14:34:13
むてふ

731:デフォルトの名無しさん
06/08/02 14:47:18
ティキストエデタ

732:デフォルトの名無しさん
06/08/02 15:05:17
www

733:デフォルトの名無しさん
06/08/02 23:11:34
ヴォラタィル

734:デフォルトの名無しさん
06/08/03 08:56:51
コンピゥタァ

735:デフォルトの名無しさん
06/08/03 12:30:55
ﾓｼ　NO=735　ﾅﾗﾊﾞ　ﾄﾍﾞ >>1000

736:デフォルトの名無しさん
06/08/03 14:38:59
static bool g;

if (!g && g = true) {}

この if ()の中でスレッド切り替えって起こります?
排他処理になりませんか?

737:デフォルトの名無しさん
06/08/03 14:54:43
>>736
その g = true というのは本当に g = grue なのか?
それとも g == true の書き間違い?

738:デフォルトの名無しさん
06/08/03 14:56:56
あ、俺も書き間違えた。すま。

739:デフォルトの名無しさん
06/08/03 15:47:48
>>736
> この if ()の中でスレッド切り替えって起こります?
起こる

> 排他処理になりませんか?
ならん

740:デフォルトの名無しさん
06/08/03 18:52:39
w

741:デフォルトの名無しさん
06/08/03 21:56:53
ちょっと待てよ。C言語だとするとショートサーキットだよな?
!g の結果が false なら g = true は実行されないよな。
true なら実行される。

排他になるんじゃないか?

742:デフォルトの名無しさん
06/08/03 22:01:59
ひょっとしたら
!g
がアトミックじゃない処理系もあるかも

743:デフォルトの名無しさん
06/08/03 22:02:10
ショートサーキットは関係ない。
!gの評価と、g=trueの間にスレッドが切り替わる可能性があれば、排他として役に立たない。

744:デフォルトの名無しさん
06/08/03 22:31:23
アセンブラレベルで考えるんだ

745:デフォルトの名無しさん
06/08/03 22:49:20
なんだろ？　書き込み見てると、CPU命令レベルでの挙動に思い至らないのが居るな。
ソースレベルの字面で捉えてコンパイルというのが何なのかまったく知らないよう
に思える。

こんなんで日本のプログラマーのレベルは大丈夫なのか？　小中学生だったら
知らなくても無理は無いのか。

746:デフォルトの名無しさん
06/08/03 23:05:44
アセンブラまで降りる必要は必ずしも無いとは思うが
メモリの読み込みと書き出しを同時(atomic)に行うことは
(普通は)出来ないということくらいは知っておく必要がある。

もちろん、プロセッサはそのための命令を(普通は)用意しているが
コストがかかるため、普通にソースを書いた場合
コンパイラはその命令を使ったコードは出力しない。

747:デフォルトの名無しさん
06/08/03 23:16:40
えらそうに講釈たれてても

> 同時(atomit)

この一言で台無しだな。

748:デフォルトの名無しさん
06/08/03 23:25:35
>>747
お前いらないから

749:デフォルトの名無しさん
06/08/03 23:36:58
必死な子がいるなぁ。

750:デフォルトの名無しさん
06/08/03 23:39:29
>>747
別のプロセッサに割り込まれないように
lock等で保護してからxchgしたりincしたりnegしたりするけど
それをatomicと言わないとでも？

例えばあるメモリの内容を+1する場合、
「+1する命令をメモリに対して発行する」ではなくて
「プロセッサがメモリを読んで、+1した値をメモリに書き込む」だし。

751:デフォルトの名無しさん
06/08/03 23:58:41
なに一生懸命説明してるの？

これスレでそんなこと知らない奴なんてあまりいないよ。

俺はただ「atomic」と「同時」って全然違うって言いたいだけなんだが。

まあ俺も atomit とか書いてるようじゃ人のことは言えないわな。(w

752:デフォルトの名無しさん
06/08/04 00:03:37
>>751
もう消えてね(^^)

753:デフォルトの名無しさん
06/08/04 00:18:24
>>751
ずいぶん必死ですね。

754:デフォルトの名無しさん
06/08/04 00:20:13
最近なりを潜めてる、某キティと文体が似てる・・・

755:デフォルトの名無しさん
06/08/04 01:02:29
読むのと同時に書かないと壊れるメモリもあるだぜ？

756:デフォルトの名無しさん
06/08/04 01:19:47
「atomic」は日本語で言ったら「不可分」ちうことですわ。

757:デフォルトの名無しさん
06/08/04 01:23:06
原子力って感じかと思ってた

758:デフォルトの名無しさん
06/08/04 03:38:13
分割不可能な最小単位つうことですょ

759:デフォルトの名無しさん
06/08/04 03:51:04
つまり、鉄腕アトムは分割不可能と言うことで宜しいか。

760:デフォルトの名無しさん
06/08/04 04:08:01
「atomic」には他に「原子の」みたいな意味もあるんですわ。
昔は原子(atom)は物質の不可分な最小単位と考えられていたので。
どっちの意味が先か知らんけどね。

761:デフォルトの名無しさん
06/08/04 07:05:02
で、何が言いたいんだ？

762:デフォルトの名無しさん
06/08/04 07:11:33
atomic bomb 分割不可能な爆弾

763:デフォルトの名無しさん
06/08/04 07:12:41
割ったら被爆しちゃうからね

764:デフォルトの名無しさん
06/08/04 07:17:17
>>761
誰でも知ってるような事をちょっと偉そうにしゃべくってみたかっただけですわ。

765:デフォルトの名無しさん
06/08/04 07:18:59
被爆と被曝

766:デフォルトの名無しさん
06/08/04 07:55:02
>>764
何のために？

767:デフォルトの名無しさん
06/08/04 07:57:34
>>760
なに一生懸命説明してるの？

これスレでそんなこと知らない奴なんてあまりいないよ。

768:デフォルトの名無しさん
06/08/04 08:37:02
「同時」って書いちゃうヤツ以外はね。

769:デフォルトの名無しさん
06/08/04 08:45:15
VRAM(昔のやつ)やWRAM(初代Milleniumが採用した奴)を思い出した。

770:デフォルトの名無しさん
06/08/04 09:45:01
>>768
どこが変なのか未だにわからんのだが？

「読み込みと書き込みが同時に出来ない」
だから
「読み込みと書き込みをatomicに出来ない」(バスロックしなければ)
という意味なんだけど？

771:デフォルトの名無しさん
06/08/04 09:48:31
>>764
俺は知らなかったからタメになりましたよ
一応ありがとう

772:デフォルトの名無しさん
06/08/04 09:53:42
この流れ見て、コンカレントとパラレルの違いが理解出来なかった当時を思い出した

773:デフォルトの名無しさん
06/08/04 10:49:55
既に「atom」という言葉があるからこそ、物質の探求の過程で原子にその言葉を当て嵌めたってことくらい
>758を理解していたら考えるまでもないだろ。

774:デフォルトの名無しさん
06/08/04 11:02:32
>>770
同時(simultaneous)と、不可分(atomic)の違い。

775:デフォルトの名無しさん
06/08/04 11:03:28
意味が分からねえ・・・

776:デフォルトの名無しさん
06/08/04 11:10:09
>>770
恥の上塗り

777:デフォルトの名無しさん
06/08/04 12:38:57
ガキ共の言葉遊びここまで

778:デフォルトの名無しさん
06/08/04 12:49:23
じゃあ今から大人の言葉遊びか・・・ｴﾛｽ

779:736
06/08/04 13:14:37
if (g = g ? false : true)

この場合でも排他にならない??
アホですまん

780:デフォルトの名無しさん
06/08/04 13:19:58
C言語のレベルでどの式がアトミックになるかという事に依存するのが間違いだと思う。
現存する全ての環境でアトミックに実行されるような式でも、それは処理系依存。

781:デフォルトの名無しさん
06/08/04 13:21:37
その後、原子は分割可能であることが判明してしまいました。

782:デフォルトの名無しさん
06/08/04 13:25:55
陽子と電子に分割できるんだっけ？

783:デフォルトの名無しさん
06/08/04 13:27:46
あと中間子

784:デフォルトの名無しさん
06/08/04 13:40:08
それらの素粒子も実は更に……
つーのはやめておこうか。

785:デフォルトの名無しさん
06/08/04 14:05:25
>>779
そもそもどう排他したいの？

786:デフォルトの名無しさん
06/08/04 14:21:49
mkdir() は atomic らしい

787:779
06/08/04 14:38:19
リスト処理でつなげるときに排他したいけど
WinAPI使うしかないみたいですね

788:デフォルトの名無しさん
06/08/04 14:39:02
デッドロックになってしまった場合に
一定時間後に解除するような作りにしたいとき

mkdir() だと unlink() すると atomic では
なくなってしまう危険があるので

rename() の方が良いそうです

URLﾘﾝｸ(www.din.or.jp)

789:デフォルトの名無しさん
06/08/04 15:16:39
>>779
もう諦めて、素直に同期オブジェクト使いなさい。

790:デフォルトの名無しさん
06/08/04 15:28:11
mutex使わないのはなぜですか

791:デフォルトの名無しさん
06/08/04 17:00:56
Windowsでプロセス内だけでいいならCriticalSectionのほうが速いんじゃなかったっけ

792:デフォルトの名無しさん
06/08/04 18:32:01
>>787
それならCriticalSectionで十分

793:デフォルトの名無しさん
06/08/04 18:35:59
>>787
これもAPIになるけど、InterlockedCompareExchangeとかでも自分でロックを作れる。
ただ、CriticalSection使うほうが簡単でおすすめ

794:デフォルトの名無しさん
06/08/04 22:35:03
>>755
> 読むのと同時に書かないと壊れるメモリもあるだぜ？

kwsk

795:デフォルトの名無しさん
06/08/04 22:42:15
それはリフレッシュのことかね。

次ページ