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

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

369:デフォルトの名無しさん
06/03/05 00:20:02
>>364 例の URLﾘﾝｸ(www.nwcpp.org)
の最後のほうに
> Replace global singletons with per-thread singletons:
> - Each can use thread-local storage.
> -- Threading concerns during initialization thus vanish.
> - But now there are multiple "singletons."
と書いてあって、TLSを364のようには使ってないのが気になります。

一方、
URLﾘﾝｸ(www.cs.umd.edu)
でDoug Leaさんが364方式のTLSの使い方に文句を言っていない(条件
付きながら)ので大丈夫な気もします。まぁ、かなり昔のML投稿ですけど
ね・・。

さて真相は？

370:デフォルトの名無しさん
06/03/06 16:07:01
>>340
普通の卵は比較的簡単に立つよな。表面に凹凸があるから。産みたてほど立ち易い。
・・・コロンブスは卵をツルツルに磨き上げていたに違いない。

371:デフォルトの名無しさん
06/03/06 17:35:06
>>370
まあまあ。
コロンブスもギャグで言っただけなんだから許してやってくれ。

372:デフォルトの名無しさん
06/03/06 19:33:03
後世の作り話ですから。
まあ>>340は底抜けの馬鹿だけど。

373:デフォルトの名無しさん
06/03/07 14:35:11
ゆで卵にして高速で回せば立つよ。
まあ>>372は底抜けの馬鹿だけど。

374:デフォルトの名無しさん
06/03/07 14:57:53
盛り上がっているところ、横から突っ込んでスマンけど。

生卵を立てるには塩をごく少量盛って、その上に立てて、横から
息をゆっくり吹きかけて塩を飛ばすといいという話を聞いた。

とかいう本当にどうでもいい話をマルチスレッドスレでする
自分は底抜けの馬鹿ですｗ

375:デフォルトの名無しさん
06/03/07 19:27:05
つまり塩スレッドに卵スレッドをロックさせれば桶？

376:デフォルトの名無しさん
06/03/08 10:03:12
卵スレッド発見

377:デフォルトの名無しさん
06/03/08 20:55:31
つまらんよ >>369-376

378:デフォルトの名無しさん
06/03/08 21:34:40
君ほどでも

379:デフォルトの名無しさん
06/03/08 23:26:59
ゆで卵の殻を剥かずに塩をかけるなんて、底ぬけの馬鹿ですね

380:デフォルトの名無しさん
06/03/09 03:03:29
観光地のゆで卵は全部そうなってるよ

381:デフォルトの名無しさん
06/03/09 03:09:09
>>379
卵殻はNa+イオンもCl-イオンも透過するのでちゃんと卵に塩味がつきます。
溶けさえすれば。

382:デフォルトの名無しさん
06/03/09 15:12:11
※注意: このスレはこの卵ネタで1000まで引っ張る覚悟です

383:デフォルトの名無しさん
06/03/09 15:22:01
たまごが立つという状態を定義してください。

384:デフォルトの名無しさん
06/03/09 16:21:34
ブスの卵

385:デフォルトの名無しさん
06/03/09 17:20:48
>>383
案１：
水平方向の任意の角度から卵を投影したときに、水平方向のスパンよりも鉛直方向のスパンの方が長い状態。
ただし卵が他の物体と接することができるのは下部のごくせまい部分のみとする（←うまい定義できないなこれ）

386:デフォルトの名無しさん
06/03/09 20:48:52
ポテンシャルの極大点。

387:デフォルトの名無しさん
06/03/09 21:13:15
あ、あんたなんかにたたれてもうれしくないんだからねっ！

388:デフォルトの名無しさん
06/03/10 00:28:56
>>383
おまいはコンピュータか？　んなもん定義しないでも分かるだろ

389:デフォルトの名無しさん
06/03/10 03:03:47
クララが立った、と言う状態を定義してください。

390:デフォルトの名無しさん
06/03/10 03:04:39
精神的な自立

391:デフォルトの名無しさん
06/03/10 03:21:15
それで泣ける、という状態を定義してください。

392:デフォルトの名無しさん
06/03/10 08:40:40
クララが勃った、と言う状態を定義してください。

393:デフォルトの名無しさん
06/03/11 18:55:33
クララが勃った
クララは女である
∴よって勃ったのは乳首である

394:デフォルトの名無しさん
06/03/11 19:03:44
class clitoris extends electiliable {

395:デフォルトの名無しさん
06/03/12 11:42:52
>>394
なんだ、選挙にでも出るんか？

…それを言うならerectibleだろ。

396:デフォルトの名無しさん
06/03/12 16:25:47
Win32
Administrator権限で実行されてるプロセスからスレッドを起こすとき、
スレッドそれぞれに異なるユーザー権限を設定することは可能？
プロセスごとならできるんだが。もし可能ならAPI名などヒントを頼む。

397:デフォルトの名無しさん
06/03/12 16:54:30
インパーソネーションとかいうんだっけ？
ImpersonateLoggedOnUserとか。
まー、RevertToSelfとか呼ばれると、元に戻るけどね。

398:デフォルトの名無しさん
06/03/12 21:06:38
>>397
ありが㌧。
まだ試せてないが、MSDNの説明から目的に適うAPIのよう。

399:デフォルトの名無しさん
06/03/15 14:41:37
なぁなぁ、
class Job extends Thread {
　　　　　public void run() {}
}

class MyJob extends Job {
　　　　　public void run() {}
}
ってあったらMyJobのrun()がJobのrun()をオーバーライドするんで
Jobのrun()に書いてある定義とか全部無視されちゃうよね？
ちゅーか、Jobのrun()の一行目に
System.out.println("Hello? Hello? Can you read me?");//never displayed
と書いても表示されないから間違いない。
でも、どうやったら両方のrun()とも動かすこと出来るんだろ？

400:デフォルトの名無しさん
06/03/15 14:42:42
一応ageとく。

401:デフォルトの名無しさん
06/03/15 14:54:45
>>399
1つのスレッドで順番に動かしたいのか？
MyJob.run() と Job.run() を別のスレッドで動かしたいのか？
MyJob と Job のインスタンスをそれぞれ作ったらいけないのか？

402:デフォルトの名無しさん
06/03/15 15:48:21
>>401
ありがと。
二番目の「別のスレッドで動かしたい」かな。
run()直接アクセスするとあかんのよね、.startで始めないと？
どうしようかな？

403:デフォルトの名無しさん
06/03/15 16:35:55
>>402
その手法が可能かどうかの前に、やろうとしていることに対して
もっと単純な方法や、別の解法が無いか検討したらいいんじゃ
ないかな。

ちょっと言語（Java?）の使い方から外れているみたいので、
本当にやりたいことが妥当かどうか見極めた方がいいと思う。

404:デフォルトの名無しさん
06/03/15 22:37:56
>>399
super.run();

405:デフォルトの名無しさん
06/03/16 09:59:17
>>403
確かにそうだったかもしれん。ありがと。

>>404
いや、直接run()にアクセスするのは禁(ry

406:デフォルトの名無しさん
06/03/16 14:36:26
Linux 　2.4.31-0vl1.8smp + glibc-2.3.3-3vl1.3

pthread (linuxthread) プログラムでたまーに(でも確実に) seg fault してしまいます。
該当箇所は
　pthread_mutex_unlock(&mutex_sleep);
という処理で、mutex_sleep はグローバル。core dump に聞いてみたらこんな返事が。

Program terminated with signal 11, Segmentation fault.
#0 　0x080551c7 in __pthread_alt_unlock (lock=0x80cb548) at spinlock.c:600
　　　 } else if ((prio = p_node->thr->p_priority) >= maxprio) {
(gdb) bt
#0 　0x080551c7 in __pthread_alt_unlock (lock=0x80cb548) at spinlock.c:600
#1 　0x08051fc9 in __pthread_mutex_unlock (mutex=0x80cb538) at mutex.c:199
#2 　0x0804e3cc in send_proc (arg=0xc) at send_proc.c:112
#3 　0x08051709 in pthread_start_thread (arg=0xbdbffbe0) at manager.c:309

何か情報ありますか？

407:デフォルトの名無しさん
06/03/16 20:44:16
mutexがすでに死んでるとか？

408:デフォルトの名無しさん
06/03/16 22:30:14
Windows Threadについて質問です。擬似コードですが、
Thread[] threads = getAllThread();
foreach (Thread t; threads) {
t.suspend();
}
このような全てのスレッドを止めるためのループがあるとします。
このループ中では、既に止められているスレッドと、
これから止められる予定のスレッドがあると思うのですが、
これから止められる予定スレッドが、既に止めたスレッドを再開(resume)するため、
このループでは全てのスレッドを止められない、ということは起こりえるのでしょうか？

409:デフォルトの名無しさん
06/03/16 22:36:16
>>408
起こりうるでしょうね。
避けたいのならばまず自分の優先順位をトテモ高くして、
その後ループに入れば良いと思います。

先方のスレッドも優先順位を上げている恐れがあるのならば
完全ではありませんが。

410:デフォルトの名無しさん
06/03/16 22:36:36
知らね。

だって、普通そんな造りにしないもん。
普通は、終了しろ、っていう合図を各スレッドに送って
自主的に終了なり中断なりするのを待つだけだから。

411:デフォルトの名無しさん
06/03/16 22:37:03
起こりえる。
おまけにこれから止めようとするスレッドが新たにスレッドを作るかもしれない。
全スレッドで、「スレッドマネージ用ミューテックス」などを使用すればいいんでない？

412:デフォルトの名無しさん
06/03/16 22:39:04
他のスレッドを suspend するってのはまず間違いなく設計ミス。
C のランタイムとか Windows に用意されているいろんな dll の
内部まで良く知っていて、何か大事なものの所有権を持ったまま
suspend されちゃったりすることはないと確信を持っているなら
別だけど。

413:408
06/03/16 22:46:12
どうも。
実は、これのpause版とresume版がD言語の標準ライブラリの中にあって、
GCを呼ぶ前にそれでスレッド止めて、後に再開ようとしているみたいなのですけど、
それのへんでアプリケーション側で実装しているスレッドの同期が変になるみたいです。
安心できませんが、安心しました。

414:408
06/03/16 22:52:58
スレッドを止める仕様はどうしようもないのですが、
とりあえずは、全てを止めるループ中(pauseAll)に
pause()、resume()とstart()が実行されないように排他とと
全てを再開(resumeAll)中に、resume()が実行されないように
排他したら大丈夫ということでしょうか？

415:デフォルトの名無しさん
06/03/16 23:01:54
>>414
GC 側が単純なメモリ操作などだけで、
他の処理で使っている（かもしれない）セマフォやミューテックスなどの
所有権なしで実行できるとするなら、問題ないはず。

例えば（MSのドキュメントを信用するなら）Windows API の OutputDebugString は、
内部で他のスレッドを全て Suspend した上でデバッグメッセージの送信を行い、
そののち Resume する、と同様の処理を行っているようです。

AP側のスレッドが変になるのはAP（or Dの何か他のライブラリ）のバグではないでしょうか。

416:408
06/03/16 23:28:41
>>415
resumeThreadの戻りを見ながら、他スレッドのsuspend待ちをしている箇所があるので、
それが、排他されていないresumeAll中に走ると、
GCが止めてこれから再開する予定のスレッドを、
"アプリケーションが思っている理由"でsuspendしたのだと
勘違いして変になるのだと思っています。

417:デフォルトの名無しさん
06/03/17 06:51:35
>>407
ありがとうございます。
pthread_mutex_destroy は呼んでいないので生きていると思っていたのですが、どうやら
syslog(3) が関係しているようです。別の core dump に聞いてみたら syslog 関数で死んで
いるケースが見つかり、付近の syslog(3) をはずしたら seg fault することはなくなりました。

syslog(3) と pthread (linuxthread) は混ぜるな危険とかいう話があるんでしょうか。
とりあえず syslog を自前で用意することにしてみます。

418:デフォルトの名無しさん
06/03/17 07:20:23
その環境ではsyslog(3)はMT-Safeじゃないのに、排他してないだけとか

419:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 19:49:50
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

420:デフォルトの名無しさん
06/03/28 00:13:15
こんな問題助けてください。
I/Oバウンドな処理をする処理プログラムが2個
CPUバウンドな処理をするプログラムが1個

それぞれCPUは85～95％占有するほど負荷が大きいです。
またそれぞれI/O処理は多重スレッドはなく2つの独立した
スレッドプログラムです。

Xeon 64bit x2 (64bitSMPカーネル+ HTTでCPU4個)
Xeon 32bit x2 (32bitSMPカーネル+ HTTでCPU4個)

Opteron 252 x 4(64bitSMPカーネル)
Opteron 252 x 4(32bitSMPカーネル)

いずれの場合も、CPUを占有したいと考えるならばcpu_affinityを
ハードウェア的に割り当てるべきなのでしょうか。
それともカーネルのSMP処理に任せるべきなのでしょうか。

421:デフォルトの名無しさん
06/03/28 06:09:38
page outないくらいメモリが十分にあると考えると、
(OSによってはI/Oキャッシュがメモリを食い潰してしまいますが)
I/Oバウンドな処理をするプログラムにCPU割り当てる意味ないでしょ。

けど、
> それぞれCPUは85～95％占有するほど負荷が大きいです。
で「I/Oバウンド」なの?

それからマルチスレッドじゃないw

422:デフォルトの名無しさん
06/03/28 12:47:04
>>420
CPU占有を占有したいなら、邪魔しに来る恐れのあるほかのプロセスは
どれか他のCPUに割り当てるべき。

CPUを占有することの利点は、
・他のCPUでの処理の邪魔をしない
・各CPUが独立した2次キャッシュを持っているとき、キャッシュの汚染に
よるパフォーマンス低下を避けられる（かもしれない）
の２つくらい。

カーネルに任せるべきかどうかはなんともいえない。
プログラムの性格にもよるし、カーネルのスケジューラーの実装にもよる。

423:420ではない
06/03/29 00:15:05
ぶっちゃけ聞きたいんだが、
「cpu_affinityをハードウェア的に割り当てる」
って、現在存在するOSの中でどれよ？

424:デフォルトの名無しさん
06/04/04 15:54:42
C++で質問ぬ
beginthreadexで作ったスレッド
exitthreadexしないでスレッド関数return で終了して
CloseHandleしても問題ないですか？

サンプルで exitthreadをreturn の前に呼んでるのと
呼んでないの
があったので

425:デフォルトの名無しさん
06/04/04 16:29:21
>>424
寧ろ、exitthreadするとC++のデストラクタが走らないので問題になりがち。
極力returnするべき。

426:デフォルトの名無しさん
06/04/06 01:56:06
世はSPEでプログラミングしたいのじゃ

427:デフォルトの名無しさん
06/04/06 13:02:49
>>423
つ z/OS

428:デフォルトの名無しさん
06/04/16 00:01:57
世界で始めてデッドロックを実際に経験した人って誰だろう。
あまりにもの恐ろしさに震え上がったことだろう。

429:デフォルトの名無しさん
06/05/06 21:33:59
俺

430:デフォルトの名無しさん
06/05/06 22:23:42
哲学者よフォークを取れ！！

431:デフォルトの名無しさん
06/05/06 23:33:04
先生、フォークが足りません！！

432:デフォルトの名無しさん
06/05/06 23:41:15
フォークを取ってどうすんだよｗ

433:デフォルトの名無しさん
06/05/06 23:46:41
通じてないのかさらに深い洞察なのか…

434:デフォルトの名無しさん
06/05/06 23:47:34
そうかパスタを取れか！！

435:デフォルトの名無しさん
06/05/06 23:50:03
>>434
てめー、すました顔してないで早くフォークよこせよ

436:デフォルトの名無しさん
06/05/06 23:54:39
まず全てのフォークをいったんテーブルに戻して、
そして．．．

哲学者よフォークを取れ！！

437:デフォルトの名無しさん
06/05/06 23:55:20
すまん、記憶違いだったら悪いんだが。
哲学者よときたら「箸をとれ」じゃなかったか？

438:デフォルトの名無しさん
06/05/06 23:58:02
>>432
哲学者の食事問題を知らない奴ｷﾀｰ

439:デフォルトの名無しさん
06/05/06 23:59:11
>>437
ヒント：哲学者は日本人ではない

440:デフォルトの名無しさん
06/05/07 00:00:54
ヒント：ダイクストラ

441:デフォルトの名無しさん
06/05/07 00:10:23
哲学者よ

死ぬくらいなら手づかみで食え

442:デフォルトの名無しさん
06/05/07 00:11:25
哲学者はきわめて明確な論理で行動するため、
臨機応変などという言葉は通用しません。

443:デフォルトの名無しさん
06/05/07 00:17:27
哲学者は、野蛮では無く極めて理知的に出来ております。

444:デフォルトの名無しさん
06/05/07 01:26:53
Dining Philosophers Problem は設定がシュール過ぎて
授業中に笑い出しそうになった

445:デフォルトの名無しさん
06/05/07 04:53:31
シュレディンガーが猫を題材にしたのと通じるものがあるな

446:デフォルトの名無しさん
06/05/07 09:56:09
お前なーやめろよ
話の流れから

シュレディンガーが猫を食材にしたのと通じるものがあるな

と読んじゃったじゃないか
まぁ、たいして違いはないが

447:デフォルトの名無しさん
06/05/07 13:34:52
哲学者よ、明日はパスタにしよう。うん、パスタ。

448:デフォルトの名無しさん
06/05/07 21:18:36
哲学者は手掴みで食べないものなのですか?

449:デフォルトの名無しさん
06/05/07 21:22:19
哲学者はそんなはしたないまねはしません。
しかし決して人に譲ることもしません。

450:デフォルトの名無しさん
06/05/08 00:23:38
哲学者よデスマーチから逃げれ！！

451:デフォルトの名無しさん
06/05/08 09:39:33
age

452:デフォルトの名無しさん
06/05/09 20:31:01
Cでスレッド固有のグローバル変数みたいなものって使えないかな
ほぼ全ての関数でスレッドごとに値の違う変数使ってるんで
毎回引数に加えるのが面倒になってきた

453:デフォルトの名無しさん
06/05/09 20:48:51
処理系固有でTLSなどがあるとは思うが。

454:デフォルトの名無しさん
06/05/09 22:34:47
>>453
サンクス。しらんかった

455:デフォルトの名無しさん
06/05/10 00:58:57
gccだと、

__thread int i;

とか。

456:デフォルトの名無しさん
06/05/10 01:26:42
調べました
pthreadだとpthread_key_create()とかですね
__threadの方が扱いやすいけどポータビリティとしてはどうなんだろう
gcc依存でも別に困りはしないんですけどｗ
何はともあれありがとうございました～

457:デフォルトの名無しさん
06/05/10 08:23:30
ポータビリティが気になるなら APR とか使うのは?

URLﾘﾝｸ(apr.apache.org)

458:デフォルトの名無しさん
06/05/14 15:00:46
結城浩のデザインパターンスレッド編って買い？

459:デフォルトの名無しさん
06/05/16 12:59:06
　　 . 　-‐-　　.　　
__ 〃　　　　ヽ :　　
:ヽ＼　ノﾉﾉ）ﾍ)､!〉 :
'. l(0_)!｡-‐　‐〈ﾘ　.はわわ～マルチが459ゲットですぅ…
　;Vﾚﾘ､" (ﾌ／ ;　
　　 : l´ヾＦ'Fl :　　　　　　　　　∧＿_∧＿___　
　　 ;. 〉､_,ノ,ﾉ :　　　　　　　　／|・∀・ ┥　.／＼
　　. /ゝ/´, ヽヽ . .　　　　　／|￣∪∪￣￣|＼／　
　 : く/l |_ノﾄ‐'⌒),)　.　　　　 |　拾って　　|／　

460:デフォルトの名無しさん
06/05/20 17:07:49
>>458
買い。

461:デフォルトの名無しさん
06/05/22 00:45:49
longの読み書きについて質問失礼します。

①マルチスレッドで InterlockedExchange を使用し、longの値を変更しています。
②別スレッドで①で変更しているlong値を参照しています。
（読むだけの Interlocked～の関数が見当たらない為）
この処理って大丈夫なんでしょうか？

実際にソースに組み込んでテストしているのですが、今の所大丈夫っぽいです。。。

462:デフォルトの名無しさん
06/05/22 01:19:41
volatile修飾すれば大丈夫という噂

463:デフォルトの名無しさん
06/05/22 01:25:57
共有リソースを元に、あるメモリに書き込みとかをしなければ問題ないよ。
参照だけなら、何の問題もなし。

464:デフォルトの名無しさん
06/05/22 03:01:15
Interlocked.Read

465:デフォルトの名無しさん
06/05/22 03:01:52
てv1か…
Interlocked.Readは2からだったな…

466:デフォルトの名無しさん
06/05/22 06:15:08
>>461
InterlockedExchangeAdd

467:デフォルトの名無しさん
06/05/23 16:38:37
Pentium XE 840 ではHyper-Threading有効となっているので、
デュアルコア×2スレッドで4スレッド同時処理ができますが、
HTの論理コアを判別する方法はないでしょうか？

SetThreadAffinityMask() を利用して１つのコアを
スレッドに対して独占的に割り当てた場合にHT論理コアだと
処理速度向上が余り望めません。

もしくはWindowsでＣＰＵ番号（コア番号）が
どのように割り当てられるかご存知ないですか？

単純に↓とか？
CPU1-Core1-Main
CPU1-Core1-HT
CPU1-Core2-Main
CPU1-Core2-HT

Opteron だと？
CPU1-Core1
CPU1-Core2
CPU2-Core1
CPU2-Core2

468:デフォルトの名無しさん
06/05/23 18:35:25
>>467
何か勘違いしてないか？

469:デフォルトの名無しさん
06/05/23 22:13:13
>>468
何か勘違いしてないか？

470:デフォルトの名無しさん
06/05/26 02:28:01
>>467
それはOSの仕事

471:デフォルトの名無しさん
06/05/26 09:01:15
SetThreadAffinityMask(hThread,0x01);
SetThreadAffinityMask(hThread,0x02);
SetThreadAffinityMask(hThread,0x04);
SetThreadAffinityMask(hThread,0x08);
とした時にどのコアが使用されるか知りたいってことじゃねーの？

472:デフォルトの名無しさん
06/05/26 11:26:01
>>467
URLﾘﾝｸ(www.intel.com)

SetThreadAffinityMaskでCPUにスレッドを固定した後、
当該スレッド APIC ID を入手して core id と SMT ID を入手すればよい。

用語が混乱してるようだけど、Coreっていうのはホントのcoreのことで、
コアの中で演算回路等を共有して独立したCPU風に振舞うのはlogical
cpu とか SMT とか言う。

例えばDualCore でコアあたり2つのSMTをサポートするCPUの論理CPU構成は
Core1-SMT1 / Core1-SMT2 / Core2-SMT1 / Core2-SMT2　だ、
とこんな風に言う。

473:デフォルトの名無しさん
06/05/26 12:26:42
CRITICAL_SECTIONを使う場合ローカルなstatic変数として使用してもよいのでしょうか？
↓のような関数をスレッド内で呼び出す場合です。（ここではcountに同時アクセスしないようにすることを目的とする）
int hoge(int init, int del, int i)
{
　　static CRITICAL_SECTION cs;
　　static int count;

　　if(init) InitializeCriticalSection(&cs);
　　if(!init && !del)
　　　　{
　　　　　　EnterCriticalSection(&cs);
　　　　　　count += i;
　　　　　　LeaveCriticalSection(&cs);
　　　　}
　　if(del) DeleteCriticalSection(&cs);

　　return count;
}

474:デフォルトの名無しさん
06/05/26 16:39:43
>>470
ヴァカ発見

475:名無しさん
06/05/26 19:42:14
＞４７３
関数のセマンティクスとしてはクソだが、特に問題は発生しないだろう。

476:467
06/05/26 20:21:43
>>472
なるほど…スレッドを固定してCPUIDでチェックすれば判別できそうですね。
用語解説は非常に勉強になりました。
ありがとうございますー

良く考えてみればSMT1が軽い負荷ならSMT2に重い負荷を
かけても遅くならないのかな…？
だとすると、同じコアのSMT1とSMT2に割り当てないようにすれば
効率が良さそうですね。

477:デフォルトの名無しさん
06/05/26 23:31:44
時期尚早な最適化は諸悪の根源だ

478:473
06/05/27 00:41:46
>>475どもです。

479:デフォルトの名無しさん
06/05/27 01:31:47
>>476
みんなpthreadのデバッグってどうやってやってますか？

1ソースコードから処理を推測してデバッグ
2とりあえずなんでもいいからprintf仕込んでデバッグ
3gdbを利用する
4ツールを使って調査する。
もしいいツールとか方法あれば教えてください。

480:デフォルトの名無しさん
06/05/27 11:05:19
>>479
つ【5 - pthreadの気持ちになってみる。】

481:デフォルトの名無しさん
06/05/27 12:17:16
>>479
pgdbgはどうよ? (というかプラットフォームは何よ?)

Linuxは、IBMがpthreadを手がけた時に、
libpthdebug.aがAIXから持ち込まれるかと思ったが、
IBM版はlinuxサイドから拒絶されたので実現しなかった…

482:デフォルトの名無しさん
06/05/27 12:30:20
pgdbgですかぁ渋いですね
それでいっちょ今から会社飛んでデバッグしてきますね

483:デフォルトの名無しさん
06/05/27 17:23:07
基本的に知識足りてねぇって感じなんですが質問させてください。
boostのmutexとconditionでWindowsAPIのEventと同等機能をやろうと思ってやってたんですが
boost::condition::notify_oneを呼ぶときもmutexでロックしないとまずいですか？
これがデッドロックせずに動くってことは多分そういうものだとは思うのですが…

boost::mutex g_mutex;
boost::condition g_cond;

void Wait()
{
　boost::mutex::scoped_lock lk(g_mutex);
　g_cond.wait(lk);
}

void Notify()
{
　boost::mutex::scoped_lock lk(g_mutex);　// これって必要ですか？
　g_cond.notify_one();
}

484:デフォルトの名無しさん
06/05/27 23:06:05
それでええで。
examples/libs/thread/example/condition.cpp 見てみ。

485:デフォルトの名無しさん
06/05/27 23:06:55
examples/は余分やな…

486:デフォルトの名無しさん
06/05/27 23:20:41
だめだ、pthreadが周りでどうしても落ちる
セグ落ちでどうしてもダメううーん発見できん
神様助けてくれ

487:デフォルトの名無しさん
06/05/28 23:20:52
>>484
ありがとうございます、スッキリしました。

488:デフォルトの名無しさん
06/05/30 18:30:41
>>486
落ち始める直前の状態にまで戻して何やったのか胸に手を当てて考えてみれ。

489:デフォルトの名無しさん
06/05/31 00:36:18
ふっふっふっふ私はもうスレッドは怖くない
スレッドの挙動を完璧把握する方法を知ってしまった
ふっふっふっふ

490:
06/06/01 02:46:02
pthread_cond_timedwaitで、指定タイマーを経過しても待ち状態解除されず
停止したままになってしまっているのですが、引数パラメータに問題が
あるのでしょうか。
gdbで確認したところ引数は問題なさげで、pthread_cond_timedwait内の
pthread_sigsuspendで停止してるっぽいのですが…。

491:デフォルトの名無しさん
06/06/01 12:38:26
糞カーネルを使っているに一票

492:デフォルトの名無しさん
06/06/07 01:46:39
まずOSの種類とカーネルの素性晒せ

493:デフォルトの名無しさん
06/06/07 08:46:05
ＬＩＮＵＸですよ（＾＾）

494:デフォルトの名無しさん
06/06/08 01:10:24
それは windows でない。とだけ言ってるに等しい

495:デフォルトの名無しさん
06/06/08 13:42:04
マルチスレッドとマルチプロセスでは一般的にどちらが効率的ですか？

496:デフォルトの名無しさん
06/06/08 18:36:22
タスク間のデータ参照が多いプログラムと少ないプログラムでは、どちらが「一般的」ですか？

497:デフォルトの名無しさん
06/06/10 01:47:28
volatileで回避できますか？

498:デフォルトの名無しさん
06/06/10 04:22:44
volatileとstaticで8割方回避できます！

499:デフォルトの名無しさん
06/06/10 08:47:58
なにをだ。

500:デフォルトの名無しさん
06/06/10 10:14:15
mutexとvolatileでは一般的にどちらが効率的ですか？

501:デフォルトの名無しさん
06/06/10 12:19:02
コーディング効率か
コードの効率か
で回答が変わってくる可能性がある

502:デフォルトの名無しさん
06/06/10 12:24:23
volatileはLockFreeで高速だが、アトミック操作に限定されるので、
一変数ならともかく、全体の整合性がどういう言い出すとプログラムは
とっても面倒だし、バグがあるかないかの検証も面倒くさい

503:デフォルトの名無しさん
06/06/10 12:54:08
（　ﾟдﾟ）ﾎﾟｶｰﾝ

504:デフォルトの名無しさん
06/06/10 14:14:06
>>501-502 がﾏｼﾞﾚｽである可能性を想像し、背筋が凍った。

505:デフォルトの名無しさん
06/06/10 15:55:27
そのまま風邪引いて肺炎悪化させて死んでくれ

506:デフォルトの名無しさん
06/06/10 16:56:15
こんにちわ。誘導されてきました。
セマフォの扱い方について、よろしければ教えてください。

以下が環境です。
・HP-UX & aCC
・共有メモリを使用し、その排他制御にセマフォを使用している
・共有メモリとセマフォは専用のクラスを作成して管理している
・上記資源は複数のプロセスで使用する
・上記管理クラスのインスタンスはプロセス内に複数存在する

やりたいことは以下の通りです。
・１つのプロセス内で、同じキー値を利用するセマフォの lock を
　ネストさせても２回目以降の lock で固まらないようにしたい
・unlock はネスト中の実際に lock した箇所に対応したところで
　実行するようにしたい

　void a() {　　　　　　　　　　　　　　　void b() {
　　CSemafore sem1;　　　　　　　　　　　　CSemafore sem2;
　　sem1.lock();　　　　　　　　　　　　　　　　sem2.lock();　←ここで固まらないようにしたい
　　b();　　　　　　　　　　　　　　　　　　　　　sem2.unlock();
　　sem1.unlock();　←ここで解除したい　　}
　}

セマフォのクラスインスタンスが１つの場合は lock の回数を数えるカウンタを
用意することで解決できそうなのですが、複数の（同じキー値を利用する）インスタンスが
絡んできた場合に、上手に処理する方法が思い浮かびません。

こういったことは可能なのでしょうか。ご教示頂けると嬉しく思います。
よろしくお願いいたします。

507:デフォルトの名無しさん
06/06/10 17:01:47
trylockしてみて無理だったら待てばいいんじゃねぇの？
違うってかゴメンね

508:デフォルトの名無しさん
06/06/10 17:27:39
>>506
どういうデッドロックを想定しているの?

th1がaをlockしてbを得ようとして、th2がbをlockしてbを得ようとしているとか?

入れ子セマフォア
多重セマファオ
で解決できませんか?

509:デフォルトの名無しさん
06/06/10 17:47:33
>>508
>入れ子セマフォア
>多重セマファオ
おチツ毛

510:506
06/06/10 19:05:08
>>507
ご返信ありがとうございます。
trylock とは「lock が可能な状態であれば lock を実行し、そうでなければなにもしないで
終了する」処理との理解で正しいでしょうか。trylock が失敗した場合の処理を実装できれば
よいのですが、出来るだけ単純化したいと考えており、今回の件では少し辛いです。すみません。

>>508
ご返信ありがとうございます。
知識が足りず「入れ子セマフォ」「多重セマフォ」の言葉が分かりません。
検索も試したのですが．．．　すみません。

今回はスレッドを使用していないので基本的にはプロセス単位で考えています。
目的としては同一プロセス（スレッド）による lock でデッドロックを発生させないように
する方法を探しています。ご例示頂いた異なるスレッドによるデッドロックは‥‥実際にやって
いたのですがw、プログラムを直してうまく動くようになりました。

先の投稿に記述した「やりたいこと」について考えていたのですが、以下のようにすれば
出来そうに思えてきました。
・２つめの unlock 位置の判定の件は「カウンタ」の管理で解決できそう
　（もっと良い方法があるようでしたらご教示頂けると嬉しいです）
・１つめのネスト時のデッドロック防止については、セマフォのキー値毎に最後に lock を
　掛けたプロセス（スレッド）を識別出来るようにして、それが自プロセス（スレッド）で
　ない場合だけ lock 処理を実施する

上記の「最後に lock を掛けた（sembuf.sem_op を 0 にした）プロセス（スレッド）を識別する」
方法はあるのでしょうか。お知恵を拝借できれば幸いです。

>>509
少しウケました。そのノリは高校の時以来です。w

511:デフォルトの名無しさん
06/06/10 19:54:30
>>510
Wikipedia項目ﾘﾝｸ

古典的って言ったら古典的か．

512:デフォルトの名無しさん
06/06/10 19:56:50
>>510
ロックの話だけで頭がいっぱいになってるけど
そのsem1とsem2の間でどんな処理をするのか
教えてよ。

513:506
06/06/10 21:59:59
>>511
ご返信をありがとうございます。
これは「多重セマフォ」の解説（使用例の項）でしょうか？
残念ですが、今回の件は同時参照を全て止める必要があるため、初期値を大きくすることに
よって解決とすることは出来ないと思います。情報をありがとうございました。

>>512
ご返信をありがとうございます。
不要と判断していました。たとえばですが。

共有メモリにある情報をまとめたテーブルがあるとします。
関数 SetData01() はこのテーブルの特定のデータを変更します。
同様に SetData02() など複数の関数があり、それぞれ関数内部でデータを変更するための
（受取手にとってわかりやすい形から格納に適した形への変換などの）処理を実施しています。
これら関数には対応する GetData**() も存在し、変更／参照時には共に排他制御(sem2)を実施します。

更に上記個別の値をまとめて取り扱う関数として SetGroupData() なる関数があり、
先の個別にデータを変更／参照する関数を内部で使用します。
この関数でのデータの変更時には、関連する全てのデータ更新が終了するまではデータ間での
矛盾発生を防ぐために他からのデータ参照を止めたい場合があるため、この関数の実行時にも
排他(sem1)を掛けたいと考えています。

回避策として、SetGroupData() で SetData01() などを呼ばずに自前で個別データの
設定を行う方法もあるのですが、少々煩雑な処理をするところもあるため、可能であれば
SetData01() などを利用する形に出来ればと思っています。

そのままのことは書けないため、説明が足りないところもあるかと思いますがご容赦ください。

514:デフォルトの名無しさん
06/06/10 23:56:28
>>513
そのよくわからんけど、SetDataなんちゃらっていうメソッドをいくつも用意するの？
そんなことするよりもさ
SetData(class data)を用意してこいつが責任もって共有データを単独で更新すればいいんじゃないのか？
じゃあ、みんなで同時に呼べねーべバーカとか思うなら、このSetDataは要求をスタックに貯めて逐次実行する
仕組みだけを排他制御で実装すればいいよね。共有メモリに置く程度のデータならそれぐらいで間に合わないかな？

515:506
06/06/11 15:27:03
>>514
ご返信、ありがとうございます。
初めからそういう方向性を考えていれば．．．と後悔しているところです。(汗
次こそわ。

516:デフォルトの名無しさん
06/06/11 20:23:12
いや、変えないと今のも終わらないから。

517:デフォルトの名無しさん
06/06/12 17:52:57

質問です。
_beginThreadを使ってスレッドをつく、その中でゲームの描画をまわしているのですが

void ThreadMain(void* pParam)
{
　HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
　DWORD dwLastTime = timeGetTime();
　while(!pApp->m_bStopThread)
　{
　　WaitForSingleObject(hEvent, 16 - __min(16, timeGetTime() - dwLastTime));
　　dwLastTime = timeGetTime();
　　//実際はここで描画をするけど、今は空.
　}
CloseHandle(hEvent);
_endthread();
}

こんなことを行なうとタスクマネージャー上でCPUパワー使用率が100%近くになってしまいます。
(WaitForSingleObjectは、待機中CPUパワーを使わないとあったので期待したのですが)

Sleepあたりを入れてみたりしても、Sleep(1000);くらい大きく指定しないと使用率0%付近になりません。
スレッドを使った場合、CPU使用率は高くなってしまうものなのでしょうか？

今まではスレッドを使わず、WinMainで処理をしていたのですが、そちらでは使用率が0%に近かったです。

518:デフォルトの名無しさん
06/06/12 17:53:43

今までスレッドをやらないパターンですとこんな感じでした。
CPU使用率は常に0%付近でした。

//WinMainに
while(TRUE){
　while(0 != PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)){
　　if (!GetMessage(&msg, NULL, 0, 0))
　　　return msg.wParam;
　　TranslateMessage(&msg);
　　DispatchMessage(&msg);
　}
　else if (16 <= timeGetTime() - dwLastTime){
　　dwLastTime = timeGetTime();
　　// 処理
　}
}

519:デフォルトの名無しさん
06/06/12 18:04:20
>>517
それ、WaitForSingleObject で待ってない（即リターンしてる）から。
他のスレッドが所有権を持ってないので、呼び出したスレッドが即座に所有権を得ておしまい。
2度目以降の呼び出しは、呼び出したスレッドがすでに所有権を持っているので即座に完了。

他のスレッドに所有権を持たせておくか、selectとかSleepでも使うべし。

520:519
06/06/12 19:39:57
今思いついたんだけど、とにかくタイムアウトさせたいなら
GetCurrentThread() で得たハンドルを wait してもいいのかもしれない。

521:デフォルトの名無しさん
06/06/12 19:45:59
>>519
アドバイスありがとうございます。
ただ、デバッガで追ってみましたところきちんと毎回Waitしている様子です。
Wait時間を分かりやすく5秒にしてみたところ、私の期待通りの動作をしているようです。

selectについてもこれから試してみたいと思います。

522:デフォルトの名無しさん
06/06/12 19:53:00
Sleep、WaitForSingleObject、いずれも、寝ている時間の精度自体は5msも保証できない

523:デフォルトの名無しさん
06/06/12 19:57:04
>>522
なんと、そうなのですか？
やはりFPS60なんていう精度を望む場合
Waitなんて無しでぶんまわしつづけるしかないのでしょうか？

(そもそも、Windowsで精密ゲームを作ること自体、Windowsの設計理念とは反している気がしますが)

524:519
06/06/12 20:25:43
>>521
そですか・・・ところでメインスレッド側は PeekMessage 無しに戻しましたか？
単純に >>518 から else 以降を取ってしまうと、CPU 100% のビジーループに
なるわけですが。

525:デフォルトの名無しさん
06/06/12 21:08:55
ところで、なんで、NOREMOVEでPEEKしたあと、またGetMessage呼んでるの？
単純に、直接REMOVEでPEEKして、Translate,Dispatchすればいいと思うんだけど

526:デフォルトの名無しさん
06/06/13 14:46:50
pthread_create() で作ったスレッドが終了したかどうかの確認は
どうしたらいいんでしょうか? pthread_join() してしまうとその
スレッドが終わるまで待たされてしまいますよね?

やりたいことは、複数のスレッドを作って、作った側で pthread_t
の配列にスレッド識別子を入れておき、それぞれがバラバラの
時間で終わるんですが、作った側で pthread_t の配列に入っている
値を元にそれぞれが終わったかどうかを確認して、終わっていたら
それに対して pthread_join() をやって資源開放をて、配列の側も
その部分を終了しているという値(たとえば0)にしたいんです。
(つまり UNIX で複数 fork() したあとで waitpid() の WNOHANG
みたいにして何が終わったか、あるいは何も終わっていないのかを
確認するのと同じことです)。こういうのは pthread ではどうやる
んでしょうか?

527:デフォルトの名無しさん
06/06/13 21:33:23
pthreadは詳しくないけど自分でフラグ作っても大して開発効率落ちないと思う。

528:デフォルトの名無しさん
06/06/14 00:10:40
SIG_CHLDシグナルで判断しろよ

529:デフォルトの名無しさん
06/06/14 12:15:21
>>528
pthread で作ったスレッドに対して SIGCHLD は使えないのでは?
子プロセスじゃないんだし。(Linux の実装だと使えるとか?)

530:デフォルトの名無しさん
06/06/14 13:11:53
POSIX P1003.1cにpthread_kill()ってのがあって、
signalを指定する引数に0を指定すると、
pthreadがいれば成功(シグナルは何も送られない)、
いなければESRCHのエラーになる。

processに対するkill(2)と同じ仕様。

> 自分でフラグ作っても大して開発効率落ちないと思う。

ではありますが。

531:デフォルトの名無しさん
06/06/14 13:23:26
>>530
あー! その手があったか。
くっそー。 pthread_kill() の man ページは見ていたのに気が付かなかった。

どうもありがとうございます。

532:デフォルトの名無しさん
06/06/17 17:46:23
スレッドのデバッグって何使ってますか？
Linuxだとgdbだけかな？

533:デフォルトの名無しさん
06/06/19 00:32:10
知恵と勇気

534:デフォルトの名無しさん
06/06/19 01:05:12
>>533
そんなのいらねーよ何か教えねーと食うぞ？

535:デフォルトの名無しさん
06/06/19 10:33:24
「ちびくろ！　おまえを　たべちゃうぞ！」と、とらは　いいました。

536:デフォルトの名無しさん
06/06/19 21:49:53
>>532
かん

537:デフォルトの名無しさん
06/06/20 13:18:17
>>532
おれ、この前 gdb でやってみて大混乱。
使い方調べてから使わないといかんね。

538:デフォルトの名無しさん
06/06/24 17:19:02
無茶しやがって…

539:デフォルトの名無しさん
06/06/24 21:26:39
Windowsで、タスク内の複数スレッド間だけで通用する、高速な同期オブジェクトって無いですかね?
なんか、どれもこれも、重そうで。

540:デフォルトの名無しさん
06/06/24 23:41:41
イベント系はユーザーモードで実行される。
イベント系はプロセス間の動機にも使えるという強みがある。
クリティカルセクションのみカーネルモードで実行される。
クリティカルセクションはプロセス間の動機で使えないがイベント系に比べると
非常に高速だという強みがある

541:デフォルトの名無しさん
06/06/24 23:49:15
>>540
クリティカルセクションって何？

542:デフォルトの名無しさん
06/06/24 23:58:44
ミューテックスとほぼ同じ。
タイムアウト指定ができなかったりする。

543:デフォルトの名無しさん
06/06/25 00:07:28
カーネルモードに移行するものが高速で
ユーザーモードのまま実行できるものの方が遅いって？

544:539
06/06/25 03:10:41
クリティカルセクションだと、スレッド間での排他は楽だけど、同期には使えないよね。
イベント系はカーネルまで落ちるし、プロセス間で使えるから重いよね。

同期に使えて、カーネルまで落ちなくても良いようなヤツが欲しいンだけど、
Windowsでは用意されてない気がするんだ。
それって、正しいのかな?

545:デフォルトの名無しさん
06/06/25 03:29:24
2つのスレッドだけでいいのならクリティカルセクションでも同期は取れる。

最初にどちらかのスレッドが所有権を保持するようにする。
片方のスレッドはEnter.....()で所有権が解放されるまで待機。
所有権を持っていたスレッドが所有権を解放すれば片方のスレッドは
実行が開始されるようになる。

高速性が大事でかつ簡易な同期処理でいいならこんな方法もある。

関数自作するとか。排他制御ができれば後は自分でいろいろできる。

546:デフォルトの名無しさん
06/06/25 06:33:19
Fiberでも使ってみたら？
NT以降専用だが。

547:デフォルトの名無しさん
06/06/25 07:21:53
以前も微妙に話題になったが、MeteredSectionとか、
AdvancedWindowsのOptExとかで楽しちゃうってのもある。

MeteredSection
URLﾘﾝｸ(msdn.microsoft.com)

OpｔEx
URLﾘﾝｸ(www.microsoft.com)

548:539
06/06/26 17:26:10
>>545
>>546
>>547
とりあえず、情報どうも。Fiberだと排他・同期というより切替に近いので、同期にはならない気がする。

問題は、CriticalSection系は、同一スレッド上では同期しないので、>>545さんの方法、OptExはちょっと難しい感じ。
つーか、それだとどちらか片方の処理が重いときにバグになっちまう。

ということで、MeterdSectionを使うのが良いのかなぁ。でも、こいつ、CriticalSectionの拡張版みたいなもんみたいだから、
排他は出来るけど、同期は難しそう。
探したら日本語のページがあったので貼り付け。
URLﾘﾝｸ(www.microsoft.com)

それとも、原始的にロックファイル作るか…うーん、100近いスレッドが立ったとき考えるとやりたくないな…。
とりあえず、Mutexあたりを、最初にまとめて作成することで負担を減らすしかなさそうな感じ。
みなさん、ありがとう。
では。

549:デフォルトの名無しさん
06/06/27 21:28:46
>>548
具体的にどんな処理がしたいの？
単一プロセス内ならCriticalSection で何でも作れるよ
（だからこそOSもCriticalSectionしか提供してないわけで）。

あと「同一スレッド上では同期しないので」ってのはどういうことを
意図してるのかちょっとわからない・・・同一スレッドで非同期に
コードが実行されるのは Unix の signal のケースくらいで、
Windows のユーザモードでは起きないんじゃない？

550:デフォルトの名無しさん
06/06/27 22:11:04
>>549
ありゃ、そういう答えが返ってくると言うことは、
もしかしてオレのCriticalSectionについて根本的な使い方や理解が間違ってるのかな…。

スレッドひとつしか無ければ、EnterCritical...をいくつ並べても無視されると思ってたんだけど、違うのかな…。

551:デフォルトの名無しさん
06/06/27 22:13:57
スレッドひとつならマルチスレッドじゃないからな

552:デフォルトの名無しさん
06/06/27 22:21:17
そんなにパフォーマンス気にしてるのに
何でロックファイルとかにいくんだ…

553:デフォルトの名無しさん
06/06/27 22:39:45
英語でプログラミング勉強スレ

ｽﾚﾘﾝｸ(english板)l50

554:539
06/06/27 22:53:13
>>551
でも、プログラムは大抵、ひとつのスレッドから開始されるんだよ。最初からふたつってわけじゃない。
まあ、だから、>>545 は使えないんだよな。

555:デフォルトの名無しさん
06/06/27 23:12:31
なにか、壮大な勘違いをしている予感

556:デフォルトの名無しさん
06/06/28 01:48:11
まず、「同期する」をどういう意味で使っているのか説明してもらってからだな

557:デフォルトの名無しさん
06/06/28 01:56:37
同期の人と一緒に仕事をする
同期するじゃね？

558:デフォルトの名無しさん
06/06/28 03:31:41
>>539
そういうのは、ふつーにeventだの何だのをでも使ってみて、重くてやってらんなくなってから考えれば良い。

559:539
06/06/28 14:26:16
>>558
なんだそりゃ。そう言う回答は勘弁して欲しいぞ。

560:デフォルトの名無しさん
06/06/28 16:09:22
なんで>>539は質問してる身分でやたらと偉そうなの？
リアルでもそういう質問の仕方しか出来ない人？

561:デフォルトの名無しさん
06/06/28 16:16:15
>>559
「回答」ではないだろう。
「重そう」と思うだけで実際にやってみることもせず
そのくせ「ロックファイル」なんて単語まで飛び出し
結局何がしたいのか、「同期」が何を指しているのかも
説明してくれない君への
アドバイスじゃまいか。

562:デフォルトの名無しさん
06/06/28 16:45:09
おまえら馬鹿なんじゃね?

563:デフォルトの名無しさん
06/06/28 16:54:40
>>560-561
ウザ

564:デフォルトの名無しさん
06/06/28 17:45:49
つーか、時々デッドロックするようなプログラムしか作ってないのかょ、おまえらは。

565:デフォルトの名無しさん
06/06/28 17:46:52
なにか、壮大な勘違いをしている予感

566:デフォルトの名無しさん
06/06/28 18:17:22
なにかが気に喰わなくて暴れ始めたお母ん

567:デフォルトの名無しさん
06/06/28 18:54:40
予感でプログラムが組めるヤツはニュータイプ。

568:デフォルトの名無しさん
06/06/28 21:21:38
まてまて。
>>539 はWindows のカーネルやAPIを設計した人たちや
普段からマルチスレッドAPなんかさんざ書いてる漏れも
見落としている、何か難しい問題に対処しようとしてるんだよ。

それはたぶんロックファイルと関係のあるなにかなんだろう。
漏れには想像もできないが、頭ごなしに否定しないでだまって
観察してあげるべきじゃないか？

569:デフォルトの名無しさん
06/06/28 22:34:06
なにか、壮大な勘違いをしている予感

570:asdlman
06/06/28 22:40:26
>>569
>>555
lead reth !!!

次ページ