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

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

175:デフォルトの名無しさん
05/12/28 16:51:48
おバカSunよね～

176:デフォルトの名無しさん
06/01/02 08:35:56
くだらない質問ですみませんが
TCPで同じディスクリプタにread()するスレッドとwrite()するスレッドを分けたとき
全二重だから同時にread()とwrite()を実行しても問題ありませんよね？
あと片方が同期無しでclose()するのって問題ありますかね

177:デフォルトの名無しさん
06/01/02 08:40:05
同時にread/writeしても問題なし。
HTTPサーバのようなものを作ってるなら相手が一方的にclosesocketしたくらいでおかしくなっては困る。

178:デフォルトの名無しさん
06/01/02 12:25:53
Solaris2.xではデッドロックしてたなあ（遠い目）

179:デフォルトの名無しさん
06/01/03 03:50:46
x86 とかで int の値を書き込むスレッド(A)と読み込むスレッド(B)がある場合，
更新途中の値が(つまり 32bit 中の 16 bit が新しい値で残りが古いままとか)
B に見えてしまうということはありうるでしょうか？

# long とかだとまずいですよね．

180:デフォルトの名無しさん
06/01/03 04:40:29
>>179
前スレで延々やってたと思う

そこが本題でなければ、排他で済ませて先行った方がいいと思うヨ

181:デフォルトの名無しさん
06/01/03 04:56:02
>>180
レスありがとうございます．前スレの読み方がよく分からないので憶測になっ
てしまいますが，前スレの議論では結局「あり得る」という結論に至ったとの
理解で良いでしょうか？

参考になりそうな資料へのポインタを教えて頂けるとうれしいです．

> そこが本題でなければ、排他で済ませて先行った方がいいと思うヨ

性能的な面から可能な限り B に対する排他処理は避けたいと考えています．

182:デフォルトの名無しさん
06/01/04 15:07:19
>>181
OSに用意されている、Atomicな書き換えAPIを利用すれば宜しかろう。
32ビットバスでアライメントも合っていれば素直にAtomicに書き換わると思うが。

183:デフォルトの名無しさん
06/01/04 16:15:06
レスありがとうございます。調べてみます．

184:デフォルトの名無しさん
06/01/13 02:07:27
マルチスレッドプログラミングで注意することを列挙してくれ。

185:デフォルトの名無しさん
06/01/13 02:19:22
ひとつ！急いで口で吸え！

186:デフォルトの名無しさん
06/01/18 14:53:41
ふたつ! 不埓な悪行三昧!

187:デフォルトの名無しさん
06/01/18 16:18:23
みっつ! 想定の範囲内です。

188:デフォルトの名無しさん
06/01/18 16:55:53
よっつ、読んでも書いちゃダメ

189:デフォルトの名無しさん
06/01/18 16:56:28
いつつ、いつも心に排他処理

190:デフォルトの名無しさん
06/01/18 16:59:48
むっつ、無理せずmutex

191:デフォルトの名無しさん
06/01/18 17:21:48
ななつ、仲良くSemaphoeで共有

192:>>46
06/01/18 23:32:09
やっつ、やっぱりここでも排他処理

193:デフォルトの名無しさん
06/01/19 00:43:25
ここのつ！心を鬼にして排他処理

194:デフォルトの名無しさん
06/01/19 01:03:03
糞スレ立てんな

195:デフォルトの名無しさん
06/01/19 01:39:58
とう、でとうとう割り込まれた。

排他だけじゃなく、割り込み禁止も忘れないでね☆

196:デフォルトの名無しさん
06/01/21 01:53:34
HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, NULL)で作ったイベントに対して
SetEvent(hEvent);←TRUEがかえる
でも、その次に
WaitForSingleObject(hEvent, 0)とやってもWAIT_OBJECT_TIMEOUTがかえる。
こういうことがおきているのですがどのようなことが考えられますか？

197:デフォルトの名無しさん
06/01/21 07:15:10
>>196
SetEventは成功したけど、イベントオブジェクトがシグナル状態になる前にWaitForSingleObjectがタイムアウトした。

198:>>46
06/01/21 09:16:54
>>196
他のスレッドが一生懸命 ResetEvent(hEvent) を
やってる。

199:196
06/01/21 14:20:25
>>197
SetEventってシグナル状態にした後で戻るわけではないのですか？

>>198
ソースを見る限りほかのスレッドが触ることはなさそうなのですが確信持てないです。
SetEventとWaitForSingleObjectの間で他のスレッドにスイッチしなければそういうことはおきないですよね？
であれば確認のためにはスレッドのスイッチをSetEventとWaitForの間で抑制してあげればいいですよね。
なにか、任意のコードブロックではスレッドスイッチを禁止する方法はないでしょうか

200:デフォルトの名無しさん
06/01/21 14:26:18
ちょっと確認だが、WaitForSingleObject()の第二パラメータの0ってNoWaitだよな?
単に待てば委員で内科医?

201:デフォルトの名無しさん
06/01/21 14:42:02
>196のままのコードを実行してみたけど、ちゃんと0が帰ってきたよ。

202:デフォルトの名無しさん
06/01/21 15:04:56
>>199
>>196の事象が事実であるなら、そういうものだと思って使うべき。
嫌なら別の手段を用いるべき。

203:196
06/01/21 15:47:24
>>200
SetEventしてそれが本当にシグナルになったかを見るためにWaifFor・・したのですが、
それがなぜかシグナルになっていないのです。

>>201
検証ありがとうございます。>>196のままのコードだとそうなると思いますが、実際にはほかのスレッドもいるので
何が起きているかはよくわかっていません。（デバッガでステップ実行したりデバッグライトを入れるだけで動きが変わるため）

とりあえず、月曜にほかのスレッドがResetしていないか確認したいと思います

あとSetEventって非同期に動いたりしませんよね？
SetEvent(hEvent);
ここで誰かがResetEventしない限り下はTRUEにならないですよね？
if(WaitForSingleObject(hEvent,0)==WAIT_OBJECT_TIMEOUT)
{
}

204:デフォルトの名無しさん
06/01/21 17:01:11
>>203
だから、WaitForSingleObject(hEvent, INFINITE)してみたら?

205:デフォルトの名無しさん
06/01/21 21:15:12
そもそも、WAIT_OBJECT_TIMEOUTってなんだ？

成功：WAIT_OBJECT_0 or WAIT_TIMEOUT or WAIT_ABANDONED
失敗：WAIT_FAILED

のいずれかが、WaitForSingleObject()の戻り値なんだが・・・
とりあえず、該当部分のコードを晒せ、晒したくなかったらコピペも満足にできない房は二度とくんな。

206:>>46
06/01/21 23:02:03
>>199
> ソースを見る限りほかのスレッドが触ることはなさそ
> うなのですが確信持てないです。

はぁ？悪いけど、変数がどっからアクセスされるか自信
が持てないなんて言う奴にはマルチスレッドプログラムは
無理だよ。あきらめたら？

>>203 で、デバッガとか言ってるが君がやることは、デ
バッガでプログラムを追っかけることではなく hEvent
で全ソースに対して findstr することだと思う。
(そこらじゅうで hEvent 使ってるなら、問題のところ
の変数名を変えるべき。)

>>201
うちでも、CreateEvent() ～ SetEvent() ～
WaitForSingleObject() ～ CloseHandle() を
10,000,000 回実行したが、WAIT_OBJECT_0 しか
返らないよ。

>>202
その考え方はおかしいだろ。
>>196 みたいな動きをするイベントなんて使い物にな
らないと思う。

207:デフォルトの名無しさん
06/01/22 08:57:50
>>206
＞>>196 みたいな動きをするイベントなんて使い物にな
＞らないと思う。
eventは許可するまで待たせておくことが目的の物だから、setは少しくらい遅れても良いと思う。
acquireI->releaseする同期モノのreleaseも同じ。

208:>>46
06/01/22 10:13:10
>>207
少しってどれぐらい？
1秒なの？ 1ms なの？ 1μs なの？

他のスレッドに対して set の伝播が遅れるのは問題ない
けど、自スレッドに対して SetEvent() してからイベン
トがセットされるまでの間に「隙間」があるのは問題。

例えば、

SetEvent(hEvent); // hEvent は、ワーカースレッドか処理終了でセットする。
StartWorkerThread(); // 処理開始指示。
while(WaitForSingleObject(hEvent, 0) == WAIT_TIMEOUT){ // 終了したか？
　// 終了してないなら、他のことしてようっと。
}
(こんなプログラムは組むなと言う意見はまた別の機会に。)

と言うプログラムがうまく動かない。

動かないだけなら、まだしも下手するとうまく動いたり動
かなくなったりすると言う最悪パターンになる。

マルチスレッドプログラムやるなら「隙間」をもっと意識
できないとはまるよ。

209:デフォルトの名無しさん
06/01/22 12:18:00
>>208
「こんなプログラムは組むな」

210:デフォルトの名無しさん
06/01/22 12:45:43
＞自スレッドに対して SetEvent() してからイベン
＞トがセットされるまでの間に「隙間」があるのは問題。

いやだから、その隙間は無いんだって。
というか、先頭のSetEventはResetEventの間違いだよな、な。

211:デフォルトの名無しさん
06/01/22 16:13:56
スレ違いｽﾏｿ

下のスレでマルチコアについて侃侃諤諤の論争してるんですけど、
みなさんはこれからのマルチコア時代についてどう捉えていますか？

Intelの次世代CPUについて語ろう 21
ｽﾚﾘﾝｸ(jisaku板)

212:デフォルトの名無しさん
06/01/22 17:12:45
>>208
次にタスクスイッチが起こったときにsetしてくれればいい程度に思って使ってるね、私は。

＞while(WaitForSingleObject(hEvent, 0) == WAIT_TIMEOUT){ // 終了したか？
普通スレッド終了の検知はスレッドのハンドルをWaitForSingleObjectの引数にする。
わざわざeventなんて作らない。
スレッドをプールするなんて言い訳は聞かない。

>>211
面倒なことはOSに任せて今まで通りにやる。

213:>>46
06/01/22 20:04:17
>>210
すまん、勘違いだ。
セット側はさすがにちょっと考えにくいな。
(まあ、リセット側も無理矢理だが。)
ただ、セット側とリセット側で挙動が違うのはちょっと気
持ち悪い。

>>211
マルチコアって言ったって、マルチプロセサの一形態だろ。
別に何か変えないといけないのか？
専用のチューニングが必要になったらそのとき勉強するよ。

>>212
> 普通スレッド終了の検知はスレッドのハンドルを
> WaitForSingleObjectの引数にする。

スレッドの終了 ≠ 処理の終了

誰も、スレッドの終了の検知方法なんて聞いてないぞ。
最近知ったので、知ったかしたくなったのか？

214:デフォルトの名無しさん
06/01/22 20:06:09
さーしったかしったかたーこうりんだー
さーしったかしったかたーこうりんだー
みぎあしくんひだりあしくん

215:デフォルトの名無しさん
06/01/22 20:17:49
>>214
気が済んだか？
すっきりしたら、違うスレに行ってくれよな。

216:デフォルトの名無しさん
06/01/22 20:27:26
>>213
＞スレッドの終了 ≠ 処理の終了
そういうことを言いたかったのか。

217:デフォルトの名無しさん
06/01/22 21:08:07
VC6.0でスレッドを生成するために、
_beginthreadexを使おうと思っていますが、
１プロセスあたりに生成できるスレッド数って
決まっているのでしょうか？
MSDNのCreateThreadのヘルプには、
２０２８との数字がありますが・・・

218:デフォルトの名無しさん
06/01/23 00:53:27
スタック用のメモリ領域が1MB確保されるんじゃなかったかな

219:デフォルトの名無しさん
06/01/23 00:57:58
そんなにスレッド作ってどうするの？

220:デフォルトの名無しさん
06/01/23 22:02:30
特殊用途か設計ミスか勘違い

221:デフォルトの名無しさん
06/01/23 22:48:39
>>217-220
まさに、その「設計ミス」(要は、バグ) で、
スレッド作りすぎてアプリケーションエラー
出しまくった俺が来ましたよ。

うちの環境だと、1600個位でおかしくなった。

ただスレッドを生成するのが、メーカー提供の
COM の中なので、生成する時にどんなエラー
が返ってきているかはよくわからん。

222:デフォルトの名無しさん
06/01/24 14:21:13
なんじゃそりゃ（´・ω・`）

223:デフォルトの名無しさん
06/01/24 23:34:23
>>196

例えば

１．CreateEvent の第２引数が FALSE（自動リセットオブジェクト）である
２．スレッドＡが WaitForSingleObject(hEvent, INFINITE) している
３．スレッドＢが SetEvent(hEvent) を呼び出す
４．スレッドＡが待機状態から解放される
５．スレッドＢが WaitForSingleObject(hEvent, 0) を呼び出す

こういう場合、他のスレッドが ResetEvent しなくても５．は WAIT_TIMEOUT
を返すけど、CreateEvent の第２引数が TRUE なら WAIT_TIMEOUT を返すのは
おかしいね。

224:デフォルトの名無しさん
06/01/25 20:29:21
WAIT_OBJECT_TIMEOUT
って書いてたことがばれて逃げてったやつに追い討ちかけんなよ。

225:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/01/27 18:21:34
CreateThreadで作ったスレッドはCランタイムライブラリを使ってはいけない。
スレッド内部でCランタイムライブラリを使いたい場合は、_beginthreadexを使おう。
_beginthreadはVBみたいなもんだと思おう。

詳しくはMSDNライブラリを参照のこと。

URLﾘﾝｸ(msdn.microsoft.com)
ランタイムライブラリリファレンス
_beginthread、_beginthreadex

URLﾘﾝｸ(www.microsoft.com)
プラットフォーム SDK
CreateThread

URLﾘﾝｸ(support.microsoft.com)
C ランタイム（CRT）関数と CreateThread ()を使用するの、説明

227:デフォルトの名無しさん
06/01/27 20:30:26
>>225
むしろ逆。
B.DLL内部で_beginthread(ex)したスレッドからA.EXE中の関数bar()を呼ぶとリークする。
ただしA.EXEがCRTとスタティックリンクしていて実行環境がWindows Server 2003より前の場合。
URLﾘﾝｸ(codezine.jp)
CRTはソース公開されてるから気になるなら読むといいよ。
Express Editionだと付いてるか知らんけど。

228:225
06/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
06/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
06/01/27 23:36:13
EXE 側で作成したスレッド内で、DLL 側の関数（内部的に C ランタイム関数を
使うもの）を使えない（使うとメモリリークする）としたら、まともなマルチ
スレッドアプリケーションなんて開発出来ない気もします。

せめて malloc/free/new/delete くらいは問題なく使えるようでないと…。
でも、

URLﾘﾝｸ(support.microsoft.com)

を見ると malloc も駄目みたいですよね…。実際のところどうなんでしょ。

231:デフォルトの名無しさん
06/01/28 07:40:26
実際のところってもなあ
hackして怪我するのってあほらしくないか

232:デフォルトの名無しさん
06/01/28 10:30:25
>>230
Cランタイム関数はスレッドなんてのが出来るまえのシロモノだからね。

漏れの知る限りでは、
リンクしてるCランタイムライブラリが同じでマルチスレッド対応なら、
EXEとDLLで相互に呼び合いとかしても別段問題ない。
なぜなら、Cランタイムが使う領域は_beginthread*()でスレッド生成時に
スレッドローカルに確保されて、そちらが使用されるから。
（→see AdvancedWindows）

ただし、_*thread*()はランタイムライブラリに含まれる関数だから、
異なるライブラリを混在すると問題になる場合がある。
MS libcmtとMSVCRTの混在も危険。
（→see MSDNの/MDあたりのオプションのヘルプ）

233:デフォルトの名無しさん
06/01/28 10:43:44
>>230
それ英語版の方読めよ。機械翻訳で日本語として成立してない。
URLﾘﾝｸ(support.microsoft.com)

> スレッド内部でCランタイムライブラリを使いたい場合は、_beginthreadexを使おう。
で
> calling malloc(), fopen(), _open(), strtok(), ctime(), or localtime()

も問題なし。_endthreadex() が、CRT per-thread data-block を後始末してくれるから。

234:225
06/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
06/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
06/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 とかではどうなんでしょうね。

検証の仕方が間違ってたらご指摘下さい。

237:デフォルトの名無しさん
06/01/28 15:25:22
>>236
率直に言えば無意味な検証。
というのは、メモリリークだけが問題ではないから。

仮にメモリリークしていなかったとしても、
複数のスレッドで同時に1つのワークエリアを参照していれば、
各スレッドがお互いに1つのワークエリアをぶっ壊しあう。
喪前さんのやり方では、そのパターンが検出できない。

むしろ、メモリリークしている方が複数のスレッドで異なるワークエリアを作成している、
つまり不完全ながらもマルチスレッド対応しているという見方もできる。
（実際どうかは知らん。メモリだけ確保して1つのワークを壊しまくってる可能性もある）

つか、なんでCreateThread()で試してるんだ？
試すまでもなく駄目なの分かり切ってるだろ。
_beginthread*()ならまだわからんでもないが・・・。

238:225
06/01/28 18:02:37
> 複数のスレッドで同時に1つのワークエリアを参照していれば、
> 各スレッドがお互いに1つのワークエリアをぶっ壊しあう。

マルチスレッド対応のランタイムでは、そのような問題は起こらないことが
保証されているものだと思ってました。
_beginthread(ex) の説明を読む限り、メモリリーク問題以外については
何も記述されていません。

> つか、なんでCreateThread()で試してるんだ？

確認したかったのは、「A.EXE で作成したスレッド内で B.DLL 内の関数を
呼ぶことが出来るかどうか」だからです。

A.EXE は BCB5 で作成していて、B.DLL は VC6 で作成しています。
B.DLL 内の C ランタイムルーチンを使うのに、A.EXE の _beginthread(ex)
を使っても無意味なのは初めからわかりきっています。

また、>>235 では書きませんでしたが、３．の場合、C ランタイムルーチン
はスタティックリンクされてるので、やはり A.EXE の _beginthread(ex)
と B.DLL の _beginthread(ex) は全く別物です。

> 試すまでもなく駄目なの分かり切ってるだろ。

メモリリークという点だけ見れば、駄目とは言い切れないという結果に
なったと思うのですが。元々 DLL_THREAD_ATTACH/DETACH で解決し得る
問題だと思ってるので、この結果がおかしいとは思えません。

239:デフォルトの名無しさん
06/01/28 18:45:54
>>238
> マルチスレッド対応のランタイムでは、そのような問題は起こらないことが
> 保証されているものだと思ってました。

思うのは勝手だけど、正しい使い方をしないと正しい挙動はしてくれないよ。
この場合、_beginthread*()を呼ばないと、「正しい挙動」はしてくれない。
なぜなら、Cランタイムをスレッドセーフにする肝心の処理を_beginthread*()がやるから。

ついでに言えば、問題はB.DLLだけの話ではなくて、A.EXEのランタイムに
何を使ってるか？　というのも重要。にも関わらず、>>235でその点に
一切触れていない点からも、喪前さんの理解が足りないことが伺える。

240:225
06/01/28 20:18:06
>>239
> なぜなら、Cランタイムをスレッドセーフにする肝心の処理を_beginthread*()がやるから。

_beginthread(ex) と _endthead がやるのは、スレッドごとに必要なメモリ
の割り当てと解放を行うことですよね？

_beginthread を使わなかったせいで、ランタイムルーチンを呼び出し時に
そのスレッドではまだメモリが割り当てられてなかったなら、その場で動的に
割り当てれば問題ないでしょう。実際、動的に割り当ててると思うんだけど。

問題なのは、スレッドの終了を知ることが出来なくなるせいで、割り当てた
メモリを解放する機会が得られなくなり、その結果としてメモリリークが発
生する、ということではないの？

_beginthread(ex) を使わないことによって、排他処理的な問題が起こるとは
どこにも書いてないですよね？起こらないとも書いてないけど。

排他処理的な問題が起こると明記されてるのは、シングルスレッド版の
ランタイムを使った場合の方だけです。
マルチスレッド版の方では、メモリリークのことしか書いてないと思う
んですけど。

> ついでに言えば、問題はB.DLLだけの話ではなくて、A.EXEのランタイムに
> 何を使ってるか？　というのも重要。にも関わらず、>>235でその点に
> 一切触れていない点からも、喪前さんの理解が足りないことが伺える。

A.EXE は BCB5 で作成、B.DLL は VC6 で作成と書いてます。
理解が足りないのは認めますが。

長文ばかりで申し訳ない。

241:デフォルトの名無しさん
06/01/28 20:54:27
とりあえず消えろ

242:225
06/01/28 21:09:14
>>241

真面目に質問してるつもりなんですが、そういうのが伝わらない
あたりが 2ch のイヤなところですね。

どこかにこの件に関してきちんと解説したウェブサイトなり書籍
があればご紹介頂きたかったですがね。

243:デフォルトの名無しさん
06/01/28 21:19:39
>>242
そういうのにいちいち気にしていたら駄目だよｗ

2chの使い方からまず学んだほうが有効に使えるかも。
当然俺のレスにもレスは要らないぞｗ(あってもいいけど

244:225
06/01/28 21:40:13
>>243
やっぱりそうですか。(^^;

>>235 の結果から、（この検証が正しければ）メモリリークに関しては
処理系依存ということになったわけだし、ドキュメント化されてるわけ
でもないようだから、結局のところ結論なんて出ないんだろうな…。

「A.EXE で作成したスレッドから B.DLL の関数を呼び出すとメモリリークする」
のだとすると、Susie プラグインとか、自分ではメンテナンス出来ないプラグイン
方式の DLL を使うアプリをマルチスレッド化するのは非現実的ということになっ
てしまうのか…。ほとんどの DLL は C ランタイムを使用してるだろうから。

一度作成したスレッドはアプリが終了するまで使い回すようにするしかないの
だろうか…。なんか納得行かないな。

245:デフォルトの名無しさん
06/01/28 22:06:40
Susieプラグイン使う様なサイズのアプリなら、
スレッドプール使えば"about 70-80 bytes"のリークなんて気にする必要ないのでは?

>>242
MSDNだろ。

246:241
06/01/28 22:09:50
マルチスレッドプログラミングをしたことのない房でも225のような真面目なやつを馬鹿にできるんだから
2ｃｈって憂さ晴らしに最適だよな。

247:デフォルトの名無しさん
06/01/28 23:06:33
>>231

248:デフォルトの名無しさん
06/01/29 01:07:13
>>244
真面目におかしなことばっかり言ってるから相手したくなくなるんだよ。
依存するのは処理系自体ではなくライブラリだし、
アンドキュメントな実装に依存したコードを書くのは無謀。

漏れが言えることは、
「EXE・DLLの両方で同じライブラリ使ってれば、相互に呼び合いしても問題ない」
「泥沼に足突っ込みたくなければ推奨されてるやり方を使え」
それだけ。普通にMSVCRT使えばいい。

それ以上のこと知りたいなら、AdvancedWindowsなりMSDNなりCRTのソースなり
自分で読んで勉強してくれ。スレでいちいち書けるほど単純な話でもない。

249:225
06/01/29 04:20:43
>>248
> 「EXE・DLLの両方で同じライブラリ使ってれば、相互に呼び合いしても問題ない」

DLL は他人が作ってるので自分でいじれないし、EXE は GUI の
関係上 BCB しか使えないので。

> 「泥沼に足突っ込みたくなければ推奨されてるやり方を使え」

EXE で作成したスレッドから DLL の関数を呼ぶ場合の推奨されてる
やり方とは？EXE/DLL ともに MSVCRT を使うことですか？

> AdvancedWindowsなりMSDNなりCRTのソースなり自分で読んで勉強してくれ

MSDN と CRT のソースは自分なりに熟読してみたつもりです。
CRT のソースから、>>235 の結果は予想通りでした。
でも、３．の結果は予想通りだけど納得行かない。
BCB5 の C ランタイムライブラリのバグと言うべきなんじゃないだろうか。
仕様で片付けていい問題ではないような…。

AdvancedWindows を読んでもう少し勉強してみます。

250:デフォルトの名無しさん
06/01/29 09:28:51
最後のはBorlandのドキュメント読まないと仕方ないでしょ。
使ったことないから、どういう事になっているのか知らないし、
それで仕様通りの利用かどうかもわからない。

いずれにせよ、サードパーティのDLL内で、
CreateThread()を多発してない限り、別に大きな障壁になることじゃないよね。
スレッドを多発する場合、スレッドプール使うのは鉄則だから。

251:デフォルトの名無しさん
06/01/29 18:37:53
>>237 >>239
やなやつだなあ。
まじめに答えてる振り装ってるが不快なことこの上ない。

252:デフォルトの名無しさん
06/01/29 19:09:23
まあスレッドプログラミングなんてやってる香具師はそんな香具師ばっかりだから

253:デフォルトの名無しさん
06/01/29 19:30:17
だから日本はだめなんだよな

254:デフォルトの名無しさん
06/01/29 19:57:56
>>252
いっしょにすな！

255:デフォルトの名無しさん
06/01/29 21:20:17
URLﾘﾝｸ(support.microsoft.com)
の"static"の使い方は違和感あるなあ。
"thread local"ってことだよな。実際は生存期間が"dynamic"だし。

256:デフォルトの名無しさん
06/01/30 17:17:51
マルチスレッドでプログラムを作っているのですが、VisualC++6.0(SP6)でデバッグすると
しばらくするとフリーズしてしまいます。
フリーズというのは、VC++と実行しているEXEがまったく応答しなくなり、
さらにOSの反応がほとんどなくなる感じです。
ほとんどというのは、Alt+Tabぐらいは効くのですが、タスクマネージャーも起動せず
他のアプリも、しばらく動くのですがじきに応答がなくなります。
デバッグではなく、ただEXEを実行した場合は普通です。
OSはWindowsXPHome SP2で、まあ標準的な環境だと思います。
1つ怪しいのといえば、NortonAntiVirusですが、これに関しては
ほぼインストールしたてのWin2000SP4のマシンでやっても同じような現象が
起こったので、他のアプリが邪魔している、というわけでもなさそうです。
それなりに長いソースなので、同様の問題が発生する簡単なソースをコピペします。

257:256
06/01/30 17:18:38
#include <windows.h>
#include <stdio.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

char* szClassNme = "aaa";

DWORD WINAPI thread_proc(LPVOID param)
{
int i;

while(1)
{
i++;
Sleep(10);
}
}

258:256
06/01/30 17:19:29
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPreInst,
LPSTR lpszCmdLine, int nCmdShow)
{
MSG msg;
WNDCLASS WClass;
HWND hWnd;
DWORD tid;

if (!hPreInst) {
WClass.style= CS_HREDRAW | CS_VREDRAW;
WClass.lpfnWndProc= WndProc;
WClass.cbClsExtra= 0;
WClass.cbWndExtra= 0;
WClass.hInstance= hInstance;
WClass.hIcon= NULL;
WClass.hCursor= LoadCursor(NULL, IDC_ARROW);
WClass.hbrBackground= (HBRUSH)GetStockObject(WHITE_BRUSH);
WClass.lpszMenuName= NULL;
WClass.lpszClassName= szClassNme;
if(!RegisterClass(&WClass))
return 0;
}

hWnd = CreateWindow(szClassNme, "aaa", WS_POPUP | WS_SYSMENU | WS_MINIMIZEBOX,
100, 100, 200, 200, NULL, NULL, hInstance, NULL);

ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);

CreateThread(NULL, 0, thread_proc, NULL, 0, &tid);

259:256
06/01/30 17:24:07

while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (msg.wParam);
}

LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return(DefWindowProc(hWnd, msg, wParam, lParam));
}
return 0;
}

260:256
06/01/30 17:30:36
thread_procの、while(1)のところにブレークポイントを設定し
F5を連打し何回かループさせると、いずれ固まります。
ひょっとしてプログラムに何か原因があるのでしょうか？
デバッグがままならないとなると開発が非常に困難です。

261:256
06/01/30 20:19:40
WinXPで、ウィンドウズキー+Lで、ユーザーを切り替ることはできたので
別のユーザーからMSDEV.exeを強制終了すると、一応復帰できることが分かりました。
しかし、依然として非常に困っています。
もし以前こんな現象に見舞われたけど、こうして直したよ、とか
ここをこうしたらいいんじゃないの？っていうのがありましたらぜひ教えていただきたいです。

262:デフォルトの名無しさん
06/01/30 20:32:17
osの再インストールしても直らなかったという、ほろ苦い思い出があるよ。

263:256
06/01/30 21:32:25
>262
その後は結局どうなりました？
ひょっとしてマルチスレッドのデバッグは、VC++6.0でできないっていうのが
「仕様」なんでしょうか？

264:デフォルトの名無しさん
06/01/30 21:52:07
Windowsを2000にするか、VisualStudioをバージョンアップしませう

265:256
06/01/30 22:01:27
>264
Windows2000でもなりました。
VisualStudioをバージョンアップですか.... 高かったんですよね。

266:デフォルトの名無しさん
06/01/30 22:26:40
>>256

私も Windows2000 から XP にアップグレードしてから似たような
現象が発生するようになりました。

VC++6.0 と BCB5 でそうなっていて、どちらもマルチスレッド
アプリケーションでなくても発生します。

なんか Window メッセージの送受信の応答がシステム全体でとてつもなく
遅くなる感じですね。バックグラウンドで音楽とか流していても、音楽は
普通に流れますが、ウィンドウの切り替えとかがものすごく遅くなります。
完全なフリーズじゃないだけに、諦めて電源を落とそうにも、落とすタイ
ミングに困ってしまうというか。

URLﾘﾝｸ(www.wg7.com)

これと似たような症状なんですが、私は試していません。言語バーが
使えなくなるのも困るので。

結構頻繁に起こるので辛いのですが、起こらないときは起こらないので、
そういうものだと思って諦めています。

267:225
06/01/30 22:43:46
_beginthread(ex) の説明のところに、CreateThread だとメモリリークして
しまう C ランタイム関数の一覧でも書いてあれば良いんですけどね。

URLﾘﾝｸ(support.microsoft.com)

には malloc とか fopen でもメモリリークするようなことが書かれてるけど、
実際に試してみると、VC6/BCB5 どちらの場合もメモリリークしてるようには
思えないです。

ここに書かれてないものでは、rand() を使うとメモリリークしますね。
今回の呼び出しの結果が前回の呼び出しに依存するようなタイプの関数は
全滅なんでしょうね。

268:256
06/01/30 22:55:37
>266
確かに今まで他のプログラムを組んでいるときにそういうことはありました。
しかし、今回はそれとはちょっと違うように思えるのです。
一度固まると、少なくとも20分ぐらいは待ってみたのですが復帰しませんでした。
しかも、ほぼ毎回起こります。

上のソースに何か問題点があるのでしょうか？
ウィンドウメッセージに応じて処理をするスレッド（最初に起動されたときのもの）
別に他の計算をするスレッドを別に作っています。
競合が起こっているのかと思い、上のような簡単な簡単なソースを書いてみたのですが
あれでも必ずといっていいほど起こります。
ちなみにWindowsMeでも起こりました。家のPC全滅です..

269:266
06/01/31 00:34:55
最初は自分が書いたプログラムに原因があると思ってたのですが、
Web 上にある他人が書いたもののいくつかを自分の環境でコンパイル・実行
してもそうなるので、環境によるものだと思って諦めることにしました。

Windows2000 では問題なかったので、256 さんと私とでは状況が
少し異なりますね。マルチスレッドアプリケーションでなくても
発生しますし。お役に立てなくてすみません。

270:デフォルトの名無しさん
06/01/31 01:33:38
オレもよくなる。ステップ実行しているとなんでもないところで固まってCtrl＋Alt+Delをやって再起動とかやるが
まったく動かず、次にAlt+Tabで悪あがき。選択した窓から順に固まる。
最後電源長押し、するとmsdev.exeを終了しています、かなんかがでて、msdev.exeが終了するとほかもサクサク終わる。
もちろんまったく終わらないでそのまま固まることもある。
DLLで提供される関数をステップオーバーしたときに出るとか、なんか最初はそんなことを思っていたけど
そうでもないらしい。

271:デフォルトの名無しさん
06/01/31 09:31:42
Windowsのスケジューラ糞馬鹿だから
タスクマネージャでMSDEV.EXEのプライオリティ上げろ。

272:256
06/01/31 21:11:22
VisualStudio .NET 2003を入れてデバッグしてみたところ、簡単なものは
ほとんど固まらなくなりましたが（とはいえ、ごくたまに固まります）
開発しているプログラムは依然として固まるようです。
いまいちすっきりしないのですが、あまりこの問題にかまっている時間的
余裕も無いのでデバッグ時のみシングルスレッドで動くようにして
場当たり的な解決をすることにしました。
幸運にもあまり修正せずにすむに済みました。
依然として自分のプログラムに問題があるのかという不安はのこりますが...
266さんをはじめ、皆様、様々な情報提供ありがとうございます。
よくあることのようなので、少し安心しました。（していいのか！？）

273:デフォルトの名無しさん
06/01/31 21:27:49
>263
imeだか関係の問題だったはず。
URLﾘﾝｸ(ww1.enjoy.ne.jp)
の、マルチスレッドの注意点の項を参考にしてみては？
私は効果なかったんですが・・・

274:デフォルトの名無しさん
06/02/01 01:56:10
257のコードで何にも問題は出なかったぞ。
F5押しっぱなしでも固まるどころか快調そのもの。
Dual Pentium III 1GHz, NT4.0 VC++ 6.0+Sp5

275:デフォルトの名無しさん
06/02/03 16:12:33
>>256
デバッグモードでなぜかおかしくなるというWin個体は確かにある。
どうしようもない。マシン変えろ

276:sage
06/02/04 00:23:14
VB6.0でActiveX DLLを使用し、マルチスレッドを実現できるという噂を聞いたのですが
本当ですか？

でもイメージが掴めない・・・
VBでActiveXコンポーネント「Ａ」を呼び出し
↓
Ａ作成→Ａ何らかの処理
　　　　　　↓
VBの処理←Ａ処理終了
↓
VB次の処理

って感じでマルチスレッドとは違う気がするんですが・・

もし本当であれば、どなたか参考になるサイトをご教授頂けませんでしょうか

277:デフォルトの名無しさん
06/02/04 01:43:21
URLﾘﾝｸ(search.yahoo.co.jp)

278:デフォルトの名無しさん
06/02/04 08:38:15
>>276
DLLの中はC++で書けばなんでもやり放題なんじゃね？
DLLの中でクリートスレッド

279:デフォルトの名無しさん
06/02/04 09:02:03
>>278
クリートスレッドってなに?

280:デフォルトの名無しさん
06/02/04 09:39:29
CreateとDeleteの合成語だろ
スレッドを作ったら自分で閉じろってことだ

281:デフォルトの名無しさん
06/02/04 12:14:10
>>276
ActiveX のコンポーネントとして作成した DLL/EXE が
スレッドセーフだ、ってだけじゃね？

282:デフォルトの名無しさん
06/02/04 12:20:51
何をしたいのかしらんが
COMのスレッドは楽しいぞ

283:デフォルトの名無しさん
06/02/06 19:46:27
CreateThreadをクリートスレッドって読んだんだろ。
馬鹿みたいだが。

284:デフォルトの名無しさん
06/02/11 07:40:21
もう二日も考え込んでるんですが解決しないんで質問です。(うう、マジで目と頭が痛い…。)
基本的に生産者消費者問題なんですが
Aが物を作るとBに渡し、Bが物を作るとCに渡し、Cが物を作るとDに渡す、というように
複数の生産者/消費者のベルトコンベヤーでの流れ作業を想定しています。
で以下のように組んでみたんですが、
今度はB自身が消費したことをB自身に知らせなくてはならなくてこんがらがってきました。

public class Main
{
public static void main(String args[]) {
ConveyerBelt stationAB = new ConveyerBelt();
ConveyerBelt stationBC = new ConveyerBelt();
ConveyerBelt stationCD = new ConveyerBelt();

Worker producerA = new Worker(stationAB);
Widget consumerB = new Widget(stationAB);
Worker producerB = new Worker(stationBC);
Widget consumerC = new Widget(stationBC);
Worker producerC = new Worker(stationCD);
Widget consumerD = new Widget(stationCD);

producerA.start();
consumerB.start();
producerB.start();
consumerC.start();
producerC.start();
consumerD.start();
}
}
ConveyerBelt()バッファーが三つというのは正しいと思うんですけど
スレッドはABCDの四つだけ作ればいいんでしょうか？どなたかご教授下さい。

285:284
06/02/11 07:43:18
ちなみにセマフォは「なし」の方向でお願いします。

286:デフォルトの名無しさん
06/02/11 07:47:19
日本語で質問してください

287:デフォルトの名無しさん
06/02/11 08:44:23
>>284
Chain Of Responsibility パターンはもう検討済みなの?

288:デフォルトの名無しさん
06/02/11 10:21:28
>>284
４つじゃないとダメなわけもないし、好きに作ればいい

289:デフォルトの名無しさん
06/02/11 12:09:10
各々理由を書いてね。

> 今度はB自身が消費したことをB自身に知らせなくては
> ならなくて

> ちなみにセマフォは「なし」の方向でお願いします。

290:デフォルトの名無しさん
06/02/11 18:57:50
>>289
正確厨、規格厨、口先厨の予感。現状提示されている情報から
回答が思いつかなければ、その問題に対する類似性や経験則
など思い当たるところが無いっつーことだろ。

全部の情報が分からないとコミュニケーションできないような
応用力無しやつは黙ってろ

291:デフォルトの名無しさん
06/02/11 19:56:02
>>9
Double Checked Lockingに追加

Scott Meyers & Andrei Alexandrescu
"C++ and The Perils of Double-Checked Locking (II)"
URLﾘﾝｸ(erdani.org)

付録に"volatile: Brief History"あり。

Douglas C. Schmidt & Tim Harrison
"Double-Checked Locking
An Optimization Pattern for Efficiently Initializing and Accessing Thread-safe Objects"
URLﾘﾝｸ(www.cs.wustl.edu)

292:デフォルトの名無しさん
06/02/11 21:48:09
>>290
エスパー以外は黙れと。

293:291
06/02/11 22:33:21
せっかく流れ切ったのに…

294:デフォルトの名無しさん
06/02/11 22:58:43
>>290
やんわりと、「設計がおかしいんじゃないか？」と言われてるんだよ。

まあ、もうまともな回答は期待できないだろうからどうでもいい話だが。

295:284
06/02/12 01:45:30
ご迷惑をお掛けしております。m(__)m

>>287
そんな概念があったんですね。というくらいなので検討済みではないです。
検索してみていくつかサイトを見つけたのでもう少し読んでみます。
分からなければまた質問します。それと
if (Thread.currentThread() == "Thread[Thread-0,5,main]")
System.out.println("I am the Worker A.");
のようなチェックを入れたいんですが、そんな比較はできないみたいです。
左辺値はどんな感じにすればいいんでしょうか？
これができれば、一つ一つ鎖をつなげていける気がするんですが。

>>288
逆を言うと「4つでもできる」ということですか？

>>289
現状を話しますと
Aから渡された物をB自身が処理(消費)してもないのに
(いや、時にはAから物を渡されてもないのに)
Bは勝手に生産を始めてしまいます。
ですから現在はA-B間、B-C間、C-D間のみで同期がされてます。
それと、やっぱりセマフォアは「あり」でもいいです。

296:デフォルトの名無しさん
06/02/12 05:05:21
ここでは綺麗でも汚くても叩かれますYOW

297:デフォルトの名無しさん
06/02/12 05:06:03
誤爆した　ｽﾏﾝ．．．

298:デフォルトの名無しさん
06/02/12 07:55:32
>>294
その「やんわりと」の部分が他人をイラつかせるんだよ。現実でも
相当にいやみな人間だろう

299:デフォルトの名無しさん
06/02/12 08:00:36
>>292
そこまで行間が読めないようだと生きるのに苦労してないか？

300:デフォルトの名無しさん
06/02/12 08:14:33
>>299
292は皮肉で言っただけだから、普段は別段苦労はしてないな。

301:デフォルトの名無しさん
06/02/12 11:03:26
この業界、日本語の喋れない奴ばかりだからエスパー能力は必須だよね
低級エスパーだから日々苦労してるよ

302:デフォルトの名無しさん
06/02/12 11:38:10
エスパーってほどか？　そうじゃなくてだな、俺の言いたいことはだ、

類似の問題を経験していたら回答が思い浮かぶだろ。素直に
それ書いてやりゃいいんだ。お前らだって今まで誰かに教えて
もらったり助けてもらったことあるだろうに。

それを忘れてくだらねー皮肉や、重箱の隅をつつくようなまぜっかえしを
親切を装ってやるようないやらしいことすんなよ。ﾅｻｹﾅｽ

303:デフォルトの名無しさん
06/02/12 11:48:06
別に2chで教えようと混ぜっ返そうとどっちでも構わんと思うのだけど。
まぁ、ヒントだけ貰った方がいい場合と答丸ごと貰った方がいい場合があるのでどっちがいいとも言えないしね。
漏れはここのスレでは教えることも教わることも少ないけど、この板全体では教わることより教えることのほうが多くなるようにしている積もりだがね。
混ぜっ返したり揶揄したり誘導したりも多いけどw

304:284
06/02/12 12:23:35
で、あのー・・・

305:デフォルトの名無しさん
06/02/12 12:28:35
生産者消費者問題くらい、標準的なテキスト読んで自分でやれ

306:284
06/02/12 12:37:41
テキストには生産者消費者が一対一の例しか載ってないんですよ。
こんなに真剣に質問してるのになんでこんな目に遭うんだ…
世の中絶対におかしい。

307:284
06/02/12 12:38:49
丸投げでもなく真剣に書いてるのに…もう馬鹿馬鹿しくて泣けてきた…もういいです。

308:デフォルトの名無しさん
06/02/12 12:57:25
なんで、consumerBとproducerBが別オブジェクトなわけ？
ふつうは入口と出口のある１つのオブジェクトとして考えるでそ？

309:デフォルトの名無しさん
06/02/12 13:03:48
お前らかわいそうだから教えてやれ。おれは良く分からないのでパス。ごめん

310:デフォルトの名無しさん
06/02/12 13:05:39
レベル１エスパーだけど、

>>284
>> ConveyerBelt()バッファーが三つというのは正しいと思うんですけど
>> スレッドはABCDの四つだけ作ればいいんでしょうか？どなたかご教授下さい。

唯一の正解があると思ってるのか？好きにつくれよ

311:デフォルトの名無しさん
06/02/12 13:06:34
>>306
質問する相手を間違えているだけだろう？
世の中がおかしいのではないと思う。

次ページ