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

1 名前：デフォルトの名無しさん mailto:sage [2006/09/10(日) 00:13:53 ] マルチスレッドプログラミングについて語るスレ。 OS・言語・環境は問わないが、それゆえ明記すべし。 その１ pc3.2ch.net/tech/kako/997/997345868.html その２ pc5.2ch.net/test/read.cgi/tech/1037636153/ その３ pc8.2ch.net/test/read.cgi/tech/1098268137/ その４ pc8.2ch.net/test/read.cgi/tech/1130984585/ 152 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 23:38:46 ] 2つプロセスで共有メモリのデータを共有する サンプルってどこにあるのですか？pthread Linuxのやつを探しています。 153 名前：デフォルトの名無しさん mailto:sage [2007/02/03(土) 09:49:27 ] スレッド関係ないから。APUE買え。 154 名前：デフォルトの名無しさん mailto:sage [2007/02/03(土) 10:21:08 ] VS2005って標準でOpenMP使えたんだな 155 名前：デフォルトの名無しさん [2007/02/18(日) 16:38:41 ] ここで俺がひとまずここまでのレスをまとめる。 マルチスレッドは　ム　ズ　カ　ス　ィ 156 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 20:05:23 ] >>152 だまってmmapすればいいんでないの？ 157 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 21:12:05 ] >>155 お前にこの言葉を授けよう 「糞スレ立てるな」 158 名前：デフォルトの名無しさん [2007/02/20(火) 23:27:34 ] ファイアーモックス! 159 名前：デフォルトの名無しさん [2007/02/24(土) 10:27:57 ] 質問なんですがマルチスレッドでは同じ変数のアドレスの場所を if文等で見に行くだけならぶつかることはないですか？ 160 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 10:34:52 ] 読むだけなら問題ないと思。 最適化には気をつける必要があるが。 161 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 10:40:11 ] FAQだな。 読むだけなら排他不要。 ただしvolatileを忘れずに。 つーかvolatile最強。 162 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:17:45 ] >>159-161 別スレッドからの書き込みも考慮するならロックなどによる同期が必要。 volatile はネタだよね？ 163 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:46:43 ] 他スレッドが変更するメモリを読むなら必要でしょ。 164 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:02:15 ] おっ久々にvolatileが来たか。わくわく。 165 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:16:54 ] >>162 writerが一人、readerが複数ならロックする必要ないよ。 166 名前：デフォルトの名無しさん [2007/02/24(土) 13:28:17 ] >>165 あたまだいじょうぶか 167 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:28:40 ] 意地悪しないで教えてやれよって。 JavaやC#でのvolatileはその解釈であってる。 C/C++のvolatileは割り込みしか想定していないので、マルチスレッドでの動作は不定。 ただしシングルCPUでのマルチスレッドは割り込み(タイマー割り込み)で実現されているのでたまたま動作する。 >>165 変数がアトミックじゃない場合、例えば32bitCPUで64Bitの変数にアクセスする場合などは、 書いてる最中に読み込みされると半分しか書き換わってない状態を読み込む可能性がある。 168 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:34:19 ] シングルCPUのマルチスレッドだと動いてしまうことが多いからね。それで合ってると思い込んでしまうのだよ。 ＣＰＵキャッシュの問題は難解だね。 さらにウィークメモリモデルともなるとさすがについて行けんorz 169 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:43:29 ] 書き込み側が明示的に、アトミック書き込み命令を出せばいいんでね？ 170 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 16:37:41 ] 読み込みもアトミックじゃねーと意味ね-よ 171 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 16:41:40 ] 要は、アトミックに読み込めることが期待できるint程度のデータ以外はなんらかの排他が必要ということでよろしいか。 #いや、intでも排他するべきなのかもし煉瓦。 172 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 18:52:05 ] >>171 > #いや、intでも排他するべきなのかもし煉瓦。 というのが>>168だね マルチCPU環境の排他はバス設計の影響もうけるから 環境を明記しないと言及不能やね 173 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 20:21:33 ] >170 書き込みがアトミックに出来るのに、読み込みがアトミックに出来ない、なんて 変態CPUが現存するのか？そういうCPUではロックをどう実装するんだろ？ 174 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:09:38 ] キャッシュラインをまたぐと面白いよねー 175 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 01:29:43 ] ＞書き込みがアトミックに出来るのに、読み込みがアトミックに出来ない、なんて ＞変態CPUが現存するのか？ ＞書き込み側が明示的に、アトミック書き込み命令を出せばいいんでね？ ↓ ＞読み込みもアトミックじゃねーと意味ね-よ だれも読み込みがアトミックにできないなんて言っとらんわ。 176 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 04:26:18 ] どっちかというと ＞ねーと　 → ー ＞ね-よ　　→ - この不整合の方が気になるな どちらかがアトミックじゃないのかもしれない 177 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 05:04:12 ] こういう意味不明な誤変換はUNIX発のFEPwに多いな 178 名前：デフォルトの名無しさん [2007/02/25(日) 15:04:49 ] volatile方式を知られては困る奴が必死だなｗ 179 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 15:39:00 ] d.hatena.ne.jp/yupo5656/20040618 volatile無意味説 180 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 17:24:44 ] そのリンク先にしても、なぜvolatileでは駄目なのかが書いてなくて 「お母さんが駄目って言ってたから」レベルの話しか書いてないな。 そして、そのURLを貼る>>179も同様。 181 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 17:50:33 ] なぜ volatile で済むと言えるのか、書くかリンク貼るかしてみやがれ。 182 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:59:13 ] volatile - Multithreaded Programmer's Best Friend www.ddj.com/dept/cpp/184403766 183 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 19:32:05 ] >>182 もしかして >>181 へのレスのつもりなのか？ 184 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 19:41:48 ] そんなわけないだろ。逆だ。 "Paradoxically, it's worse to use volatile directly with built-ins, in spite of the fact that initially this was the usage intent of volatile!" 185 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 20:20:26 ] >>182 これって ＞スレッドセーフなメソッドにはvolatileをつける。 という提案だよな？まだ実装はないと思ったのだが。 186 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 22:48:59 ] volatileを実装してるJVMってほとんど無いんじゃなかったっけ 187 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:35:03 ] >>185 実装ってどういうこと？標準 C++ コンパイラがあれば使える手法に見えるんだけど。 188 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:31:15 ] C とか C++ の volatile って I/O レジスタとか, 割り込み同期変数とかを, オ プティマイザがレジスタキャッシュしないように指示するために導入された物で, バリア同期命令とか生成する処理系は皆無のような気がするが... 俺の認識が古くって, バリア同期とか生成してくれる処理系が既にあるんだった ら先にあやまっとく 189 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 05:30:32 ] 何故「volatileで済む用途」のケースにメモリバリアがどうのという話になるのかわからんね。 簡単な例で言えば (タイマ割り込み等で更新される)カウンタを読む場合とか 複数スレッドで値を読み取るとしても、ロックする必要なんか無い。 たとえ1ns更新が遅れたって、問題が出ることは無い(問題が出るようなら、設計がおかしい)。 え、更新時の再入を考慮しろって？ そういうのを「設計」と言うんだろうに。 190 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 06:29:25 ] >>182 int func() const { } はよく使うが、int func() volatile { } を実際に使ってる例ははじめてみる。 ただその記事のLockingPtrは func() volatile の仕組みだけ拝借して実際の排他はmutexでやってるようだ。 よく理解できない部分もあるがvolatileしておいてconst_castで限定的に穴あけてるのだろうか。 このスレで問題になるのはそこではなくて、 記事の最初と２番目のコードで　while (!flag_)　のflagがvolatileだけでいいのか、 同期機構を使わなくてはいけないかのポイントだと思う。 191 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 07:52:54 ] >>188 volatileで済むってのは、コヒーレントキャッシュを持っている環境で アトミックに読み書きできるサイズ限定だから、メモリバリアは関係ないよ。 2つ以上の変数に依存関係があったら、volatileだけでは無理。 一般論の話をすれば、キャッシュの一貫性を保障しない環境もあるから int程度でもvolatileでは駄目という話になるが。 192 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:15:17 ] ちゃんと読めてないが、>>182って、コンパイラの実装とか関係なくて constみたいな印としてvolatileを使ってみようっていう提案だよね？ 193 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 19:26:29 ] volatileの仕様は処理系定義だとあれほど言ってるのに… 処理系を指定しないでvolatileについて語れることはない 194 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 21:25:32 ] 処理系どころか言語すら指定されてない気がするのは 漏れだけではないはずだ 195 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 00:02:42 ] とりあえず、volatileをCの最適化阻害だけと仮定して、 >>191 一貫性を保証しなかったとしても、それはあくまで保証の話。 いつまで経っても同期されないような腐ったCPUってあるの？ あったとしたら処理系としてBrokenだよなぁ・・・。 >>193 ここに書いてる人のほとんどは処理系依存だなんて承知の上でしょ？ とりあえず、intだとしても同期やメモリーバリアは必要か？ って問いはもう少しレベル分けした方がいいと思う。 1. 読み込みに依存した書き込み(read-modify-write) ⇒ 同期もしくはメモリーバリアを含んだCASが必要。 2. 読み込みに依存しないが、確実に更新を見る必要がある ⇒ OoOを回避するために、少なくともメモリーバリアは必要。 3. 読み込みに依存しないし、更新は近いうちに反映されればよい ⇒ volatileでレジスタへの張り付きを阻害するだけで問題なし？ >>189の「更新が遅れても構わない」は3になると思うんだが。 196 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 01:19:13 ] つまり、例えば時間掛かる処理をするスレッドがあってその進捗をプログレスバーに出すような用途なら、 進捗を書き込むのを処理スレッドに限定してGUIスレッドでそこをvolatileで参照するのもありってことでOK? 197 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 01:57:30 ] マルチスレッドの話は環境によって差異がありすぎるから 環境を限定しない討論に何の意味もないって感じだな。 198 名前：デフォルトの名無しさん [2007/02/27(火) 03:01:55 ] volatile最強伝説が吹き荒れるｗｗｗ 199 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 08:43:30 ] > 195 > とりあえず、volatileをCの最適化阻害だけと仮定して、 曖昧な仮定だな。 まずはお前の想定している処理系と、そのマニュアルにある volatile参照の仕様を書くんだ。 200 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 09:11:34 ] もう>>182みたいにvolatileキーワード使って組込型でも何でもロック必須にしちゃいなyo! template <typename T> struct NativeWrapper { operator T&() { return obj; } private: T obj; }; volatile NativeWrapper<int> syncint; mutex mtx; LockingPtr<NativeWrapper<int> > pInt(syncint, mtx); *pInt = 10; 201 名前：195 mailto:sage [2007/02/27(火) 12:18:08 ] >>196 そんなとこ。他ではTwo-Phase Terminationの終了フラグとか。 こちらの場合はメモリーバリアを含んだ同期をループの内部で 実行する事が殆どだから、次のループで確実に気付くだろうけど。 >>197,199 おまえら処理系依存って書きたいだけだろ？ 実際のとこはどうなのか、って話がしたいんだよ。 少なくともOoOやコヒーレンシが問題になるんだから、 最低限SMP/Multi Core/HT等のアーキテクチャとなる。 例えばIA-32,Power PC,Sparc等のSMPの類をサポートした アーキテクチャのうち、>>195よりも厳しい制約が必要と なるものは存在するの？ 202 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:04:58 ] >>201 個々の CPU について考えるなんて面倒だから、 保証されてるかどうかで話したほうが楽なのに。 今は無くても将来にわたって無いとも言えないしね。 203 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:04:14 ] >>193 データ構造上の都合か何かでキャッシュラインをまたぐような位置から int を読み込む場合には 3 もだめじゃないかな。 204 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:12:43 ] >>201 Intel Itanium では、非共有キャッシュが大きい上にキャッシュフラッシュの順序が 書き込みの順序と異なる。ので、 ・volatile int a を監視 ・aが変更されたら「何か」を行う という処理の場合、大抵は「何か」の準備が出来たから a を1にしてるんだと思うけど、 メモリバリアが無いとその準備の処理結果を読み出せない可能性がある。 例） volatile size_t buflen; volatile char buf[max_buf]; で、 スレッド1:　buflen = read(hoge); ... スレッド2:　if (buflen>0) { bufを利用; } で、（スレッド2側のCPUから見て）buflen には read の結果のバイト数が書かれているが、 buf の内容はデタラメ、という状況がごく当たり前にあり得る。 205 名前：195 mailto:sage [2007/02/27(火) 14:54:42 ] >>203 キャッシュラインをまたぐ場合って、普通のコードじゃ起きないし、 char buf[sizeof(int)+1]; *(int *)(buf+1) = 0;した場合とかでしょ？ 今では例外飛ばさずにアクセスできるアーキテクチャの方が少数派なのでは？ >>204 他の変数を確定的に見る必要がある場合はOoOの関係で無理。 >>195はひとつのintを扱う場合なつもりで書いてます。 >>196を例にすると、タイマでプログレスバーを更新する時はvolatileのみ、 最後に終了したかを確定的に判断したい時だけpthread_join()するケースとか。 206 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:21:57 ] >>205 PCで使われているCPUの98%は、それをごく普通に実行します。 任意位置からの32bitの整数読み出しはMPEG系のビデオコーデックの 処理では多利用されるし。 207 名前：195 mailto:sage [2007/02/27(火) 16:11:02 ] CPUの数が多いのは当たり前だからアーキテクチャって書いたのに。 そんな下らないツッコミは要らないって。。 Codecの処理だろうが、境界整列に反したメモリアクセスなんて 行儀の悪いコードなんじゃないの？少なくともポータブルじゃない。 処理系依存のレベルで言ったらvolatileの比じゃないと思うんだけど。 208 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:25:35 ] アーキテクチャの数で言って多いか少ないかについては、 漏れは何も言っていません。 実存するシステムの大半では割合で例外は飛ばないという （関連する）別の事実を提示しただけですよ。 209 名前：195 mailto:sage [2007/02/27(火) 18:33:40 ] >>208 おまえ例外が飛ばないって書きたいだけだろ？ 実際のとこはどうなのか、って話がしたいんだよ。 210 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 19:55:55 ] 理屈で勝てそうにないと急におまえ呼ばわりですか。 実際の例で言うなら、MPEGのシステムストリームから4バイト長さの整数を取り出すとき、 ポータビリティを重視している ffmpeg ではバイト単位で取り出して整列してますし、 IA32/64が前提のIPPではポインタをそのままデリファレンスしてアライメントを気にせずに整数を取り出してます。 「普通のコードじゃ起きないし、例外飛ばさずにアクセスできるアーキテクチャの方が少数派」だから、 キャッシュラインまたぎの問題は無視してよいとでも言いたげな感じですが、 実際のとこどんなプログラムをどれだけ調べた上で書いてるんですか？ 211 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 20:59:04 ] IA86において、そもそも、アラインメントが狂った位置への アトミック書き込みはできない。 212 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:54:58 ] 傍から見てるモノとしては 実装の詳細じゃなくてアーキテクチャの視点で語ってほしいです>< 213 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 22:12:28 ] 「相談室」なんだから、なにか適当なターゲットを想定するのが普通だろ メタ論がやりたいならどっか適当にスレ立てろよ これがほんとにマルチスレッド 214 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 23:34:05 ] そういうアクセスははなからそういうあくせすという前提で特別に処理を書くんじゃないの？ intでもアトミックに読めないとか、そういう問題とは別次元だろ。 215 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 23:35:07 ] わざとあえて意識してそういうことをしないとそういうことは起こらない。 216 名前：195 mailto:sage [2007/02/28(水) 01:26:31 ] >>210 >>209は自分じゃないんで・・・。 他の方も書いているように、CodecみたいにCPUベタベタな 最適化を行う場合を考えてもしょうがないかと。 今のところは>>189や>>196みたいなケースの場合にvolatileで 不十分な証拠は(処理系依存を除いて)出ていないんじゃないですか？ そんなわけで、今のところ>>180から進展はなさそうに思います。 >>213 自分はPCサーバクラスで使われるCPU辺りをメインに書いてます。 今はノートですらDual Coreだったりするので、その辺りも含めて 昔で言うワークステーションクラスまででしょうか。 217 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 02:53:24 ] 言語組み込みの volatile で全部済ませられると主張するなら、 「あぁそうだといいね」とも思えるが、場合によってはロックが必要なことは 理解しているようだし。そうなると細かいこと考えずに全部ロックしとけば いいと考えそうなもんだ。 なんでそんなに必死になってまでロック使いたくないの？ わざわざ保証されてないコード書くメリットが何かあるの？ 218 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 06:28:24 ] このスレは頭ごなしにmutex使えやゴラーというやからが多いから意固地になってるのだろう。 結論はそうなんだけど、そこに至る過程を検証したいというのも分からないではない。 mutexの中の人が何をやっているかとか、実際身近にあるＰＣで賢い小人さんがどう働いているかとか、 そういう話題なら問題は無いだろう？ 219 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 13:20:29 ] >>217 >なんでそんなに必死になってまでロック使いたくないの？ 実行コストに決まってるだろ。 実行コスト無視できるなら、スピンロック、read-writeロック、プロセス内Mutex、プロセス間Mutex、 の使い分けなんて必要ない。 ただ、volatileで生成されるコードと、他のロックでどちらがコストが高いかは知らん。実行系によるし。 220 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 13:51:46 ] スレッド間で変数を共有する場合問題になるのは次の４つくらいか。 1)変数のレジスターへのキャッシュ。 2)コンパイル時の命令の並び替え。 3)CPUによる命令の並び替え(out of order) 4)CPUキャッシュ間の非同期。 1,2はコンパイラの仕事。 3は単一CPUでは発生しない。マルチCPUでは両方のケースがある。 4は単一CPUでは発生しない。マルチでもコヒーレント(一貫性)が保障されている処理系が多い。 3,4が発生しないでメモリー更新の順番が正しく見える構成をstrong memory orderと呼ぶ。 volatileだと1,2でかつアトミックな操作ができる単独の変数のみ。 メモリバリアは1,2,3,4すべてを満たしていて、 同期系のファンクションを使えばメモリバリアは適切に適用される。 書き込みが１スレッドで多数の読み込みスレッドがある場合に通常のLockが負荷が高いようなら、 ReadWriteLockとかInterLockとかそういったものを検討すべきだろう。 221 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 13:57:54 ] >>195 ＞いつまで経っても同期されないような腐ったCPUってあるの？  ＞あったとしたら処理系としてBrokenだよなぁ・・・。  ないとは言い切れない。互換性、安全性をとるなら同期ファンクションを使っておこう。 windowsXPまではstrong memory orderを前提にしているらしい。 MSDNのvolatileの説明が変なのはこのためだろうか。 移植性を無視してターゲットを絞るなら独自にいろいろやるのもありかもしれないが、 windows2003(今のところItanium用だけらしいけど)からは上記の3,4があるweak memory orderも 視野にいれているらしいから、こういうヴァージョンアップ時に困るな。 222 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 17:09:18 ] 組み込み用だとキャッシュの同期なんて全くしない環境もあるようだが、 （そもそもCPUがマルチプロセッサ用に作られていない） そういう環境にマルチスレッド対応のOSが移植されてるかは、 ググってみたが見つからなかったな。 一昨年あたりから、組み込み用CPUでもキャッシュ同期メカニズムを 持った物が出てきたようで、SMP対応のlinuxが移植されてたりするけど。 223 名前：195 mailto:sage [2007/02/28(水) 17:27:11 ] >>218 ほぼそんなとこです。 あとは、なんでPOSIX ThreadsにCASがないのか、とかね。 プリミティブ志向な設計なんだから追加されてもいいのに。 有名どころのアプリのいくつかは自前で実装してたりするし。 >>221 そりゃないとは言い切れないでしょ。 でもそういうのって、二の補数表現や1byte=8bitを仮定して プログラムを書くのは良くないってのと同じなんじゃないの？ 1word=36bitみたいな変態アーキテクチャを相手するのと一緒。 224 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 00:19:15 ] _beginthreadの使い方について質問です。 子スレッドの処理が止まっているとき、終了する方法が知りたいです。 ----------------------------------------------------------------- //子スレッドの関数 void thread_func(){ //Sleep();やソケットのaccept関数など永久に待つ関数などで、 //処理が止まっているので終了状態になりません } //子スレッド呼び出し thread_id = _beginthread(thread_func,0,(void *)param) //終了処理 GetExitCodeThread( thread_id,lpExitCode );//終了コード取得 ExitThread(lpExitCode );//終了コード指定して終了 CloseHandle(thread_id);//ハンドル閉じる ----------------------------------------------------------------- １、子スレッドのsleep、accept関数など待ち状態を、解除する方法あるでしょうか？ 処理が進めば、_endthreadで終了することが出来きるのですが。 ２、強制的に親スレッドから、安全に子スレッドを強制終了する方法あるでしょうか？ _beginthreadは、CreateThreadを呼んでるみたいなのですが、上記のように "//終了処理"しても大丈夫でしょうか？安全な方法教えていただけないでしょうか。 よろしくお願いします。 225 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 00:19:22 ] >>223 なんで良くないと言われていることをわざわざやりたがるの？ 226 名前：sage mailto:195 [2007/03/01(木) 00:43:41 ] >>225 良くないって、仕様で未定義だからってだけでしょ？ 検証もせずに「お母さんが駄目って言ってたから」な方が嫌。 227 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 01:06:04 ] >>226 最近のレスでロック API の仕様の根拠となるものはあらかた提示されたんじゃないの？ 228 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 01:22:09 ] >>224 とりあえず、 ・必要なら、子スレッドでは極力タイムアウトするAPIを使う ・_beginthread()の場合、スレッド関数の戻りで子スレッドのハンドルは自動開放されるので 　明示的に開放する必要はない ・少なくとも_beginthread()のハンドルにCloseHandle()を使うのは間違い 　きちんと対応する関数をセットで使わなければいけない ・ただ、親スレッドでExitThread()したら、その後のCloseHandle()は実行されないよ ・子スレッドの安全な中断方法はない。 突っ込み所満載すぎるので、MSDNなりナニなりよく読むべし。 229 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 03:23:13 ] >>228 タイムアウト処理を考えるという方針でいきたいと思います。 sleepは時間を短くすればいいですし、 acceptは、selectを使ってrecvのタイムアウト関数（timeoutRevcとします） と同じにすれば、timeoutAccept関数作れるかもしれないです。 ・timeoutAccept抜けたら、はじめの一回目は、ソケットが読み込めるのわかってるので普通のrecv関数を呼ぶ。 ・次の受信から、timeoutRevc呼ぶ感じでしょうか。 いくつも箇条書きでアドバイス、ありがとうございました。 230 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 07:04:23 ] 229です。 acceptする前に、select関数使えないんでしょうか。 FD_ZERO(&readfds); FD_SET(soc,&readfds); select(width,&readfds,NULL,NULL,&timeout) socは、きちんと渡せていたんですが、接続試しても select抜けられずに、全部タイムアウトになります。 accept呼んでからじゃないと、ソケットの読み取り可能か わからないかもです。 スレ違いになりますので、ネットワークのスレに行きたいと思います。 ありがとうございました。 231 名前：デフォルトの名無しさん [2007/03/01(木) 11:14:25 ] やべーvolatile最強すぎる 「volatileが最強でない環境って存在するの？」 「現存しないからvolatile最強ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」 >>161 でFA出てるしｗｗｗ 232 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 11:18:50 ] 2000年問題に通じるものがあるな 233 名前：デフォルトの名無しさん [2007/03/01(木) 12:28:10 ] [すれ立てるまでもない質問はここで] で聞いてたんだが、此処で聞いた方が良いかと思ったので、 再質問させてもらいます。 Windows MFCでマルチスレッドは止めておいた方が良い と、良く聞くんだけど、具体的にどんな問題が発生するのか 掲示しているところが無いんだけど、どうしてMFCでの スレッドは嫌われるのか教えてもらえないでしょうか。 単なる好奇心なので、仮説でもうれし。 234 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 12:42:43 ] 誰が言ってんだ、そんなこと。 235 名前：デフォルトの名無しさん [2007/03/01(木) 12:48:10 ] >>233 それま色々なスレで同じ質問をしないほうが良いと言われただけでは？ 236 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 12:50:14 ] >>233 とりあえず移動元に誘導書いておけよ、マルチ扱いされるぞよ。 俺も聞いたことない。 237 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 13:27:04 ] MFCに限らず、マルチ(複数の)スレッドで質問するのは良くない。 238 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 14:21:41 ] ﾜﾛﾀ 239 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 16:05:38 ] >>224 つ support.microsoft.com/kb/254956/ 240 名前：233 mailto:sage [2007/03/01(木) 16:17:27 ] >>234 >MFC のシステムそのものがマルチスレッドに向いていない。 ttp://www.kab-studio.biz/Programing/PragmaTwice/Main/292.html さすがにどこで見たかを思い出せなかったので検索して 出てきたのが例えばこれとか。 >>236 >>237 移動元に書いてきたよ。 ごめんよ。 241 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 17:05:31 ] >>240 WaitForSingleObjectで待つんじゃなくて自イベントで通知 MFC関係なくないか？ 読みづらいし会話式がアレだな 242 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 17:17:57 ] ＵＩスレッドは確かに使わないかもしれない。向いてないとか難しいとかいうより必要性が薄い。 ワーカースレッドについては特にMFC特有の問題じゃないな。 243 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 18:03:52 ] >>240 じゃあ、そのサイトが間違い。 いや間違いというか、MFCがマルチスレッドに対して便利な機構を用意しているかというとNoだけど、 マルチスレッドを意識してないわけじゃない。つまり、ユーザーからロックできないグローバル変数、 クラス変数はロックしてる。 なんで、ユーザーからロックできる部分については、勝手にロックして、スレッドセーフにしろよ、 ってスタンス。それを「向いてない」と表現するかどうかは人による。 ・MFCとマルチスレッドの関係 (Afx...でのMFCグローバル情報へのアクセス等)、 ・Win32とマルチスレッドの関係 (SendMessageがらみのウィンドウループの把握、WinSockでのWM_を使った非同期処理等)、 ・一般的なGUIシステムにおけるマルチスレッドの作法 (GUIスレッドを止めない、長時間処理は別スレッド、非同期化等) を分けて考えるべき。 244 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 18:24:21 ] まぁMFCはガベコレがないという致命的欠点を持っているなんて Wikipediaに書かれるほど挫折した連中に嫌われているってことだな。 245 名前：デフォルトの名無しさん [2007/03/01(木) 18:47:00 ] > それを「向いてない」と表現するかどうかは人による。 「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？ 「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。 >まぁMFCはガベコレがないという致命的欠点を持っているなんて これは笑いどころですか？ 246 名前：243 mailto:sage [2007/03/01(木) 19:03:59 ] >> それを「向いてない」と表現するかどうかは人による。 >「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？ >「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。 いや、俺に言われても。 247 名前：244 mailto:sage [2007/03/01(木) 19:38:14 ] >>245 > これは笑いどころですか？ いや、俺に言われても。 248 名前：244 mailto:sage [2007/03/01(木) 19:57:04 ] >>247 いや、そこで騙られても。 249 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 21:02:37 ] MFCにガベコレを求めるとかバカとしか思えない 250 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 21:11:36 ] 244はそんなことを言ってるわけじゃないんだが。 改行位置のせいで勘違いするのも分からんでもないが。 251 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 21:27:35 ] このスレのガベージをコレクトしたい 252 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 22:08:15 ] 　　　　　　　／　＿＿＿＿ヽ　　　　　　 　 　　／ ￣　　￣ ＼ 　　　　　　　|　 | /, −､, -､ｌ　　　　　　 　 　 /､　　　　　　 　　 ヽ 　　　　　　　| _|　-|　 ･|<　||　　　　　　 　 　 |･ |―-､　　　　　　 | 　　 , ―-､　(6　 ＿ｰ っ-´､}　　　　　　 　 ｑ -´　二 ヽ　　　　　 | 　　 |　-⊂)　＼ ヽ_ ￣￣ﾉﾉ　　　　　　 　　 ﾉ＿　ー　 |　　　　　| 　 　 |￣￣|／ （_ ∧￣ / ､　＼　　　　　　　 ＼.￣｀　 |　 　 　　/ 　 　 ヽ　　｀　,.|　 　　￣　　|　　|　　　　　　 　　O＝＝＝＝＝ | 　 　 　 ｀− ´ |　　　　　　　| ＿|　　　　　　　　/　　　　　　 　　 | 　　　　　　 　　|　　　　　　 （t 　）　　　　　　　/　 　 /　　　　　　| 「>1からマークスイープでGCするよ！」　　　「コンパクションも忘れずにね」 １時間後… 　　　　　　,-――-､　　　　　　　　　　　　　　　 　　　　　　　　　＿＿＿ 　　　　　 { , -_−_−　　　　　　　　　 　　 　　　　　　　　　　 ／　　_ 　　_ ヽ 　　　　　.(6（ /),(ヽ|　　　　　　 　　　　　 　　　　　　　　　　/　 ,-（〃）bヾ）､l 　 　　 ／人 ー- ソヽ ＿　　　　　　　　　　 　　　　　　　　 |　/三 U 　|~ 三|_ 　 ／　 /　 | ￣_∧／　　 ヽ　 　　　　　　　 　　 　　　　　　|（__.）―-､_|＿つ_） 　 　 　 | |　 ＼/_/-､　 　　/　 　　　　　　　　 　　　　　　 /　 /｀ー--―-´ / 　 　 　 |-＼ _|_ ）＿|　　 /　 　　　　　　　 　　　　　　　　|　 //￣（ ｔ ）￣/ 　 　 　 ヽ-|￣|　 |＿|_ /　 　　　　　　　　 　　　　　　,− |　　 | ヽ二二/⌒l 　 　 ／　 l―┴､|＿＿)　 　　　　　　　　　　 　　　　|　 （＿＿＞ -―（＿ﾉ 　／　 　　｀-―┘ /　　　　　　　　　　　 　　 　　　　｀- ´ 　　　　　　 　 　 / 「>1しか残らなかった…」　　　　　　　　　　　　　　　「テンプレへのリンクもなかったのか！」

---

---

[ 続きを読む ] / [ 携帯版 ]

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