pthread地獄 part 2

pthread地獄 part 2 (232ﾚｽ)
上下前次 1-新

1: 2006/12/20(水) 22:11:47 AAS
Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。
■前スレ
　pthread地獄
　2chｽﾚ:unix

106(1): 93 2008/07/22(火) 18:20:41 AAS
>>105
どういうレベルかと言われると良く判らないのですが、
SIGSEGVとか、SIGILLとか、SIGFPEとかのシグナルは、同期シグナルと呼ばれていて、
スレッド側で、signal(3)でハンドラを設定しておいてあげれば、そのシグナルを発生させた
スレッドがシグナルを受け取ってくれるみたいです。
"pthread 同期シグナル" でぐぐった時の２ページ目の最後のマルチスレッドのプログラミング
というSunのPDFへのリンク先の資料に書いてありました。

Solaris10(x86)と、FreeBSD(i386)でサンプルを作ってみたところ、スレッド側で定義した
シグナルハンドラでpthread_self()すると、ちゃんとしたスレッドIDが取得できました。

107: 93 2008/07/22(火) 18:55:40 AAS
ちゃんとしたスレッドIDってのは、SIGSEGVを発生させたスレッドIDって言う意味です。

108: 105 2008/07/22(火) 20:40:51 AAS
>>106
ありがとうございます。
comp.programming.threads FAQにも、
Q40: Which signals are synchronous, and whicn are are asynchronous?
というのがあって、同じような記述がされてました。

POSIXとかの仕様として挙動がちゃんと決まっているなら、安心してこの性質が使える
と思うのですが、実装依存と言われると便利だけど使いにくいなぁと思ったもので…

109: 2008/07/23(水) 09:00:47 AAS
使うべきなのは条件変数じゃなくてセマフォ。
子スレッドは終了時にsemaphoreを解放して、
管理スレッドはsemaphoreを得てスレッド作ればいいだけの話。

シグナルハンドラから安全にpthread_*呼び出せるかどうかは知らんがな。
やろうとも思わん。

110: 2008/07/24(木) 00:03:24 AAS
条件変数とmutexがあればセマフォも実装できるから同じことだよ。

mutex で保護したカウンタを、スレッド数で初期化して作っておいて、
待つ側のスレッドはそのカウンタが0になるまでpthread_cond_wait()、
終了するスレッドは、pthread_exit()する直前にカウンタをデクリメント、
もしカウンタがゼロになったらpthread_cond_signal()すればいいだけ。
かんたん。
pthread_join()は使う必要ない。

あとSIGSEGVが起きているということは、そのプロセス内のメモリ空間は
ぶち壊れて不整合が起きているってことだから、さっさとプロセスごと
死ぬべき。そんな状態で動作を続けたら、誤動作して余計悲惨なことに
なるのがオチ。

111: 2008/07/24(木) 01:25:25 AAS
まあ、世の中にはsigaltstack(2)というものもあるわけでね。
SEGVから戻ってこれるケースもあるわけで、そこまで言いきるのはどうかな。

112: 2008/07/24(木) 02:29:58 AAS
確かにそういうケースもあるにはあるな。
>>98は明らかにそういうケースじゃないけどな。

113(1): 93 2008/07/24(木) 09:46:56 AAS
複数のワーカースレッドの終了を待つロジックを書いてみた。

/* 全てのワーカースレッドの終了を待つ */
pthread_mutex_lock(&m_end);
while (0 != thread_num) {
while(NULL == thr_end) {
pthread_cond_wait(&c_end, &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);
}
pthread_mutex_unlock(&m_end);
fprintf(stdout, "ALL thread is exited... thread_num=%d\n", thread_num);

114(1): 93 2008/07/24(木) 09:47:40 AAS
こっちがワーカースレッド側

/* メインスレッドに処理終了を通知 */
pthread_mutex_lock(&m_end);
while (NULL != thr_end) {
pthread_cond_wait(&c_end, &m_end);
}
thr_end = pthread_self();
pthread_cond_broadcast(&c_end);
pthread_mutex_unlock(&m_end);
pthread_exit((void *)NULL);

115: 93 2008/07/24(木) 09:51:36 AAS
やっと、条件変数の使い方が判った。
添削してもらおうとは思ってないけど、とりあえずいろいろ教えてもらったので
張っときます。

複数の子プロセスの任意のタイミングでの終了を親プロセスが待つって
いうケース(親がwaitpid(2)で任意の子プロセスの終了を待つ)を想定してます。

116: 2008/07/24(木) 10:44:00 AAS
子が正しく死ぬなら、semaphoreでやるのが楽そうではある。

117: 93 2008/07/24(木) 11:24:46 AAS
セマフォでやるってのがいまいちピンと来ないんだけど。
親(メイン)スレッドがいつ居なくなるか判らない複数の子(ワーカー)スレッドの終了を待っていて
どれかの子(ワーカー)が居なくなったら、それをハンドリング(どの子が居なくなったかを認識)するってどうやるの？

118(2): 2008/07/24(木) 11:37:20 AAS
わかりにくいし余計なスレッド起床も伴うから
条件変数は使いまわさず親スレッド起床用と子スレッド起床用とで分けた方がよくね?

119: 2008/07/24(木) 11:46:43 AAS
勘違いしてた。単純に死んだのを取りこぼさずに知りたいわけではないのか。
じゃあやっぱcondかな。

120(1): 2008/07/24(木) 12:01:12 AAS
作ってdetachして放置。
子から親になにか渡さないといけないなら、親側に渡してから死ぬ。

121(3): 2008/07/24(木) 12:04:34 AAS
子スレッドの数だけ充足するならsemaphore、
ハンドリングまでするならqueueだな。
どちらもmutexとcondition variableで書けるのはいいとして、
pthreadでの標準的な実装はないのかな?

122: 93 2008/07/24(木) 12:52:22 AAS
>>118
最初はそう考えたんですが、親がcond_waitしてないときに子が親にcond_signal
するケースを考えると、なんか余計に複雑になるような気がして、
>>113
>>114
に落ち着いたんです。
条件変数分けると、mutexも分けないといけないし。
(ん？条件変数だけ分けてmutexは使い回せばよい？)
もっかい考えてみる。

>>120
ケースバイケースだと思うんだけど、pthreadでプログラム作るときって、detachするのが
どっちかと言うとデフォなの？

>>121
そうなんですよね。
こんなのって定石だと思うんですが、なんでpthread_XXが無いんだろう？

123: 93 2008/07/24(木) 13:11:48 AAS
>>121

>ハンドリングまでするならqueueだな。
あー、確かに、queue作って、子が死ぬ前に突っ込んで親がそれを拾えば
うまくいきますね。

子が居なくなるのと親がそれを検出するのの同期を取らなくても良い場合は、
それが一番良さそうな気がしますね。

124: 2008/07/24(木) 13:38:01 AAS
>>121
セマフォは普通にPOSIXのセマフォ使えばいいよね

125(1): 93 2008/07/24(木) 13:50:31 AAS
>>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);

126: 93 2008/07/24(木) 19:31:08 AAS
pthreadとシグナルについてですが、
同期シグナルは発生要因となったスレッドに送られ、そのスレッド上でシグナルハンドラが起動される。
非同期シグナルは、それを受け取る準備をしているスレッドに送られる。(結果的に、同期的にシグナルを扱うことが出来る)
いずれの場合も、シグナルを受け取ったスレッドでpthread_XXを使ってもうまく動くと思うんですが、間違ってますか？

ようは、SIGSEGVのハンドラからpthread_XXを呼んでみるとうまく動いているように見えるんだけど、
これって、実装(環境)依存なだけなのか、そうでないのかが知りたいんです。

127(1): 2008/07/25(金) 02:27:24 AAS
実装依存以前どころか、たんに運がいいだけである可能性が高いな。
SIGSEGVが起きる状況の場合、SIGSEGVのきっかけとなったメモリ破壊の結果、
pthread_mutex_tやpthread_cond_tまで巻きぞえをくらって壊れている可能性
がある。その状況でpthread関数を呼んでちゃんと動く保証なんてありえない。

シグナルハンドラから呼ばれて正常動作する保証があるのは、マニュアルに
async-signal-safeと明記されている関数だけ。
そういう関数は、実際のところはシステムコールであることが多い。

128: 93 2008/07/25(金) 10:14:40 AAS
確かにそういうケースだとpthread関数がまともに動く可能性はないかもしれないですね。
私がSIGSEGVを発生させたパターンは単に、NULLアドレスに書き込んでるだけなので、
その辺のデータ(pthread関数が使用している内部データ)を壊してるって訳ではないです。

そもそも、シグナルハンドラからPthread関数が呼べない理由ってのは何故なんでしょう？
Pthread関数の内部データはそのスレッドのスタック上に存在していて、
シグナルハンドラはスレッドとは別のスタックを使って実行されるからって事ですか？

129: 2008/07/25(金) 11:07:22 AAS
仮にシグナルハンドラからpthread_*が完全に問題なく呼べたとしても、
mutexとかのリソース持ってる状態でシグナル発生したら状態復旧は絶望的だお。

130: 2008/07/25(金) 11:13:24 AAS
おれもわざわざそんな茨の道に行かなくてもと思う。

131(1): 2008/07/25(金) 11:44:36 AAS
そこまで苦労してまでバグを直接修正したくない理由の方に興味がわいてきた。

132: 93 2008/07/25(金) 12:44:25 AAS
今、気になっているのは、Webサーバの様なサーバプログラムで、ボスは常にaccept()待ち。
クライアントからの接続があったら、ワーカーを起動して、そのあとの処理はワーカに任せる。
といった、定番的なネットワークサーバを書く場合に、いわゆるfork()モデルと、スレッドモデルで
どのような差があるのか(特にエラー発生時において)という事です。

なので、ワーカー側の処理ってのは、基本的に独立していてワーカー同士で共有を行うデータも
不要であると考えています。
非同期シグナルも使う必要は無いと考えています。(多分)

fork()モデルの場合は、ワーカプロセスが同期シグナル(SIGSEGV,SIGILL等)を発生させたとしても、
他のワーカープロセスへの影響は特に無く、再度クライアントが接続してくれば、また、サービスを
再開することが出来ます。

スレッドモデルで同じことを実装することは可能なのか？
特定のワーカーが何らかの理由で同期シグナルを発生させた場合、その特定のワーカが死ぬのは
しょうがないと思うんですが、他のワーカーまで道連れにしてしまうのは避けたいと思っています。

スレッドモデルを使ってこのような処理を安全に書けないって事は無いんじゃないのって思うんですが、
いかがなもんでしょう？

また、MySQLはマルチスレッドで動いているらしいのですが、こういったDBサーバは更に複数のワーカ間で
データの排他や同期を取る必要があると思うんですが、こういったプログラムは同期シグナルとどうやって
折り合いをつけているんでしょうか。

これがいわゆる茨の道ってやつですか？

133: 93 2008/07/25(金) 12:52:01 AAS
>>131
まだ、なにも作ってないですよ。
pthreadというか、マルチスレッドのプログラムを作るのが始めてなので、
いろいろサンプルを作って勉強している最中です。

このスレとっても勉強になります。
レスしてくださっている皆さんありがと。

ところで、本屋行っても、pthread(マルチスレッド)に関する書籍ってほとんどないですよね。
あっても、１０年ぐらい前に出版されたものが殆んどで。
この先、CPUはメニィコアに進もうとしているからもっと沢山あっても良いと思うんですが、
pthreadってあんまり使わないんですかね？

134(2): [sage ] 2008/07/25(金) 12:57:45 AAS
> スレッドモデルで同じことを実装することは可能なのか？

想定しているのがSIGSEGVやSIGILLのようなプログラムロジックの
バグである限り、不可能というのが答。
プロセスには、スレッドに比べて、メモリ空間が分離されていて
SIGSEGVやSIGILLのような誤動作の影響を完全に排除できるという
特徴がある。つまり、まさにプロセスの利点に当てはまるケースな
わけで、このような想定状況で、スレッドにプロセスと同等の信頼性
を求めることはできない。

> こういったプログラムは同期シグナルとどうやって折り合いをつけて
> いるんでしょうか。

バグが原因で発生するシグナルは別として、sigwait() で対処するのが常識。

135: 93 2008/07/25(金) 13:40:09 AAS
>>134
そっか。
やっぱりそうなんですか。

非同期シグナルであれば、シグナル受け専のスレッドを立てておいて、そこで
sigwait()するってのは判るんですが、同期シグナルはsigwait()では待てないですもんね？
ん？待てるのか？
ちょっと試してみる。
でも、待てたとしても、どのスレッドがその同期シグナルを発生させたかって、シグナル受け専
スレッドで判らないけりゃどうしようもないですし。

136: 2008/07/26(土) 12:58:41 AAS
悪いこといわねえだ。signal扱いたいならprocess村に帰った方がええ。

137: 2008/07/26(土) 17:23:08 AAS
つ libevent

138: 2008/07/26(土) 19:24:07 AAS
libevent はマルチスレッド環境でも安全に使う方法があるってだけで、
それ自体がスレッドセーフな作りになってるってわけじゃなかったはず。

139: 93 2008/07/29(火) 10:32:25 AAS
とりあえず、やってみました。(Solaris10 x86です。)
ボス側で全てのシグナルをブロックし、シグナル受信専用スレッドを作成し、そこでsigwait()。
ワーカースレッドでSGISEGVを発生させるために、NULLアドレスに書き込み。
結果は、プロセスごと終了。
同期シグナルは発生元のスレッドに送られるのでシグナル受信専用スレッドでsigwait()していても
捕まえる事が出来ないってことですね。

同期シグナルは、ワーカースレッド側でsigset()して、シグナルハンドラ側でボスに >>125 すれば、
とりあえずハンドリングは出来ますが、 >>127 にもあるように、どこまで動くのかは不明ですね。

>>134 にもあるように、この辺りがマルチスレッドと、マルチプロセスの差という事なんですね。

そもそもスレッドってなに？、スタックとスレッドの関係って？、プロセスとスレッドの関係って？
OSはスレッドをどう認識してるの？
なんてことが判っている人にとっては自明なんでしょうが、私にもようやくこの辺りが判って来た
様な気がします。

なかなか使いどころが難しいですが、面白い仕組みですね。

140: 2008/07/30(水) 21:16:41 AAS
シグナルのことを考えるとunixでスレッドをモリモリ使うのはキツい。角度とか。

141: 2008/08/09(土) 19:15:44 AAS
あと、子プロセス生成(fork）も相性が悪くて、深い悲しみに包まれた。

142: 2008/08/09(土) 20:02:32 AAS
マルチスレッドプログラミング→排他漏れ続出→永遠とバグが取れない→いくえ不明

143: 2008/08/09(土) 20:41:21 AAS
俺はマルチプロセスを使い手なんだが相手が残念な事にスレッドを使ってきたので「お前それで良いのか？」と言うと「何いきなり話かけて来てるわけ？」と言われた。
俺の弟がスレッドの熟練者なのだがおれはいつも勝つから相手が気の毒になったので聞いただけなんだがむかついたので「お前ｼｸﾞﾅﾙでﾎﾞｺるわ・・」と
言ってmain直後に力を溜めてkillしたら多分リアルでビビったんだろうな、、pthread_sigmaskしてたからｻｽﾍﾟﾝﾄﾞしてｶｶッっとforkしながらkillしたらかなり青ざめてた
おれは一気にlongjmpしたんだけどスレッドが硬直してておれの動きを見失ったのか動いてなかったからｺﾏﾝﾄﾞ投下で排他を崩した上についげきのデッドロックでさらにﾀﾞﾒｰｼﾞは加速した。
わざとｾﾏﾌｫをとり「俺はこのままﾀｲﾑｱｳﾄでもいいんだが？」というとようやく必死な顔してなんかｺｰﾄﾞのはしっこからﾌﾞﾛｯｸ型ｼｽﾃﾑｺｰﾙ出してきた。
おれはselectで回避、これは一歩間違えるとｶｳﾝﾀｰで大ﾀﾞﾒｰｼﾞを受ける隠し技なので後ろのギャラリーが拍手し出した。
俺は「うるさい、気が散る。一瞬の油断が命取り」というとｷﾞｬﾗﾘｰは黙った
スレッドは必死にやってくるが、時既に時間切れ、ｽﾀｯｸｶﾞｰﾄﾞを固めた俺にｽｷはなかった
たまに来るｽﾀｯｸｶﾞｰﾄﾞでは防げない攻撃もexitで撃退、終わる頃にはズタズタにされたﾒﾓﾘ空間のcoreがいた

144: 2008/08/10(日) 03:35:51 AAS
MTは処理効率も応答性もいいのでプログラマからは良くたよりにされる
だがたよりにされたいからMTに分けてもダメだと言う事が最近わかった
MTに分けるのは真にMTの問題だから処理を分けたくて分割するんじゃない
分かれてしまう処理がMT
GUIはざんねんがはっきりいってmutexはつかわないしAPIもMT-unsafeとかイマイチだから信頼されにくい

145: 2008/08/15(金) 13:04:59 AAS
これ以上スレッドを作るなよ
プロセスはお前等のためにメモリ空間提供してやってるんだからな
プロセスが終了すればすぐ死ぬくせに調子こき過ぎ
あまり調子に乗ってると裏世界でひっそり幕を閉じる

146: 2008/10/09(木) 04:28:39 AAS
hosyu

147: 2009/11/04(水) 21:43:34 AAS
pthread_yeild って無いの？

148: 2009/11/04(水) 23:49:54 AAS
なくなったよ。
外部ﾘﾝｸ[html]:www.opengroup.org

149(2): 2009/12/07(月) 01:53:37 AAS
スレッドの一覧ってどうやれば取得できるの？

150(1): 2009/12/08(火) 15:14:40 AAS
>>149

FILE* p = popen("ps aux", "r");
while(fgets(buf,sizeof(buf),p)){
...
}

151: 2009/12/08(火) 20:09:24 AAS
>>150
それプロセスの一覧じゃね？だいじょうぶ？

152(1): [sega] 2009/12/12(土) 02:28:19 AAS
スレッド内からforkしたらセマフォとかって受け継がれんの？

153(1): 2009/12/12(土) 12:57:32 AAS
>>149
大抵のpsにはスレッド(LWP)も表示するオプションがある。

>>152
引き継がれるから問題が起きやすい。
外部ﾘﾝｸ:d.hatena.ne.jp

154: 2009/12/12(土) 13:24:05 AAS
外部ﾘﾝｸ[html]:www.opengroup.org
* forkして作ったプロセスはsingle threadだよ。
* マルチスレッドプロセスからforkすると、fork呼んだスレッドひとつとmutexの状態とかも含めてプロセス空間が複製されるよ

forkallというスレッド丸ごとforkするのは却下されたってあるね。

155: 2009/12/12(土) 15:51:24 AAS
>>153
なるほど、forkしてすぐexecなら問題ないけどそれ以外なら死ぬのんか
system関数がNGなのはここでひっかかるんかな

156(1): 2009/12/19(土) 16:08:13 AAS
pthread_createで作られたスレッドをptraceで追いかけたいんだけど
どうしたらいい？

157: 2009/12/20(日) 12:42:35 AAS
>>156
ptrace の p は process の p。

SEGV って嫌われてるのな。
昔 mmap(2) した後に mprotect(2) して SEGV 捕捉しながらキャッシュを昇格させる
ような DB 作ったなぁ。

158: 2009/12/20(日) 18:54:37 AAS
いやいや、pthreadで出来たスレッドってプロセスみたいなもんじゃん。
straceで追うときは、-fか-Fをつければ追えるし。

やっぱstraceを気合い入れて読むしかないのかなぁ・・・嫌だなぁ・・・

159: 2009/12/20(日) 19:33:17 AAS
プロセスみたいじゃないよ？

Linuxは、なんかごっちゃにしてるとこあるけど

160: 2009/12/20(日) 20:33:10 AAS
Solaris も軽量プロセスって言うね

161: 2009/12/21(月) 01:47:45 AAS
NetBSDでも light-weight process だな。

162(1): 2009/12/21(月) 20:29:34 AAS
Linux、psで表示しないだけで内部的には完全にプロセスだよね。
メモリがちょいっと共有されてるだけで

163: 2009/12/22(火) 00:03:45 AAS
Linuxのスレッドって、昔は psで普通に複数プロセスに見えてたし、
今でも中身は基本的にそれと変わってないね
まあ、誰も困ってないようだから、そういう実装もアリなんだろうけど

164(4): 2009/12/22(火) 02:36:56 AAS
ちょっと前の仕事でスレッドプール実装した時のテスト
ケースで、FreeBSD だと数千位作れたのに Linux だと
数百でアウトだったのは多分その辺の何かが影響してる
と思う。

165(2): 2009/12/22(火) 02:40:11 AAS
>>164
そりゃシステムで上限決めてっからだよ
ulimitコマンドとかでGENKAI TOPPAしる

166(1): 2009/12/22(火) 06:03:03 AAS
>>165
だからその辺の上限の根拠が、って話だよ。

167(1): 2009/12/22(火) 07:45:20 AAS
>>164-166
絶対違う。

賭けてもいいぜ。
>>164は32bit環境で、かつ、各スレッドのスタックサイズをデフォルトのままで試してるから。
>>164のような制限として、確かに他の理由もあるが
そんなに少なく制限され、しかもあからさまな差がつく理由なんて一つしかない。
(デフォルトで)スタック10Mの32bitOSで各プロセス最大何スレッド程度作れるか
同じく1MのOSでは各プロセスで計いくつか
ちょっとだけ考えてみな。

168(1): 2009/12/22(火) 08:05:11 AAS
じゃあ Linux のスレッドサイズの由来は何なのさ。

169: 2009/12/22(火) 09:24:51 AAS
>>168
1プロセスあたりのスタックサイズを継承すっから
そのデフォルトが由来じゃね？

170(1): 2009/12/22(火) 09:52:26 AAS
linuxのスレッド数の上限が「linuxではスレッド ≡ プロセス」である事に
起因しているという主張は、プロセス数の上限も数百であるという事と同値。
ところがそんな(数百)プロセス数制限はない。
よって、>>164の主張は間違っている。証明完了。

実験だけで終わらせ、真の原因を突き止めようとしないのはB級エンジニア。

171: 2009/12/22(火) 10:34:19 AAS
>B級エンジニア。
ただのてーへんだろ？

172(2): 2009/12/22(火) 13:13:46 AAS
>>162
> Linux、psで表示しないだけで内部的には完全にプロセスだよね。

いつの時代の話だw

>>164
7,8年前から性能も大逆転だが?

173: 2009/12/22(火) 13:15:13 AAS
閉鎖系ではよくあること。
そっとしておいてやれ。

174: 2009/12/22(火) 19:23:08 AAS
>>172
＞いつの時代の話だw
違うの？だって隠しプロセスIDを指定してstraceで追うとか出来るよ？
概念的にはともかく実装上はプロセスの延長かと思ってた。
なんか実装上で「ほらここ見ろ」って場所教えてください。

175: 2009/12/22(火) 21:47:53 AAS
>>172
つ外部ﾘﾝｸ:www.ibm.com

プロセス管理は、プロセスの実行に集中的に取り組みます。カーネルではプロセスは
スレッドと呼ばれ、プロセッサーの個々の仮想化 (スレッド・コード、データ、スタック、
および CPU レジスター) を表します。ユーザー空間ではプロセスという用語が一般的に
使用されていますが、Linux 実装ではこの 2 つの概念 (プロセスとスレッド) を
区別していません。カーネルは SCI を介して、新規プロセスの作成 (fork、exec、または
POSIX (Portable Operating System Interface) 関数)、プロセスの停止 (kill、exit)、
そしてプロセス間の通信と同期 (信号、または POSIX メカニズム) を行うための
アプリケーション・プログラム・インターフェース (API) を提供します。

176(1): 2009/12/23(水) 00:11:53 AAS
>>170
> ところがそんな(数百)プロセス数制限はない。

メモリ量に依存するけど?

外部ﾘﾝｸ[c]:www.gelato.unsw.edu.au
> max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

177: B級エンジニア 2009/12/23(水) 00:27:34 AAS
>>176
ここで process と thread に区別はないのはいいよな?

プロセス数とスレッド数の合計は max_threads を越え
られない。また、pthread_attr_setstackaddr() でどう
こうしようがこの制限からは逃れられないので >>167
も的外れ。

これを「プロセス≡スレッドに起因してる」っていうの
は、そんなに言い過ぎかね?

178: 2009/12/23(水) 03:24:34 AAS
内部的には完全にプロセスっていうより、
プロセスとスレッドを統一的に扱っているって感じでしょ。
今は。昔は特殊なプロセスとして実装していたけど。
だからsignalの扱いが変だった。

FreeBSDはrforkとpthreadが別フレームワーク上の実装で
もうちょっと整理できないのかと思う。

179(1): 2009/12/23(水) 10:05:31 AAS
組み込みとかでマルチタスキングモニタ書いてた俺から
すると（当然こいつも区別無かったんだが）、Linux 実
装の方がお手軽実装（悪く言えば手抜き）に見える。

それに Linux 側も最近はスレッド≡プロセスの柵から
脱却しつつあるんじゃなかったっけ?

180: 2009/12/23(水) 11:33:40 AAS
シッタカ煽りの172が逃亡してしまった

181: 2009/12/23(水) 13:06:48 AAS
SunOSとかのLWP使ったスレッドはどうだったの？
Solaris8までは、M:Nだったと言うことはスレッド≡プロセスではないよね。

182: 2009/12/23(水) 15:02:53 AAS
Linux だけ特殊だと思えばいいよ。

183(1): 2009/12/23(水) 15:15:35 AAS
>>179
脱却しようと思ったけどやっぱプロセス扱いの方が便利だから脱却やーめた
って感じがする。気のせいかもしれないけど。

184: 2009/12/23(水) 15:19:22 AAS
ん、結局、今はスレッドに軽量性というメリットは
無かったりするの?

185(1): 2009/12/23(水) 16:11:43 AAS
あるよ。
カーネル内でプロセスと似た処理していることと、
軽量かどうかは全く関係ない。

186: 2009/12/23(水) 17:00:04 AAS
>>185
似たような処理をしているなら似たような重さになるんじゃないの？
なんで速く処理できるの？

187(1): 2009/12/23(水) 17:26:12 AAS
ぶら下がるリソースが違うから。
rforkを勉強してみたら?

188: 2009/12/23(水) 17:39:09 AAS
>>187
ありがとう。Linuxではまだ関係ないってことだね。

189(2): 2009/12/23(水) 17:47:46 AAS
SMP 対応前後くらいで thread の扱いも大分違うんじゃ
ないかと思うんだけどどうかね? > 識者

それ以前はユーザプロセス空間内で閉じたスレッド機構
もそれなりにあったと思うんだけど、流石に SMP とな
るとスケジューラの管理下に入れないわけにはいかない
だろうし。

そう考えると Linux とそれ以外では同じ形態を目指し
ていてもアプローチの仕方が正反対なんじゃないか?
>>183 的なのもそこに理由がある気がする。

190: 2009/12/23(水) 17:56:14 AAS
>>189
> そう考えると Linux とそれ以外では同じ形態を目指し
> ていてもアプローチの仕方が正反対なんじゃないか?

なにも変らないよ。

191(2): 2009/12/23(水) 18:54:39 AAS
>>189
C10K問題外部ﾘﾝｸ[cgi]:www.hyuki.com が提唱された
あたりから、複雑怪奇な割に性能が上がらないM:Nモデルから、単純明快な1:1モデル
へと向かうOSが増えたのは確か。

あと、プロセスとスレッドとを同じように扱うか否かはNUMAみたいなアーキテクチャを
どう考えるのかにもよりそう。

192: 2009/12/23(水) 19:34:54 AAS
>>191
面白いね。

FreeBSD はその後に SMPng の作業を完了しているから
現状を見てみたいけど、それぞれの OS が同期を取って
開発されているわけじゃないからどのタイミングで評価
するかってのは難しい問題だな。

193: 2009/12/23(水) 20:01:30 AAS
>>191
WebサーバがPC UNIX系の主戦場になったからね。
I/Oセントリックだとカーネルスケジューラが有利。
システムコールの中でスケジュールしたいから。

194(1): 2010/01/05(火) 22:01:20 AAS
めちゃくちゃ古い実装ベースの情報ではあるけど、
www.acme.com/software/thttpd/benchmarks.html
の一番下にある表は、結構面白いとこ突いてるいるように見える。

195: 2010/01/05(火) 22:26:35 AAS
>>194
ほほう・・・

196: 2011/01/19(水) 02:40:41 AAS
プラズマクラスター効果なしｗｗ
Twitterﾘﾝｸ:saramura6

197: 2011/01/20(木) 19:08:51 AAS
node.jsとか、非同期通信寄りが増えてきたな。

198(1): 2011/04/07(木) 03:13:05.15 AAS
pthread_createで300前後しかスレッドを吐き出せないのだが・・・。
もちろん、pthread_detachを使ってデタッチしてるんだけど、全く増える気配なし。

Linuxの設定を見てみると、システム全体のスレッド上限が9万、ユーザーが4万5千
お手上げ状態です。

199: 2011/04/07(木) 04:00:50.39 AAS
アドレス空間が足りないだけ

200: 198 2011/04/07(木) 04:07:26.75 AAS
Stackのサイズを変更したら、すんなり3万2千くらいまで行けました。
どうも、お騒がせしました。

201(1): 2011/04/22(金) 21:31:00.83 AAS
pthread_mutexで複数のスレッドが待ち状態のとき、起床するのは優先度順ですか？
先に待ち状態になった順から起床させれないですか？
セマフォなら待ち順になるのかな

202: 2011/04/26(火) 00:16:55.83 AAS
>>201
待ち順にはならぬ・・・ならぬのだ・・・

203: 2011/04/26(火) 11:49:13.33 AAS
カーネルさん「順番は俺の都合のいいようにやるから、
順序を規定したければ自分で管理しろよ。
その代わり、マルチCPUになろうがなんだろうが
俺のやることは今と変わらんから安心しろ」

204: 2011/04/27(水) 02:10:10.39 AAS
カーネル△

205(1): 2011/08/31(水) 08:26:04.18 AAS
スレッドの同時実行数って決められない？
同時実行数１にして似非RTOSみたいにしたいんだけど
ちなみに各スレッドはsetschedpolicyでSCHED_FIFOにしてるつもりでエラーは返ってきてない
管理者で実行しているし、sched_priorityは１〜５にしてsetschedparamしてます

なにか手順が足りないでしょうか？
自分でセマフォとかで管理するしかないんでしょうか？

206: 2011/09/01(木) 08:57:44.31 AAS
うむ、cygwinではpthread_attr系がダミー実装しかされていない

207: 2011/09/01(木) 21:12:56.51 AAS
>>205
スレッド作ってコルーチン動かせばいい

208: 2011/09/09(金) 12:37:20.07 AAS
>コルーチン動かせばいい
これって具体的には何をすることをいってるの？
何か簡単な方法があるの？

209: 2011/09/12(月) 22:42:44.40 AAS
スレッド作った時点でそれってコルーチンだよな
中断再開を管理するスレッドを別に用意しろということか？

210: 2011/09/13(火) 00:33:50.94 AAS
いえ、こういう文脈でコルーチンといえば、
・エントリポイントが複数ある
・コードで指定した場所で実行停止が可能な
サブルーチンのことです。
「指定した場所」でCPUを明け渡しながら動きます。

211: 2011/09/16(金) 18:30:28.02 AAS
エントリポイントが複数あるってどういうこと？

212: 2011/09/17(土) 19:37:06.16 AAS
哲学者の食事問題を例に取ると、全体で一つのコルーチン。
最初にどの哲学者から食事を開始してもいい。

213: 2011/10/18(火) 04:37:25.13 AAS
自前でユーザレベルスレッドを作ればできるってことじゃないのかな？

ready_queue/wait_queueそれからスレッドインスタンスの構造体、
あとはwait(sleep)/act(wakeup)関数を定義すればいい。
もしカーネルの内部構造について知識/技術がある人なら簡単と言えるかも。

大変かもしれんが、スレッド間の排他制御とか不要(最低限)になるから、
元の設計がしっかりしていれば、かえってデバックは楽だったりする。

214: 2011/12/17(土) 12:34:40.08 AAS
地獄ではないだろ……

215(1): 2013/01/17(木) 05:50:17.84 AAS
今時pthreadでゴリゴリて、流行らないのかな？

216: 2013/02/11(月) 18:25:18.64 AAS
>>215
流行り廃りで避けられるジャンルじゃないだろこれ
代替に何使うつもりだったの？

217: 2013/02/12(火) 00:23:57.14 AAS
pthread直ではなく、上位のライブラリ越しにつかうとかじゃない?

218(1): 2013/02/12(火) 03:14:17.06 AAS
pthread獣を召喚するライブラリでオススメなんかある？

219: 410 2013/02/19(火) 20:34:50.11 AAS
>>218 C++11の<thread>とか、Boost::thread とか、OpenMP とか。

220: 2013/06/09(日) 15:26:03.82 AAS
先日、他部署を交えて開かれた社内技術交換会でのこと。
先輩は自分が開発担当したあるソフトのプログラミング中に思いついたという
文字列処理の高速化アルゴリズムについて得意気に解説し始めた。
話し始めてしばらくして、隣の部署の人が口をはさんだ。
「それ、有名な番兵のアルゴリズムですよね。ウチでも昔はよく番兵を使いました。
でも番兵はマルチスレッドで使えないという欠点があるので、
今では番兵のアルゴリズムを使うことは禁止してます。
これ使われると発見しにくいバグになって困るんですよねぇ…
ところで今日のお話というのは、
番兵のアルゴリズムをマルチスレッドに対応させるような方法か何かですか?」
そのあと先輩の話は支離滅裂になり、何の技術交換会だったのか
よく覚えていない…

221: 2013/12/06(金) 03:08:00.49 AAS
いまさらだけど"Pthreadsプログラミング"を買ってきた
がんばって積読するぞ

222: 2013/12/06(金) 09:51:35.50 AAS
マルチメディアで番兵使っちゃ駄目なの？

223: 2013/12/07(土) 15:25:25.69 AAS
モーティミーディアー

224: 2013/12/08(日) 18:03:34.98 AAS
中略）
いやいや、●流出事件でも分かった様に叩きスレが伸びるってのは理由が有る訳です。２ちゃんねる運営の金になる。
運営の工作員が自演で火を付けてるわけ、それに乗った一般人が情報出して、その情報溜め込んだ運営の工作員がその情報元にまた煽る。

２ちゃんねるの運営にはそう言う集客方法が有る訳です。
それ系のサイトじゃあ、良く語られてる『プロ固定（プロ名無し）』ですよ。

各板覗いて御覧なさい、必ずあるでしょ？個人対象にした叩きスレッドが、
内容は似たり寄ったりですよ、どのスレッドも。運営の工作員が掛け持ちでテコ入れしてますから（笑
一種の炎上ビジネスなんです。

一般利用者ってのはお手軽に誹謗中傷出来る対象があると、何も考えずに叩くんです。とりあえず多少の正当性みたいなものが有ればいい。
どんな小さな事で良いし、自分が何らかの係わりや知識が有れば尚の事。

日本最大の電子掲示板２ちゃんねるが板によって専門的に分かれてるってのはそう言う意味でも凄く都合が良いわけです。
各専門分野の関係者が勝手に情報持ち寄って、叩く対象の情報提供者になってくれる・・・

正にカモがネギ背負って毎日飛んで来ては個人の誹謗中傷スレッドに情報投下してスレッド伸ばしてくれてる訳です。
炎上とか本人降臨とかは運営にとってはご馳走。

巷で言われております『ネットイナゴ、無敵の人』は運営と二人三脚な所がありまして、
酷い煽り方のレスは自作自演の運営工作員だったりするんですけど、一般人のですね、例えば関係者や嫉み僻み私怨持ってる様な、
又は何だか良く分からない“正義感”に突き動かされてしまう様な程度の人も誹謗中傷スレッドの叩きの一連の流れを見るとですね。
２ちゃんねるの運営方法の一部になってるんですよ。

ネラーと運営と言うのはお互い共存共生関係に有ると、まぁ、そう言う話なわけです。
（後略
.

225: 2013/12/11(水) 22:58:32.94 AAS
番兵使うとマルチスレッドでバグるって、どういうロジックなんだろうか。

226: 2017/12/29(金) 07:43:45.56 AAS
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

AUQ0EKC298

227: 2018/05/22(火) 06:08:23.65 AAS
知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

1HZYE

228: 2023/09/15(金) 19:16:18.64 AAS
めっちゃええ感じやん。

229: 2023/11/20(月) 11:35:48.04 AAS
あなたと肩を並べて歩きたいの

230: 2024/03/27(水) 19:57:34.12 AAS
著名人が乗っていましたが

231: 2024/03/27(水) 20:32:45.41 AAS
もっと整理して弱い
グーナー絶頂の順位に変動あり得る)よな」みたいな

232: 2024/03/27(水) 21:54:58.94 AAS
なんか思ったより下げない
相変わらずツボガーは話に広がりがなくて実在の居酒屋で喜んでるだけの人エナプ公式グッズのサンダル履いてる状態なの分まで歌う」

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.683s*