pthread地獄 part 2
Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。
■前スレ
pthread地獄
http://pc8.2ch.net/test/read.cgi/unix/1010933537/ わかりにくいし余計なスレッド起床も伴うから
条件変数は使いまわさず親スレッド起床用と子スレッド起床用とで分けた方がよくね? 勘違いしてた。単純に死んだのを取りこぼさずに知りたいわけではないのか。
じゃあやっぱcondかな。 作ってdetachして放置。
子から親になにか渡さないといけないなら、親側に渡してから死ぬ。 子スレッドの数だけ充足するならsemaphore、
ハンドリングまでするならqueueだな。
どちらもmutexとcondition variableで書けるのはいいとして、
pthreadでの標準的な実装はないのかな? >>118
最初はそう考えたんですが、親がcond_waitしてないときに子が親にcond_signal
するケースを考えると、なんか余計に複雑になるような気がして、
>>113
>>114
に落ち着いたんです。
条件変数分けると、mutexも分けないといけないし。
(ん? 条件変数だけ分けてmutexは使い回せばよい?)
もっかい考えてみる。
>>120
ケースバイケースだと思うんだけど、pthreadでプログラム作るときって、detachするのが
どっちかと言うとデフォなの?
>>121
そうなんですよね。
こんなのって定石だと思うんですが、なんでpthread_XXが無いんだろう?
>>121
>ハンドリングまでするならqueueだな。
あー、確かに、queue作って、子が死ぬ前に突っ込んで親がそれを拾えば
うまくいきますね。
子が居なくなるのと親がそれを検出するのの同期を取らなくても良い場合は、
それが一番良さそうな気がしますね。
>>121
セマフォは普通にPOSIXのセマフォ使えばいいよね >>118
こんな感じですか。
ワーカー側でcond_broadcast使わなくても良くなったので、無駄なスレッドが
起こされなくなってちょっと軽くなったのかな。
ボス側
pthread_mutex_lock(&m_end);
while (0 != thread_num) {
while(NULL == thr_end) {
pthread_cond_wait(&c_end_boss, &m_end);
}
nrc = pthread_join(thr_end, NULL);
if (0 == nrc) {
fprintf(stdout, "thread %5d is exited...\n", thr_end);
--thread_num;
thr_end = NULL;
}else{
fprintf(stdout, "Error pthread_join() return %d\n", nrc);
}
pthread_cond_broadcast(&c_end_work);
}
pthread_mutex_unlock(&m_end);
ワーカー側
pthread_mutex_lock(&m_end);
while (NULL != thr_end) {
pthread_cond_wait(&c_end_work, &m_end);
}
thr_end = pthread_self();
pthread_cond_signal(&c_end_boss);
pthread_mutex_unlock(&m_end);
pthread_exit((void *)NULL); pthreadとシグナルについてですが、
同期シグナルは発生要因となったスレッドに送られ、そのスレッド上でシグナルハンドラが起動される。
非同期シグナルは、それを受け取る準備をしているスレッドに送られる。(結果的に、同期的にシグナルを扱うことが出来る)
いずれの場合も、シグナルを受け取ったスレッドでpthread_XXを使ってもうまく動くと思うんですが、間違ってますか?
ようは、SIGSEGVのハンドラからpthread_XXを呼んでみるとうまく動いているように見えるんだけど、
これって、実装(環境)依存なだけなのか、そうでないのかが知りたいんです。
実装依存以前どころか、たんに運がいいだけである可能性が高いな。
SIGSEGVが起きる状況の場合、SIGSEGVのきっかけとなったメモリ破壊の結果、
pthread_mutex_tやpthread_cond_tまで巻きぞえをくらって壊れている可能性
がある。その状況でpthread関数を呼んでちゃんと動く保証なんてありえない。
シグナルハンドラから呼ばれて正常動作する保証があるのは、マニュアルに
async-signal-safeと明記されている関数だけ。
そういう関数は、実際のところはシステムコールであることが多い。 確かにそういうケースだとpthread関数がまともに動く可能性はないかもしれないですね。
私がSIGSEGVを発生させたパターンは単に、NULLアドレスに書き込んでるだけなので、
その辺のデータ(pthread関数が使用している内部データ)を壊してるって訳ではないです。
そもそも、シグナルハンドラからPthread関数が呼べない理由ってのは何故なんでしょう?
Pthread関数の内部データはそのスレッドのスタック上に存在していて、
シグナルハンドラはスレッドとは別のスタックを使って実行されるからって事ですか? 仮にシグナルハンドラからpthread_*が完全に問題なく呼べたとしても、
mutexとかのリソース持ってる状態でシグナル発生したら状態復旧は絶望的だお。 そこまで苦労してまでバグを直接修正したくない理由の方に興味がわいてきた。 今、気になっているのは、Webサーバの様なサーバプログラムで、ボスは常にaccept()待ち。
クライアントからの接続があったら、ワーカーを起動して、そのあとの処理はワーカに任せる。
といった、定番的なネットワークサーバを書く場合に、いわゆるfork()モデルと、スレッドモデルで
どのような差があるのか(特にエラー発生時において)という事です。
なので、ワーカー側の処理ってのは、基本的に独立していてワーカー同士で共有を行うデータも
不要であると考えています。
非同期シグナルも使う必要は無いと考えています。(多分)
fork()モデルの場合は、ワーカプロセスが同期シグナル(SIGSEGV,SIGILL等)を発生させたとしても、
他のワーカープロセスへの影響は特に無く、再度クライアントが接続してくれば、また、サービスを
再開することが出来ます。
スレッドモデルで同じことを実装することは可能なのか?
特定のワーカーが何らかの理由で同期シグナルを発生させた場合、その特定のワーカが死ぬのは
しょうがないと思うんですが、他のワーカーまで道連れにしてしまうのは避けたいと思っています。
スレッドモデルを使ってこのような処理を安全に書けないって事は無いんじゃないのって思うんですが、
いかがなもんでしょう?
また、MySQLはマルチスレッドで動いているらしいのですが、こういったDBサーバは更に複数のワーカ間で
データの排他や同期を取る必要があると思うんですが、こういったプログラムは同期シグナルとどうやって
折り合いをつけているんでしょうか。
これがいわゆる茨の道ってやつですか? >>131
まだ、なにも作ってないですよ。
pthreadというか、マルチスレッドのプログラムを作るのが始めてなので、
いろいろサンプルを作って勉強している最中です。
このスレとっても勉強になります。
レスしてくださっている皆さんありがと。
ところで、本屋行っても、pthread(マルチスレッド)に関する書籍ってほとんどないですよね。
あっても、10年ぐらい前に出版されたものが殆んどで。
この先、CPUはメニィコアに進もうとしているからもっと沢山あっても良いと思うんですが、
pthreadってあんまり使わないんですかね?
> スレッドモデルで同じことを実装することは可能なのか?
想定しているのがSIGSEGVやSIGILLのようなプログラムロジックの
バグである限り、不可能というのが答。
プロセスには、スレッドに比べて、メモリ空間が分離されていて
SIGSEGVやSIGILLのような誤動作の影響を完全に排除できるという
特徴がある。つまり、まさにプロセスの利点に当てはまるケースな
わけで、このような想定状況で、スレッドにプロセスと同等の信頼性
を求めることはできない。
> こういったプログラムは同期シグナルとどうやって折り合いをつけて
> いるんでしょうか。
バグが原因で発生するシグナルは別として、sigwait() で対処するのが常識。 >>134
そっか。
やっぱりそうなんですか。
非同期シグナルであれば、シグナル受け専のスレッドを立てておいて、そこで
sigwait()するってのは判るんですが、同期シグナルはsigwait()では待てないですもんね?
ん?待てるのか?
ちょっと試してみる。
でも、待てたとしても、どのスレッドがその同期シグナルを発生させたかって、シグナル受け専
スレッドで判らないけりゃどうしようもないですし。
悪いこといわねえだ。signal扱いたいならprocess村に帰った方がええ。 libevent はマルチスレッド環境でも安全に使う方法があるってだけで、
それ自体がスレッドセーフな作りになってるってわけじゃなかったはず。 とりあえず、やってみました。(Solaris10 x86です。)
ボス側で全てのシグナルをブロックし、シグナル受信専用スレッドを作成し、そこでsigwait()。
ワーカースレッドでSGISEGVを発生させるために、NULLアドレスに書き込み。
結果は、プロセスごと終了。
同期シグナルは発生元のスレッドに送られるのでシグナル受信専用スレッドでsigwait()していても
捕まえる事が出来ないってことですね。
同期シグナルは、ワーカースレッド側でsigset()して、シグナルハンドラ側でボスに >>125 すれば、
とりあえずハンドリングは出来ますが、 >>127 にもあるように、どこまで動くのかは不明ですね。
>>134 にもあるように、この辺りがマルチスレッドと、マルチプロセスの差という事なんですね。
そもそもスレッドってなに?、スタックとスレッドの関係って?、プロセスとスレッドの関係って?
OSはスレッドをどう認識してるの?
なんてことが判っている人にとっては自明なんでしょうが、私にもようやくこの辺りが判って来た
様な気がします。
なかなか使いどころが難しいですが、面白い仕組みですね。
シグナルのことを考えるとunixでスレッドをモリモリ使うのはキツい。角度とか。 あと、子プロセス生成(fork)も相性が悪くて、深い悲しみに包まれた。 マルチスレッドプログラミング→排他漏れ続出→永遠とバグが取れない→いくえ不明 俺はマルチプロセスを使い手なんだが相手が残念な事にスレッドを使ってきたので「お前それで良いのか?」と言うと「何いきなり話かけて来てるわけ?」と言われた。
俺の弟がスレッドの熟練者なのだがおれはいつも勝つから相手が気の毒になったので聞いただけなんだがむかついたので「お前シグナルでボコるわ・・」と
言ってmain直後に力を溜めてkillしたら多分リアルでビビったんだろうな、、pthread_sigmaskしてたからサスペンドしてカカッっとforkしながらkillしたらかなり青ざめてた
おれは一気にlongjmpしたんだけどスレッドが硬直してておれの動きを見失ったのか動いてなかったからコマンド投下で排他を崩した上についげきのデッドロックでさらにダメージは加速した。
わざとセマフォをとり「俺はこのままタイムアウトでもいいんだが?」というとようやく必死な顔してなんかコードのはしっこからブロック型システムコール出してきた。
おれはselectで回避、これは一歩間違えるとカウンターで大ダメージを受ける隠し技なので後ろのギャラリーが拍手し出した。
俺は「うるさい、気が散る。一瞬の油断が命取り」というとギャラリーは黙った
スレッドは必死にやってくるが、時既に時間切れ、スタックガードを固めた俺にスキはなかった
たまに来るスタックガードでは防げない攻撃もexitで撃退、終わる頃にはズタズタにされたメモリ空間のcoreがいた MTは処理効率も応答性もいいのでプログラマからは良くたよりにされる
だがたよりにされたいからMTに分けてもダメだと言う事が最近わかった
MTに分けるのは真にMTの問題だから処理を分けたくて分割するんじゃない
分かれてしまう処理がMT
GUIはざんねんがはっきりいってmutexはつかわないしAPIもMT-unsafeとかイマイチだから信頼されにくい これ以上スレッドを作るなよ
プロセスはお前等のためにメモリ空間提供してやってるんだからな
プロセスが終了すればすぐ死ぬくせに調子こき過ぎ
あまり調子に乗ってると裏世界でひっそり幕を閉じる >>149
FILE* p = popen("ps aux", "r");
while(fgets(buf,sizeof(buf),p)){
...
} >>150
それプロセスの一覧じゃね? だいじょうぶ? スレッド内からforkしたらセマフォとかって受け継がれんの? >>149
大抵のpsにはスレッド(LWP)も表示するオプションがある。
>>152
引き継がれるから問題が起きやすい。
ttp://d.hatena.ne.jp/yupo5656/20040715/p1 ttp://www.opengroup.org/onlinepubs/009695399/functions/fork.html
* forkして作ったプロセスはsingle threadだよ。
* マルチスレッドプロセスからforkすると、fork呼んだスレッドひとつとmutexの状態とかも含めてプロセス空間が複製されるよ
forkallというスレッド丸ごとforkするのは却下されたってあるね。 >>153
なるほど、forkしてすぐexecなら問題ないけどそれ以外なら死ぬのんか
system関数がNGなのはここでひっかかるんかな pthread_createで作られたスレッドをptraceで追いかけたいんだけど
どうしたらいい? >>156
ptrace の p は process の p。
SEGV って嫌われてるのな。
昔 mmap(2) した後に mprotect(2) して SEGV 捕捉しながらキャッシュを昇格させる
ような DB 作ったなぁ。 いやいや、pthreadで出来たスレッドってプロセスみたいなもんじゃん。
straceで追うときは、-fか-Fをつければ追えるし。
やっぱstraceを気合い入れて読むしかないのかなぁ・・・嫌だなぁ・・・ プロセスみたいじゃないよ?
Linuxは、なんかごっちゃにしてるとこあるけど NetBSDでも light-weight process だな。
Linux、psで表示しないだけで内部的には完全にプロセスだよね。
メモリがちょいっと共有されてるだけで Linuxのスレッドって、昔は psで普通に複数プロセスに見えてたし、
今でも中身は基本的にそれと変わってないね
まあ、誰も困ってないようだから、そういう実装もアリなんだろうけど ちょっと前の仕事でスレッドプール実装した時のテスト
ケースで、FreeBSD だと数千位作れたのに Linux だと
数百でアウトだったのは多分その辺の何かが影響してる
と思う。 >>164
そりゃシステムで上限決めてっからだよ
ulimitコマンドとかでGENKAI TOPPAしる >>165
だからその辺の上限の根拠が、って話だよ。 >>164-166
絶対違う。
賭けてもいいぜ。
>>164は32bit環境で、かつ、各スレッドのスタックサイズをデフォルトのままで試してるから。
>>164のような制限として、確かに他の理由もあるが
そんなに少なく制限され、しかもあからさまな差がつく理由なんて一つしかない。
(デフォルトで)スタック10Mの32bitOSで各プロセス最大何スレッド程度作れるか
同じく1MのOSでは各プロセスで計いくつか
ちょっとだけ考えてみな。 じゃあ Linux のスレッドサイズの由来は何なのさ。 >>168
1プロセスあたりのスタックサイズを継承すっから
そのデフォルトが由来じゃね? linuxのスレッド数の上限が「linuxではスレッド ≡ プロセス」である事に
起因しているという主張は、プロセス数の上限も数百であるという事と同値。
ところがそんな(数百)プロセス数制限はない。
よって、>>164の主張は間違っている。証明完了。
実験だけで終わらせ、真の原因を突き止めようとしないのはB級エンジニア。
>>162
> Linux、psで表示しないだけで内部的には完全にプロセスだよね。
いつの時代の話だw
>>164
7,8年前から性能も大逆転だが?
>>172
>いつの時代の話だw
違うの?だって隠しプロセスIDを指定してstraceで追うとか出来るよ?
概念的にはともかく実装上はプロセスの延長かと思ってた。
なんか実装上で「ほらここ見ろ」って場所教えてください。 >>172
つ ttp://www.ibm.com/developerworks/jp/linux/library/l-linux-kernel/
プロセス管理は、プロセスの実行に集中的に取り組みます。カーネルではプロセスは
スレッドと呼ばれ、プロセッサーの個々の仮想化 (スレッド・コード、データ、スタック、
および CPU レジスター) を表します。ユーザー空間ではプロセスという用語が一般的に
使用されていますが、Linux 実装ではこの 2 つの概念 (プロセスとスレッド) を
区別していません。カーネルは SCI を介して、新規プロセスの作成 (fork、exec、または
POSIX (Portable Operating System Interface) 関数)、プロセスの停止 (kill、exit)、
そしてプロセス間の通信と同期 (信号、または POSIX メカニズム) を行うための
アプリケーション・プログラム・インターフェース (API) を提供します。 >>170
> ところがそんな(数百)プロセス数制限はない。
メモリ量に依存するけど?
http://www.gelato.unsw.edu.au/lxr/source/kernel/fork.c
> max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); >>176
ここで process と thread に区別はないのはいいよな?
プロセス数とスレッド数の合計は max_threads を越え
られない。また、pthread_attr_setstackaddr() でどう
こうしようがこの制限からは逃れられないので >>167
も的外れ。
これを「プロセス≡スレッドに起因してる」っていうの
は、そんなに言い過ぎかね? 内部的には完全にプロセスっていうより、
プロセスとスレッドを統一的に扱っているって感じでしょ。
今は。昔は特殊なプロセスとして実装していたけど。
だからsignalの扱いが変だった。
FreeBSDはrforkとpthreadが別フレームワーク上の実装で
もうちょっと整理できないのかと思う。 組み込みとかでマルチタスキングモニタ書いてた俺から
すると(当然こいつも区別無かったんだが)、Linux 実
装の方がお手軽実装(悪く言えば手抜き)に見える。
それに Linux 側も最近はスレッド≡プロセスの柵から
脱却しつつあるんじゃなかったっけ?
SunOSとかのLWP使ったスレッドはどうだったの?
Solaris8までは、M:Nだったと言うことはスレッド≡プロセスではないよね。 >>179
脱却しようと思ったけどやっぱプロセス扱いの方が便利だから脱却やーめた
って感じがする。気のせいかもしれないけど。 ん、結局、今はスレッドに軽量性というメリットは
無かったりするの?
あるよ。
カーネル内でプロセスと似た処理していることと、
軽量かどうかは全く関係ない。
>>185
似たような処理をしているなら似たような重さになるんじゃないの?
なんで速く処理できるの? ぶら下がるリソースが違うから。
rforkを勉強してみたら? >>187
ありがとう。Linuxではまだ関係ないってことだね。 SMP 対応前後くらいで thread の扱いも大分違うんじゃ
ないかと思うんだけどどうかね? > 識者
それ以前はユーザプロセス空間内で閉じたスレッド機構
もそれなりにあったと思うんだけど、流石に SMP とな
るとスケジューラの管理下に入れないわけにはいかない
だろうし。
そう考えると Linux とそれ以外では同じ形態を目指し
ていてもアプローチの仕方が正反対なんじゃないか?
>>183 的なのもそこに理由がある気がする。 >>189
> そう考えると Linux とそれ以外では同じ形態を目指し
> ていてもアプローチの仕方が正反対なんじゃないか?
なにも変らないよ。
>>189
C10K問題 ttp://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem が提唱された
あたりから、複雑怪奇な割に性能が上がらないM:Nモデルから、単純明快な1:1モデル
へと向かうOSが増えたのは確か。
あと、プロセスとスレッドとを同じように扱うか否かはNUMAみたいなアーキテクチャを
どう考えるのかにもよりそう。 >>191
面白いね。
FreeBSD はその後に SMPng の作業を完了しているから
現状を見てみたいけど、それぞれの OS が同期を取って
開発されているわけじゃないからどのタイミングで評価
するかってのは難しい問題だな。 >>191
WebサーバがPC UNIX系の主戦場になったからね。
I/Oセントリックだとカーネルスケジューラが有利。
システムコールの中でスケジュールしたいから。 めちゃくちゃ古い実装ベースの情報ではあるけど、
www.acme.com/software/thttpd/benchmarks.html
の一番下にある表は、結構面白いとこ突いてるいるように見える。 node.jsとか、非同期通信寄りが増えてきたな。 pthread_createで300前後しかスレッドを吐き出せないのだが・・・。
もちろん、pthread_detachを使ってデタッチしてるんだけど、全く増える気配なし。
Linuxの設定を見てみると、システム全体のスレッド上限が9万、ユーザーが4万5千
お手上げ状態です。 Stackのサイズを変更したら、すんなり3万2千くらいまで行けました。
どうも、お騒がせしました。 pthread_mutexで複数のスレッドが待ち状態のとき、起床するのは優先度順ですか?
先に待ち状態になった順から起床させれないですか?
セマフォなら待ち順になるのかな >>201
待ち順にはならぬ・・・ ならぬのだ・・・ カーネルさん「順番は俺の都合のいいようにやるから、
順序を規定したければ自分で管理しろよ。
その代わり、マルチCPUになろうがなんだろうが
俺のやることは今と変わらんから安心しろ」 スレッドの同時実行数って決められない?
同時実行数1にして似非RTOSみたいにしたいんだけど
ちなみに各スレッドはsetschedpolicyでSCHED_FIFOにしてるつもりでエラーは返ってきてない
管理者で実行しているし、sched_priorityは1〜5にしてsetschedparamしてます
なにか手順が足りないでしょうか?
自分でセマフォとかで管理するしかないんでしょうか? うむ、cygwinではpthread_attr系がダミー実装しかされていない >コルーチン動かせばいい
これって具体的には何をすることをいってるの?
何か簡単な方法があるの? スレッド作った時点でそれってコルーチンだよな
中断再開を管理するスレッドを別に用意しろということか? いえ、こういう文脈でコルーチンといえば、
・エントリポイントが複数ある
・コードで指定した場所で実行停止が可能な
サブルーチンのことです。
「指定した場所」でCPUを明け渡しながら動きます。
哲学者の食事問題を例に取ると、全体で一つのコルーチン。
最初にどの哲学者から食事を開始してもいい。
自前でユーザレベルスレッドを作ればできるってことじゃないのかな?
ready_queue/wait_queueそれからスレッドインスタンスの構造体、
あとはwait(sleep)/act(wakeup)関数を定義すればいい。
もしカーネルの内部構造について知識/技術がある人なら簡単と言えるかも。
大変かもしれんが、スレッド間の排他制御とか不要(最低限)になるから、
元の設計がしっかりしていれば、かえってデバックは楽だったりする。 今時pthreadでゴリゴリて、流行らないのかな? >>215
流行り廃りで避けられるジャンルじゃないだろこれ
代替に何使うつもりだったの? pthread直ではなく、上位のライブラリ越しにつかうとかじゃない? pthread獣を召喚するライブラリでオススメなんかある?