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

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/ 136 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 21:35:35 ] 我が社では回転元彌チョップと呼んでいる。 137 名前：129 mailto:sage [2005/12/17(土) 22:48:09 ] >>131 よくわからんです >>133 その単純な変数の読み書き以外に、どうしても spin lock を使い たいんじゃ! とか、spin lock じゃないとうまくいかないような、 典型的なケースってないすか? 138 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:05:24 ] >>134 じゃあ、どこがおかしいのか指摘しろよ。 業界最底辺を何年も続けてる事だけが自慢の 低脳プログラマさんよ。 マルチプロセッサでも、 ロックを取得している状態で実行権を奪われたら起こりうるのは確かだけどな。 139 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:40:53 ] >>138 だれか解読頼む。 140 名前：デフォルトの名無しさん [2005/12/18(日) 01:43:49 ] >>138 お前の存在そのものがおかしいことを指摘してやらんでもない。 141 名前：デフォルトの名無しさん [2005/12/18(日) 01:46:16 ] 指摘してほしいのに　しろよ　はないだろ。 せめて、「わたくしは無知なので、できれば、ご指摘いただけないでしょうか？」だろ。 誠心誠意で言葉に気をつけろ。 142 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 01:51:21 ] ナニこいつ 143 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 01:59:03 ] 具体的に指摘しないのは荒らしと同じだから放置汁 144 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 14:48:34 ] チョンはすぐにファビョるからやあねえ。 145 名前：デフォルトの名無しさん [2005/12/18(日) 18:57:20 ] Win32（XP）で下のような排他制御を考えないプログラムを書いて 実際にハングするところを確かめたかったのですが、何度実行しても上手くハングしてくれません たまたま運が良くてハングしなかっただけなのでしょうか？ご教示願います #include <stdio.h> #include <windows.h> #include <process.h> unsigned __stdcall mythread(LPVOID); int main(){ unsigned int thID; HANDLE hTh = (HANDLE)_beginthreadex(NULL, 0, mythread, NULL, 0, &thID); for (int i = 1; i <= 100; i++) { FILE *fp = fopen("test.txt", "a"); fprintf(fp, "Main---%d\n", i); fclose(fp); } WaitForSingleObject(hTh, INFINITE); CloseHandle(hTh); return 0; } unsigned __stdcall mythread(LPVOID lpx) { for (int i = 1; i <= 100; i++) { FILE *fp = fopen("test.txt", "a"); fprintf(fp, "Thread---%d\n", i); fclose(fp); } return 0; } 146 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 19:34:13 ] この程度でハングはしないと思うが、 同期とらない＝ファイルの中身はグチャグチャになるの？　 って意味ならば出力されたファイルを読め。 147 名前：デフォルトの名無しさん [2005/12/18(日) 19:38:13 ] >>146 ファイルもぐちゃぐちゃになりません。きちんと出力されます また、一度に書き込む文字列のサイズを100KB程度と大きくしてもきちんとと出力されます しかし、どちらかのスレッドにSleep(0)等を入れる程度でぐちゃぐちゃになります 境界はどこに有るのでしょうか？ 148 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 21:36:48 ] ヒント：ストリーム系はバッファリングされるから混ざりにくい。 149 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 00:03:34 ] fprintf-fcloseの間にスレッドが切り替わらなければセーフ。 んで、100回くらいのループではWindowsのタイムスライスに 引っかからなかったりするのでは。 マルチプロセッサなら、カナリヒドい事になりそうな気がするのだけれど。 150 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 06:15:26 ] >>149 > fprintf-fcloseの間にスレッドが切り替わらなければセーフ。 そうとは限らない。 151 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 10:16:27 ] >>148 「一度に書き込む」っていってんだから、 バファリングの有無は関係ないような気がするんだけど。 152 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 21:48:15 ] そもそもハングするのか？　ハングはしないだろ 153 名前：145 mailto:sage [2005/12/20(火) 01:28:57 ] いろいろ調べてましたが IO絡みの関数は基本的にスレッドセーフに作られてるから ってのが答えみたいです お騒がせしました >>149 それは違います。たとえfcloseをコメントアウトしてもハングしません >>152 ハングはしないようですね このページに「大抵ハングしてしまいます」と書かれていて気になったのです www.kumei.ne.jp/c_lang/intro2/no_106.htm まあこのページに限らずネット上でマルチスレッドを初心者向けに教えているサイトでは 大抵同じような書かれ方がされてるので、 もしかすると私の検証が不十分なのかもしれませんが･･･ 154 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 04:36:05 ] 同時に書き込んで壊れなくても 後からの書き込みで前の書き込みは上書きされて消える訳だが 155 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 14:28:30 ] >>153 ランタイムライブラリがスレッドセーフで無い場合はハングするかもしれないけど、 VS2005からシングルスレッドのランタイムは無くなっているなあ。 156 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 14:44:54 ] 「ハングする」なんて言い方は止めて、 「動作が未定義」くらいにしてくれないか。 本当にハングアップするかどうかを問題にしているんじゃないだろ? 157 名前：デフォルトの名無しさん [2005/12/25(日) 13:24:46 ] >>156 このマニアめが。 158 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 13:38:00 ] /MT ってやってればたいがい大丈夫だろうけど、スレッドセーフでない関数で gethostbynameとかが未定の動作されるとかなり困る、 無理矢理排他同期とって使ってるけどなんかかっこ悪い。 159 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 13:45:27 ] winsockのgethostbynameはスレッドセーフじゃなかったっけ？ 160 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 13:49:25 ] /MTってことはWindows? getaddrinfoはMT-Safeでしょ。 msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/getaddrinfo_2.asp には明記してないけど、gai_strerrorは違うから〜って書いているくらいだから。 161 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 13:54:49 ] 明記してあるな。 >Remarks >The gethostbyname function returns a pointer to a hostent structure-a structure allocated by >Windows Sockets. The hostent structure contains the results of a successful search for the >host specified in the name parameter. >The application must never attempt to modify this structure or to free any of its components. >Furthermore, only one copy of this structure is allocated per thread, so the application should 　　　　　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > copy any information it needs before issuing any other Windows Sockets function calls. 162 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 13:57:38 ] struct hostent *host; host = gethostbyname(argv[1]); ってな形だし、どうみてもスレッドセーフでないと思ってた。 スレッド固有メモリなんてものでも使ってるのかな。 163 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 14:14:38 ] >>161 それだけでMT-Safeだとは限らない。 164 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 14:50:26 ] getaddrinfo ってのがあるんだ、 参考にしてた本が古っかったので知らなんだ。 該当箇所を書きかえねば orz 165 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 15:28:14 ] ２ちゃんで書き込みするときの文字2048制限解除方法誰か教えてください。 166 名前：デフォルトの名無しさん mailto:age [2005/12/25(日) 15:29:18 ] 制限解除して書き込んでる人が増えてるんですが 167 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 15:38:13 ] >>164 古いWindowsではありませんのでその辺は配慮を。 168 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 03:11:55 ] 「スレッドできる」と「スレッドでファイル操作しても問題ない」は同義じゃないよなあ。 単一リソース操作は対策しないと普通は競合するよ。 169 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 19:09:27 ] マルチスレッドなサーバプログラムを作ってみようかと思ってます クライアント数が少ない場合1クライアントに1スレッドを割り当てればいいかなと思いますが クライアント数が多い場合はどういった方法が良いんでしょうか？ 1スレッドあたりのクライアント数を決めてスレッドごとにselect()するとか 親スレッドでselect()して処理を別スレッドに任せるとか一応考えてはみていますが どういった方法がスタンダードなんですかね？ 170 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 20:42:42 ] ジョブキュー 171 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 22:37:27 ] +スレッドプール 172 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 23:38:08 ] 裏技としてApache 勉強にはならんな・・・ 173 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 13:56:11 ] apacheって何言ってんの？ ネットワークプログラミング相談室にも沸いたバカだろか。 174 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 15:39:12 ] なぜそこで、あと半歩踏み込んで「apache馬鹿よね〜」とか言えないよねぇ 175 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 16:51:48 ] おバカSunよね〜 176 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 08:35:56 ] くだらない質問ですみませんが TCPで同じディスクリプタにread()するスレッドとwrite()するスレッドを分けたとき 全二重だから同時にread()とwrite()を実行しても問題ありませんよね？ あと片方が同期無しでclose()するのって問題ありますかね 177 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 08:40:05 ] 同時にread/writeしても問題なし。 HTTPサーバのようなものを作ってるなら相手が一方的にclosesocketしたくらいでおかしくなっては困る。 178 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 12:25:53 ] Solaris2.xではデッドロックしてたなあ（遠い目） 179 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 03:50:46 ] x86 とかで int の値を書き込むスレッド(A)と読み込むスレッド(B)がある場合， 更新途中の値が(つまり 32bit 中の 16 bit が新しい値で残りが古いままとか) B に見えてしまうということはありうるでしょうか？ # long とかだとまずいですよね． 180 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 04:40:29 ] >>179 前スレで延々やってたと思う そこが本題でなければ、排他で済ませて先行った方がいいと思うヨ 181 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 04:56:02 ] >>180 レスありがとうございます．前スレの読み方がよく分からないので憶測になっ てしまいますが，前スレの議論では結局「あり得る」という結論に至ったとの 理解で良いでしょうか？ 参考になりそうな資料へのポインタを教えて頂けるとうれしいです． > そこが本題でなければ、排他で済ませて先行った方がいいと思うヨ 性能的な面から可能な限り B に対する排他処理は避けたいと考えています． 182 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 15:07:19 ] >>181 OSに用意されている、Atomicな書き換えAPIを利用すれば宜しかろう。 32ビットバスでアライメントも合っていれば素直にAtomicに書き換わると思うが。 183 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 16:15:06 ] レスありがとうございます。調べてみます． 184 名前：デフォルトの名無しさん [2006/01/13(金) 02:07:27 ] マルチスレッドプログラミングで注意することを列挙してくれ。 185 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 02:19:22 ] ひとつ！急いで口で吸え！ 186 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 14:53:41 ] ふたつ! 不埓な悪行三昧! 187 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:18:23 ] みっつ! 想定の範囲内です。 188 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:55:53 ] よっつ、読んでも書いちゃダメ 189 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:56:28 ] いつつ、いつも心に排他処理 190 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:59:48 ] むっつ、無理せずmutex 191 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 17:21:48 ] ななつ、仲良くSemaphoeで共有 192 名前：>>46 mailto:sage [2006/01/18(水) 23:32:09 ] やっつ、やっぱりここでも排他処理 193 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 00:43:25 ] ここのつ！心を鬼にして排他処理 194 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 01:03:03 ] 糞スレ立てんな 195 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 01:39:58 ] とう、でとうとう割り込まれた。 排他だけじゃなく、割り込み禁止も忘れないでね☆ 196 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 01:53:34 ] HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, NULL)で作ったイベントに対して SetEvent(hEvent);←TRUEがかえる でも、その次に WaitForSingleObject(hEvent, 0)とやってもWAIT_OBJECT_TIMEOUTがかえる。 こういうことがおきているのですがどのようなことが考えられますか？ 197 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 07:15:10 ] >>196 SetEventは成功したけど、イベントオブジェクトがシグナル状態になる前にWaitForSingleObjectがタイムアウトした。 198 名前：>>46 mailto:sage [2006/01/21(土) 09:16:54 ] >>196 他のスレッドが一生懸命 ResetEvent(hEvent) を やってる。 199 名前：196 [2006/01/21(土) 14:20:25 ] >>197 SetEventってシグナル状態にした後で戻るわけではないのですか？ >>198 ソースを見る限りほかのスレッドが触ることはなさそうなのですが確信持てないです。 SetEventとWaitForSingleObjectの間で他のスレッドにスイッチしなければそういうことはおきないですよね？ であれば確認のためにはスレッドのスイッチをSetEventとWaitForの間で抑制してあげればいいですよね。 なにか、任意のコードブロックではスレッドスイッチを禁止する方法はないでしょうか 200 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 14:26:18 ] ちょっと確認だが、WaitForSingleObject()の第二パラメータの0ってNoWaitだよな? 単に待てば委員で内科医? 201 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 14:42:02 ] >196のままのコードを実行してみたけど、ちゃんと0が帰ってきたよ。 202 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:04:56 ] >>199 >>196の事象が事実であるなら、そういうものだと思って使うべき。 嫌なら別の手段を用いるべき。 203 名前：196 mailto:sage [2006/01/21(土) 15:47:24 ] >>200 SetEventしてそれが本当にシグナルになったかを見るためにWaifFor・・したのですが、 それがなぜかシグナルになっていないのです。 >>201 検証ありがとうございます。>>196のままのコードだとそうなると思いますが、実際にはほかのスレッドもいるので 何が起きているかはよくわかっていません。（デバッガでステップ実行したりデバッグライトを入れるだけで動きが変わるため） とりあえず、月曜にほかのスレッドがResetしていないか確認したいと思います あとSetEventって非同期に動いたりしませんよね？ SetEvent(hEvent); ここで誰かがResetEventしない限り下はTRUEにならないですよね？ if(WaitForSingleObject(hEvent,0)==WAIT_OBJECT_TIMEOUT) { } 204 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 17:01:11 ] >>203 だから、WaitForSingleObject(hEvent, INFINITE)してみたら? 205 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 21:15:12 ] そもそも、WAIT_OBJECT_TIMEOUTってなんだ？ 成功：WAIT_OBJECT_0 or WAIT_TIMEOUT or WAIT_ABANDONED 失敗：WAIT_FAILED のいずれかが、WaitForSingleObject()の戻り値なんだが・・・ とりあえず、該当部分のコードを晒せ、晒したくなかったらコピペも満足にできない房は二度とくんな。 206 名前：>>46 mailto:sage [2006/01/21(土) 23:02:03 ] >>199 > ソースを見る限りほかのスレッドが触ることはなさそ > うなのですが確信持てないです。 はぁ？ 悪いけど、変数がどっからアクセスされるか自信 が持てないなんて言う奴にはマルチスレッドプログラムは 無理だよ。あきらめたら？ >>203 で、デバッガとか言ってるが君がやることは、デ バッガでプログラムを追っかけることではなく hEvent で全ソースに対して findstr することだと思う。 (そこらじゅうで hEvent 使ってるなら、問題のところ の変数名を変えるべき。) >>201 うちでも、CreateEvent() 〜 SetEvent() 〜 WaitForSingleObject() 〜 CloseHandle() を 10,000,000 回実行したが、WAIT_OBJECT_0 しか 返らないよ。 >>202 その考え方はおかしいだろ。 >>196 みたいな動きをするイベントなんて使い物にな らないと思う。 207 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 08:57:50 ] >>206 ＞>>196 みたいな動きをするイベントなんて使い物にな ＞らないと思う。 eventは許可するまで待たせておくことが目的の物だから、setは少しくらい遅れても良いと思う。 acquireI->releaseする同期モノのreleaseも同じ。 208 名前：>>46 mailto:sage [2006/01/22(日) 10:13:10 ] >>207 少しってどれぐらい？ 1秒なの？ 1ms なの？ 1μs なの？ 他のスレッドに対して set の伝播が遅れるのは問題ない けど、自スレッドに対して SetEvent() してからイベン トがセットされるまでの間に「隙間」があるのは問題。 例えば、 SetEvent(hEvent); // hEvent は、ワーカースレッドか処理終了でセットする。 StartWorkerThread(); // 処理開始指示。 while(WaitForSingleObject(hEvent, 0) == WAIT_TIMEOUT){ // 終了したか？ 　// 終了してないなら、他のことしてようっと。 } (こんなプログラムは組むなと言う意見はまた別の機会に。) と言うプログラムがうまく動かない。 動かないだけなら、まだしも下手するとうまく動いたり動 かなくなったりすると言う最悪パターンになる。 マルチスレッドプログラムやるなら「隙間」をもっと意識 できないとはまるよ。 209 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 12:18:00 ] >>208 「こんなプログラムは組むな」 210 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 12:45:43 ] ＞自スレッドに対して SetEvent() してからイベン ＞トがセットされるまでの間に「隙間」があるのは問題。 いやだから、その隙間は無いんだって。 というか、先頭のSetEventはResetEventの間違いだよな、な。 211 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 16:13:56 ] スレ違いｽﾏｿ 下のスレでマルチコアについて侃侃諤諤の論争してるんですけど、 みなさんはこれからのマルチコア時代についてどう捉えていますか？ Intelの次世代CPUについて語ろう 21 pc7.2ch.net/test/read.cgi/jisaku/1136822334/ 212 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 17:12:45 ] >>208 次にタスクスイッチが起こったときにsetしてくれればいい程度に思って使ってるね、私は。 ＞while(WaitForSingleObject(hEvent, 0) == WAIT_TIMEOUT){ // 終了したか？ 普通スレッド終了の検知はスレッドのハンドルをWaitForSingleObjectの引数にする。 わざわざeventなんて作らない。 スレッドをプールするなんて言い訳は聞かない。 >>211 面倒なことはOSに任せて今まで通りにやる。 213 名前：>>46 mailto:sage [2006/01/22(日) 20:04:17 ] >>210 すまん、勘違いだ。 セット側はさすがにちょっと考えにくいな。 (まあ、リセット側も無理矢理だが。) ただ、セット側とリセット側で挙動が違うのはちょっと気 持ち悪い。 >>211 マルチコアって言ったって、マルチプロセサの一形態だろ。 別に何か変えないといけないのか？ 専用のチューニングが必要になったらそのとき勉強するよ。 >>212 > 普通スレッド終了の検知はスレッドのハンドルを > WaitForSingleObjectの引数にする。 スレッドの終了 ≠ 処理の終了 誰も、スレッドの終了の検知方法なんて聞いてないぞ。 最近知ったので、知ったかしたくなったのか？ 214 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 20:06:09 ] さーしったかしったかたーこうりんだー さーしったかしったかたーこうりんだー みぎあしくんひだりあしくん 215 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 20:17:49 ] >>214 気が済んだか？ すっきりしたら、違うスレに行ってくれよな。 216 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 20:27:26 ] >>213 ＞スレッドの終了 ≠ 処理の終了 そういうことを言いたかったのか。 217 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 21:08:07 ] VC6.0でスレッドを生成するために、 _beginthreadexを使おうと思っていますが、 １プロセスあたりに生成できるスレッド数って 決まっているのでしょうか？ MSDNのCreateThreadのヘルプには、 ２０２８との数字がありますが・・・ 218 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:53:27 ] スタック用のメモリ領域が1MB確保されるんじゃなかったかな 219 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:57:58 ] そんなにスレッド作ってどうするの？ 220 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:02:30 ] 特殊用途か設計ミスか勘違い 221 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:48:39 ] >>217-220 まさに、その「設計ミス」(要は、バグ) で、 スレッド作りすぎてアプリケーションエラー 出しまくった俺が来ましたよ。 うちの環境だと、1600個位でおかしくなった。 ただスレッドを生成するのが、メーカー提供の COM の中なので、生成する時にどんなエラー が返ってきているかはよくわからん。 222 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:21:13 ] なんじゃそりゃ（´・ω・`） 223 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:34:23 ] >>196 例えば １．CreateEvent の第２引数が FALSE（自動リセットオブジェクト）である ２．スレッドＡが WaitForSingleObject(hEvent, INFINITE) している ３．スレッドＢが SetEvent(hEvent) を呼び出す ４．スレッドＡが待機状態から解放される ５．スレッドＢが WaitForSingleObject(hEvent, 0) を呼び出す こういう場合、他のスレッドが ResetEvent しなくても ５．は WAIT_TIMEOUT を返すけど、CreateEvent の第２引数が TRUE なら WAIT_TIMEOUT を返すのは おかしいね。 224 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 20:29:21 ] WAIT_OBJECT_TIMEOUT って書いてたことがばれて逃げてったやつに追い討ちかけんなよ。 225 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 17:33:55 ] A.EXE と B.DLL があり、B.DLL が foo() という関数をエクスポートしており、 foo() は内部的に strtok 等の C ランタイム関数を呼ぶとする。 B.DLL 内部で _beginthread(ex) したスレッドの中で foo() を呼ぶのは当然問題 ないはずだけど、A.EXE が内部で CreateThread または _beginthread(ex) した スレッドの中で B.DLL の foo() 関数を呼び出した場合、メモリリークするの？ B.DLL が DLL_THREAD_ATTACH/DETACH できちんとスレッドごとの初期化・後始末 をしていれば大丈夫そうな気がするんだけど、VC とか BC とかの C ランタイム ライブラリはこの辺どうなってるんだろう。 226 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 18:21:34 ] CreateThreadで作ったスレッドはCランタイムライブラリを使ってはいけない。 スレッド内部でCランタイムライブラリを使いたい場合は、_beginthreadexを使おう。 _beginthreadはVBみたいなもんだと思おう。 詳しくはMSDNライブラリを参照のこと。 ttp://msdn.microsoft.com/library/ja/vclib/html/_crt__beginthread.2c_._beginthreadex.asp ランタイム ライブラリ リファレンス _beginthread、_beginthreadex ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdllpro/html/_win32_createthread.asp プラットフォーム SDK CreateThread ttp://support.microsoft.com/default.aspx?scid=kb;ja;104641 C ランタイム（CRT）関数と CreateThread ()を使用するの、説明 227 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 20:30:26 ] >>225 むしろ逆。 B.DLL内部で_beginthread(ex)したスレッドからA.EXE中の関数bar()を呼ぶとリークする。 ただしA.EXEがCRTとスタティックリンクしていて実行環境がWindows Server 2003より前の場合。 ttp://codezine.jp/a/article.aspx?aid=235&p=2#col4 CRTはソース公開されてるから気になるなら読むといいよ。 Express Editionだと付いてるか知らんけど。 228 名前：225 mailto:sage [2006/01/27(金) 23:32:29 ] >>227 > B.DLL内部で_beginthread(ex)したスレッドからA.EXE中の関数bar()を呼ぶとリークする。 コールバック関数とかも、そのコールバック関数が自EXE で _beginthread(ex) したスレッドから呼ばれないなら C ランタイムを使えないことになりますね。 >>227 の質問を繰り返すことになりますが、A.EXE 内部で _beginthread(ex) した スレッドから B.DLL 中の関数 foo() を呼ぶのは大丈夫なんでしょうか。 DllMain の DLL_THREAD_ATTACH/DETACH はこのへんの問題を解決するための 機構だと思ってるので、きっと大丈夫なんだと自分に言い聞かせるようにし てるんですが…。 229 名前：225 mailto:sage [2006/01/27(金) 23:34:18 ] >>227 > CRTはソース公開されてるから気になるなら読むといいよ。 VC6 のソースを見る限りでは、DLL_THREAD_ATTACH/DETACH でスレッドごとの 初期化/後始末をしているようです。 CRT を使う DLL に関して、VC6 のソースを見た感じでは、その DLL が C ランタイムをスタティックリンクしている場合は _DllMainCRTStartup 内で DllMain を呼ぶ前に DisableThreadLibraryCalls を呼ばないようです。 MSVCRT.DLL を使用する場合は、ユーザー定義の DllMain がない場合のみ、 DisableThreadLibraryCalls を呼んでいるようです。DllMain があった場合、 DllMain 内部で DLL_THREAD_ATTACH/DETACH が必要になる可能性があるから DisableThreadLibraryCalls を呼ばないようにしてるのでしょう。おそらく。 だから、EXE 側で作成したスレッド内で、DLL 側の C ランタイム関数を使う 関数を呼び出しても、DLL_THREAD_DETACH で後始末が行われるのでメモリリーク は発生しないのではないかと思ってますが、それが明記されているドキュメント が見当たらないので気になっています。 230 名前：225 mailto:sage [2006/01/27(金) 23:36:13 ] EXE 側で作成したスレッド内で、DLL 側の関数（内部的に C ランタイム関数を 使うもの）を使えない（使うとメモリリークする）としたら、まともなマルチ スレッドアプリケーションなんて開発出来ない気もします。 せめて malloc/free/new/delete くらいは問題なく使えるようでないと…。 でも、 support.microsoft.com/default.aspx?scid=kb;ja;104641 を見ると malloc も駄目みたいですよね…。実際のところどうなんでしょ。 231 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 07:40:26 ] 実際のところってもなあ hackして怪我するのってあほらしくないか 232 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 10:30:25 ] >>230 Cランタイム関数はスレッドなんてのが出来るまえのシロモノだからね。 漏れの知る限りでは、 リンクしてるCランタイムライブラリが同じでマルチスレッド対応なら、 EXEとDLLで相互に呼び合いとかしても別段問題ない。 なぜなら、Cランタイムが使う領域は_beginthread*()でスレッド生成時に スレッドローカルに確保されて、そちらが使用されるから。 （→see AdvancedWindows） ただし、_*thread*()はランタイムライブラリに含まれる関数だから、 異なるライブラリを混在すると問題になる場合がある。 MS libcmtとMSVCRTの混在も危険。 （→see MSDNの/MDあたりのオプションのヘルプ） 233 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 10:43:44 ] >>230 それ英語版の方読めよ。機械翻訳で日本語として成立してない。 support.microsoft.com/?scid=kb%3Ben-us%3B104641&x=11&y=5 > スレッド内部でCランタイムライブラリを使いたい場合は、_beginthreadexを使おう。 で > calling malloc(), fopen(), _open(), strtok(), ctime(), or localtime() も問題なし。_endthreadex() が、CRT per-thread data-block を後始末してくれるから。 234 名前：225 mailto:sage [2006/01/28(土) 14:56:16 ] ちょっと試してみました。 B.DLL void foo(void) { 　　char dummy[256]; 　　strtok(dummy, ""); } A.EXE DWORD WINAPI ThreadProc(void *pvParam) { 　　foo();//B.DLL 内の関数 　　return 0; } void test(void) { 　　HANDLE hThread; 　　DWORD dwThreadId; 　　int i; 　　for(i = 0; i < 10000; i++){ 　　　　hThread = (HANDLE)CreateThread(NULL, 　　　　　　　　　　　　　　　　　　　 0, 　　　　　　　　　　　　　　　　　　　 ThreadProc, 　　　　　　　　　　　　　　　　　　　 0, 　　　　　　　　　　　　　　　　　　　 0, 　　　　　　　　　　　　　　　　　　　 &dwThreadId); 　　　　WaitForSingleObject(hThread, INFINITE); 　　　　CloseHandle(hThread); } } 235 名前：225 mailto:sage [2006/01/28(土) 14:57:27 ] >>234 の続き １．A.EXE: BCB5 で作成、B.DLL: VC6 libcmt.lib で作成 ２．A.EXE: BCB5 で作成、B.DLL: VC6 msvcrt.lib で作成 ３．A.EXE: BCB5 で作成、B.DLL: BCB5 で作成 結果： １：DllMain で DisableThreadLibraryCalls を呼ぶとメモリリークする 　　（test を呼ぶ度にメモリ使用量が増える） 　　DllMain で DisableThreadLibraryCalls を呼ばなければメモリリークしない 　　（test を何回呼んでもメモリ使用量は変わらない） ２：DllMain で DisableThreadLibraryCalls を呼んでも呼ばなくてもメモリリークしない ３：DllMain で DisableThreadLibraryCalls を呼んでも呼ばなくてもメモリリークする ちなみに void foo(void) { 　　char* dummy = (char*)malloc(128);// char *dummy = new char[128]; 　　free(dummy);// delete[] dummy; } の場合、どの場合においてもメモリリークしない 236 名前：225 mailto:sage [2006/01/28(土) 14:59:56 ] >>235 の続き 結論： BCB5/VC6 で作成した B.DLL においては、C ランタイムルーチンのうち、少なくとも malloc/free/new/delete しか使わない分には、A.EXE で作成したスレッド内で B.DLL の関数を呼び出してもメモリリークしない。スレッドの作成に _beginthread(ex) を 使う必要もない。 VC6 で MSVCRT.DLL とリンクする B.DLL では、A.EXE で作成したスレッド内で B.DLL の関数（内部で C ランタイム関数を呼ぶもの）を呼び出してもメモリリークしない。 VC6 で libcmt.lib とスタティックリンクする B.DLL では、DllMain で DisableThreadLibraryCalls() を呼ばなければ、A.EXE で作成したスレッド内で B.DLL の関数（内部で C ランタイム関数を呼ぶもの）を呼び出してもメモリリーク しないが、DisableThreadLibraryCalls()を呼ぶと、B.DLL が内部で呼び出している C ランタイムルーチンによってはメモリリークする可能性がある。 他にも色んな組み合わせが考えられますが、とりあえず自分が知りたかった 「A.EXE で作成したスレッド内で B.DLL 内の関数を呼び出してもメモリリーク しないのか」は検証出来ました。この程度の実験で検証出来たと断言して良い のかはわかりませんが。 BCB5 の C ランタイムルーチンは DLL_THREAD_ATTACH/DETACH をきちんと処理して いないものと思われます。BCB5 で作った DLL はマルチスレッドアプリケーション からは使いにくいですね。 VC7 以降とか GCC とかではどうなんでしょうね。 検証の仕方が間違ってたらご指摘下さい。

---

---

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

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