トップページunix
213コメント82KB

pthread地獄 part 2

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2006/12/20(水) 22:11:47
Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。
■前スレ
 pthread地獄
 http://pc8.2ch.net/test/read.cgi/unix/1010933537/
0163名無しさん@お腹いっぱい。2009/12/22(火) 00:03:45
Linuxのスレッドって、昔は psで普通に複数プロセスに見えてたし、
今でも中身は基本的にそれと変わってないね
まあ、誰も困ってないようだから、そういう実装もアリなんだろうけど
0164名無しさん@お腹いっぱい。2009/12/22(火) 02:36:56
ちょっと前の仕事でスレッドプール実装した時のテスト
ケースで、FreeBSD だと数千位作れたのに Linux だと
数百でアウトだったのは多分その辺の何かが影響してる
と思う。
0165名無しさん@お腹いっぱい。2009/12/22(火) 02:40:11
>>164
そりゃシステムで上限決めてっからだよ
ulimitコマンドとかでGENKAI TOPPAしる
0166名無しさん@お腹いっぱい。2009/12/22(火) 06:03:03
>>165
だからその辺の上限の根拠が、って話だよ。
0167名無しさん@お腹いっぱい。2009/12/22(火) 07:45:20
>>164-166
絶対違う。

賭けてもいいぜ。
>>164は32bit環境で、かつ、各スレッドのスタックサイズをデフォルトのままで試してるから。
>>164のような制限として、確かに他の理由もあるが
そんなに少なく制限され、しかもあからさまな差がつく理由なんて一つしかない。
(デフォルトで)スタック10Mの32bitOSで各プロセス最大何スレッド程度作れるか
同じく1MのOSでは各プロセスで計いくつか
ちょっとだけ考えてみな。
0168名無しさん@お腹いっぱい。2009/12/22(火) 08:05:11
じゃあ Linux のスレッドサイズの由来は何なのさ。
0169名無しさん@お腹いっぱい。2009/12/22(火) 09:24:51
>>168
1プロセスあたりのスタックサイズを継承すっから
そのデフォルトが由来じゃね?
0170名無しさん@お腹いっぱい。2009/12/22(火) 09:52:26
linuxのスレッド数の上限が「linuxではスレッド ≡ プロセス」である事に
起因しているという主張は、プロセス数の上限も数百であるという事と同値。
ところがそんな(数百)プロセス数制限はない。
よって、>>164の主張は間違っている。証明完了。

実験だけで終わらせ、真の原因を突き止めようとしないのはB級エンジニア。
0171名無しさん@お腹いっぱい。2009/12/22(火) 10:34:19
>B級エンジニア。
ただのてーへんだろ?
0172名無しさん@お腹いっぱい。2009/12/22(火) 13:13:46
>>162
> Linux、psで表示しないだけで内部的には完全にプロセスだよね。

いつの時代の話だw

>>164
7,8年前から性能も大逆転だが?
0173名無しさん@お腹いっぱい。2009/12/22(火) 13:15:13
閉鎖系ではよくあること。
そっとしておいてやれ。
0174名無しさん@お腹いっぱい。2009/12/22(火) 19:23:08
>>172
>いつの時代の話だw
違うの?だって隠しプロセスIDを指定してstraceで追うとか出来るよ?
概念的にはともかく実装上はプロセスの延長かと思ってた。
なんか実装上で「ほらここ見ろ」って場所教えてください。
0175名無しさん@お腹いっぱい。2009/12/22(火) 21:47:53
>>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) を提供します。
0176名無しさん@お腹いっぱい。2009/12/23(水) 00:11:53
>>170
> ところがそんな(数百)プロセス数制限はない。

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

http://www.gelato.unsw.edu.au/lxr/source/kernel/fork.c
> max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
0177B級エンジニア2009/12/23(水) 00:27:34
>>176
ここで process と thread に区別はないのはいいよな?

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

これを「プロセス≡スレッドに起因してる」っていうの
は、そんなに言い過ぎかね?
0178名無しさん@お腹いっぱい。2009/12/23(水) 03:24:34
内部的には完全にプロセスっていうより、
プロセスとスレッドを統一的に扱っているって感じでしょ。
今は。昔は特殊なプロセスとして実装していたけど。
だからsignalの扱いが変だった。

FreeBSDはrforkとpthreadが別フレームワーク上の実装で
もうちょっと整理できないのかと思う。
0179名無しさん@お腹いっぱい。2009/12/23(水) 10:05:31
組み込みとかでマルチタスキングモニタ書いてた俺から
すると(当然こいつも区別無かったんだが)、Linux 実
装の方がお手軽実装(悪く言えば手抜き)に見える。

それに Linux 側も最近はスレッド≡プロセスの柵から
脱却しつつあるんじゃなかったっけ?
0180名無しさん@お腹いっぱい。2009/12/23(水) 11:33:40
シッタカ煽りの172が逃亡してしまった
0181名無しさん@お腹いっぱい。2009/12/23(水) 13:06:48
SunOSとかのLWP使ったスレッドはどうだったの?
Solaris8までは、M:Nだったと言うことはスレッド≡プロセスではないよね。
0182名無しさん@お腹いっぱい。2009/12/23(水) 15:02:53
Linux だけ特殊だと思えばいいよ。
0183名無しさん@お腹いっぱい。2009/12/23(水) 15:15:35
>>179
脱却しようと思ったけどやっぱプロセス扱いの方が便利だから脱却やーめた
って感じがする。気のせいかもしれないけど。
0184名無しさん@お腹いっぱい。2009/12/23(水) 15:19:22
ん、結局、今はスレッドに軽量性というメリットは
無かったりするの?
0185名無しさん@お腹いっぱい。2009/12/23(水) 16:11:43
あるよ。
カーネル内でプロセスと似た処理していることと、
軽量かどうかは全く関係ない。
0186名無しさん@お腹いっぱい。2009/12/23(水) 17:00:04
>>185
似たような処理をしているなら似たような重さになるんじゃないの?
なんで速く処理できるの?
0187名無しさん@お腹いっぱい。2009/12/23(水) 17:26:12
ぶら下がるリソースが違うから。
rforkを勉強してみたら?
0188名無しさん@お腹いっぱい。2009/12/23(水) 17:39:09
>>187
ありがとう。Linuxではまだ関係ないってことだね。
0189名無しさん@お腹いっぱい。2009/12/23(水) 17:47:46
SMP 対応前後くらいで thread の扱いも大分違うんじゃ
ないかと思うんだけどどうかね? > 識者

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

そう考えると Linux とそれ以外では同じ形態を目指し
ていてもアプローチの仕方が正反対なんじゃないか?
>>183 的なのもそこに理由がある気がする。
0190名無しさん@お腹いっぱい。2009/12/23(水) 17:56:14
>>189
> そう考えると Linux とそれ以外では同じ形態を目指し
> ていてもアプローチの仕方が正反対なんじゃないか?

なにも変らないよ。
0191名無しさん@お腹いっぱい。2009/12/23(水) 18:54:39
>>189
C10K問題 ttp://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem が提唱された
あたりから、複雑怪奇な割に性能が上がらないM:Nモデルから、単純明快な1:1モデル
へと向かうOSが増えたのは確か。

あと、プロセスとスレッドとを同じように扱うか否かはNUMAみたいなアーキテクチャを
どう考えるのかにもよりそう。
0192名無しさん@お腹いっぱい。2009/12/23(水) 19:34:54
>>191
面白いね。

FreeBSD はその後に SMPng の作業を完了しているから
現状を見てみたいけど、それぞれの OS が同期を取って
開発されているわけじゃないからどのタイミングで評価
するかってのは難しい問題だな。
0193名無しさん@お腹いっぱい。2009/12/23(水) 20:01:30
>>191
WebサーバがPC UNIX系の主戦場になったからね。
I/Oセントリックだとカーネルスケジューラが有利。
システムコールの中でスケジュールしたいから。
0194名無しさん@お腹いっぱい。2010/01/05(火) 22:01:20
めちゃくちゃ古い実装ベースの情報ではあるけど、
www.acme.com/software/thttpd/benchmarks.html
の一番下にある表は、結構面白いとこ突いてるいるように見える。
0195名無しさん@お腹いっぱい。2010/01/05(火) 22:26:35
>>194
ほほう・・・
0196名無しさん@お腹いっぱい。2011/01/19(水) 02:40:41
プラズマクラスター効果なしww
http://twitter.com/saramura6/statuses/6688087715352576
0197名無しさん@お腹いっぱい。2011/01/20(木) 19:08:51
node.jsとか、非同期通信寄りが増えてきたな。
0198名無しさん@お腹いっぱい。2011/04/07(木) 03:13:05.15
pthread_createで300前後しかスレッドを吐き出せないのだが・・・。
もちろん、pthread_detachを使ってデタッチしてるんだけど、全く増える気配なし。

Linuxの設定を見てみると、システム全体のスレッド上限が9万、ユーザーが4万5千
お手上げ状態です。
0199名無しさん@お腹いっぱい。2011/04/07(木) 04:00:50.39
アドレス空間が足りないだけ
02001982011/04/07(木) 04:07:26.75
Stackのサイズを変更したら、すんなり3万2千くらいまで行けました。
どうも、お騒がせしました。
0201名無しさん@お腹いっぱい。2011/04/22(金) 21:31:00.83
pthread_mutexで複数のスレッドが待ち状態のとき、起床するのは優先度順ですか?
先に待ち状態になった順から起床させれないですか?
セマフォなら待ち順になるのかな
0202名無しさん@お腹いっぱい。2011/04/26(火) 00:16:55.83
>>201
待ち順にはならぬ・・・ ならぬのだ・・・
0203名無しさん@お腹いっぱい。2011/04/26(火) 11:49:13.33
カーネルさん「順番は俺の都合のいいようにやるから、
順序を規定したければ自分で管理しろよ。
その代わり、マルチCPUになろうがなんだろうが
俺のやることは今と変わらんから安心しろ」
0204名無しさん@お腹いっぱい。2011/04/27(水) 02:10:10.39
カーネル△
0205名無しさん@お腹いっぱい。2011/08/31(水) 08:26:04.18
スレッドの同時実行数って決められない?
同時実行数1にして似非RTOSみたいにしたいんだけど
ちなみに各スレッドはsetschedpolicyでSCHED_FIFOにしてるつもりでエラーは返ってきてない
管理者で実行しているし、sched_priorityは1〜5にしてsetschedparamしてます

なにか手順が足りないでしょうか?
自分でセマフォとかで管理するしかないんでしょうか?
0206名無しさん@お腹いっぱい。2011/09/01(木) 08:57:44.31
うむ、cygwinではpthread_attr系がダミー実装しかされていない
0207名無しさん@お腹いっぱい。2011/09/01(木) 21:12:56.51
>>205
スレッド作ってコルーチン動かせばいい
0208名無しさん@お腹いっぱい。2011/09/09(金) 12:37:20.07
>コルーチン動かせばいい
これって具体的には何をすることをいってるの?
何か簡単な方法があるの?
0209名無しさん@お腹いっぱい。2011/09/12(月) 22:42:44.40
スレッド作った時点でそれってコルーチンだよな
中断再開を管理するスレッドを別に用意しろということか?
0210名無しさん@お腹いっぱい。2011/09/13(火) 00:33:50.94
いえ、こういう文脈でコルーチンといえば、
・エントリポイントが複数ある
・コードで指定した場所で実行停止が可能な
サブルーチンのことです。
「指定した場所」でCPUを明け渡しながら動きます。

0211名無しさん@お腹いっぱい。2011/09/16(金) 18:30:28.02
エントリポイントが複数ある ってどういうこと?
0212名無しさん@お腹いっぱい。2011/09/17(土) 19:37:06.16
哲学者の食事問題を例に取ると、全体で一つのコルーチン。
最初にどの哲学者から食事を開始してもいい。
0213名無しさん@お腹いっぱい。2011/10/18(火) 04:37:25.13
自前でユーザレベルスレッドを作ればできるってことじゃないのかな?

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

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