pthread地獄 part 2 (232ﾚｽ)
pthread地獄 part 2 http://mevius.5ch.net/test/read.cgi/unix/1166620307/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
1: 名無しさん＠お腹いっぱい。 [sage] 2006/12/20(水) 22:11:47 Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。 徳の高い人はpthread天国でも可。 ■前スレ pthread地獄 http://pc8.2ch.net/test/read.cgi/unix/1010933537/ http://mevius.5ch.net/test/read.cgi/unix/1166620307/1
2: 名無しさん＠お腹いっぱい。 [] 2006/12/20(水) 22:22:58 2GET http://mevius.5ch.net/test/read.cgi/unix/1166620307/2
3: 名無しさん＠お腹いっぱい。 [sage] 2006/12/21(木) 18:16:54 4さま http://mevius.5ch.net/test/read.cgi/unix/1166620307/3
4: 名無しさん＠お腹いっぱい。 [sage] 2006/12/21(木) 18:21:11 次スレいらんって言ってたのに……。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/4
5: 名無しさん＠お腹いっぱい。 [sage] 2006/12/21(木) 19:21:20 並列プログラミング一般にしてしまえ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/5
6: 名無しさん＠お腹いっぱい。 [sage] 2006/12/21(木) 21:37:07 マルチスレッドと並列は同じじゃないべさ http://mevius.5ch.net/test/read.cgi/unix/1166620307/6
7: 名無しさん＠お腹いっぱい。 [] 2006/12/21(木) 23:19:52 並行プログラミング http://mevius.5ch.net/test/read.cgi/unix/1166620307/7
8: 名無しさん＠お腹いっぱい。 [] 2006/12/22(金) 21:08:24 段違い並行プログラミング http://mevius.5ch.net/test/read.cgi/unix/1166620307/8
9: 名無しさん＠お腹いっぱい。 [sage] 2006/12/22(金) 21:12:47 リンダ・リンダ・プログラミング http://mevius.5ch.net/test/read.cgi/unix/1166620307/9
10: 名無しさん＠お腹いっぱい。 [sage] 2006/12/24(日) 11:14:52 どぶねーずみ、みたいに http://mevius.5ch.net/test/read.cgi/unix/1166620307/10
11: 名無しさん＠お腹いっぱい。 [sage] 2006/12/24(日) 13:50:16 (´▽｀) (σσ ヘイ！ Let's プログラミング！ < < http://mevius.5ch.net/test/read.cgi/unix/1166620307/11
12: 11 [sage] 2006/12/24(日) 13:58:16 よし。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/12
13: 名無しさん＠お腹いっぱい。 [] 2006/12/24(日) 15:36:30 pthreadってもう廃れるんですかね。ってか廃れてるんですかね http://mevius.5ch.net/test/read.cgi/unix/1166620307/13
14: 名無しさん＠お腹いっぱい。 [sage] 2006/12/26(火) 18:58:53 枯れるではなく廃れてるってこと？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/14
15: 名無しさん＠お腹いっぱい。 [sage] 2006/12/31(日) 02:22:07 Boost::threadってUNIX系ではpthread使ってなかったっけ？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/15
16: 名無しさん＠お腹いっぱい。 [sage] 2006/12/31(日) 15:07:00 UNIXといってもいまやいろいろあるし・・・犬糞とか 商用と非商用に分けて語ろうぜ http://mevius.5ch.net/test/read.cgi/unix/1166620307/16
17: 名無しさん＠お腹いっぱい。 [sage] 2007/01/23(火) 00:54:40 未だに Windows で pthread_kill() をどうやっていいのかわかんない。 って、Windows では使えないんだったけ…。 なんかそれも混乱してわかんなくなってきた…。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/17
18: 名無しさん＠お腹いっぱい。 [sage] 2007/01/23(火) 10:18:44 POSIX Parallel Programming, Part 3: Threads ttp://www.informit.com/articles/article.asp?p=686610&rl=1 http://mevius.5ch.net/test/read.cgi/unix/1166620307/18
19: 名無しさん＠お腹いっぱい。 [sage] 2007/03/16(金) 23:19:10 OpenMPな人は何処へ行けばいいのかしらん。。。 せっかくDual Core や Quad Coreが個人でも利用できる時代になったのにい。。。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/19
20: 名無しさん＠お腹いっぱい。 [sage] 2007/03/16(金) 23:45:41 ム板池 http://mevius.5ch.net/test/read.cgi/unix/1166620307/20
21: 名無しさん＠お腹いっぱい。 [sage] 2007/05/14(月) 00:15:07 http://lists.freebsd.org/pipermail/cvs-src/2007-May/078202.html > Change the default thread library to libthr. FreeBSDのデフォルトスレッドライブラリも1:1のものに変更されました。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/21
22: 名無しさん＠お腹いっぱい。 [sage] 2007/05/14(月) 07:21:14 >>21 n:mはつかえないということなの？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/22
23: 名無しさん＠お腹いっぱい。 [sage] 2007/05/15(火) 00:00:56 >>22 今までのM:Nスレッドライブラリはlibkseという名前で残っているから シンボリックリンクを張り替えるなどすればいい。 libkseは少なくとも7.x系までは生き残るだろうけど、 8-currentあたりで消されそうな気もする。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/23
24: 名無しさん＠お腹いっぱい。 [sage] 2007/05/15(火) 10:04:12 libmap.conf じゃ駄目なのか? http://mevius.5ch.net/test/read.cgi/unix/1166620307/24
25: 名無しさん＠お腹いっぱい。 [sage] 2007/05/16(水) 07:27:30 つかえないというのは いいところなしというつもりでした。 複雑な制御の割に性能が出ないのでしょうか。 Solarisも1:1になったし。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/25
26: 名無しさん＠お腹いっぱい。 [sage] 2007/05/16(水) 07:42:38 前スレで擁護してた奴の言い訳が聞きたいところだが… http://mevius.5ch.net/test/read.cgi/unix/1166620307/26
27: 名無しさん＠お腹いっぱい。 [sage] 2007/05/22(火) 08:02:39 javaみたいにスレッドをCPU数に関係なくたくさんつくるやつの性能も1:1で満足できるのか知りたい。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/27
28: 名無しさん＠お腹いっぱい。 [sage] 2007/06/10(日) 00:00:13 言い訳よりも、ベンチの結果とかが欲しいね。 Apache (worker) + DB とかの。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/28
29: 名無しさん＠お腹いっぱい。 [sage] 2007/06/11(月) 15:38:16 SunStudio11や12もいいよ。 何せ無償だし。OpenMPもあるでよ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/29
30: 名無しさん＠お腹いっぱい。 [sage] 2008/03/13(木) 00:37:42 Remove kernel support for M:N threading. http://lists.freebsd.org/pipermail/cvs-src/2008-March/088489.html http://mevius.5ch.net/test/read.cgi/unix/1166620307/30
31: 名無しさん＠お腹いっぱい。 [!sage] 2008/03/13(木) 10:41:17 このスレ忘れてた… http://mevius.5ch.net/test/read.cgi/unix/1166620307/31
32: 名無しさん＠お腹いっぱい。 [sage] 2008/03/13(木) 16:53:54 いまやpthreadを生で使うことはほとんどないからなぁ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/32
33: 名無しさん＠お腹いっぱい。 [sage] 2008/03/18(火) 11:07:37 純粋に興味があるんだけどpthread以外って何使ってる? http://mevius.5ch.net/test/read.cgi/unix/1166620307/33
34: 名無しさん＠お腹いっぱい。 [sage] 2008/03/18(火) 22:18:18 javaのスレッド 最近はjava.util.concurrentがあるからね。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/34
35: 名無しさん＠お腹いっぱい。 [sage] 2008/03/19(水) 18:46:40 >>34 1.5の時はメモリリークに悩まされました>concurrent周り http://mevius.5ch.net/test/read.cgi/unix/1166620307/35
36: 名無しさん＠お腹いっぱい。 [] 2008/06/06(金) 15:37:18 mutexを使って資源の共有ではなく、単にスレッド間の同期を取りたいのですが、 デッドロックしないようにするにはどのように書けばよいのでしょうか？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/36
37: 名無しさん＠お腹いっぱい。 [sage] 2008/06/06(金) 15:46:12 pthread_barrier_waitがあるのにmutexが使いたいと申すか http://mevius.5ch.net/test/read.cgi/unix/1166620307/37
38: 名無しさん＠お腹いっぱい。 [sage] 2008/06/09(月) 15:07:17 たくさんのthreadをpthread_create()で作成する場合、 作成した子スレッドへの引数ってどうやって渡せば良いんでしょうか？ for (narg = 0; narg < 100; ++narg) { nrc = pthread_create(&t1, NULL, tfunc, (void *)&narg); } こんな感じで渡そうとしたんですが、作成された子スレッド(tfunc)側で 引数を使おうとすると、親スレッド側でどんどん値がインクリメントされて いってしまいます。(並列に動いてるんだから当然なんでしょうけど。) http://mevius.5ch.net/test/read.cgi/unix/1166620307/38
39: 名無しさん＠お腹いっぱい。 [sage] 2008/06/09(月) 15:34:40 値そのものをパラメータとして(void *)にキャストして渡す、 もしくはスレッド数分の配列に格納してその要素へのポインタを渡す。 というか、あなたはまだマルチスレッドプログラミングに手を出すのは早い。 そんなんではデバッグも満足にできないから、 基礎をしっかりやってからの方が近道。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/39
40: 38 [sage] 2008/06/09(月) 16:06:42 >>39 レスTHX >もしくはスレッド数分の配列に格納してその要素へのポインタを渡す。 やってみたら、ちゃんと渡りました。 この時に確保しておくスレッド数分の配列って、ヒープにとるもの？ それとも、親スレッド側のスタックにとるもの？ それとも、グローバル変数もしくはスタティック変数としてとるもの？ それとも、ケースバイケース？ 子スレッド実行中にそのエリア(子スレッド用の引数エリア)が開放 されなければ良いと思うんだけど、親スレッド側のスタックにとった 場合ってどうなるんでしょうか？ 親スレッドは子スレッドがすべて終了するまで存在するとした場合、 親スレッド側のスタックにとったエリアを子スレッドへの引数エリアと して使用するのはOKでしょうか？ >基礎をしっかりやってからの方が近道。 今が基礎のつもりです。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/40
41: 名無しさん＠お腹いっぱい。 [sage] 2008/06/09(月) 22:05:04 このスレのタイトルは上手く考えられているな。 pthread_createでスレッドに渡す引数の渡し方を人に聞くというのは、 地獄に入口から一歩入ったところで、番犬ケルベロスに向かって 「この先にお弁当屋さんはありますか?」と聞いているような、不思議な感じが醸し出される。 >>40 実際のメモリマップを想像すれば、答えは自ずとわかる。 MTは単一のプロセス空間内でPCとスタックを複数切り替えるだけで、マジックはない。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/41
42: 名無しさん＠お腹いっぱい。 [sage] 2008/06/10(火) 12:24:05 void*に入るなら、キャストして渡した方が後のこと考えないで良いから楽ちん。 親のスタックに取ったら、その寿命考えないといけないから面倒。 個別にヒープにとってアドレス渡して、その領域の後片付けも子スレッドがすれば良いんじゃない。 場合によっては、1スレッドに必要な領域*スレッド数をまとめて取って、 子スレッドがすべて終了したら、親がまとめて捨てても良いと思うけど。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/42
43: 名無しさん＠お腹いっぱい。 [sage] 2008/06/11(水) 02:48:23 pthreadsなんで単純なsleep/wakeupインターフェースないのん? http://mevius.5ch.net/test/read.cgi/unix/1166620307/43
44: 名無しさん＠お腹いっぱい。 [sage] 2008/06/11(水) 23:36:23 >>43 mutexを直前まで持ったままsleepできないとwakeupの取りこぼしがおこるから。 基礎から勉強しなおしてね http://mevius.5ch.net/test/read.cgi/unix/1166620307/44
45: サカムラ・アントワネット [sage] 2008/06/12(木) 02:15:33 とりこぼしちゃまずいなら、μITRONのwup_tskみたいにキューイングすればいいじゃない http://mevius.5ch.net/test/read.cgi/unix/1166620307/45
46: 名無しさん＠お腹いっぱい。 [sage] 2008/06/12(木) 11:27:18 それ何てセマフォ？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/46
47: 名無しさん＠お腹いっぱい。 [sage] 2008/06/13(金) 08:46:34 キャンセルができるみたい。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/47
48: 名無しさん＠お腹いっぱい。 [sage] 2008/06/17(火) 10:56:17 マルチスレッドプログラミングに関する書籍で良書と言われている ものってどんなものがあるんでしょうか？ この本は良いよってのがあれば紹介して頂けると嬉しいです。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/48
49: 名無しさん＠お腹いっぱい。 [sage] 2008/06/18(水) 15:55:48 Patterns for Parallel Programming http://mevius.5ch.net/test/read.cgi/unix/1166620307/49
50: 名無しさん＠お腹いっぱい。 [sage] 2008/06/19(木) 13:50:07 CSPモデルの理論 http://mevius.5ch.net/test/read.cgi/unix/1166620307/50
51: 名無しさん＠お腹いっぱい。 [sage] 2008/06/19(木) 15:27:45 javaだけど Java並行処理プログラミング Doug Leaも書いてる http://mevius.5ch.net/test/read.cgi/unix/1166620307/51
52: 名無しさん＠お腹いっぱい。 [sage] 2008/07/09(水) 22:12:50 外部のカウンタ変数をひとつ用意して、 複数のスレッドで、それをインクリメントするだけのときも mutex使った方がいいのでしょうか。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/52
53: 名無しさん＠お腹いっぱい。 [sage] 2008/07/09(水) 23:01:05 extern int i; foo() { ... i++; /* is it atomic? *? ... } が atomic operation かどうかは処理系による。 ++/-- だけなら mutex よりも semaphore の方がいい気がする。 cf. sem_init(3) http://mevius.5ch.net/test/read.cgi/unix/1166620307/53
54: 名無しさん＠お腹いっぱい。 [sage] 2008/07/10(木) 00:29:47 >>52 IA32ですら、その手のことをアセンブリ言語レベルで正しく実装する場合に LOCKプレフィクス付きでインクリメントしなきゃならなかったりする。 何らかの排他制御は必要。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/54
55: 名無しさん＠お腹いっぱい。 [sage] 2008/07/10(木) 01:52:53 volatileで十分ｗ http://mevius.5ch.net/test/read.cgi/unix/1166620307/55
56: 名無しさん＠お腹いっぱい。 [sage] 2008/07/10(木) 12:09:34 インクリメントするのが一人なら確かに十分。 mutexはまあ確実だけど、性能の要求によってはspinとかrwlockとか。 semaphoreは、規定回数処理するっていうならいいけど、 回数が分からない場合どうするの？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/56
57: 名無しさん＠お腹いっぱい。 [sage] 2008/07/11(金) 10:19:44 冗談なのか何なのか知らないがインクリメント対象に volatile なんて付けたら read-modify-write なコードになると思うんだが。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/57
58: 名無しさん＠お腹いっぱい。 [sage] 2008/07/11(金) 23:36:36 cond_timedwaitがシステム時刻を要求するのは問題があると思うけど、 少なくとも日本語ではそういう情報が見当たらない。 wait中にシステム時刻が変更されたらどうなるんだろう。 どう考えてもSUNのcond_reltimedwait_npみたいなのが標準化されるべきだと 思うけど、そういう動きはないんだろうか。 標準のtimedwaitでどうエミュレーションしてもバグの潰し様が無いはず。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/58
59: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 01:40:32 相対値はそれはそれでまずいんだよ。 標準はなんも考えずにシステムクロックを採用してるわけじゃなくて、 あれはあれでちゃんと角度とか考えられてるんだ。 http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html のRATIONALE読んでね。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/59
60: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 05:25:18 読んだ。 >a relative time measure can be easily implemented on top of a function that specifies absolute time ダウト。任意のタイミングによるシステム時刻変更を考えれば これが実装できないから問題にしている。 現在時刻取得 -> timespec変数にタイムアウト値加算 -> timedwait()に渡す -> wait中 全ての過程で競合が発生するだろ？ 時間が進むことでタイムアウトが早く発生するのはまあ、対処できる。 (無駄にコードが複雑になるけど。) しかし、時間が巻き戻ると、タイムアウトの発生が遅れてしまう。 制御が戻らないことには何もできない。 異常時に即座に実行しないといけない処理が遅れてしまう。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/60
61: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 05:26:02 さらに、逆のパターンの実装は競合が発生するという主張について、 > clock_gettime(CLOCK_REALTIME, &now) > reltime = sleep_til_this_absolute_time -now; > cond_relative_timed_wait(c, m, &reltime); > If the thread is preempted between the first statement > and the last statement, the thread blocks for too long. Blocking, > however, is irrelevant if an absolute timeout is used. これもよく分からん。 このコードの間のプリエンプトが問題になるハードリアルタイムシステムなら リアルタイムOS使わないと無理じゃないの？ まあ、絶対時刻指定のAPIが要らないとまでは云わない。 > An absolute timeout also need not be > recomputed if it is used multiple times in a loop これもダメ、システム時刻の変更があり得る状況では、 システム時刻によって、ある時点から何秒経過したか知ることはできない。 タイムアウト内で、条件成立前にシグナルされる可能性がある場合、 俺の場合は、仕事ではWindowsなので、GetTickCount()を使い、 システム起動からの経過時間を元に次のタイムアウト指定値を求める。 Unixならプロセスの使用時間を取得できるAPIがあったはず。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/61
62: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 12:20:38 > 時間が巻き戻ると そんな運用しないのが前提じゃないのか。 普通は進み方を遅らせて徐々に合わせるか、一気に合わせるなら シングルユーザモードもしくは他にそのへんに敏感なプロセスが 動いていないときにするものだと思うが。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/62
63: 52 [sage] 2008/07/12(土) 12:26:43 返事が遅れました。 やはり何らかの制御が必要ということですね。 みなさん、ありがとうございました。 もっと勉強してきます。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/63
64: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 13:38:59 >>62 そういう常識？が通用する業界もあるんだ。 言いたいことはわかるけど、pthreadなんぞ知ったこっちゃない オペレータやユーザにそんな制限かけられないことが多いのでは？ 全然別のこと担当してる同じマシン上のプログラムに制限かけたり こっちから監視したりとかも無理な相談だなあ。 これがもしも、普通の個人がPCで使うソフトなら、 どのプログラムがpthread使ってるとか関係なく、 好きなときに時刻の調整くらいするよね？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/64
65: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 13:47:45 >>61 お前みたいな奴が、cond_relative_timedwait()で1秒って指定したのに 1.1秒で復帰してきた!クソが!って怒るから絶対時刻にしたんだよ。 pthreadsの待ちの時間の正確性なんて信頼できないんだから、この点について 議論してもあまり意味ないと思う。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/65
66: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 15:53:32 >>65 信頼できない、のレベルによるな。 俺の仕事では1秒以下のズレは全然許容できるレベルだな。 それ以下はリアルタイムOS使う世界だと思う。よく知らんけど。 タイムアウト1秒に指定しても、制御戻るのは1分後かも･･･なんてのは全く話にならない。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/66
67: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 16:52:10 >>64 だから、通常の運用だと ntp がゆっくり時間補正するようになっている。 >>62 の後半は例外的な運用だろ。 # 知識, 理解力, 謙虚な心 の全てが欠如してると今後辛いぞ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/67
68: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 18:13:59 そりゃ、運用や通信プロトコルまで口出しできりゃ、なんでもできる。 あんまり具体的な例挙げても仕方ない気がするが、 半導体業界の某標準プロトコルで、工場のホストから受け取った時刻に 工場内の装置(OSは普通Windows)が問答無用で同期することは普通に行われている。 Linuxに移行したいとか軽率に言い出されるとやばいと思う。 時刻なんて人間に表示するためのもので 制御プログラムとかが依存していいもんじゃないと思うんだが。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/68
69: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 22:25:13 >>68はまるで自分の業界がスタンダードで世界中がそれを基準にすべきと いわん勢いだけど、それが根本的に噛み合ってないといいかげんに気付いたらどうよ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/69
70: 名無しさん＠お腹いっぱい。 [sage] 2008/07/12(土) 23:03:27 >>68 そう言う特殊な要件があるなら、それに合うように作ればいいだけ。 ホストの時刻に影響されたくなければ、システム時刻とホストから受け取った 時刻を別々に管理するとか、やりようはいくらでもあるだろ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/70
71: 名無しさん＠お腹いっぱい。 [] 2008/07/12(土) 23:41:27 俺のためにみんなが喧嘩するのはもうたくさんだ http://mevius.5ch.net/test/read.cgi/unix/1166620307/71
72: 名無しさん＠お腹いっぱい。 [sage] 2008/07/13(日) 01:28:38 >>68 なんだ、ただのシッタカだったのか、お前。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/72
73: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 12:27:38 > 半導体業界の某標準プロトコルで、工場のホストから受け取った時刻に > 工場内の装置(OSは普通Windows)が問答無用で同期することは普通に行われている。 自分で書いているように、それはパソコン系の「普通」であって、 UNIX界隈の人間がその種の運用をすることは100%有り得ないから、 時刻が急に巻き戻ってタイムアウトまで1秒のはずが61秒かかっちゃったりする心配を あなたがする必要はない。 もしプロトコル上、工場のホストと同期する必要があれば、 システムクロックを変更するのではなく、 アプリケーションの実装でシステムクロックとリモートホストのクロックの差を管理する。 このようにUNIX系へ移行するとしてもちゃんと問題なく出来るから、 あなたは心配しなくてよい。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/73
74: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 12:45:33 POSIXがatomic increment/decrementをAPIとして規定しなかったのはなぜ? mutexがあっても軽量なカウンタが不要になることはないわけで、 結局、みな独自に実装しているのだが。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/74
75: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 13:53:53 ここで聞かずpthreadsのインタフェースを決めた人に聞いてください。 そういうAPIが必須ならプラットフォームを変えることを検討してください。 どうしてもpthreadsに必要ならpthreadsを変えるべく努力してください。 それもいやなら文句言わず今使えるもので実装しなさい。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/75
76: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 14:56:12 知らないと一言書けば済むことをなぜ4行にも渡って http://mevius.5ch.net/test/read.cgi/unix/1166620307/76
77: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 22:08:16 > アプリケーションの実装でシステムクロックとリモートホストのクロックの差を管理する。 俺が知りたいのは、特定の仕様のシステムを実現する方法じゃなくて、 他のプログラムが何していようが、 ユーザが好き勝手に時刻を変更しようが、 現在からN秒以内に条件が成立しなければ、アウトという監視は本当にできないのかってこと。 Pthread標準の枠内で。 時刻をいじってるプログラムと密に連携したり同期とれるとか、 そんなこと当てにできないし、したくもない。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/77
78: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 23:00:10 ああ、わかった。 要は、pthread の仕様バグを見つけた俺を誉めてくれと言うことね。 「お前は、偉いよ。」 これで十分だろ、もう出てくるな。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/78
79: 名無しさん＠お腹いっぱい。 [sage] 2008/07/14(月) 23:55:03 だいたいUnixで「ユーザ」が時刻を好き勝手にいじれるわけねーだろ。 そういう権限を生身の人間に与えちゃってるとしたらその時点で頭おかしい。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/79
80: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 00:26:26 > そういう権限を生身の人間に与えちゃってるとしたらその時点で頭おかしい。 ちょっ、お前ン所のサーバー管理者はロボットかよ !! http://mevius.5ch.net/test/read.cgi/unix/1166620307/80
81: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 00:55:01 サーバ管理者が時刻を好き勝手にいじるような頭の沸いたサイトはどうにもできねーよ。pthread以前の問題。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/81
82: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 01:49:43 >>74 POSIXで規定されなかった理由は知らんが、 C++0xではちゃんと Atomic operation や Memory barrier が 定義されるから安心しろ。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/82
83: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 09:21:07 ちなみにWin32のWaitForMultipleObjectsは相対時間指定なので >>59の"Timed Wait Semantics"に挙げられた問題が存在する。 >>61をみると理解できていないようなので、何が問題なのかわかるまで考えた方がよいだろう。 プロセスのプリエンプション自体が問題なのではないので、絶対指定のPOSIXにはこの問題はない。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/83
84: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 09:25:58 >>82 Cで頼む http://mevius.5ch.net/test/read.cgi/unix/1166620307/84
85: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 12:11:40 Cに入れるようなもんじゃないだろう。 pthread_xxx_npあたりでいいよ。 CASとかもセットで。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/85
86: 名無しさん＠お腹いっぱい。 [sage] 2008/07/15(火) 15:46:11 >>85 pthread_xxx_npあたりで頼む http://mevius.5ch.net/test/read.cgi/unix/1166620307/86
87: 名無しさん＠お腹いっぱい。 [sage] 2008/07/18(金) 10:56:20 Solaris10なんだけど、マルチスレッドのプロセスからコールされる サブルーチンをコンパイルする時って、どんなコンパイルオプションを 付ければ良いんですか？ 普通に、コンパイルして共有ライブラリを作ればよい？ このサブルーチンの中では、pthread_XXXはコールしていないので、 #include <pthread.h> もしてないんですがこれってダメ？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/87
88: 87 [sage] 2008/07/18(金) 10:59:53 ちなみに、そのサブルーチンは複数のスレッドから同時に呼ばれても 大丈夫な様に作ってあります。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/88
89: 名無しさん＠お腹いっぱい。 [sage] 2008/07/18(金) 14:33:31 なにもいらないと思うけど。 引数だけで計算して値を返すとか、完全に状態に依存しないものならね。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/89
90: 名無しさん＠お腹いっぱい。 [sage] 2008/07/18(金) 15:12:22 Sun cc使ってる場合は-mtが必要になったりする。 http://docs.sun.com/app/docs/doc/819-0390/compile-94179?a=view これは-D_REENTRANT -lthreadと等価なようだ。 gccであっても、使っているライブラリによっては、同様に何らかのシンボル定義が 必要になるかもしれない。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/90
91: 名無しさん＠お腹いっぱい。 [sage] 2008/07/19(土) 11:43:35 int f(int a, int b) { return a + b; } でも？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/91
92: 名無しさん＠お腹いっぱい。 [sage] 2008/07/19(土) 15:22:04 gcc風に言えば__attribute_((const))な関数なら特別なコンパイラフラグは不要。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/92
93: 名無しさん＠お腹いっぱい。 [sage] 2008/07/22(火) 12:01:15 複数のスレッドの終了を待つってどう書くんですか？ マルチプロセスだと、waitpid(2)とかで複数の子プロセスの終了を 待てるんですが、pthread_join()だと、特定のスレッドの終了しか待てません。 例えば、 １００個の子プロセスを作成して、親プロセスはwaitpid()で任意の子プロセスの終了を 監視していて、特定の子プロセスが死んだ場合に、そのプロセスの再起動(fork())を 行うという処理を、pthreadで書こうとした場合、どうすれば良いんでしょうか？ そもそも、上記の様な考え方は、プロセスの親子関係が前提となっているので、 この考え方を、親子という関係のないpthreadに持って来る事がおかしいのでしょうか？ http://mevius.5ch.net/test/read.cgi/unix/1166620307/93
94: 名無しさん＠お腹いっぱい。 [sage] 2008/07/22(火) 12:38:18 死ぬとき親に何か通知したら？ 勝手に死ぬなら、たまにpthread_kill(thread_id, 0)するとか。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/94
95: 93 [sage] 2008/07/22(火) 13:21:54 それだと、作成したスレッドが死ぬようなイベントが発生したタイミングを 捕まえるという動作ではないですよね。(ポーリングっぽい) 例えば、１００個スレッドを作って、その各スレッドがTCPソケットを使って 通信していて、TCPコネクションがcloseされたので、pthread_exit()を コールしたとか、、ソケットから受け取ったデータを処理している最中に SIGSEGVで死んだとかした場合に、これら１００個のスレッドを常に監視 していて、死んだスレッドを再度作成したいって感じの処理をすっきりと 書きたい場合ってどうやるんでしょう？ スレッドじゃなくてプロセスだったら、子プロセスがexit(2)した場合も、 子プロセスが、SIGSEGVで死んだ場合も、親プロセスがwaitpid(2)してれば 子プロセスが死んだタイミングで親プロセスはそれを知ることが出来るじゃ ないですか。 これと同じような事をpthreadでやりたいんですが、なんかよく判らんのです。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/95
96: 名無しさん＠お腹いっぱい。 [sage] 2008/07/22(火) 14:09:26 SIGSEGVなどで「死ぬ」場合はプロセスごと道連れなので、pthreads的な対処は 無意味では？ そう考えていくと、スレッドが自発的に終了するケースだけを扱えばいいわけなので、 (スレッドプール的な構成なら)条件変数での通知・待機を使えばよさそうに思う。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/96
97: 名無しさん＠お腹いっぱい。 [sage] 2008/07/22(火) 14:17:14 そう。プロセスと異なり、スレッドは勝手に死んだりしない。だから終了を監視する 必要もない。個々のスレッドは処理が終わったら終了するのではなく、次の処理要求 を待って休眠するように書く方がよいだろう。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/97
98: 93 [sage] 2008/07/22(火) 14:58:19 >>96 >>97 確かに、SIGSEGVなどで死ぬ場合は、SIGSEGVを発生させたロジックを実行中のスレッド のみが死ぬわけではなく、プロセス自体がいなくなりますが、これをハンドリングして 特定のスレッドのみを再起動して処理を継続するってのは変でしょうか？ プログラムのバグも含めて考えると、やっぱりスレッドがSIGSEGVするケースも考慮して おきたんです。 Webサーバの様なプログラムをマルチスレッドで書くとすると、クライアントから送られて来た データがメタメタでサーバ側の処理がSIGSEGVしてしまったとか。(だったらちゃんとデータを 処理する前にチェックしろってのは、ちょっと置いといて。) こういったケースで正常なクライアントとのコネクションも全部潰れてしまうのは、なんだかなぁ って思ったんです。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/98
99: 93 [sage] 2008/07/22(火) 15:06:19 あと、条件変数でスレッド間で待ち合わせを行うってのはなんとなく判るんですが、 それと、スレッドの終了を待つってのがどうもうまく結び付きません。 例えば、 ワーカースレッドがもうダメポってpthread_cond_signal()をコール。 メインスレッドは、pthread_cond_wait()で待ってる。 ワーカースレッドはどのタイミングでpthread_exit()をコールすればいいの？ メインスレッドは、どのタイミングでpthread_join()をコールすればいいの？ ワーカースレッドが居なくなったタイミングって条件件数を使えばメインスレッドで 捕まえることって出来ますか？ なんか、この辺りがよく判らんのです。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/99
100: 名無しさん＠お腹いっぱい。 [sage] 2008/07/22(火) 15:24:43 不正なポインタが使用されないよう入力の厳密なチェックを追加するか、普通 にプロセスで書くのをお薦めする。Apacheでも普通に使われているのを見れば わかるように、UNIXのプロセスはそれほど遅くない。 どうしてもpthreadで書きつつsignalが捕捉したいのなら止めないが、 "pthread地獄"のスレタイは伊達や酔狂ではないので。 http://mevius.5ch.net/test/read.cgi/unix/1166620307/100
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 132 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.033s