pthread地獄 part 2

1 ：06/12/20 〜 最終レス ：11/12/17

Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。
■前スレ
　pthread地獄
　http://pc8.2ch.net/test/read.cgi/unix/1010933537/

2 ：

2GET

3 ：

4さま

4 ：

次スレいらんって言ってたのに……。

5 ：

並列プログラミング一般にしてしまえ。

6 ：

マルチスレッドと並列は同じじゃないべさ

7 ：

並行プログラミング

8 ：

段違い並行プログラミング

9 ：

リンダ・リンダ・プログラミング

10 ：

どぶねーずみ、みたいに

11 ：

(´▽｀)
(σσ ヘイ！ Let's プログラミング！
< <

12 ：

よし。

13 ：

pthreadってもう廃れるんですかね。ってか廃れてるんですかね

14 ：

枯れるではなく廃れてるってこと？

15 ：

Boost::threadってUNIX系ではpthread使ってなかったっけ？

16 ：

UNIXといってもいまやいろいろあるし・・・犬糞とか
商用と非商用に分けて語ろうぜ

17 ：

未だに Windows で pthread_kill() をどうやっていいのかわかんない。
って、Windows では使えないんだったけ…。
なんかそれも混乱してわかんなくなってきた…。

18 ：

POSIX Parallel Programming, Part 3: Threads
ttp://www.informit.com/articles/article.asp?p=686610&rl=1

19 ：

OpenMPな人は何処へ行けばいいのかしらん。。。
せっかくDual Core や Quad Coreが個人でも利用できる時代になったのにい。。。

20 ：

ム板池

21 ：

http://lists.freebsd.org/pipermail/cvs-src/2007-May/078202.html
> Change the default thread library to libthr.
FreeBSDのデフォルトスレッドライブラリも1:1のものに変更されました。

22 ：

>>21
n:mはつかえないということなの？

23 ：

>>22
今までのM:Nスレッドライブラリはlibkseという名前で残っているから
シンボリックリンクを張り替えるなどすればいい。
libkseは少なくとも7.x系までは生き残るだろうけど、
8-currentあたりで消されそうな気もする。

24 ：

libmap.conf じゃ駄目なのか?

25 ：

つかえないというのは
いいところなしというつもりでした。
複雑な制御の割に性能が出ないのでしょうか。
Solarisも1:1になったし。

26 ：

前スレで擁護してた奴の言い訳が聞きたいところだが…

27 ：

javaみたいにスレッドをCPU数に関係なくたくさんつくるやつの性能も1:1で満足できるのか知りたい。

28 ：

言い訳よりも、ベンチの結果とかが欲しいね。
Apache (worker) + DB とかの。

29 ：

SunStudio11や12もいいよ。
何せ無償だし。OpenMPもあるでよ。

30 ：

Remove kernel support for M:N threading.
http://lists.freebsd.org/pipermail/cvs-src/2008-March/088489.html

31 ：

このスレ忘れてた…

32 ：

いまやpthreadを生で使うことはほとんどないからなぁ。

33 ：

純粋に興味があるんだけどpthread以外って何使ってる?

34 ：

javaのスレッド
最近はjava.util.concurrentがあるからね。

35 ：

>>34
1.5の時はメモリリークに悩まされました>concurrent周り

36 ：

mutexを使って資源の共有ではなく、単にスレッド間の同期を取りたいのですが、
デッドロックしないようにするにはどのように書けばよいのでしょうか？

37 ：

pthread_barrier_waitがあるのにmutexが使いたいと申すか

38 ：

たくさんのthreadをpthread_create()で作成する場合、
作成した子スレッドへの引数ってどうやって渡せば良いんでしょうか？
   for (narg = 0; narg < 100; ++narg) {
      nrc = pthread_create(&t1, NULL, tfunc, (void *)&narg);
   }
こんな感じで渡そうとしたんですが、作成された子スレッド(tfunc)側で
引数を使おうとすると、親スレッド側でどんどん値がインクリメントされて
いってしまいます。(並列に動いてるんだから当然なんでしょうけど。)

39 ：

値そのものをパラメータとして(void *)にキャストして渡す、
もしくはスレッド数分の配列に格納してその要素へのポインタを渡す。
というか、あなたはまだマルチスレッドプログラミングに手を出すのは早い。
そんなんではデバッグも満足にできないから、
基礎をしっかりやってからの方が近道。

40 ：

>>39
レスTHX
>もしくはスレッド数分の配列に格納してその要素へのポインタを渡す。
やってみたら、ちゃんと渡りました。
この時に確保しておくスレッド数分の配列って、ヒープにとるもの？
それとも、親スレッド側のスタックにとるもの？
それとも、グローバル変数もしくはスタティック変数としてとるもの？
それとも、ケースバイケース？
子スレッド実行中にそのエリア(子スレッド用の引数エリア)が開放
されなければ良いと思うんだけど、親スレッド側のスタックにとった
場合ってどうなるんでしょうか？
親スレッドは子スレッドがすべて終了するまで存在するとした場合、
親スレッド側のスタックにとったエリアを子スレッドへの引数エリアと
して使用するのはOKでしょうか？
>基礎をしっかりやってからの方が近道。
今が基礎のつもりです。

41 ：

このスレのタイトルは上手く考えられているな。
pthread_createでスレッドに渡す引数の渡し方を人に聞くというのは、
地獄に入口から一歩入ったところで、番犬ケルベロスに向かって
「この先にお弁当屋さんはありますか?」と聞いているような、不思議な感じが醸し出される。
>>40
実際のメモリマップを想像すれば、答えは自ずとわかる。
MTは単一のプロセス空間内でPCとスタックを複数切り替えるだけで、マジックはない。

42 ：

void*に入るなら、キャストして渡した方が後のこと考えないで良いから楽ちん。
親のスタックに取ったら、その寿命考えないといけないから面倒。
個別にヒープにとってアドレス渡して、その領域の後片付けも子スレッドがすれば良いんじゃない。
場合によっては、1スレッドに必要な領域*スレッド数をまとめて取って、
子スレッドがすべて終了したら、親がまとめて捨てても良いと思うけど。

43 ：

pthreadsなんで単純なsleep/wakeupインターフェースないのん?

44 ：

>>43
mutexを直前まで持ったままsleepできないとwakeupの取りこぼしがおこるから。
基礎から勉強しなおしてね

45 ：

とりこぼしちゃまずいなら、μITRONのwup_tskみたいにキューイングすればいいじゃない

46 ：

それ何てセマフォ？

47 ：

キャンセルができるみたい。

48 ：

マルチスレッドプログラミングに関する書籍で良書と言われている
ものってどんなものがあるんでしょうか？
この本は良いよってのがあれば紹介して頂けると嬉しいです。

49 ：

Patterns for Parallel Programming

50 ：

CSPモデルの理論

51 ：

javaだけど
Java並行処理プログラミング
Doug Leaも書いてる

52 ：

外部のカウンタ変数をひとつ用意して、
複数のスレッドで、それをインクリメントするだけのときも
mutex使った方がいいのでしょうか。

53 ：

extern int i;
foo() {
...
i++; /* is it atomic? *?
...
}
が atomic operation かどうかは処理系による。
++/-- だけなら mutex よりも semaphore の方がいい気がする。
cf. sem_init(3)

54 ：

>>52
IA32ですら、その手のことをアセンブリ言語レベルで正しく実装する場合に
LOCKプレフィクス付きでインクリメントしなきゃならなかったりする。
何らかの排他制御は必要。

55 ：

volatileで十分ｗ

56 ：

インクリメントするのが一人なら確かに十分。
mutexはまあ確実だけど、性能の要求によってはspinとかrwlockとか。
semaphoreは、規定回数処理するっていうならいいけど、
回数が分からない場合どうするの？

57 ：

冗談なのか何なのか知らないがインクリメント対象に volatile なんて付けたら
read-modify-write なコードになると思うんだが。

58 ：

cond_timedwaitがシステム時刻を要求するのは問題があると思うけど、
少なくとも日本語ではそういう情報が見当たらない。
wait中にシステム時刻が変更されたらどうなるんだろう。
どう考えてもSUNのcond_reltimedwait_npみたいなのが標準化されるべきだと
思うけど、そういう動きはないんだろうか。
標準のtimedwaitでどうエミュレーションしてもバグの潰し様が無いはず。

59 ：

相対値はそれはそれでまずいんだよ。
標準はなんも考えずにシステムクロックを採用してるわけじゃなくて、
あれはあれでちゃんと角度とか考えられてるんだ。
http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html
のRATIONALE読んでね。

60 ：

読んだ。
>a relative time measure can be easily implemented
on top of a function that specifies absolute time
ダウト。任意のタイミングによるシステム時刻変更を考えれば
これが実装できないから問題にしている。
現在時刻取得 -> timespec変数にタイムアウト値加算
-> timedwait()に渡す -> wait中
全ての過程で競合が発生するだろ？
時間が進むことでタイムアウトが早く発生するのはまあ、対処できる。
(無駄にコードが複雑になるけど。)
しかし、時間が巻き戻ると、タイムアウトの発生が遅れてしまう。
制御が戻らないことには何もできない。
異常時に即座に実行しないといけない処理が遅れてしまう。

61 ：

さらに、逆のパターンの実装は競合が発生するという主張について、
> 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があったはず。

62 ：

> 時間が巻き戻ると
そんな運用しないのが前提じゃないのか。
普通は進み方を遅らせて徐々に合わせるか、一気に合わせるなら
シングルユーザモードもしくは他にそのへんに敏感なプロセスが
動いていないときにするものだと思うが。

63 ：

返事が遅れました。
やはり何らかの制御が必要ということですね。
みなさん、ありがとうございました。
もっと勉強してきます。

64 ：

>>62
そういう常識？が通用する業界もあるんだ。
言いたいことはわかるけど、pthreadなんぞ知ったこっちゃない
オペレータやユーザにそんな制限かけられないことが多いのでは？
全然別のこと担当してる同じマシン上のプログラムに制限かけたり
こっちから監視したりとかも無理な相談だなあ。
これがもしも、普通の個人がPCで使うソフトなら、
どのプログラムがpthread使ってるとか関係なく、
好きなときに時刻の調整くらいするよね？

65 ：

>>61
お前みたいな奴が、cond_relative_timedwait()で1秒って指定したのに
1.1秒で復帰してきた!クソが!って怒るから絶対時刻にしたんだよ。
pthreadsの待ちの時間の正確性なんて信頼できないんだから、この点について
議論してもあまり意味ないと思う。

66 ：

>>65
信頼できない、のレベルによるな。
俺の仕事では1秒以下のズレは全然許容できるレベルだな。
それ以下はリアルタイムOS使う世界だと思う。よく知らんけど。
タイムアウト1秒に指定しても、制御戻るのは1分後かも･･･なんてのは全く話にならない。

67 ：

>>64
だから、通常の運用だと ntp がゆっくり時間補正するようになっている。
>>62 の後半は例外的な運用だろ。
# 知識, 理解力, 謙虚な心 の全てが欠如してると今後辛いぞ。

68 ：

そりゃ、運用や通信プロトコルまで口出しできりゃ、なんでもできる。
あんまり具体的な例挙げても仕方ない気がするが、
半導体業界の某標準プロトコルで、工場のホストから受け取った時刻に
工場内の装置(OSは普通Windows)が問答無用で同期することは普通に行われている。
Linuxに移行したいとか軽率に言い出されるとやばいと思う。
時刻なんて人間に表示するためのもので
制御プログラムとかが依存していいもんじゃないと思うんだが。

69 ：

>>68はまるで自分の業界がスタンダードで世界中がそれを基準にすべきと
いわん勢いだけど、それが根本的に噛み合ってないといいかげんに気付いたらどうよ。

70 ：

>>68
そう言う特殊な要件があるなら、それに合うように作ればいいだけ。
ホストの時刻に影響されたくなければ、システム時刻とホストから受け取った
時刻を別々に管理するとか、やりようはいくらでもあるだろ。

71 ：

俺のためにみんなが喧嘩するのはもうたくさんだ

72 ：

>>68
なんだ、ただのシッタカだったのか、お前。

73 ：

> 半導体業界の某標準プロトコルで、工場のホストから受け取った時刻に
> 工場内の装置(OSは普通Windows)が問答無用で同期することは普通に行われている。
自分で書いているように、それはパソコン系の「普通」であって、
UNIX界隈の人間がその種の運用をすることは100%有り得ないから、
時刻が急に巻き戻ってタイムアウトまで1秒のはずが61秒かかっちゃったりする心配を
あなたがする必要はない。
もしプロトコル上、工場のホストと同期する必要があれば、
システムクロックを変更するのではなく、
アプリケーションの実装でシステムクロックとリモートホストのクロックの差を管理する。
このようにUNIX系へ移行するとしてもちゃんと問題なく出来るから、
あなたは心配しなくてよい。

74 ：

POSIXがatomic increment/decrementをAPIとして規定しなかったのはなぜ?
mutexがあっても軽量なカウンタが不要になることはないわけで、
結局、みな独自に実装しているのだが。

75 ：

ここで聞かずpthreadsのインタフェースを決めた人に聞いてください。
そういうAPIが必須ならプラットフォームを変えることを検討してください。
どうしてもpthreadsに必要ならpthreadsを変えるべく努力してください。
それもいやなら文句言わず今使えるもので実装しなさい。

76 ：

知らないと一言書けば済むことをなぜ4行にも渡って

77 ：

> アプリケーションの実装でシステムクロックとリモートホストのクロックの差を管理する。
俺が知りたいのは、特定の仕様のシステムを実現する方法じゃなくて、
他のプログラムが何していようが、
ユーザが好き勝手に時刻を変更しようが、
現在からN秒以内に条件が成立しなければ、アウトという監視は本当にできないのかってこと。
Pthread標準の枠内で。
時刻をいじってるプログラムと密に連携したり同期とれるとか、
そんなこと当てにできないし、したくもない。

78 ：

ああ、わかった。
要は、pthread の仕様バグを見つけた俺を誉めてくれと言うことね。
「お前は、偉いよ。」
これで十分だろ、もう出てくるな。

79 ：

だいたいUnixで「ユーザ」が時刻を好き勝手にいじれるわけねーだろ。
そういう権限を生身の人間に与えちゃってるとしたらその時点で頭おかしい。

80 ：

> そういう権限を生身の人間に与えちゃってるとしたらその時点で頭おかしい。
ちょっ、お前ン所のサーバー管理者はロボットかよ !!

81 ：

サーバ管理者が時刻を好き勝手にいじるような頭の沸いたサイトはどうにもできねーよ。pthread以前の問題。

82 ：

>>74
POSIXで規定されなかった理由は知らんが、
C++0xではちゃんと Atomic operation や Memory barrier が
定義されるから安心しろ。

83 ：

ちなみにWin32のWaitForMultipleObjectsは相対時間指定なので
>>59の"Timed Wait Semantics"に挙げられた問題が存在する。
>>61をみると理解できていないようなので、何が問題なのかわかるまで考えた方がよいだろう。
プロセスのプリエンプション自体が問題なのではないので、絶対指定のPOSIXにはこの問題はない。

84 ：

>>82
Cで頼む

85 ：

Cに入れるようなもんじゃないだろう。
pthread_xxx_npあたりでいいよ。
CASとかもセットで。

86 ：

>>85
pthread_xxx_npあたりで頼む

87 ：

Solaris10なんだけど、マルチスレッドのプロセスからコールされる
サブルーチンをコンパイルする時って、どんなコンパイルオプションを
付ければ良いんですか？
普通に、コンパイルして共有ライブラリを作ればよい？
このサブルーチンの中では、pthread_XXXはコールしていないので、
#include <pthread.h> もしてないんですがこれってダメ？

88 ：

ちなみに、そのサブルーチンは複数のスレッドから同時に呼ばれても
大丈夫な様に作ってあります。

89 ：

なにもいらないと思うけど。
引数だけで計算して値を返すとか、完全に状態に依存しないものならね。

90 ：

Sun cc使ってる場合は-mtが必要になったりする。
http://docs.sun.com/app/docs/doc/819-0390/compile-94179?a=view
これは-D_REENTRANT -lthreadと等価なようだ。
gccであっても、使っているライブラリによっては、同様に何らかのシンボル定義が
必要になるかもしれない。

91 ：

int f(int a, int b) {
　return a + b;
}
でも？

92 ：

gcc風に言えば__attribute_((const))な関数なら特別なコンパイラフラグは不要。

93 ：

複数のスレッドの終了を待つってどう書くんですか？
マルチプロセスだと、waitpid(2)とかで複数の子プロセスの終了を
待てるんですが、pthread_join()だと、特定のスレッドの終了しか待てません。
例えば、
１００個の子プロセスを作成して、親プロセスはwaitpid()で任意の子プロセスの終了を
監視していて、特定の子プロセスが死んだ場合に、そのプロセスの再起動(fork())を
行うという処理を、pthreadで書こうとした場合、どうすれば良いんでしょうか？
そもそも、上記の様な考え方は、プロセスの親子関係が前提となっているので、
この考え方を、親子という関係のないpthreadに持って来る事がおかしいのでしょうか？

94 ：

死ぬとき親に何か通知したら？
勝手に死ぬなら、たまにpthread_kill(thread_id, 0)するとか。

95 ：

それだと、作成したスレッドが死ぬようなイベントが発生したタイミングを
捕まえるという動作ではないですよね。(ポーリングっぽい)
例えば、１００個スレッドを作って、その各スレッドがTCPソケットを使って
通信していて、TCPコネクションがcloseされたので、pthread_exit()を
コールしたとか、、ソケットから受け取ったデータを処理している最中に
SIGSEGVで死んだとかした場合に、これら１００個のスレッドを常に監視
していて、死んだスレッドを再度作成したいって感じの処理をすっきりと
書きたい場合ってどうやるんでしょう？
スレッドじゃなくてプロセスだったら、子プロセスがexit(2)した場合も、
子プロセスが、SIGSEGVで死んだ場合も、親プロセスがwaitpid(2)してれば
子プロセスが死んだタイミングで親プロセスはそれを知ることが出来るじゃ
ないですか。
これと同じような事をpthreadでやりたいんですが、なんかよく判らんのです。

96 ：

SIGSEGVなどで「死ぬ」場合はプロセスごと道連れなので、pthreads的な対処は
無意味では？
そう考えていくと、スレッドが自発的に終了するケースだけを扱えばいいわけなので、
(スレッドプール的な構成なら)条件変数での通知・待機を使えばよさそうに思う。

97 ：

そう。プロセスと異なり、スレッドは勝手に死んだりしない。だから終了を監視する
必要もない。個々のスレッドは処理が終わったら終了するのではなく、次の処理要求
を待って休眠するように書く方がよいだろう。

98 ：

>>96
>>97
確かに、SIGSEGVなどで死ぬ場合は、SIGSEGVを発生させたロジックを実行中のスレッド
のみが死ぬわけではなく、プロセス自体がいなくなりますが、これをハンドリングして
特定のスレッドのみを再起動して処理を継続するってのは変でしょうか？
プログラムのバグも含めて考えると、やっぱりスレッドがSIGSEGVするケースも考慮して
おきたんです。
Webサーバの様なプログラムをマルチスレッドで書くとすると、クライアントから送られて来た
データがメタメタでサーバ側の処理がSIGSEGVしてしまったとか。(だったらちゃんとデータを
処理する前にチェックしろってのは、ちょっと置いといて。)
こういったケースで正常なクライアントとのコネクションも全部潰れてしまうのは、なんだかなぁ
って思ったんです。

99 ：

あと、条件変数でスレッド間で待ち合わせを行うってのはなんとなく判るんですが、
それと、スレッドの終了を待つってのがどうもうまく結び付きません。
例えば、
ワーカースレッドがもうダメポってpthread_cond_signal()をコール。
メインスレッドは、pthread_cond_wait()で待ってる。
ワーカースレッドはどのタイミングでpthread_exit()をコールすればいいの？
メインスレッドは、どのタイミングでpthread_join()をコールすればいいの？
ワーカースレッドが居なくなったタイミングって条件件数を使えばメインスレッドで
捕まえることって出来ますか？
なんか、この辺りがよく判らんのです。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
【本スレ保護用】2ch閉鎖対策 総合雑談・議論スレ
/**軽くて多機能--XFceスレ**/
フォルダ名をわかりやすい名前に変えないか？
qmailいろいろ(8)