pthread地獄

Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。

サーバを開発する事になった
↓
select(2)を使うのはイヤだったのでpthreadを使ってみる事にした
↓
OSの選択権があったので、*BSD, Linuxのpthreadの実装を調べてみた
↓
FreeBSD 3.xとOS標準のユーザレベルpthreadを使う事にした
↓
その時一番慣れていた言語だったのでC++を使う事にした
↓
C++の例外処理を本格的に使った事がなかったので、評価を兼ねてﾊﾞﾝﾊﾞﾝ使ってみた

かなり完成に近付いてから、何かおかしい事に気付いた
↓
調べてみた
↓
libgccでpthreadと例外フレームがふしぎなおどりをおどっていた
↓
( ﾟдﾟ) ﾎﾟｶｰﾝ
↓
まぜるな危険
↓
ｶﾞ━━(ﾟДﾟ;)━━ｿ!

そうなん？pthread(3)には何も書いてないな。

libgcc2.c はpthreadを意識してるよなあ…
どの辺みればふしぎなおどりの詳細がわかるの？>1

>>5
まさにそのあたりだった。libgcc_r.aをデッチあげてごまかした。

その後出たFreeBSD 4.xではOS側でlibgcc_rが用意されてたから、解決
してるのかも。

ああ、そういえば昔、C++とpthread絡みで
Mozillaがbrokenでどうのこうのとかいろいろあったような気が…

結論としては「まともなthread使いたかったら商用UNIX使え」だね。
今のFreeBSDでもSMPではいまいちだ。
Solarisマンセー。

>>7
> 結論としては「まともなthread使いたかったら商用UNIX使え」だね。

そうだね。漏れ的に悲しいけどね。

そろそろApache2の足音が聞こえてくるけど、どうしよう。Solaris for
Intelは雲行きが怪しいし、*BSDはまだ先だし。Linuxか?

そもそもpthread自体がいまいちだと思うんだが。
同期にしてもプリミティブな物しかないから、mutex使って自分でちまちま
実装しなきゃいかんし。

http://www.gnu.org/software/pth/
http://oss.software.ibm.com/developer/opensource/pthreads/

この辺早く普及してくれるといいんだけど。

9はpthreadの規格自体がいまいちと思ってるんだよね?

でも、>>9のNGPTって「より良いpthread実装を開発しましょう」という
ブツに見えるんだけど。もちっとドキュメント読めば違いがわかる?

ん? そうだよ > 「より良い〜」
つまり、現状のpthreadだと色々機能も足りないし、結局ベンダ固有機能使う
しかなかったりしていまいちだよなぁって話。

ああ、誤解招く書きかたスマソ。
「より良い〜」は「実装」にかけたつもりで、pthreadの規格自体には
手を加えず性能向上のみ実現するブツ、の意だった。

pthreadの規格自体詳しく知らないんだけど、このNGPTはAPIの拡張まで
やってるって理解でいいの?

>このNGPTはAPIの拡張までやってるって理解でいいの?
うん。pth系の機能については
http://www.gnu.org/software/pth/pth-manual.html#application programming interface (api)
辺りを見るといいかな。

ちなみにpth自体はthreadと言うよりコルーチンとか、win32で言えばfiber
みたいな物なので、システムコール呼ばないで延々計算し続けるような時は
自分でyield()しなきゃいけないってのがナニではあるんだけど。
Event handlingとか、機能面では充実してると思う。

Pth API見たよ。event facility ｲｲ!

昔のソース見たらcondition variableとmutexでセコセコとイベント伝
達機構を自作してたけど、本格的なスレッドプログラミングが必要な時
は標準が欲しいなあ。

IBMの努力でNGPTがLinux標準の座をGET
↓
なし崩し的に他OSもAPI取り入れ
↓
Posix標準化

てなシナリオｷﾎﾞﾝ

FreeBSD 5-current にて実装中の KSE の解説
http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html

おお、こんなにキッチリまとめたページがあったんだ >KSE
漏れ一応FreeBSDで生活してるけど情報収集に熱心でないから知らな
かった。

図解わかりやすそう。そのうち読んでみるよ。Thx!

今日のpthread探訪。pthread規格の一次情報源はこれでいいのかな?

http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+9945%2D1%3A1996

$224は払えんなぁ...
他の売れ筋規格書みたいに$18にならんかな。

忘れないうちにメモしとく。全12ページ。気が向いたら読もっと。

NetBSD Scheduler Activations:

ftp://deas-ftp.harvard.edu/techreports/tr-31-95.ps.gz

間違った。"Scheduler Activations on BSD"だ。>>18

保守sageでLinux関係のメモ。

The Linux clone() project:
http://www.accessone.com/~jql/clone.html

The LinuxThreads library:
http://pauillac.inria.fr/~xleroy/linuxthreads/

2つともobsoletedな臭いがするけど、歴史を辿るきっかけぐらいにはな
るだろう。2年前読んだLinuxのpthreadはソース汚かった。
pthread_cleanup_(pop|push)あたりで激萎えたけど、今はどうなったの
かな?

今年上半期中に*BSDとLinuxのpthread地獄巡りするかもしれない予感。
Apache2がリリースされたら尻に火をつけます。イヤでも。

亡者1さん、応援してます。
簡単でもいいので報告頼みます！

んじゃ、プチ地獄情報。NetBSD-currentのnathanw_sa branchでは
Apache2のコンパイルが通る模様。

亡者21さんはmachいじる人? cthreadって。亡者らしくプチ語りしよう
よ。

>>17
SUSで我慢。

>>22
sigwait は?

>>23
> sigwait は?
まだダミーなんじゃない? "it blew out"って書いてあったからコンパ
イルは通ったと思ってるんだけど。実物見てないから完成度は知らない。

SUSってpthread関係でよく参照されているけど何の略?

最近C系の言語でマルチスレッドプログラミングしてねえなあ。
Javaでおもちゃつくるぐらいしかしてないからなあ。

>>24
SUS は
ttp://www.unix-systems.org/version3/
このへん。

>>25
java は楽でええよね。

Single Unix Specificationか。ありがと。>>23

ヲレは Ruby thread…。DOS でも使える thread なんだい! と強がる。

>>29
RubyのThreadはいいよね。1.0の頃から超ラクチン生活だったよ。

FreeBSD KSE Milestone 3でスレッド動いたよ〜〜ってなお話し。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=98696+0+archive/2002/freebsd-arch/20020203.freebsd-arch
# まだ1プロセッサ上でだけど。

18に出てる奴は、中身を読むと、全然 scheduler activations じゃないので、
見ないほうがいい。書いた人間は、本質を全然分かってないと思われる。
オリジナルの Thomas E. Anderson のペーパーを読んだ方がいい。

>>32
そう言われるとむしろ読みたくなるなあ。
後で読もっと(w

>>31
おお、ありがと。もう動いてるのか。

リンク先のテストプログラムを読んで「makemainthread()とか
startkse()って何じゃその関数名は!」って思ったけど、この人がテス
ト用に作った関数か。それが実装されてるkse_threads_test.cを読んで
みたけど、面白いね。カーネルの外でそういうのいじるのか。

そのまま>>15のKSE解説とかlibpthreadを読みたい気になったけど、ガ
マンガマン。地獄巡りの時に楽しみが残ってないとね。

>>32
オリジナルのURLｷﾎﾞﾝ

>>35

scheduler activations と thomas anderson をキーにして、google で探せば
すぐ見つかるYO。

やっぱりリンク貼りは1の仕事か…
ｸﾞｸﾞｯて参りました。

Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism
http://www.cs.berkeley.edu/~brewer/cs262/Scheduler.pdf

地獄に仏とはまさにこれのこと

>>31
イイ!

FP stateとかほったらかしなのは
テスト用だからかな。
softFPはどーするのかな。
TLSに突っ込むのかな。errnoみたいに。

>>31
なんかnathanw_saのlibpthreadとあんまり変わらないね。
当たり前だけど(w

>>40
あんまり変わらないのは仕組み? それとも開発の進み具合?

仕組。
進み具合は、NetBSDのほうが大分先行してる気がするけど、
FreeBSDの方はちょっと覗いただけなのでよーわかりません。

地獄の底で保守sageメモ。SlashdotでのApache2とpthreadの話題。

Apache Server Nears 2.0:
http://slashdot.org/apache/02/02/20/0028204.shtml?tid=148

この記事を流し読んで拾ったプチ情報たち。

--------
Linux never had this problem, because of the _clone system call,
which makes threads to be seperate processes that share memory.
--------
In addition, ngpth [ibm.com] has been accepted by Linus and they
are very close to 100% compliant as well as providing for M:N
mapping to scale on multiple processors, and to give programmers
choice of kernel or userland threads with standard calls.
--------
A programmer's guide to thread programming on FreeBSD:
http://www.idiom.com/~bko/bsd/freebsd-threads.txt
--------

Linus さんって、むかーし 2level thread なんていらねーYO! とか
言ってなかったっけ。まあいいか。

プロジェクトリーダーが前言を飜せるのはいい事だと思うな。実際の現
場はどうだか知らないけど。

考えてみたらLinus氏の直発言はタネンバウムｾｿｾｲとの喧嘩しか読んだ
事ないや。開発MLでも覗いてみるかな。

>>37
> http://www.cs.berkeley.edu/~brewer/cs262/Scheduler.pdf

ここは"system software"のいい論文集めてあるよね。素晴らしい授業だ。

ただオリジナルの論文は読みにくい、
つーか具体性という意味で読み応えがないから、
翻訳本「Solarisインターナル」を読むのもよい。
Adoptive lockなんかの記述もあるし。

Scheduler Activationて、感覚的には、あるスレッドがread/writeなどの
システムコールでブロックしたら、ＯＳが新しいスレッドを作って、この
プロセスの特定のエントリポイント（たぶんユーザレベルスケジューラの
入り口）をアップコールする、でいいの？

>>47
その時新たに作るか、幾つかあるkernel threadをうまく使い回すかは、
thread API libraryが決める。Scheduler Activationはそのための機構を提供。

SunOSなんかはアドバイス(指定ではない)するAPIがある。
http://www.sun.com/software/white-papers/wp-realtime/wp-realtime.pdf
なんかに軽く触れられている。

>>48

Solaris的には その通りだけど、オリジナルの論文的には、47で正しいよん。

現実の実装では、毎回一から作ると遅くなるので、半分初期化したのをプール
しておくとか、スレッドをジャカジャカ作られるとカーネルのリソース的に厳
しくなるので、制約を設けるとかすることになると思うが、これはどっちかって
いうと実装の詳細に入る話だな。

>>49
> これはどっちかっていうと実装の詳細に入る話だな。

挙動が変わってくるから仕様の範疇じゃん

> 挙動が変わってくるから仕様の範疇じゃん

半分初期化の方は挙動変わってこないっしょ。

スレッド数に制限設ける方は確かに挙動が変わる…というか、それなりの
仕様を設ける必要があるんだが、オリジナルの論文には、そういう話は
載ってなかったと思った (うろ覚え)。
Scheduler Activations にすると何が嬉しいかについては、Vahalia本や
Solaris本を読むよりもオリジナルの論文を読んだ方が分かりやすいと
俺は思うな。

47が Solaris 関係を見てたか、オリジナルの論文を見てたかは不明だけどね。

オリジナルの論文読んで見ます＞ thanks>all
ところで、Solarisでは、ユーザレベルのM:Nスレッドをやめてカーネル
スレッドの方向に行っています。
1:1のlibthreadが用意されているし、これがデフォルトになるという話
もある。

> ところで、Solarisでは、ユーザレベルのM:Nスレッドをやめてカーネル
> スレッドの方向に行っています。

ええ？ ちょっと信じがたい。(ある種の応用だと確実に遅くなるよ)
情報ソース・キボン

> 1:1のlibthreadが用意されているし、

libthread って、pthread の規格が決まる前に作られた UNIX Internatinal
仕様の thread ライブラリだよ。つまり今後の方向ってわけじゃなくて、
むしろ pthread よりも古い。

>>54
solarisのlibpthreadには実装の実体は有りません。pthreadの関数も実際には
libthread内で実装されています。

/usr/libで nm libpthread.so.1　で、定義されている関数のサイズが妙に小
さいのが判ると思います。

また、 ldd libpthread　で、libpthreadがlibthreadにリンク上依存し
ているのがわかると思います。

nm libthread.so.1 で __付きでpthread関連の関数が定義されています。
こっちが本体です。
なんでこんなややこしいことになっているのか、私にはわかりませんが。
（マルチポストみたいになってしまったのはすみませんでした）

私の罪状:
UNIX NETWORK PROGRAMMINGの第2版のIPC篇を読んでしまい、
POSIX IPCとpthreadをふんだんに使うシステムを作ってしまった。
言語はCね。
作りはじめるとき(3年前)から気がついてはいたが、今でも商用系UNIX
(Solaris,AIX等)でしか動かないシステムになってしまってる。
そのうちLiunx,BSDでも動くようになるだろうと思ってけど、3年たっても
だめでした。考えてみると、浅はかだったわけですが、

SMPとかpthreadとかPOSIX IPCとか、大多数のユーザーにとって積極的に
必要性がヒシヒシと感じられない機能とか、
あと、国際化フレームワーク(iconv()もろもろ)
ここらへん、はコミュニティベースじゃインセンティブ働かないから
どうしても開発スピードがでないですね。

ドイツ政府がGnuPGにお金出してるように、国として米国の私企業のclosedな
OS使うしかないというのはやばいと思うので、税金投入して、ハッカー
フルタイム、パートタイムで雇わないとだめそうです。

>>53
そのものズバリの情報ソースがみつからなくてすみません。
Solaris8 (FCS版ですな）の新機能の説明の
http://www.sun.co.jp/solaris/8/whatsnew2.html#performance
の「パフォーマンスおよびスケーラビリティ」の項の「代替Libthread
モデル」というのが、実際には１：１版のスレッドライブラリのことです。

>>53
Solaris8でman libthread してみました。その一部です。
ALTERNATE IMPLEMENTATION
The standard threads implementation is a two-level model in
which user-level threads are multiplexed over possibly fewer
lightweight processes, or LWPs. An LWP is the fundamental
unit of execution that is dispatched to a processor by the
operating system.

The system provides an alternate threads implementation, a
one-level model, in which user-level threads are associated
one-to-one with LWPs. This implementation is simpler than
the standard implementation and may be beneficial to some
multithreaded applications. It provides exactly the same
interfaces, both for POSIX threads and Solaris threads, as
the standard implementation.

To link with the alternate implementation, use the following
runpath (-R) options when linking the program:


POSIX
cc -mt ... -lpthread ... -R /usr/lib/lwp (32-bit)
cc -mt ... -lpthread ... -R /usr/lib/lwp/64 (64-bit)

Solaris
cc -mt ... -R /usr/lib/lwp (32-bit)
cc -mt ... -R /usr/lib/lwp/64 (64-bit)

以下略

これですかねぇ。
http://www.sun.de/Partner/Softwarepartner/Oracle/Technik/pdf/oracle_on_Solaris.pdf

Kernel threadである必要があるのは分かるけど、1:1である必要があるのかな?
それともkernelとのinterfaceが違うのだろうか?

> solarisのlibpthreadには実装の実体は有りません。pthreadの関数も実際には
> libthread内で実装されています。

昔はそうだったのは知ってたけど、これって相変わらずそのままなのか。

> 「代替Libthread モデル」というのが、実際には１：１版のスレッドライブ
> ラリのことです。

なるほど。どうもありがとう。
ふーん、現在の Oracle だと、1:1 mapping の方がパフォーマンス向上に有利
なのかあ。
Oracle の場合マルチスレッドよりも非同期 I/O 主体に作ってあって、スレッ
ドをプロセッサ毎に固定できさえすれば、あとはどうでもいいんじゃないかと
思ってたんだけど、1:1 mapping にした方が良い点ってどこら辺にあるんだろ？

>> これがデフォルトになるという話もある。

この情報のソースはどの辺？
少なくとも I/O じゃなくて計算の方が主体の細かいスレッドを多数発生させ
るような場合は、M:N スレッドの方が間違いなく有利だと思うけど。
ま、両方用意して、アプリケーション開発者が選択できるようにするって
話なら、デフォールトはどちらでもいいかあ。

あ、あと、Solaris の場合 1:1 mapping を使ったとしても、mutex が
spin と sleep の間で自動調整するといった点で、現在の Linux の
pthread の 1:1 mapping とはかなり本質的に性能が違います。
その辺誤解なきよう。＞ Linux 関係者

>>60
Oracleは、
より低レベルな(M:Nはその上に作られているという意味で)libthreadを利用して、
kernel threadを直接controlしている、ってだけの話じゃないのかなあ？

>>54の言うとおりだと思う。

うお、何かいっぱい書き込まれてる!

上の書き込みのおかげでM:N, 1:1, M:1がそれぞれどんなモデルなのか
は分かったんだけど、MとNっていう記号は何に由来してるの? Mがコン
テキストでNが仮想プロセッサ(カーネルスレッド)だよね?

>>56
> そのうちLiunx,BSDでも動くようになるだろうと思ってけど、3年たっても
> だめでした。考えてみると、浅はかだったわけですが、
この辺全く同じ。よい経験しました。

>>62
M とか N とかは
整数という程度の意味かと。

>>62
M:Nは、２レベルスケジューリングで、たとえばM個のユーザスレッドをN個の
カーネルスレッドの上でユーザレベル（ライブラリ）でスケジューリングします。
（通常のカーネルのスケジューラは、この下の階層となり、カーネルスレッド
をスケジューリングします）

1:1は、１レベルスケジューリングで、ユーザスレッド＝カーネルスレッド
（Solarisの場合にはLWP(Light wait process）という）です。ユーザレベルの
スケジューラは有りません。プロセスのスケジューリングと同じくカーネルまかせ
になります。(これでいいよね＞all)

>>60
デフォルトになる、の情報源は、たしかSolaris8 FCSの時のSunの説明会だった
とおもう。僕の周りのだれかが聞きに言って、将来そうなるかもしれない、程度
の説明があったと聞いたような気がします。

>>65
簡潔な解説書き込みありがと。いや、意味はその通りに理解してたんだ
けど、>>64が分かんなかったんだよ。普段数学と無縁なんで。

せっかくなんで検索猿してみた。
http://mathforum.org/dr.math/faq/faq.terms.html によると "the
middle letters, m, n, p... represent the parameters" だそうで。
中学生の頃の俺に見せたかった。

ついでにMathWorldが復活してるの見つけて感激。
http://mathworld.wolfram.com/Ratio.html

スレ違いな話題スマソ。

>>65
>プロセスのスケジューリングと同じくカーネルまかせになります。

まあCPU利用率に基づくpriority schedulerは持ってないんだけど、
schedulingまったくやってないってことはなくて、
lockに伴うCPUのreleaseおよびallocateはやってるよね。
これもschedulerの仕事だから。ないも同然という意見もあるあるでしょうけど。

調べてないからなんとも言えないけど、ユーザスレッドがロック取った
ときにCPUのpinをしているのかなァ？（勉強不足で必然性がわかりません）

すくなくともカーネル内のmutex_enter()/mutex_exit()では、CPUの
pinはしない。だって、割り込み（スケジューラでの最優先度）が入って
割り込みスレッドを動かすときには、割り込まれるスレッドがロックを
もっていようがいまいが、割り込むから。
ただ割り込まれたスレッドがresumeする時には同じＣＰＵで動くようにする仕掛はあるような
ことが「solaris インターナル」に書いてあったと思う（現在、読んでいる
最中）。

ＯＳの中が、こんなんだから、ユーザスレッドがロック持っていても、優先度
が高いスレッドがreadyになれば、そちらが動くはず。（と思う。これ想像）

なお、Solarisには、スレッドの優先度の継承機能があるので、スケジューリング
のpriority inversionの問題は完全に解決されています。

Solarisの話しでなくて申し訳ないですが、
M:NはAIXにもあるこれら↓と同等ですよね？
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365a81.htm

ちょっと気になったのですが、他の商用 UNIX はどうなってるのでしょうか？

Compaq (旧DEC)Tru 64 UNIXもそう。
Tru 64は、thread framwork(バカチョンアプリスケルトン)もあるよ。
MacOSXはkernel threadのみだな。

>>68
68を書き込んだ者です
良く考えてみると、カーネル内のlock（排他制御）の話と、ユーザス
レッドに提供されているのロックの話はレベルが全く異なるので、　
68の書き込みは無視して下さい。

>>56>>63
あの本は麻薬だ！
スチーブンス先生の霊がのりうつってます。

と、言いつつ私は現在DoorRPCを使ったプログラミングをしている・・・。
まぁSolarisで動けばいいんですが。

72に、そんなに高速なIPCが必要なんか。
もしそうなら、全体設計を見直した方がいいと違うんか、
と問い詰めたひ…

使った理由が「単にその方が面白いから」だったなら許そう。
つーか、普通そうだよねえ。(ぉぃ

>>72
たしかに麻薬かも。
3年前翻訳なくて、まともなPOSIX IPCの解説書というとあれぐらいしか
なかった記憶があります。「そのうち翻訳でるだろう」というのだけは、
あたりまえっすけど、それしかあたらなかった。

>>73
今は反省して、RMIになってます。(<-え、反省になってない？)
疎な分散ならSOAPとかもいいんでしょうが、

比較的密な分散システムって、何で書くのがしぇいかいですか？

>>74
>比較的密な分散システムって、何で書くのがしぇいかいですか？
CORBAはどうですか？これならCも逝けますよ。

>>74
Apollo Domain はどうよ。

>>75
分散オブジェクト地獄の予感…

>>74
あの本、訳者も訳者だしねぇ。クソ訳本書いている人は、あの本読んで
反省して欲しいところ。

ってことで、密でも粗でも .NET とかいってみるテスト。

>>75
地獄に足をつっこめといっていますな。

やっぱJavaが一番いい答えだな

>>79
俺みたいな初心者にとっては何するにも楽な言語。それがJava

この間C++でCORBA client作ったんだけど、各ORBで色々こまかーい違いが
多くてうんざりしたよう。minor codeの取得方法くらい統一しとけ。

Javaだったらorg.omg.CORBAパッケージが標準になってるからまだまし
なんだけど(それでもやっぱりORB依存なAPI使わざるを得ない部分もある
けどね)

あとURL忘れたけど、CORBAなMLのアーカイブで、CORBA + pthreadで
メモリリークがーとかはまってる人もいたなぁ(解決したかどうか不明)。

って感じで恐いので、もうC++でCORBAは避けて通りたい今日この頃。

すごい勢いで沈んでるので保守sage。
新ネタないのでリンク集を貼ってみる。

Thread Information: 「POSIX スレッドに関する情報を集めてみました」
ttp://www.media.osaka-cu.ac.jp/~k-abe/PTL/thread-info-ja.html

１さんの意向に反してあげちゃいまーす

ObjectReferenceの登録方法ってバラバラなんだよなーCORBA
ちゃんとプログラムから登録するつーのがお作法なんだろうけどさ。
コマンドで長々と指定したりするのとか
ファイルに書いたのをアップロードしたりするのとか。

忘れたころにこのスレを見るのが
ひそかなたのしみな今日このごろ。
>>1さん頑張って。

>>85
ありがとう。忘れられた頃にがんばるよ。

ageとくよ

Solaris specificな話題でｽﾏｿ．(Solaris8 IA)

http://docs.sun.com/ab2/coll.45.13/MTP/@Ab2PageView/idmatch(GUIDE-78983)
　　So, creating and destroying threads as they are required is usually
　　better than attempting to manage a pool of threads that wait for
　　independent work.
とありますが......
threadの生成・破壊を繰り返すような場合にはunbound threadを
使う方がいいのだろうと思ってたんですが，テストしてみたら
必ずしもそうではないようですね．dual CPUの場合，実時間
／カーネル時間ともにunbound threadが一番かかっているようで．
さらに，unbound threadを使った時にSIGSEGVでコケることもあります．


　　[PIII-900MHz x2]
% time thr 3000
0.04u 0.68s 0:00.75 96.0%
% time thr 3000 bound
0.13u 0.43s 0:00.37 151.3%
% ( setenv LD_LIBRARY_PATH /usr/lib/lwp ; time thr 3000 )
0.02u 0.22s 0:00.23 104.3%
% ( setenv LD_LIBRARY_PATH /usr/lib/lwp ; time thr 3000 bound )
0.03u 0.22s 0:00.23 108.6%　　# まぁこれはあまり意味ないんですが

　　[PIII-550MHz x1]
% time thr 3000
0.08u 1.23s 0:01.33 98.4%
% time thr 3000 bound
0.20u 1.40s 0:01.62 98.7%
% ( setenv LD_LIBRARY_PATH /usr/lib/lwp ; time thr 3000 )
0.10u 0.57s 0:00.71 94.3%
% ( setenv LD_LIBRARY_PATH /usr/lib/lwp ; time thr 3000 bound )
0.09u 0.64s 0:00.80 91.2%

　　[コケた時のcoreのbacktrace]
(gdb) bt
#0 0xdfb89226 in noerror () from /usr/lib/libc.so.1
Cannot access memory at address 0x4e3f0d2c

/* テストプログラム */
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

static size_t nthreads = 0;
static pthread_mutex_t nthreads_mx = PTHREAD_MUTEX_INITIALIZER;

void *
thrfn(void *arg)
{
poll(NULL, 0, 10);
pthread_mutex_lock(&nthreads_mx);
nthreads--;
pthread_mutex_unlock(&nthreads_mx);
return NULL;
}

int
main(int argc, char *const *argv)
{
size_t i, nthr;
pthread_attr_t thrattr;
if (argc < 2) {
fprintf(stderr, "Usage: %s nthreads [bound]\n", *argv);
return -1;
}
if (pthread_attr_init(&thrattr)
|| pthread_attr_setdetachstate(&thrattr, PTHREAD_CREATE_DETACHED)
|| (argc > 2 && !strcmp("bound", argv[2])
&& pthread_attr_setscope(&thrattr, PTHREAD_SCOPE_SYSTEM))) {
perror("pthread_attr_*()");
return 1;
}
nthr = strtoul(argv[1], NULL, 0);
for (i = 0; i < nthr; i++) {
pthread_t thr;
if (pthread_create(&thr, &thrattr, thrfn, NULL)) {
fprintf(stderr, "%s: pthread_create(): %s [i = %lu]\n",
*argv, strerror(errno), (ulong_t)i);
return 2;
}
else {
pthread_mutex_lock(&nthreads_mx);
nthreads++;
pthread_mutex_unlock(&nthreads_mx);
}
}
while (nthreads) poll(NULL, 0, 10);
return 0;
}

apache2.0出ましたねぇ
ベンチの結果とかどんどん出てくるのかな？
Linuxも2.5系のスケジューラはかなり強力そうだし
Solarisと比べてどうなんだろ。

worker MPMってずいぶん変則的という気がするのですが（１プロセスあたりの
スレッド数固定で，プロセス数を増減させる）．
perchild MPMの方が本来のmultithreadingのやり方に近いと思うのですが
（プロセス数固定で，スレッド数を増減させる），
　　This MPM does not currently work on most platforms. Work is ongoing to
　　make it functional.となっているのは，multithreadサポートが完全ではないOSのためで，
worker MPMというのはある意味苦肉の策なのかな？

ああ、とうとうApache2.0出ちゃった。

てなわけで、ちまちまいじり始めました。GNU configure化されてるの
がうれしい。

とりあえずFreeBSDでMPM=preforkにされちゃう件を調べる事にする。

pthread関係はAPRに隠蔽されてるようなのでAPRでのpthreadまわりを嗅
ぎまわる事にした。srclib/aprでconfigure --enable-threadsした結果
を最初の手掛りにする。

Checking for Threads...
checking for pthreads_cflags... -pthread
checking for pthreads_lib...
checking for pthread.h... yes
checking whether pthread_getspecific takes two arguments... no
checking whether pthread_attr_getdetachstate takes one argument... no
checking for pthread_key_delete... yes
checking for pthread_rwlock_init... yes
APR will use threads
checking for readdir in -lc_r... yes
checking for gethostbyname in -lc_r... yes
checking for gethostbyaddr in -lc_r... yes
checking for gethostbyname_r... no
checking for gethostbyaddr_r... yes
checking for sigsuspend... yes
checking for sigwait... yes
checking for poll... yes
checking for getpwnam_r... no
checking for getpwuid_r... no
checking for getgrnam_r... no
checking for getgrgid_r... no

configureの報告でネガティブな事が書いてある箇所を嗅ぎまわってみた。

checking whether pthread_getspecific takes two arguments... no

apr/configure:
pthread_key_t key;
void *tmp;
pthread_getspecific(key,&tmp);

FreeBSD4.5 man:
void *pthread_getspecific(pthread_key_t key);
pthread_getspecific() conforms to ISO/IEC 9945-1:1996 (``POSIX.1'').

結論: 単に呼び出し形式の違い。問題ない
#ifdefで呼び分けている。apr/threadproc/unix/threadpriv.cで確認した。

つづき。

checking whether pthread_attr_getdetachstate takes one argument... no

apr/configure:
pthread_attr_t *attr;
pthread_attr_getdetachstate(attr);

FreeBSD4.5 man:
int pthread_attr_getdetachstate(const pthread_attr_t *attr, int *detachstate);
conform to ISO/IEC 9945-1:1996 (``POSIX.1'')

結論: 単に呼び出し形式の違い。問題ない
#ifdefで呼び分けている。apr/threadproc/unix/thread.cで確認した。

もう一発。

checking for getpwnam_r... no

・getpwnam()のthread safe版getpwnam_r()が標準化されている
SUSv2
int getpwnam_r(const char *nam, struct passwd *pwd, char *buffer, size_t bufsize, struct passwd **result);

・FreeBSDでのgetpwnam_r()の実装状況
- FreeBSD 4.5-RELEASE-p2
getpwnam_r()はlibc_rに存在しない

- FreeBSD-CURRENT (2002/04/10時点)
未実装だが、libc_r/genというディレクトリができているので実装す
るつもりはあるのかも

- MLでの検索結果
Date: Wed, 17 Feb 1999 00:26:13 -0700
> Where are the thread-safe, reentrant versions of this routine in
> FreeBSD 3.1?
Not done yet.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=482572+0+archive/1999/freebsd-hackers/19990214.freebsd-hackers

・FreeBSD4.5のgetpwnam()がreentrantになっていない事を確認した
- libc/gen/getpwent.c
static struct passwd _pw_passwdを使って以下の関数間の値受け渡しをしている
* getpwent()
* __hashpw()

・aprによるthread safe化は行われていない
apr/user/unix/userinfo.c: getpwnam_safe()
#if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && defined(HAVE_GETPWNAM_R)
if (!getpwnam_r(username, pw, pwbuf, PWBUF_SIZE, &pwptr)) {
/* nothing extra to do on success */
#else
if ((pwptr = getpwnam(username)) != NULL) {
memcpy(pw, pwptr, sizeof *pw);
#endif

以下の関数はgetpwnam_r()と同じ扱いだろうと予想してノータッチ。

checking for getpwuid_r... no
checking for getgrnam_r... no
checking for getgrgid_r... no

以下の関数はまた後で。

checking for readdir in -lc_r... yes
checking for gethostbyname in -lc_r... yes
checking for gethostbyaddr in -lc_r... yes
checking for gethostbyname_r... no
checking for gethostbyaddr_r... yes

うーん、今のとこ楽しいなあ。

忘れたころに見に来ました。
あなた〜かわりは〜ないですか〜♪

日ごと〜疲労がつのります〜♪

面白い

勉強になるのでたまにココ覗いております。
頑張って下さい。

ｺｿｰﾘ保守sageメモ。

このスレで話題になったLWPやM:Nスレッドモデルがわかりやすく解説されてます。

LinuxとSolarisの違いを知る：第3回 スレッド・モデル
http://www.idg.co.jp/lw/back/200108/20010824_01_solaris.html

LinuxとSolarisの違いを知る：第4回 スレッド・モデル ─その2─
http://www.idg.co.jp/lw/back/200109/20010924_01_solaris.html

ただ，Solaris9だとuser-level threadをLWPに1:1にboundするスレッドライブラリ
のみになっていますね．Solaris8での"/usr/lib/lwp/libthread.so.1"（代替
スレッドライブラリ）がSolaris9では"/usr/lib/libthread.so.1"になっていて，
"/usr/lib/lwp"配下にはシンボリックリンクが置かれているだけになっています．

性能だしにくいつーのもあったのかな？ < 1:1のみ化

確かに、CPUの個数考えて動かした方がいい結果だったこと多かった。

質問と相談があります。

FreeBSD(4.5-RELEASE)のスレッドについてです。
デフォで使えるpthreadはユーザーランド(1:N)ですよね？
1:1のを使いたいんですが、どうすればいいでしょう。
rfork_threadを見たんですがよくわかりません...

5.0はイロイロ強化されてるっぽいのですが
それまで待ったほうがいいんでしょうか。

自己レスです

freebsd.orgの検索サービスなどで調べてみましたが、
どうもまだスレッド周りはショボイようですね。
スレッドセーフかどうかの検証も不十分らしい。
あとsignalがどうのこうのとか言ってる・・・だめだあ

linux/solaris/win32みたいに気軽に使えると思ってたんで
ガッカリですわ(;´Д`)

関係ない話で申し訳ないのですが、linuxにおいてm:nスレッドを
実現するには、カーネルの書き直しに近い作業をやらないといけないのでしょうか？

>>107
102のリンク先を読もう。

>>107
すくなくとも、カーネルスレッドの管理構造体くらいは修正せんといかんじゃなかか？

Linux は早いとこ clone() を obsolete にせな。

>>110
> Linux は早いとこ clone() を obsolete にせな。

そのあとどうするの?

psしたときにスレッドがボロボロ見えたときに、
なんだかやるせない気持ちになるのはおれだけですか？

それが単純かつパフォーマンスもそれほど悪くないとしても。

solaris で ps -L するとボロボロ出ますね。
つかプロセスがボロボロ見えるのとどう違うの？

よーしパパ NetBSD 用に clone(2) 使ったアプリ書いちゃうぞー

NetBSD SA ぷれぜんてーしょんあげ。

http://web.mit.edu/nathanw/www/usenix/

>>107
NGPT
http://www-124.ibm.com/pthreads/
http://www-124.ibm.com/pthreads/docs/unstable/RELEASE

結論: 君がさらにやる必要はない。

ports/devel/linuxthreads
使えば良いんじゃないの?＞1:1thread
Linux ABIのスレッドライブラリじゃないよ。

次のDP2にはKSE-M3が入るってjulianが言ってたな。
あと、横でnathanのSAなプレゼンテーションを聞いて来たし。
あの人結構切れ者で華奢な感じの人だったな。

最近 pthread を使い始めたのですが、
聞きたい事があります。

スレッドA pthread_mutex_lock
スレッドA pthread_cond_wait
スレッドB pthread_mutex_lock
スレッドB pthread_cond_signal
スレッドB pthread_mutex_unlock
スレッドC pthread_mutex_lock

この時、スレッドCの方が先にロックできてしまう。
pthread_cond_signal を送られたスレッドAって
優先的に動いて、先に mutex をロック出来るわけじゃないんですね・・・
使いものにならない・・・
どのように対処すれば良いでしょうか？

pthread を使わないって言うのは無しで。
OSは、Solarisです。

pthreadの同期機構で、実行権取得の"順序"が保証されるものは存在しないはず。
FIFOな待ち行列作るしかないんじゃあ。

しかし、シグナルされたスレッドが
mutex ロックの待ち行列（たぶんあるんだろ？）の
頭に追加される事が保証されなきゃ
pthread_cond_wait
のパラメータに mutex が何のために
あるのか理解できん・・・。ほんとクソだな。

まあ、クソみたいな機構でも限定的になら使用できるから
あるだけいいのか・・・？

>>120
> pthread_cond_wait
> のパラメータに mutex が何のために
> あるのか理解できん・・・。ほんとクソだな。
教科書読んだら? もしくは自分で簡単なthread機構を実装してみれば理解できるよ。

ｺﾞﾒｿ。ageちゃった。

教科書って何の？
何か学べるものがあるの？
pthread がクソなのは誰もが認める所じゃないのかなぁ？
妥協して、こんな仕様になった、と言う事が言いたかったのかな？
まあ、それならわかるけど。

言いたい事は、>>120 で書いた事をしてくれなきゃ
unlock, wait, lock を一つの関数でする意味がないって事。
自分で一つ一つ関数を呼んでも同じやん。

>>123
俺の教科書には

> unlock, wait, lock を一つの関数でする意味がないって事。
> 自分で一つ一つ関数を呼んでも同じやん。

これがいかに痛い発言であることがきちんと書かれているよ。
やっぱり良書探してきちんと勉強した方が手っ取り早いと思う…

>>124
お返事、ありがとうございます。
現在、SOLARIS インターナルという本で勉強中です。
この本は良書でしょうか？
あと、「俺の教科書」ってやつを教えてください。

あと、勉強には時間がかかると思うので
unlock, wait, lock を一つの関数でする意味を教えて
頂けないでしょうか？
大変気になるので、さわりだけでもお願いします。

あと pthread ではどのようなコーディングが
一般的＆効果的なのでしょうか？
今まで、スレッド＆同期は Windows でしか経験ありません。
どうしても、Windows のイベントを使用したプログラムに
比べると、pthread のそれは、扱いにくくてしかたないのです。

pthreadはthreadプログラミングに本当に必要なプリミティブな機能しか提供しないんで、
その上に便利な機構を作るための基盤と思った方がいいかもしれない。>>9-14も参考に。

プリミティブ故にcondition variableに剥き出しのmutexが必要なわけで。
Windowsはよく知らないけど、原理的に必要なこの辺の操作が隠蔽されてると思われ。

>>125
残念ながら pthread の教科書は知らないんだが(俺は勉強したことないし)、
スティーヴンスの「UNIXネットワークプログラミング第2版」には
そのものずばりの解説があるよ。P.606-609 な。特に P.608

このくらいなら立ち読みでもいけるだろう。

第2版っていうぐらいだったら、ちゃんと Vol.1 なのか、Vol.2 なのか書けYO!ｳﾞｫｹ
で、Vol.1 のほうだな。

R.Stevensの本は買いましょう。ぜったい損しないから。

実行権取得の順番が保証される同期機構ってwindowsにもsolarisにも
ないと思うんだけど・・・

>>126 >>127 >>130

実は、やりたかった事は、Windows の WaitForMultipleObjects
なのですが、とりあえずそれ相当の物が実装できました。

Sun のサイトにも何かあるけど、機能が限定されすぎて
使い物になりませんでした。

別に pthread 実装上の都合とかは興味ないです。

> 実行権取得の順番が保証される同期機構ってwindowsにもsolarisにも
> ないと思うんだけど・・・

ちょっとした言葉の間違いでした。
いいたかった事は、それじゃないんだけどね。

> プリミティブ故にcondition variableに剥き出しのmutexが必要なわけで。

なぜ、剥き出しの mutex が必要なのですか？
自分で勉強しろって？

もう一つ、pthread_cond_timedwait のタイムアウト指定は
何故、目覚まし時計みたいなんでしょう？
nanosleep と同じでええやん・・・

>>131
あなたが、これから改心できるかどうかは
あなた自身の心がけ次第です。

>>131 >>132
氏ね

氏ねやカス

> 実は、やりたかった事は、Windows の WaitForMultipleObjects

ああ、これ欲しいよな。
つかfdとpthread_mutexとsysv ipcが一緒に待てないからunixは糞

>>131
> 別に pthread 実装上の都合とかは興味ないです。

実装上の都合じゃなくて、
"機構を提供し、ポリシーは提供しない"という設計哲学に基づいています。

>>135
> つかfdとpthread_mutexとsysv ipcが一緒に待てないからunixは糞

実装できます。「一緒に待つ」時のポリシーはあなたが自由にコーディングできます。


「俺は『定食』でいいから、フレームワークが欲しいよ!」という意見なら、
わからないでもないです。DCEthread辺りがどのUNIXでも使えるようになればいいのに。

unix板にもこういう困ったチャンが居るのか・・・寒

> 実装できます。

嘘付き。

>>130
>実行権取得の順番が保証される同期機構ってwindowsにもsolarisにも
>ないと思うんだけど・・・

プリミティブの組み合わせで実現できるものは用意しないという奴では。
下手に用意しても使い物にならなかったりするし。

そのおかげで車輪の再発明的ラッパがあちこちで作られてるんだけど、
そのレイヤのプログラミングの練習にはなるだろうね。
生産的行為とは言えないけど。

＞126、131
Windowsでも隠蔽されてねーのでわ？
http://www.mtl.t.u-tokyo.ac.jp/~nminoru/pc/event.txt

>>125
POSIXスレッド プログラミング
David R.Butenhof (ASCII Addison Wesley Series)

>>138
thread 3本でwaitして、どれかがmutex_unlockすればいいだけでしょ?

WaitForMultipleObjectsにしても、kernel内のschedulerまで観察すれば、
同じ(様な)ことをやっているわけだし。

同じ様な事なら、そりゃ簡単。

あまり知らない人の為に説明すると、
Windowsでの同期オブジェクトには、シグナル状態と、非シグナル状態
の二つの状態があります。(ここが pthread との大きな違い)

また、非シグナル状態→シグナル状態にする時、
自動リセットの同期オブジェクト（手動もあります）は、すべての待機スレッドを
開放した後に、シグナル状態→非シグナル状態に戻してくれます。

Inside NTだったかで「シグナル状態になってWaitFor〜の待機が
解けた場合、一時的にそのスレッドの優先度をageる」とか書いて
あったのを今ふと思い出した。

>>137
学生かい？勉強頑張れや。

>thread 3本でwaitして、どれかがmutex_unlockすればいいだけでしょ?

processのwaitでもう一本かな。
確かに糞だ。

> processのwaitでもう一本かな。
> 確かに糞だ。

あと、スレッドの終了を待つスレッドも必要だな。

KSE M3 commit予告age

糞は何本までＯＫでしょうか？

漢なら一本糞。

ちょっとやそっとで流れないうんこをした後は充実感があります。

正直、SOLARISｲｿﾀｰﾅﾙはマルチスレッダーが欲しい情報がありのまま書いてないと思われ
（穴があくほど読んで感覚的にも理屈でも理解できたらコーディングに落とせると思うけど）

はやく徳をためなければ...。

この板なんなの？
学生が多い為か、こんな人ばっかだな。
もっとプログラム組もうぜぇぇぇ！！本ばっか読んでるな！！

>>153
×徳
○便

>>144
「きっとそいつはクリティカルセクションやるんだろうなーやるんだよね？
　うわーうぜーはやくおわらせてしまえ」

と考えて、優先度あげて早くスレッドの処理が終わることを祈願してあげる儀式と思われる。

要はスケジューラーがプロの風俗嬢でスレッドがうざい客と思えばわかるだろうか。
早くイカせて「お客さん早いのね〜はいこれで終了」としたい、と。

>>154 は現場たたきあげ。

pthread 触ったあとに、
WaitForMultipleObjects 使うとなんか感動するね。
イベントを取りこぼす事がないので、安心して使える。
変な小細工いらないし。

pthread 考えた人は、あまりマルチスレッドなプログラム
していないと言うのが良くわかる。
pthread 使うのは何か怖いよ。

取りこぼす?
WaitForMultipleObjectsもソケットが使えりゃな。

え？つかえるけど、、、

でも、WaitForMultipleObjects 使うと一つのスレッドですべて出来るから
マルチスレッドにならないんだよね。
ただ、６４個しか待てないないから、その場合はスレッドを分ける必要があるけど。

>>160
詳細は忘れちゃったんだけど、blockingに関して制限がなかったっけ。

WaitForMultipleObjectsって結局「オブジェクト指向select」だから
pthreadと比較するのはちょっと違う気がする。

それに、pthreadってのはスレッドプログラミングに最低限必要な
APIだけを提供して、その上位層にライブラリやフレームワークを
ユーザが好きなように構築できるってのがいいんじゃない?

pthreadとよく似たスレッドAPIを持つJavaの場合はもっと便利だね。
しこしこイベントキューを自作するのもいいが、
Java Message Service (JMS)ってのを使うと本当に楽。

>>158
pthead生で使わずにNGPT使えばいい。

>>160
ソケットを指定するのは実装依存と聞いたがな。
WSACreateEvent()を使わないとダメだとか。

>>165
実装依存って、どう言う意味？
CreateEvent と WSAEventSelect で普通に使えているよ。

>>166
WSAEventSelect抜きでソケットを直に使うという話。
オレの聞いた話でもWSAEventSelect使えってことだったけど、non-blockingに
なっちゃんだよね、たしか。
WaitForMultipleObjectsのときだけWSAEventSelect使うとかできるのかな。

　　[参考]
Emulation of Win32 API WaitForMultipleObjects() Functionality
Under The Solaris[tm] Operating Environment
http://soldc.sun.com/articles/waitfor_api.html

　　[関連スレ(？)]
マルチスレッドプログラミング相談室
http://pc3.2ch.net/test/read.cgi/tech/997345868/l50

>>167
やっぱ、言っている事わかんないや。
non-blockingになるのは当然では？
ブロックしたくないから WaitForMultipleObjects を使うんだし。
もしかして、何か勘違いしている！？

俺の使い方だけど、
FD_READ と FD_ACCEPT だけ
WSAEventSelect してるよ。

アトミックな値のインクリメント/デクリメントの命令
(Win32でいうところの InterlockedIncrementとか)
って pthread とか posix とかで存在しないんでしょうかね。
イチイチmutex使うのもアホらしいんですが・・・

>>169
いや、たぶんこっちの勘違いだろう。thx

ソケットと非ソケットの同時使用になにか制限があるようなことをどこかで読
んだ気がしたんだが、思い出せんのでまあいいや。

>>170
単一のインストラクションで実行したい、ということなら、
もろCPU依存だからPortableじゃない。よって、"P"OSIXの範囲外。

#if CPUが〜だったら
asm文;
#else
mutexでロック;
増減;
mutexでアンロック;
#endif

>>158 WaitForMultipleObjects 使うとなんか感動するね。
イベントを取りこぼす事がないので、安心して使える。

頻繁にあがるイベントを配列の頭のほうに置いて、頻度の少ないものを後ろの
ほうに置いたら、少ないイベントを捕まえることができなくってる人がいた。

>>172
ありませんか・・・ガックシ
今のところ実行する予定のCPUは限られているので、
それで逃げとくことにしまする。

>>174 こうすれば気分的には少し楽になるかもね(？)

#if CPUが〜だったら
#define InterlockedIncrement(i, dummy) asm文
#else
#define InterlockedIncrement(i, mutex) \
mutexでロック; \
i増減; \
mutexでアンロック
#endif

>>173
バカチョン系API(というかframework)だから、
スケジューラ必要な時は自分で書かないと駄目だろ。
DB journaling engineを書く時のように。

>>176
最初に見付かったイベント以降を全部タイムアウト0でWaitForSingleObjectす
るとかかな?

sscliにInterlocked〜系ありましたわ。あはは。
これかっぱらっとこう。

sscliってなんだろうと思ってぐぐってみた
マイクロソフトのアレか

６４ビットアドレスのソフト環境でのPthreadは、参考書が大抵３２ビット
アドレス環境にもとづいてかかれているので、よくバグをいれてしまう。

>>180
ん、例えば?
stdint.hとかptrdiff_tとかちゃんと使えば、んなことないんじゃないの?

LP64だとsizeof(int)!=sizeof(void*)だからねえ
むしろ旧いunixから抜けきれない人たちが苦労するんじゃないかなあ

>>172
範囲外かどうかは解釈によると思うんだけど。

今の大抵のCPUならアトミックな整数演算命令持ってるし、
もしも使えないならmutex使った実装にしとけばいいじゃん。

どうせ実装のどこかで使ってるから、それを公開すればいい。

int pthread_atomic_inc(int *p);

みたいな感じで。マクロだとしても普通はgetc()みたいに関数の
実装も持たす仕様にするから、使う側としてはどっちでも構わない。

少なくともmutexと同等以上の速度が保証されてればね。

pthread使ってるとアプリ毎にインラインアセンブラなコードを
書いてるのが現状でしょ？それって規格として酷くない？

> 今の大抵のCPUならアトミックな整数演算命令持ってるし、
> もしも使えないならmutex使った実装にしとけばいいじゃん。

だったら_np_にでも実装があるかなあと想像したんだが
今のところ見たことが無い。

需要が無いのか？ いわゆるリファレンスカウンタには必須だと思う
んだが、ねえ。

>>184

みんな自前で実装してるから要らないのかもね。
pthread以外でも、共有メモリ使うアプリならみんな使うのに。

個人的な意見だと、pthreadに足りないものは、

1. 単純なアトミック演算関数
　-> アプリ毎にアセンブリ言語のコード持たなきゃいけないの？

2. Win32みたいなEvent
　-> SemaphoreよりEventの方が使う頻度遥かに高いでしょ？

3. 複数待機の同期機構
　-> 複数の同期オブジェクトの管理が楽になる場合も多いでしょ？

4. FDも待てるポーリング機構
　-> 3に近いけど、あったらいいなって思うこと多いし。

実装がどうのとか言ってるヲタはほっといて、POSIX ThreadsとWin32 Threadsの
どっちが扱いやすいかって言ったら、どう見てもWin32の方が上だと思うよ。

>>183
> 今の大抵のCPUならアトミックな整数演算命令持ってるし、

持ってね─よ、アフォ!

>>185
Win32 thread APIと比べるべきなのは、
pthreadじゃなくてDEC thread(on pthread)辺りだよ? 理解できてる?

>>187
そのDEC threadって、HP-UXやSolarisなんかで(追加ライセンスも無く)
普通に使える物？

実際仕事でマルチスレッドなプログラム作る時って、Unix系だとpthread直で
ごりごり書くか、自分でフレームワーク作るか位しか選択肢ないと思うんだ
けど。俺の認識が甘い？

# あ、もちろんお金がｲﾊﾟｰｲ出せるとか、フリーのスレッドライブラリ使って
# おっけーとかいう場合はまた別ね

この板は田舎モンが多いのか、
win32がイイとか書くと噛み付かれるからやめときー>>185
つか、実用で揉まれないといいものにならないよね。

>>185
なるほど、その辺はたしかに欠けてるね。
そのせいで車輪の再発明的愚行がまかりとおってる(雇用の創出ともいう)
スレタイどおりpthread地獄だねえ...寒

個人的には 3:複数待機 4:FD込みのポーリング に加えて
5: sysv IPCと一緒に待機 も欲しいな。

なんというか、同期APIの存在がthreadを立てる理由になるなんて
馬鹿馬鹿しいにもほどがあるよ。
threadはドメイン(win32用語ならアパートメントか)に縛られるべきなのに。

>>187
2,3,4についてDECのはどう解決してますか？

>>186
確かに大抵って書いたら語弊はあるな。
Sparc、IA-32、Power PCなんかのWS/PC向けCPUね。

それに、SMP出来るCPUだったらアトミック操作命令あるだろうし、
SMPできないCPUだったら、そもそも必要ないじゃん。

>>187
それはpthreadの仕様が足りてないって認めてるのと同じでは？
わざわざOS非依存な規格作ったくせに、使いにくくする意味は何？

>>185の3,4はカーネルの変更も要るから標準規格には含めにくいだろうけど。

>>185
> 1. 単純なアトミック演算関数
> 　-> アプリ毎にアセンブリ言語のコード持たなきゃいけないの？

これはポータブルなセマフォが欲しいって事だと思うんだけど、
pthreadではなくlibcにセマフォAPIがあるよ。俺はアプリケーションレベルで
セマフォが必要になった事がないから使った事ないけど。

>>183=185
sysV IPC って知ってる?

>>192
知ってるよ。

SysV IPCは、pthreadがまともなら殆ど使わなくていいはずだから、
あえて項目には挙げなかっただけ。

共有メモリはmmap、セマフォもpthreadのを使えばいい。
メッセージはAF_LOCALなソケット使えば何とかなるはず。

互換性を考えると、これは結構無茶な意見だとも思うけどね。

SysV IPCはプロセスがコケた時にリソースリークするのが最低。
個人的にはとっととObsoleteにすべきだと思ってる。

>>191
いや、アトミック演算って、アトミック加算みたいなやつのことでしょ。
イベントカウンタモデル(Advance/Read/Await(n))で、
Advance演算を実装するのに便利な奴。

ただ、カウンタが溢れることを考えると、
アトミック加算だけでは実装できないから、
結局pthread_mutexやセマフォが総合商社的解決をするんだけどね。
イベントカウンタなんてセマフォがあれば簡単に実装できるから。

>>193
> SysV IPCはプロセスがコケた時にリソースリークするのが最低。

ただ、SysV IPCセマフォのUNDOはなかなか面白いな。
セマフォリソース自体はリークする可能性があるが、値は戻すことができる。

まあ、SysV IPC全体がもはやobsoleteなのは確かだけど。

>>194
そうだよね。ptherad的にはmutexでOKだった。
アセンブリコード云々で脊髄反射的にセマフォって発想になってしまった。

しかし、ptheradのAPIが貧弱って話ならわかるけど、アセンブリコードは
mutexに抽象化されてるもので十分なような。x86にはlock prefixなんてものがあるけど、
他のプロセッサはatomic inc/decぐらいしか無かったような憶えがある。

Java のスレッドみたいに扱いやすくて理解しやすい簡単なスレッドって
ないかな。あんまり原始的な(pthread 的な)スレッドは使いたくない。

なんつーか、もっとプログラマが楽できる標準のフレームワークが欲しい。

>>196
> 他のプロセッサはatomic inc/decぐらいしか無かったような憶えがある。

今時こんなん持っているのは、組み込み用くらいでしょ?
今はscalabilityを考え、load linked/store conditionalペア持つのが主流。

>>197
Javaのスレッドからpthreadへの置き換えは結構楽ですぞ。

ちょうど1つのオブジェクトに1つのmutexと1つの条件変数が対応してるから、
synchronizedブロック -> pthread_mutex_lock() & pthread_mutex_unlock()
Object#wait() -> pthread_cond_wait()
Object#notify() -> pthread_cond_signal()
Object#notifyAll() -> pthread_cond_broadcast()
Threadクラスの各メソッド -> pthread_*
てな感じの置き換えで大体同じように動くよ。

ただし、mutexが普通はrecursiveでない(あるmutexをロックしているスレッドが
もう一度同じmutexをロックしようとするとデッドロックしてしまう)ってことと、
いろいろ処理が分岐してる場合でも必ずpthread_mutex_unlock()が呼ばれるように
しなきゃならんってことに注意。

でも、Javaの最大の利点であるスレッド対応ライブラリ(JMSとか)の豊富さは
真似できないですな。

Javaみたいに楽したいなら、Javaで書きゃいいじゃん…

Java使わせてくれるんだったらJavaで書きます。

>>199
> ただし、mutexが普通はrecursiveでない

最近はLinuxでさえ、recursive, adoptiveありだけどね〜。

>>201
今まさにpthread地獄?

OpenMP　Fortranがあれば、pthread を使わねばならない理由は特に
ないような気がするが、そこのところどうなんですか、解説をおねがい
します。

>>204
何を書くのだ?
GUI applicationをOpenMP Fortranで書くのか?

質問です。
pthread_mutex_t の初期化に PTHREAD_MUTEX_INITIALIZER
が使えるらしいのですが、"静的" って書いてあるのが気になります。
スタック上に作られた pthread_mutex_t には使っちゃ駄目って事でしょうか？
もしそうなら、なんでなんだろ？
pthread_mutex_init/pthread_mutex_destroy でエラーをチェックするのは面倒・・・

スタック上の構造体に初期化子を与えられる処理系なら問題ないだろ。

pthread_mutex_init()/pthread_mutex_destroy()の戻り値は無視してもよさげ。

PTHREAD_MUTEX_INITIALIZERで構築できるんだから、
動的なリソース取得に失敗することはありえないんだろうし、
破棄に関しても「失敗しましたけど、何か？」な状況が多いと思われ。

Solarisだけど、ソースみると、こうなってた。
#define PTHREAD_MUTEX_INITIALIZER {{0, 0, 0, 0, 0}, {{{0}}}, 0}

mutexクラスを作ろうと思ったんだけど、
下の形式で初期化できないのが、なんだかなぁ。
仕方ない、pthread_mutex_init/pthread_mutex_destroy を使うか。

pthread_mutex_t Mutex(PTHREAD_MUTEX_INITIALIZER);

pthread_once() に渡す関数って、なんでパラメータがないんだ？
グローバル変数を使う事を強制されているな・・・

>>210
というか、まさにグローバル変数の初期化用だからでは？
PTL2だとブロック内部を一度だけ実行する為のpthread_first_np()なんてのを
持ってるようだけど。
http://www.media.osaka-cu.ac.jp/~k-abe/PTL/PTL2/manual_toc.html#TOC14

# 結局便利な機能はみんな_npなんだよな…さすがプリミティブAPI ;-<

>>206
Cの言語仕様の制約上そうならざるを得ない。

>>207の説明でピンと来ないなら、
処理系依存のコードを書く可能性が高いから、
pthreadの仕様の仰せに従うとよい。

> mutexクラスを作ろうと思ったんだけど、
> pthread_mutex_t Mutex(PTHREAD_MUTEX_INITIALIZER);

PTHREAD_MUTEX_INITIALIZERで初期化する場合、
引数なしの呼び出しがC++的でいいのでは? (俺はそうしてる)

GNU CommonC++辺り参考にするとか。

Solaris 9がM:Nスレッドを捨てて1:1スレッドonlyになったのは
結構衝撃的だったのだが、
http://java.sun.com/docs/hotspot/threads/threads.html
http://sdc.sun.co.jp/NASApp/sdcpersonal/private/sdc/newsletter/2002/09/tech_sol01.html
Linuxも同じ道を歩もうとしているのですかねえ。
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0209.2/1075.html

http://www.egroups.co.jp/message/jvm-talk/60
http://www.egroups.co.jp/message/jvm-talk/61

sa_nathawnブランチはどうなるのでしょうか？

>>215
雌伏

良スレ保守sageカキコ

>>214
これって退化じゃないのか...

>>217
最近のようにCPUが高速だとカーネルに出入りする回数を減らすよりも、
スケジューラを一つにしてキャッシュミスを減らすことが効果的らしいです。

また，ユーザレベルで排他制御を行うのはカーネル内でやるよりも
やっかいな事が多くて結局パフォーマンスが出ないようです。

>>218
へぇ。

じゃあ昔のマシンだと Sol9 はかえって遅いのかな。

>>218
それから、Solaris + multi thread用途が、(高いserverでは特に)
Web server中心になっているのも大きいんじゃねぇ?

I/Oが多い応用だと、user空間でscheduler動かす意味が少ないんだよね。
I/O block時にkernel内で、CPUをreleaseすることが圧倒的に多いから。

>>60にも書いてあるけど、
I/Oが少ないprocess内でthreadがmutexを使って排他し合うような応用だと、
(例えば科学技術計算、シミュレーションなど)
M:Nの方が速いような気がするんだけど、どうだろう? 論文出てないかな?

>>220
>> M:Nの方が速いような気がするんだけど
どういう理由で？
60読んでもわからないです。

system callなしで、schedulerが動くわけだから、
「内部割り込み、register待避」がなくて済む。
// もちろんprocess内でCPUの受け渡しが済む場合。

で、最近は218なんだと。

そうかそうか。>>221 読んでやっと分かった。でも技術的には
M:N の方が高度だよなぁ。俺にはやっぱり退化しているようにしか見えない。

>>224
CPU速度とメモリ速度の比率が退化し続けるんだものしょうがないでしょ
技術が高度だとなにか良いことあるん？

>>218の論拠が分からないんだけど、誰か説明してくれる?

一段落目: タスクの内容独立で、キャッシュミスが一番少ないのは、
・ほとんどユーザ空間のみ(I/Oは皆無に近い)
・スケジューラもユーザ空間で動いている。
だと思うんだけど?
余分なスケジューラが必要ないのは、I/Oセントリックなタスクに限られるでしょ?
限られると言っても、Solarisのマーケットの殆んどがWebアプリなので、
I/Oセントリック、だからM:Nスレッドモデルを放棄したんじゃないのかな?

二段落目は分かる。
Signal handling systemはうざいとしか言い様がない。

ちょほいと識者の皆に聞いてみるよ。

スレッド間通信のために、メッセージキューを作ろうと思うのです。
で、そのとき計数セマフォとメッセージ用のバッファを用意して使おうと思
っている。

ここで計数セマフォとして、pthreadの条件変数、POSIXメモリベースセマフ
ォのどっちを使おうかと悩める少年になってるんだよ。

どっちが良いかねぇ?
メリット・デメリットあったら教えてほしいねん。
お願い申し上げます。

>>227
条件変数で良いのでは？
理由は、俺がそうしているから。
特に不便はないし。

>> 226
シングルプロセッサで計算主体のマルチスレッドでは M:N > 1:1
マルチプロセッサで多数のサーバプロセスの場合は M:N < 1:1
まではOKです。では、境界はどの辺りでしょうか？
たとえばmozillaはどっちの方が良いと思いますか？
もう一つ重要なこととして、その境界は将来的にはどちらへ
動くと思いますか？

pthread_spin_xxxx( )で十分な気がするんだが。

すまん、pthread_spin_xxxx( )って、
ADVANCED REALTIME THREADSだったわ。逝ってきます。

>>226の亀レスです。

>>229
パフォーマンスに限れば、
< マルチプロセッサで計算主体のマルチスレッドでは M:N > 1:1
だと思ってるんですが。さらにN:1 > 1:1。

I/Oが絡まない科学計算はほとんどないので、
「計算のみ」がカバーする範囲の広いモデルとは思わないのですけども…

> もう一つ重要なこととして、その境界は将来的にはどちらへ
> 動くと思いますか？

System callのcostを安くする技術が進めば、
パフォーマンスに限ってもどんどん1:1が有利になるでしょうね。

M:Nで設計しているプロジェクトは今ないですね。(少なくとも知らない)
やっぱりM:Nの設計は大変です。スケジューラ一つとっても、
realtimeとかやること一杯あるし、signalや
割り込み可能なsystem callの事を考えると…

>>232
system callが速くなるというより、普通のメモリアクセスがどんどん
遅くなっているというのが現状だと思います。特にマルチプロセッサで
グローバルなデータ(リストやロック変数)を扱うことはますます苦痛に
なってくると思われます。

FreeBSDとかNetBSDがSAやKSEというように、M:Nの改良版の実装を
進めているのですが、なぜ今どきそんな方向にいくのだろう？
と疑問を書いておけばBSD厨がなんか有意義な反論してくれないかと期待。

期待age

>>233
有意義な反論のできる人を「厨」と呼ぶのには違和感があると思われ

232 の最初にあるように計算主体で かつスレッド数＞プロセッサ数 なら、
どう考えても M:N の方が速くなる筈でしょ。そういうアプリケーションで、
かつ I/O bound ではなく CPU bound な科学計算って、それなりにあると
思うけどな。計算主体のアプリケーションで 1:1 の方が速かったとしたら、
そのスレッド・ライブラリの実装に問題があると考えるべきじゃないかな。

Pentium III と Pentium 4 の比較なんかが典型的だけど、ハードウェアの
トレンドとしては、システム・コール呼びだしのような明示的なコンテキ
スト・スイッチは高価になる傾向にあるしね。

SA の場合、ライブラリ側ではsignalや割り込み可能なsystem callに
関するラッパーは要らないので、ライブラリを作る難易度は、1:1 と
それほど変わらないよ。contention が起きてない場合の spin lock の
速度とかだと、M:N が 1:1 の 100倍くらい速くても全然不思議はないと
思うんだけどどう? 関数コールとシステムコールだと、関数コールの
方がこれくらい速いからね。(ちなみに Linux-2.4.20-rc1 と P4 2GHz
で計測。)

計算主体のくせにコンテキストスイッチが多いとしたら、
それがまず間違いだと思われ。

>>237
スレッド沢山作って、生産者&消費者モデルでデータを受け渡すような
プログラム作ると、コンテキストスイッチが増えてしまうだよ。
シミュレーション系では良くあるアプローチだと思うが、どうよ。

良スレsage保守カキコ

1:1 モデルの実装が簡単なのは想像つくけど、なんか無駄が多い気がする。

けど、priority inheritanceをM:Nで実装しろって言われたら泣きたい…
User spaceだけで済むはずが、kernel spaceからもロック依存関係を、
examineする必要がある。逆も…

>>240
> User spaceだけで済むはずが、

　上で軽いと言われている状況では、「User spaceだけで済むはずが」、
　kernel threadの同期も起り得ることを考えると
と補完しておきます。

シンプルな実装のほうが、原理的には劣るものの実際は性能も出やすかったり
するからなあ。とはいえ、せっかく M:N を実装していた Solaris が 1:1 に
戻ったのはちょっと驚きだけど。

>>240,241
SAの場合、カーネル・スレッドが同期待ちになったら、新しい
アクティベーションを用意して、それを使ってユーザーランドに
upcallして教えてやり、あとはユーザーランドのスレッド・
スケジューラが良きに計らうのでは? すなわち、240で心配した
ような状況は、起きえないと思う。

>>242
>>原理的には劣る
これはどこかの仮想計算機においてのお話でつか？

（＾＾）

NetBSD currentにSAを組み込むとかいうメールがcurrentに来てたので記念カキコ

スレ違いだったらすまんのだけど
SysV メッセージのmsgrcv() をpthreadのスレッド内で実行したら
エラーが発生しても errno が 0 のままになってしまう。

スレッドを使わずに実行すると何の問題もないのだけど。


if(msgrcv(id, &buff, size, 0, IPC_NOWAIT) < 0) {
　if(errno == ENOMSG) {
...

っていうあまりにも基本的な使い方しかしてないのに
スレッド内でこれを動かすとダメなのは何がいけないのかわかりませんか？

マルチスレッドなのにグローバル変数で値の受け渡しができることに
疑問をいだかないのだろうか？何かマクロ定義を忘れてはいませんか？

>>248
最近の処理系で、errnoがスレッドセーフになってないようなものが
あるの？

errno.h はなんのためにある？

>>248
もちろん、変だとは思っていたんですが errno はスレッドセーフと
いう記述があったので。

error.h をよく見てみます。

ふつーは#ifdef _REENTとかで、ただのグローバルerrno使うか
MT safeなerrno()使うか切り分けてたりするもんだがな。

pthreadのmanとかにMTでコンパイルする時は-D_REENT=1しろ
みたいな事書いてないのかね？

どうもお騒がせしました。
無事に解決しました。

errno.h を見て疑問が氷解した感じです。

>>253
つーか、マクロ定義だけじゃなくて、ライブラリも、
MT safe版とそうでないのを、コンパイラのオプションで切り替える環境があるから、
error.hだけじゃなくて、コンパイラのマニュアルも読め。
# -pthreadとかね。

環境書けば誰か即答してくれるだろうし。

困ったときは　man　！

http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf

pthread_spinxxxとpthread_mutexxxって何が違うのか判らないですが
mutexのほうがいろいろattrがあるのは除外して。

排他制御という本質的な点では、
先にlockしたもの勝ちであとからlockした人はunlockされるまで待ち
という点では同じな感じなんだけど。

それともblockのされかたが違う
spinは文字通りくるくる回っているだけで
mutexはスケジューラが実行権を渡さないことでblockさせているとか

スレッドの排他はflockfileでやってるんだけど、良くないの？
使うときは、記憶クラスautoで、初期化もなにも要らないし
こればっかし。

extern int tlock_counter;
class Tlock {
public:
　　Tlock() {
　　　　flockfile(stdout);
　　　　++tlock_counter;
　　};
　　~Tlock() {
　　　　--tlock_counter;
　　　　funlockfile(stdout);
　　};
};

NFSマウントだったときどうする気?

>>259
普通関係無いと思うが..
flockfile で flock とかする実装があるの？

>>259
NFSだったら何がまずい？

そういうことやると、全然並列動作しない (stdout に対する単一の
ロックを使っているため、本来並列に動作できる筈のところが、
動作できる部分が封鎖されてしまう。しかも、stdout は出力を伴う
ため、かなり長い間、stdio ライブラリによって封鎖されている
可能性がある) 上に、条件変数との併用もできないんだが、本当に
それでいいのか？ >>258

みんな呆れてツッコんでないのかニャ。

正直、( ﾟдﾟ) ﾎﾟｶｰﾝ

pthread_cond_waitで多数のスレッドにお待ちいただいて、
pthread_cond_broadcastで働かせるという動きの、
単純なサンプルってないかしら。

barrier 関係から調べたらええんでないかい？

>>264
http://www-6.ibm.com/jp/developerworks/linux/010119/j_l-posix3.html
では？

（＾＾）

有難う御座います。

RedHat9で採用されたNPTLって、なかなか良いのかしら。
今まではLinuxでpthreadすると各スレッドにプロセスIDが振られてたけど、
RedHat9で試すとその現象がなくなってました。
よかった おわり

プロセスIDが各スレッドに振られると何か困るの?

>>270
シグナルの通知先に一瞬迷うこと??

うん、シグナルの扱いが本物のpthreadとはまるで違いましたね。

nptlのソース読むとblue threadと書いてあるね。
あの会社はなんでもかんでも青いんだね。

聞きたいじ。

話題のredhat9使っています。
バババッとpthread_creatしまくると、自分を含めて255個作ったところでEAGAIN？エラーです。
この上限、どうやって上げるのでしょうか。

自己レスですみません。
スタックサイズの調整でした。精進して出直してまいります。

（＾＾）

あぼーん

linuxって、シグナルハンドラは、スレッドごとにあるの？
Unix(solaris、HP-UX用)のCで書かれたコードをlinuxに移植中なんだが、
シグナル受信すると、たまにセグフォるって現象が起きてて参ってます。
Linuxの場合どうもシグナルハンドラが複数回呼ばれてるようなんだが。。。

あっ、ちなみに、>>278はRedhat 7.2での話。
今だに、何故RHL7.2かは、上の人の決めた方針なので
仕方がない。

>>278
通常のLinux kernelの場合:
私がグダグダ説明するより、
http://pauillac.inria.fr/~xleroy/linuxthreads/README ←何はともあれこれから
http://pauillac.inria.fr/~xleroy/linuxthreads/
をどうぞ。

NGPT拡張のLinux kernelの場合:
>>116へ。

Solarisの場合:
POSIX realtime extension(1003.1b)のsignal/threadがあるので、
theadを指定してsignalを送ることができる。

あぼーん

>>278
うぉーめちゃめちゃ参考になった。ありがちょう。
linuxってPOSIXのスレッドとは違って、プロセスに対してでなく、
スレッドに対してシグナルを送ることしかできないのね。
nptlやngpt(obsolated?)では違うのだろうが。
なんか苦労しそうだ。Redhat 9にしたい。。。
#話の流れで聞いてしまったが、良く考えると、激しく板違いだったかも

> POSIX realtime extension(1003.1b)のsignal/threadがあるので、

これも知らなかった。やばい？

>>282
やばい

あぼーん

>>282
相当ヤバイ

あぼーん

で結局、UlrichのNPTLて使い物になるの?

>>177
ﾜﾛﾀ

ところではなし変わるけど、携帯ゲーム機"プレイステーションポータブル(PSP)

　久夛良木氏は，“PSPはゲーム業界が待ち望んだ究極の携帯機”として説明。「ここまでやるかと言われるスペックを投入した」という。
　発表によれば「PSP」は，曲面描画エンジン機能を有し，3Dグラフィックでゲームが楽しめる。
7.1chによるサラウンド，E3での発表以来，クリエイターたちにリクエストが高かった無線LANも搭載（802.11）。
MPEG-4（ACV）による美しい動画も楽しめるという。これによりゲーム以外の映画などでのニーズも期待する。
　外部端子で将来，GPSやデジタルチューナーにも接続したいとする。
また，久夛良木氏は，繰り返し「コピープロテクトがしっかりしていること」と力説。会場に集まった開発者たちにアピールしていた。
　さらに，ボタン設定なども明らかにされ，PS同様「○△□×」ボタン，R1・L1，アナログスティックが採用される。

この際、スク・エニもGBAからPSPに乗り換えたらどうでしょう。スク・エニの場合、PSPの方が実力を出しやすいような気がするんですが。
任天堂が携帯ゲーム機で圧倒的なシェアをもってるなら、スク・エニがそれを崩してみるのもおもしろいですし。かつて、PS人気の引き金となったFF７のように。

いきなりこんな事いいだしてすまそ・・・・
GBAと比べてみてどうなんでしょうか？(シェアの事は抜きで)

質問なのですが、一般的に C でスレッドセーフなプログラミング
をするにはどうすればよいのでしょうか。

例えばプログラム内にグローバル変数があれば、これは排他して
アクセスするようにしないと値の一意性を保証できないんですよね。
グローバル以外の普通のローカル変数はスタックに取られるから、
こういうのは排他しなくてもいいんでしょうか。

一般的な話を教えていただければ幸いです。

>>289
> グローバル以外の普通のローカル変数はスタックに取られるから、
> こういうのは排他しなくてもいいんでしょうか。

そのアドレスを他のスレッドに渡さない限りは。

>>289
一般的というのなら「スレッド間で共有する変数、スレッド内でのみ利用する
変数をきちんと分けて管理する」ということになるんじゃないかな。
って、あんまりにも一般的すぎるか。

>>289
漏れの理解では、
各スレッドはそれぞれのコンテキストを持っていて、
とうぜんスタックポインタも別々に持っている。
なので、スタックにとられるローカル変数は、スレッドローカルかつ関数スコープローカルになるから、
排他しなくてもいい、はず。

呼び出された関数内でのローカル変数（へのアクセス）を関数スコープの外へ持ち出すようなのは、
スレッドセーフ以前にCセーフでないから論外だし。

>>291が書いているように、
グローバルかローカルか、ではなく、スレッド間で共有されるかどうか、に注意を払う必要がある。
各スレッドが（自身を含む）各スレッドのコンテキスト／環境を乱さないことが重要で、
「排他」はその手段にすぎないから。

>>292
> 呼び出された関数内でのローカル変数（へのアクセス）を関数スコープの外
> へ持ち出すようなのは、スレッドセーフ以前にCセーフでないから論外だし。

void f(void) {
　char buf[BUFSIZ];
　(void)g(buf);
関連スレッド終了を待つのよ。
} // buf解放

void g(char *p) {
　なんだかんだで、pをpthread_createに渡したり。
}

無茶苦茶セーフなんだが…

あぼーん

あれ、御馬鹿な疑問なんですが、スタック領域も
スレッドで共有してるんですか？今まで共有するときは
無条件でヒープに取ったメモリを共有してたのだけど。

スタック自体は共有してないけど、おなじメモリ空間にあるんだから参照させることは当然できる。

>>293
プププ
ねぇねぇ、ぼく、セーフの分かってまちゅかぁ？

間違ってるのは293じゃなくて292の方だろ。

あるauto変数の生存期間内に、他のスレッドとそのauto変数を
共有するのは、何の問題もないし、その場合は排他する必要が
ある。もちろん、普通は290が書いた条件が成り立つから、排他
しなくて良いことが多いけど、絶対成り立つわけじゃない。

>>293は、g()の暗黙の型宣言を使っている。そこがﾁｮﾄセーフじゃない。

>>298
つーか>>297が一番馬鹿。

8プロセッサのSMPマシンでスレッドを２つ起動して実行した場合は、各スレッドに1つずつで2つのCPUだけが使われると思うのですが、
なぜか8このCPUが少しずつ使われるという結果になってしまいました。一体どうしてでしょうか？

>>293
>>298
あいまいな言葉でしゃしゃり出たのはスマンかった。
またいい加減な言葉づかいになるかもしれんが…。

２段落目は、auto変数へのポインタを返り値にかえしちゃうような、
もっとおバカなケースをイメージしてた。（なので〆で「Cセーフ」なんてﾃｷﾄｰな造語を出してる）

もちろん、
>>293は、
＞関連スレッド終了を待つのよ。
と書いてあるから、漏れの言葉では「コンテキストを壊してない」のでセーフなのは当然。
（この「コンテキスト」の使い方も妥当でない？）

というか、「終了を待つ」場合に、
呼び出された関数g()も、そこからつくられるスレッドも、ｆ（）の「関数スコープ」内にある、
と見なすのは、考え方が間違ってる？　言葉の使い方が間違ってる？

>>298の
＞あるauto変数の生存期間内に、他のスレッドとそのauto変数を
＞共有するのは、何の問題もないし、その場合は排他する必要が
＞ある。
も、そのとおり。

>>289の
＞普通のローカル変数
が、どんな使い方を想定してるのかがよく読めなかったんで。

ちと考え（と経験）が足りんかったみたいね＞漏れ
一般的な話なら、>>290-291で充分だろうから、レスしないほうがよかったか。

すまん、名前入れ忘れ。

scope(有効範囲)は、C言語の規格上、識別子の有効範囲を示す
言葉であり(JIS X3010-1993, 6.1.2.1)、変数の記憶域期間
(storage duration, 6.1.2.4)とは別のもの。
「関数スコープの外に持ち出す」と書いた場合、識別子が
有効な範囲の外に持ち出すという意味になる。すなわち、
関数の戻り値として返す(これは、記憶域期間の外に持ち出す
ことになる)のみならず、単に他の関数に引数としてアドレス
を渡す場合も、「関数スコープの外に持ち出す」という表現に
含まれる。

従って、言葉の使い方が間違ってる。

C言語に限らず、プログラミング言語一般として、単にスコープ
といった場合、lexical scope すなわち識別子の可視性の範囲
を意味すると思うぞ。

すまん、ちょっと間違えた。
lexical scopeだけじゃなく旧式lispみたいにdynamic scope
であってもscopeはscopeだから、

> 単にスコープといった場合、lexical scope すなわち識別子の
> 可視性の範囲を意味する

ここを、
「単にスコープといった場合、識別子の可視性の範囲を意味する」
に訂正する。

>>303-304
解説thx、気をつけます。

>>298
え〜と、スレッド間で共有するんだから気をつけなさいよってことだから、
要は>>291ってこと?

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

Windowsにおいては、main関数内の自動変数の方が、
グローバル変数より安全という噂は本当ですか？

たぶんその文章は正しくないです。

グローバル変数より危険なものってあんまり思い付かんが。

>>308
pthread関係ある話ですか?

FreeBSD 5.2R の TODO で Production-quality M:N threading なんてものが。
あと、Light-weight interrupt threads, context switches なんてものも。
他に Fine-grained network stack locking without Giant とか ATA driver
structural improvements, MPsafety とかもある。

どうでもいいけどＰＳＰとかってぜーんぜん興味わかないんだけどｗ

pipe(2) ってスレッドセーフ？
(対象は Linux, FreeBSD, NetBSD)

なにこのスレ・・・・

>>316
POSIX準拠なスレですが何か？

Solaris8（gccはversion 2.95.3 20010315 (release)）のpthreadを今激しく疑っているのですが、
スレッド関数の中で、fprintfを呼ぶのはやめた方が良いのでしょうか？
１年間普通に動いていたプログラムが、fprintfでcoreを吐いてしまいました。
どなたかpthreadを熟知している方、ご指導よろしくお願いします。

>>318
> スレッド関数の内で、fprintfを呼び出すのはやめた方が良いのでしょうか？

マニュアル読んでMT-Safeかどうか調べなよ。Solaris 9はそう。

> Solarisのpthreadを今激しく疑っているのですが、

その前にマニュアルは読めるのか?

>>319
ありがとうございます。
＞ロケール変更のために setlocale(3C)が呼び出されていない限り、
＞マルチスレッドアプリケーションにおいて printf() および fprintf() 関数を安全に使用できます。
でした。pthreadを使うときは、MT-Safeを要確認なんですね。

>>320
pにかぎらんよ。multi-thread programmingでは常に。

>>321
FreeBSDの場合 man には MT-safeかどうか書いてないようなんだけど、
何かお勧めの情報源ってご存知ありませんか？

>>322
正攻法の答え
・sourceを読め
余計なお節介だが正しい方向
・FreeBSDを使うのをやめろ
ここでやればいいじゃん
・FreeBSDのversionは? 2.2.6とか言ったら死刑

>>322
ソース。
…いや冗談抜きで。


http://www.freebsd.org/projects/c99/index.html
とりあえず↑の中に
> Document thread safety and async-cancel safety.
とか
> Make non thread-safe functions thread-safe.
とかはあるが、どちらも未完。

>>323,234

レスありがとうございます。
version は 4.7 がインストールしてありまつ。

やっぱりソースでつか。(^_^;
pthreadのべんきょしたいだけなんでつが。。。ガムバッテ読んでいきまつ。

>>325
> version は 4.7 がインストールしてありまつ。
> pthreadのべんきょしたいだけなんでつが。。。

pthread標準の勉強には甚だ向かない環境です…
最新のreleaseにするか、LinuxあるいはSolaris for x86へ

http://www.jp.freebsd.org/www.FreeBSD.org/ja/releases/5.0R/relnotes-i386.html
>libc が標準でスレッドセーフになりました。

これは嘘だったのか!? ＿|￣|○

>>322
SUSv3(The Single UNIX Specification Version 3)を
読むといいんじゃないか?
thread-safeかどうかもちゃんと書いてある。
ttp://www.unix-systems.org/version3/online.html

FreeBSDがこれに完全に準拠しているわけじゃないが、
できるだけ近づけようとする努力は行なわれている。
# ただし-currentの追っかけは必須。
ttp://www.freebsd.org/projects/c99/index.html


>>327
嘘じゃないでしょ。
現にlibcの大半の関数がthread-safeなものに置き換えられている。
ただ、basename(3)等、thread-safeでなくて構わないとSUSv3で
宣言されているものについてはほったらかし。

商用UNIXなどでは _REENTRANT 付きでコンパイルされた場合、
自動的にthread-specific dataを利用して
basename(3)等をthread-safeにしてくれる
拡張が入っているものもある。
>>324の
> Make non thread-safe functions thread-safe.
ってのは、そういうことを言っているんじゃないか?

>>328
> # ただし-currentの追っかけは必須。

それはpthread programmingの勉強には不向きだなあ。
自分のプログラミングミスなのか、システムの標準不適合な部分か、
調べないと分からない、ソース読まない限り分からないなんていうのは。

pthread自体の実装の勉強にはいいかも知れないが。

pthreadの勉強に*BSD、これはしばらく待った方がいいよ。

>>329
かといって、Linux-threadはまともなの?
(pthreadの勉強ができる程度に)

>>330
素直にSolaris使えばいいやん。

>>330
FreeBSD 4.7との比較なら圧倒的に。

5.1-Releaseだとどうなんだろう…
MT-Safeなlibrary増えてますか〜?

まともな実装(というか仕様)じゃないと、signal絡むと嫌らしいよね〜。

NetBSDにしなよ

>>332
5.1-RELEASEだとまだまだ。
signalまわりでよくデッドロックしてた。

でも、最近の-currentは非常に(･∀･)ｲｲ!!
5.2-RELEASEは期待度大。

>>334
> signalまわりでよくデッドロックしてた。
> でも、最近の-currentは非常に(･∀･)ｲｲ!!

そっか。
確かに、document読んだだけなんだけど、期待できそうなんだな。

>>333
NetBSDはどうなんですか?
pmpthread以来、userlandは一緒なんじゃないのかな?

Linuxは、kernel threadは一歩進んでいたものの、
ここのところちょっと停滞してるな。

NPTLで落ち着くのは決して悪いことではないような

NetBSD-current の pthread (1.6.x にはない) は、1.2 まで入ってた
pthread とは完全に別物です。設計は格好いいけどまだ安定してない感
じなので勉強には向いてないっぽ。

Linux のは設計はダサダサだけど、使うぶんにはとくに悪い評判はきか
ないような。

>>336
なんやら怪しげと思ってたんだけど、NPTLって
使い物にな(って)るの？

>>337
そう？
今どき 2 level thread もないだろという気もするけど...。
numa とか、どうすんのよ。

1-level だと、どういう点で NUMA のマシンで有利なの？

IBMの連中が 2-level の NGPTを推してたぐらいだから、
2-level でも NUMAで問題なく動くようにできるんじゃないかな。

2-levelにしたからといって、それだけで、
CPU, kernel thread, user threadのbindingが頻繁に変るわけじゃないしね。

2-levelがいやらしいのは、signalがらみでしょ。

>>339
> 今どき 2 level thread もないだろという気もするけど...。

そうか?
KSEはm:n threadの複雑さをうまく整理してて、
結構スジがいいと思うが。
結局チューニングとベンチマークを繰り返した結果待ちって
ところだろうな。

> numa とか、どうすんのよ。

考えなきゃならんことは1:1 threadとあまり変わらないような気が。
とりあえずは、KSEGを各プロセッサに貼りつけられるようにすれば
いいのかな?

NPTLとFreeBSDのlibpthreadのソースを比較したのですが、
ロック変数の数と頻度、コードパスの長さがエラく違いますね。
Solarisがm:n threadから逃げた理由がわかるような気がします。
>>342
チューニングで解決するもんなんでしょか？わからんですけど。

どちらがロック変数の数と頻度が多かったの？

>>343
> NPTLとFreeBSDのlibpthreadのソースを比較したのですが、
> ロック変数の数と頻度、コードパスの長さがエラく違いますね。

そりゃそうだ。
NPTLとFreeBSDのlibpthreadじゃ、実装している機能の量が
全然違うからな。

たとえば、PTHREAD_SCOPE_PROCESSのスレッドに
SCHED_FIFOのスケジュールポリシーを与えてぶん回したりとか、
PTHREAD_PRIO_INHERIT属性を持たせたmutexを使って
優先度の逆転を防いだりとかはNPTLにはできない。
まあ、これらはrealtime threads拡張とされている機能だから、
実装していなくてもPOSIX threadは名乗れるけどね。

> チューニングで解決するもんなんでしょか？わからんですけど。

確かにチューニングだけで解決する問題ではないね。

「世の中の大半のソフトウェアはLinuxをターゲットにしているから、
FreeBSD-libpthreadのPOSIXへの準拠度がいくら高くても
その機能の多くは使われないのではないか。
だとしたら、もっと機能を絞ってパフォーマンスだけを
徹底的に追求したスレッドライブラリを用意して、
そちらをシステム標準にしたらどうだ。」
なんて意見がfreebsd-threads MLに流れたこともあったし。

　結　局　、　政　治　的　問　題　か

HP-UXやSolarisならpthreadはまともなの?
少なくとも日本の水道や電力といったインフラ系の
会社の基盤システムの実装に使っても問題なさげ?

>>347
商用システムが、まともでなくてどうする。
UNIXでは無理にthread使わなくてもいいような気はするが・・

>>347
検証を行って使えると判断したAPIだけ使うのであれば、
ちょっとやそっと変な実装やバグのあるAPIが紛れていた
としても問題無いです。
そういう点においては、FreeBSD4のスレッドでも旧来の
linuxthreadsでも、Windows95/98のスレッドでも同様です。
>>345
ユーザレベルのスケジューラの中にあるロック変数は
m:nのスレッドライブラリの実装の宿命であり、
(Sunの文書によると)Solarisの実装においても性能の
ネックになったと言われています。

>>349
まともなスケジューラを実装する場合は、
カーネルの世界から、ユーザレベルの世界の降りていって、
ロックを解除して(ユーザレベルスケジューラ関連事前事後処理も)、
カーネルの世界に戻ってこなければいけない場合があるからね。

で、I/Oセントリックな場合には結構頻発する。
そもそもI/O自体がカーネル←→ユーザレベルの激しいジョブだから。

pthread の標準的なベンチマークプログラムってないかな?

>>349
> ユーザレベルのスケジューラの中にあるロック変数は
> m:nのスレッドライブラリの実装の宿命であり、
そりゃスケジューラなんだからロック変数があって当然なんだが、
> (Sunの文書によると)Solarisの実装においても性能の
> ネックになったと言われています。
「Solarisの実装において」問題になったからといって
m:nスレッドそのものを否定するのは時期尚早かと。

>>350
???
KSE(もしくはScheduler Activation)を理解してる?

>>352

どう読んでも理解してないでしょ。だめだめ。
そもそも350のような状況はScheduler Activations系の実装では
ありえない。

バスが激速だったり、CPUが少なかったりする場合は
m:nでも見劣りしない性能が出る可能性がありますね。

>>354
> バスが激速だったり、CPUが少なかったりする場合は
> m:nでも見劣りしない性能が出る可能性がありますね。

スケジューラ内において多数のCPU間の同期が問題になるようなら(特にNUMAなど)、
少数のCPUのまとまり毎にスケジューラを持てるようにすればよい。
FreeBSDの実装ならKSEGというレイヤがあるので、これに多少手を加えれば
実現は比較的容易だと思う。

また、1:1モデルとm:nモデルの性能がほぼ同等だとしたら、
スケジューリングの自由度が高いm:nモデルの方が
プログラマにとっては嬉しいだろう。

「少数のCPU」とは1CPUのことですか？
マルチプロセッサシステムでロック変数がCPUのキャッシュ間を
移動するのがどれほど遅いか御存じですか？
CPUが多いシステムではシステムコールやプロセス間の
コンテキストスイッチより遅いんですよ？

>>356
それは1:1でも同じでないの？

>>356
> 「少数のCPU」とは1CPUのことですか？

別に1CPUでなくてもいい。
たとえばHT対応Pentium4のように1つのプロセッサ内に
複数の論理CPUが見えるような場合もあるし。

ユーザレベルでスケジューリングを行なうことの欠点は、
こういうCPUのアーキテクチャに関係する情報が隠蔽されていて、
「CPU時間」という抽象化されたリソースしか利用できないこと。

逆に言えば、>>355のような方法などでこれらのヒントを与えることができれば
あとは1:1モデルとほとんど変わらんってことだ。

>> 別に1CPUでなくてもいい。
そうするとバスコンテンションによって性能が上がらない

>>359
うーん、たとえが悪かったか?

俺が言いたいのは、システム内すべてのCPU間でのメモリの一貫性を
保証するのが高コストであっても、ある少数のCPU間だけでの
メモリの一貫性を保証するだけなら低コストで実現できることもあるってこと。

http://www.atmarkit.co.jp/icd/root/77/44603477.html
たとえば、↑のような構成のマシンがあったとして、
16個すべてのCPUに対して同期を行なう命令を発行するのは高コストだが
1つのモジュール内だけでの同期を保証する命令なら低コストで発行可能だろう。

# HTの場合は、キャッシュを共有した論理CPU間の同期の話に置き換えればいい。

で、そういう低コストで同期が行なえる組合せが存在するのなら、
それらを一つのグループにまとめてスケジューリングの対象に
してもいいだろって言ってるわけ。

>>ある少数のCPU間だけでのメモリの一貫性を保証するだけなら
>>低コストで実現できることもあるってこと。
普通のデータの一貫性についてはそうだとしても、アトミックな変数が
キャッシュ間を移動するのは極めてコストが高いです。

>>360
CPUのグループを指定出来るのは別にかまわないが
使用するメモリもローカルになるよう指定できないと不便な気がする。
カーネル任せでも、たいてい大丈夫だと思うが・

>>361
キャッシュミス自体コスト高いけど、アトミックかどうかはあんまし影響しない

その辺を一般論で話してても不毛なんじゃないの？
個別のハードウェアでどう実装されてるかって泥臭いところを
見ていかないと大して意味のある議論にならない気がするけど。

>>361
ハァ?
「アトミックな変数がキャッシュ間を移動する」って一体どこの言葉よ?
>>356とか>>359とかもあんたの発言だと思うが、
結局あんたが何を言いたいのか、俺には理解できない。

俺が思うに、あんたはLinuxのO(1)スケジューラのような実装を見て
CPU毎にランキューを用意しなければならないと思い込んでいるだけ
だったりしないか?
CPU毎にランキューを持つことにはデメリットも伴うこと
(CPU時間割当量が偏りやすい、リアルタイムスケジューリングに
うまく対応できない等)を忘れちゃいけない。

単なる思い込みで「コストが高い」発言をするんじゃなく、
ベンチマークとかの裏付けをもってきてくれよ。

>>362
> CPUのグループを指定出来るのは別にかまわないが
> 使用するメモリもローカルになるよう指定できないと不便な気がする。
> カーネル任せでも、たいてい大丈夫だと思うが・
>>360のような構造だと、そういうところもユーザレベルから操作できるよね。
たとえば、malloc()の中で現在のスレッドがどのKSEGに属しているか調べて、
KSEG毎に用意されているメモリプールから領域を返してやるというように。

>>364
「変数がキャッシュ間を移動する」はsnoop cacheの説明する時に
普通に言う言葉だと思います。
#364は「アトミックな変数」に引っかかってる？
そして、それが数百クロックを消費すること、キャッシュを増やしても
解決しないこと、大きなシステムでは状況が悪化することは性能を議論する
上で重要ですね。
#x86の2CPUで100クロック程度？

とある資料によると700MHzのPentiumIIIで各操作の時間(ns)
Instruction 0.7 (2命令同時実行)
Clock cycle 1.4
L2 Cache Hit 12.9
Atomic Increment 58.2
cmpxchg atomic increment 107.3
Main memory 162.4
CPU-local lock 163.7
Cache transfer 170.4〜360.9

pthreadで任意のスレッドの終了って待つことできます?

pthread_join以外に?

あ、複数あってどれか一つでも終了したらってことかな?

>>369
それです。

>>365
> #364は「アトミックな変数」に引っかかってる？
Yes.

> そして、それが数百クロックを消費すること、キャッシュを増やしても
> 解決しないこと、大きなシステムでは状況が悪化することは性能を議論する
> 上で重要ですね。
> #x86の2CPUで100クロック程度？

そんなのは百も承知。
で、結局>>355において、少数のCPUのまとまり毎にスケジューラを
持つようにするのと、厳密に一つのCPU毎にスケジューラを持つようにするのとで、
実際にApache2とかを動かした時の性能にどれだけ影響するんだ?
結局、実際にベンチマークをとってみないとわからんでしょ。

俺が、理論上の話だけで可能性を否定されることを嫌っているのには
ちゃんとわけがある。

FreeBSDのlibpthread(libkse)は-DSYSTEM_SCOPE_ONLYを付けて
コンパイルすると、全てのユーザスレッドとKSE, KSEGが
1:1:1に固定され、upcallも行なわれなくなる。
つまり、ユーザレベルでのスケジューリングが全く行なわれない
完全な1:1スレッドライブラリとして振舞うわけだ。

で、この1:1モードと通常のm:nモードとでの性能を比較した
ベンチマーク結果がthreads@FreeBSDメーリングリストに
いくつか流れたりしてるんだが、両者の実行速度に
ほとんど差はみられない。
ユーザレベルのスケジューリングがまるまる削られているにも
かかわらずだ。
# まあ、libpthread自体がまだ開発途中であるから
# 将来的にどうなるかはまだわからんが。

で、スケジューラに求められるのは単純な速度だけではない。
スケジューリングの公平性やリアルタイムなどの拡張への対応とかだ。
俺は、そういう要素も絡めて総合的に判断すべきでは、と言っているんだ。

>>372
brake-handle?

>>373
No.

そうなのか。俺も373と同じ考えだったのだが。
えーと、じゃ takawata?

野暮なインターネットですね。

>>375
別に、おいらが誰だっていいじゃんかよ〜
￣￣￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣
　　　　　　　　　 　∧＿∧
　　　　　　　　　　（ ´Д⊂ヽ
　　　　　　　　　⊂　　　　ノ
　　　　　　　　　　 人　 Ｙ
　　　　　　　　　　し （＿）

そういやBSDconJ 2003のsoda大明神の発表どうだった?
今回も、ちょっと前のJNUG総会も行けなかったんで
何か面白い話があったら報告きぼん。
# 個人的にはNetBSDのSAとFreeBSDのKSEの違いとかに興味あり。

>>378
全体に時間足りず。
その上「スレッドとは..」みたいな話に時間をかけてしまったため
最後の方はとっても駆け足だった。

内容は、
仕組に関しては概略だけ。実装にはほとんど触れず。
ベンチマーク取ってみました。NetBSD速いですね。サイコー。
という感じ。

SMPではどーなのよ、っていう突っ込みはあえて誰も入れず。:)

linuxで動くマルチユーザのサーバでスレッドごとに各ユーザにsetuid(2)
して、ホームディレクトリを読み書きするのがあるんですが、
これって他のOSでは使えないですよね？

>>380

もちろん無理。っていうか、将来は Linux でも無理になる可能性が
あるんじゃないの？ ひどいソフトウェアやな。ちなみに名前は？

forkしろよなー。

>>380
FreeBSDにあるrfork()ってのは、(*BSDはあるんだろうか…)
forkする時に共有するresourceを指定できるはず。
porting、結構簡単なんじゃないかな。むしろLinuxの方が近い将来駄目。

>>383
うーむ…
>The clone() function call appeared in NetBSD 1.6. It is compatible with
>the Linux function call of the same name.

あ、肝心な事書き忘れ。NetBSDではrfork()は無い模様。
(で、そのかわりclone()があるという…)

Linux API互換性持たせたいのはわかるけど、なんでいまさらLinux
コミュニティでも鬼子のように嫌われているclone()なんぞ実装するのだ…。

>>381
iiimf-skkというソフトがそういうことをやっているらしい

>>386
wasabi の仕事で必要だったんでしょ、きっと。

>>386
> Linux API互換性持たせたいのはわかるけど、なんでいまさらLinux
> コミュニティでも鬼子のように嫌われているclone()なんぞ実装するのだ…。
嫌われてるか?
例のNPTLも相変わらずclone(2)べっとりだし、むしろ愛されているのかもしれないよ。

>>387 uidセットできなかったら読み書きしないんじゃなかったかな
むしろそういう小技使わんとsecureにできんiiimfの方が(ry

>>390
小技を使うとsecureになるのか？

>>390

読み書きする仕事を別プロセスに分離するのは可能でしょ？
iiimf一般についてはともかく、この件については、ちゃんと
ポータブルな対処方法もあると思うがどうよ。

/libや/usr/libの下のスレッド対応が進んでるのは、
PC-UNIXではどれになるんでしょうか？

「PC-UNIX」の定義を明確にされたく

>>394
{Free,Net,Open}BSD Linuxの四つです。

Solaris x86も忘れないでー。

Solaris for x86 > Linux > *BSD

UnixWareモナー

WindowsNT > Solaris for x86 > Linux > *BSD

値段の話かい？

MT対応の徹底度でいえば、確かにWindowsは大したもの。なにをやるにも
threadだもんなぁ。

>>401
TerminateThread がクソなのが腹立つ

TerminateThreadなんて使ってる香具師が糞だと思うが。

TerminateThread も、それを使ってる香具師もクソということでファイナルアンサー？

まあ、使える局面では使えばいいとは思うが、
そんなことはほとんどないのが現実だわな。

Threadを外から止めることの危険も知らない香具師は糞決定だが。

TerminateThread のダメさ加減にうんざりしている人は
世の中にたくさんいるようですな。
ttp://diary.imou.to/~AoiMoe/2003.09/late.html#2003.09.29_s02

ダメさ加減もなにも、使っちゃいけないものを勝手に使ってるだけだろ。
ものには使い方ってのものがあるんだよ。アホか。

ただ、TerminateThreadの仕様がかなり疑問なのも事実…

「使っちゃいけないもの」というより「使いものにならない」。
なんのために用意してあるんだか、まったくもって疑問。

スレッドを使うプログラムでは、
【プログラム中のすべてのスレッドは、
常に同じ順序でロックを要求しなければならない】という、
原則があるらしいですが、具体的にどのようにすればいいか、
わかりません。キューとか使って、
自前でスレッド・ロック・マネージャみたいなのを作るんでしょうか？
おまいらのアドヴァイスまってまつ。

>>410
ここのスレの住人は実際にはスレッドなんてろくに使ってないと思われ。
ム板のスレへどうぞ。

>>410
データベースでもスレッドでも同じだけどそれは同期の大原則

でも、都合のいい機構なんて存在しないので大抵自前でロックする順番考えたりする。
簡単なサーバーとかで内部が単純に整理されてるならロックマネージャもどきを作る
こともできるけど構造が変わったら使い回せない。

オブジェクト＆コンポーネント指向とスレッド同期ってすごい相性悪いと思うんだけどどう思う？

>>411
402さん、こんばんは。

mutex

>>412
> オブジェクト＆コンポーネント指向とスレッド同期ってすごい相性悪いと思うんだけどどう思う？

そうか? むしろ相性はいいと思うがね。

Active Objectとか非同期メッセージとかを使って設計すれば
スレッドを生で扱うより格段に楽だし、コンポーネントの使い回しも
やりやすい。

>>415
デッドロック防止の話では？

JavaとかOOPの世界は、細分化していくのは得意だけど、
ふと全体としてどう動作するのか知りたいとなると、
なにも分からなくなってることが多いような気がする。

>>416
> デッドロック防止の話では？

ん? デッドロック防止にも役にたつよ。
そりゃ、Passice Objectと同期メッセージしか使わなかったら
地獄が待っているが…

> JavaとかOOPの世界は、細分化していくのは得意だけど、
> ふと全体としてどう動作するのか知りたいとなると、
> なにも分からなくなってることが多いような気がする。

全く逆でしょ。
実装の詳細を隠蔽し、抽象化することによって
全体としての見通しを良くしていこうってのがOOなんだから。

単純に分割統治できる場合はそうだけど、
相互に関連して呼び合う場合なんかは全体の流れを把握するのがかえって難しい。

× 全体としての見通しを良くしていこうってのが
○ 一度に考えるものの量を減らそうってのが

だと思うが。

スレッドに絡めて話すならいいけど、OO宗教論争やるならム板に逝ってね。

>>403
クソだから使ってませんが何か？

>>420
ひとつ上の書き込みすら読めないのか？

>>415
面倒臭いことを全部メインスレッドにやらせてしまって、
他のスレッドは単機能の実現に徹するなら、OOともうまく
やっていけるとは思う。でもそれってスレッドの有難味を
半減させている気もするよなあ。

>>422
リアルタイムOOの世界はそんな浅いもんじゃない。
とりあえず↓ここらへんの本を読んでみれば?
ttp://www.amazon.co.jp/exec/obidos/ASIN/4881359797/
ttp://www.cqpub.co.jp/hanbai/books/33/33231.htm

# これ以上はさすがにthread違いの話題だろうから、続けるならム板へ。

既存のリソースに目を向けないで
独自に作ろうとする発想が既にOO的にﾀﾞﾒな感じ

スレッドプログラミングもろくにしたことない香具師が
何を偉そうに

正直ｽﾏﾝｶｯﾀ

TerminateThread, TerminateProcess辺りって、kill -KILLみたいな存在
なんだから普通は使わん(使えない)だろ。(DLL_THREAD_DETACHとか
DLL_PROCESS_DETACHでcleanupなんてやってたりすると…)

まぁ確かにkill()やpthread_kill()みたいのはあると便利ではあるんだけど、
「いきなり割り込まれる」「シグナルハンドラを実行するのは誰か」という
のをちゃんと意識してないとハマるポイントになりがちだしねぇ。

その辺何も考えてなさそーな周りの連中見てると「まぁ無くてもいっか」
と思ったりする今日この頃。(Win32でもkill -INT相当は使えるけどね)

mutexが他スレッドにロックされてるのか自スレッドがロックしてるのか
区別する便利な方法はありませんか?recursiveなmutexだけだとちょっと
役不足です。

ロックしてるスレッドが何かを区別してい時ってどんな時よ。
それは設計おかしいヲカン。

腐ったフレームワークからのコールバックの実装にどうしても必要で。
>>429

mutexをlockした後にpthread_tの変数に自スレを代入するのじゃダメ?

>>431
その変数の初期値に困らないか?

やりようはあると思うが。

どんな?

スレッドのＩＤを芋ズル式に書き込んじゃだめ？

pthread_tの実体って、システムによってunsigned longだったり
単なるポインタだったりと、まちまちだからなあ。

どんなスレッドの値とも一致しない PTHREAD_NULL みたいな
マクロをPOSIXで定義してくれればよかったのに。

unlockすればいいんぢゃねーか?

ダミーのスレッド作っておくとか？

boolな変数を一つつけて有意な値が入っているか判定すればいーんじゃねーの。

-pthread

-lpthread

>>436
0にならないっていう保証なかったっけ...

ｽﾚｯﾄﾞを作った後sigwait()でＳＩＧＵＳＲ２シグナルキャッチを契機にｽﾚｯﾄﾞをｼﾞｮｲﾝしようとしたんですが、シグナルキャッチできませんでした。なぜですか？赤帽7.3でにゅ。教えてこの世でｲﾁﾊﾞﾝｴﾛｲ人。

sigunaruとsureddoは注意して扱わないと大変なことになる。マスクとか。

ｳｦ　ＪＭ見たら、ｼｸﾞﾅﾙを受けたいｽﾚｰﾄ以外全部そのｼｸﾞﾅﾙをﾌﾞﾛーｸしなければ確実にｷｬｯﾁできなイっぽいことが書いてある。ﾘﾅｸｽｽﾚｯﾄﾞってＬＷﾌﾟﾛｾｽだからﾋﾟｰｽﾚｯﾄﾞｷﾙではﾌﾟﾛｾｽに対して（ＰＩＤで）ｼｸﾞﾅﾙ送ってるのかとｵﾓﾃﾀｰﾖ。違ったのか。。　thxｴﾛｯﾁ！ﾀﾒｼﾃﾐﾏｽ。

pthread ----- 天国 ------ pushed .

>>445
その辺、kernelのversionで変わるので気をつけて。

>>445
そろそろNPTL使おうよ

linux使いとしては、旧linuxthreadsやthreadごとのsetuidの
ような汚点は恥ずかしいから触れないで欲しいと感じます。
nptl使ってあげてください>>445

そういえばNGPTはどうなるのかな?
http://www-124.ibm.com/pthreads/
ではperformance,scalabilityが向上したった書いてあるけど、
ベンチマークの結果どこかにありますかね。

Linux板に行く話な気もするが、
>>450
NGPTはメンテナンスモードに移行する、ってアナウンスでてたよな。
ML archiveあさったらいろいろ議論の残骸が見えるけど、結局
glibcの絶対君主なUlrich Drepperサマ御製のNPTLと闘ってNGPTをぶっこめそうもない
やーめた、ってことのようで。
(性能の議論を仕掛ける気配もなく「あー、どうせDrepperサマだからムダムダ」って感じで)

ところで、LinuxThreadsを外してNGPTを入れて、しかる後にgccをコンパイルするとlibioのコンパイルでエラーがおきて
libstdc++が作れなかったりしねえ？

NPTL age

>>452
板違いではないか？

他の実装との比較とかならいいんじゃねーの

NPTLの実装以外になんかあったっけ？
NGPL？

他のOSとの比較とか、あとシングルCPUの場合ならユーザーレベルスレッド
ライブラリとの比較もできるね。

>>455
> NPTLの実装以外になんかあったっけ？
> NGPL？
NGPTですな。
ttp://www-124.ibm.com/pthreads/

といっても、もう終わっちまったプロジェクトだけど。
ttp://www-124.ibm.com/pthreads/docs/announcement

>>454
確かに。興味ある。
各ＯＳごとのthread実装状況を知りたいね。

このスレ的にはどういう基準で(どういうベンチマークで)比較するのが良いの?
上で議論されてたFreeBSDのスレッド実装の話も面白げなんだけど。

各Unixごとのthread実装解説書なんて本が出たら、
開発者とかには売れそうな感じだが。

だが、商用Unixは内部非公開だからなぁ。
実現性ないよね。

SunOSは(限定的だけど)公開してる。

http://www.amazon.co.jp/exec/obidos/ASIN/0132075563/249-7688813-0268363
これももう最新からはだいぶ置いて行かれてるだろうしな…

邦訳「UNIXカーネルの魔法」か。これ、そんなにpthreadについて書いてたかな…

Solaris なら、これでしょ。そこそこ新しい。内容も楽しい。
ttp://www.pearsoned.co.jp/washo/unix/wa_uni19-j.html

翻訳版が2001年つー事はSolaris7辺り？

そう。Solaris 7 まで。
スレッド関係とか、vnode cache の扱いとか Solaris 8
以降でかなり変わったんだけど、まあこれらについては、
Web でも多少資料あるから…

>>466web の多少ある資料の url きぼん

http://developers.sun.com/solaris/articles/alt_thread_lib.html
辺りから辿ってはどうか?

沢山CPUついてるマシンで、あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
読めることはなんかの規格で保証されていますか？
教えてください。

Solarisを主に使っています。

アーキテクチャによる。ccNUMAだとかその辺。

>>469
volatile 宣言してある変数のこと？

>>470
> アーキテクチャによる。ccNUMAだとかその辺。
ありがとうございます。

えと、ccNUMAについてはいまから調べてみようと思いますが、
要するにpthreadを使う場合、

>>あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
>>読めることはなんかの規格で保証されていますか？

保証されていない、でFAでしょうか?

CPUローカルのキャッシュをフラッシュする関数とか、pthreadには
ありませんよねえ?

>>472
SMPとかccNUMAマシンではH/Wが勝手に同期してくれるという意味では。
ccってcache coherentの略だろう。

# あとは>>470にお任せ ﾉｼ

>>472
threadの発想は１つのアドレススペースに複数のコンテキストだから、
スレッド間で自由に変数が共有できないのなら１つのアドレス空間に
する意味ないわな。
何がしたいんだ？

>>474
ちゃんと共有されることが規格等で保証されているか知りたいのです。

>>472
UNIX(POSIX準拠)が動いているマシンが、そういう（同期が保証されない）アーキテクチャな例ってあるの？？

>>471
> volatile 宣言してある変数のこと？
レジスタは関係ないとｵﾓﾜﾚﾒ

メモリ番地Xには値0が入ってる
スレッドAがXに1をカキコした
次いでスレッドBがXを読み込んだとき、1であるためには、
AやBは何をすればよいか

という話か？

>>469
> 沢山CPUついてるマシンで、あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
> 読めることはなんかの規格で保証されていますか？

POSIX仕様に書いてある。
ttp://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_10

> CPUローカルのキャッシュをフラッシュする関数とか、pthreadには
> ありませんよねえ?

POSIXにはキャッシュをフラッシュするだけの関数とかは無い。

ただ、一般的に言って「CPUローカルのキャッシュをフラッシュ」できれば
それでいいってもんでもない。
メインメモリへの書き出し操作をOut of Orderで実行するようなプロセッサの場合、
カレントスレッドが動作しているCPUキャッシュだけをフラッシュしても
他のスレッドが書き換えたメモリを正しい順序で読み出すことは保証できない。

だからといって全てのCPUのキャッシュをいちいちフラッシュするわけにもいかんので、
最近のプロセッサには大抵「Memory Fence命令」みたいなものが用意されている。

>>478
> メモリ番地Xには値0が入ってる
> スレッドAがXに1をカキコした
> 次いでスレッドBがXを読み込んだとき、1であるためには、
> AやBは何をすればよいか

です！

>>479
ありがとうございます。読みました。

> > 沢山CPUついてるマシンで、あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
> > 読めることはなんかの規格で保証されていますか？
>
> POSIX仕様に書いてある。
> ttp://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_10

ここにリストされているような関数を使って変数の同時更新・参照を回避すれば、マシンのアーキテクチャがなんで
あろうと(NUMAでも?)、

>メモリ番地Xには値0が入ってる
>スレッドAがXに1をカキコした
>次いでスレッドBがXを読み込んだとき、1である

が保証されるということですよね？
# 後半については御意。

>>481
> ここにリストされているような関数を使って変数の同時更新・参照を回避すれば、マシンのアーキテクチャがなんで
> あろうと(NUMAでも?)、
>
> >メモリ番地Xには値0が入ってる
> >スレッドAがXに1をカキコした
> >次いでスレッドBがXを読み込んだとき、1である
>
> が保証されるということですよね？

そういうこと。

# もちろん、POSIX準拠の環境である、って大前提の上での話だけど。

NUMAでpthreadに準拠したマルチスレッドライブラリを持っている
OSってあるの？

>>483
IRIX とか AIX とか NUMA でも posix pthread じゃなかったけ?

posix pthread
頭痛が痛い
馬から落馬

>>484
ccNUMAじゃなくてNUMAなの？

>>486
今時, そこそこの規模で cache coherent でない NUMA があったら教えてほしい.

>>485
> posix pthread
すまん orz

>>487
単にNUMAといえばccNUMAのことだということ？

じゃぁ質問を変えるが、
non-cc な NUMAのアーキテクチャに規格準拠のpthreadが実装されている例はあるの？

-D_POSIX_PTHREAD_SEMANTICS
-D_ACHE_HEADACHE_SEMANTICS

いま490がいいことを言った。

>>489
> non-cc な NUMAのアーキテクチャに規格準拠のpthreadが実装されている例はあるの？
pthread 規格が出てきた時点で, 現役で動いていた
non-cc な NUMA マシンの存在をしらんのだわ...
少なくともおいら的には.

>>492
ｻﾝｽｺ.

なんかNUMAの話題になってるけど、
>>469がNUMAでない環境に１００００マルク

>>494
どうなんでしょう。Sun Fire 4xxxになるとおもいますが。

少なくとも>>469さんは、NUMAを知ってなかった。

じゃぁ最終の質問を
> non-cc なアーキテクチャに規格準拠のpthreadが実装されている例はあるの？
に変更した上でだれか答えてあげればﾖﾛｼ

だれからも返答なしかよagege

Linuxのthreadで質問があります。
現在、稼働しているLinux boxがnptlに対応しているかどうかというのを
調べるためにはどうしたらいいでしょうか？
例えば誰かが構築したLinuxでLFSとかで構築されていた場合とかです。
ようするにディストロのパッケージを調べずに、そのシステムがnptl対応かどうか知る方法です。

>>499
Linuxの事はよく知らないけどobjdump -pとか-Tとかで調べられない?

>>499
スレッド使うプログラムを書いて、プロセスとして見えるか確認する。

>>499
pthreadというよりはLinux固有の問題なので、Linux板の方が的確な答がもらえそう

http://pc5.2ch.net/test/read.cgi/tech/1037636153/834n-
誰かpthreadネタで参戦汁

荒れてきた

linuxでスレッドを使用したプログラムを作ってるんですが、
root権限無しで、各スレッドの優先度を変えることってできないんですか？

Pth とかのスレッドライブラリって， read, select なんかを wrap してるけど，
ヘッダファイルのインクルード順序って気にすべき?
あと，陽に Pth の関数を使っていないソースファイルでも，
マルチスレッドで実行される可能性があって，かつselectなんかのシステム
コールを呼び出している部分のあるソースファイルでは pthread.h を
インクルードしておかなければいけないという認識は正しい?

wrapというのがsymbolの置き換えだったら、
libpthreadがlibcよりも先にリンクされるようにすれば
いいんじゃなかろうか

実はよく知らない

>>507
Pth の pthread.h を見ると，
#define select __pthread_select
みたいなのがズラーっと並んでる．これってかなりデンジャラスな感じが．

別に。

GD-2.0.33を./configureしてmakeする際、
エラーがずらーっとでるのだが、これもpthreadのせいなのかな・・・？

うわさでは、-lpthreadがなんたらかんたらとかだけど、わけがわからない。。。

>>510
消えろ

　 　　　　./　　　　　　 ;ヽ　
　　　　　 l　　＿,,,,,,,,＿,;;;;i　 ＜いいぞ　pthread！
　　　　　 l l''|~___;;､_y__ lﾐ;l　 バグを出す奴はプログラマだ！！
　　　　　 ﾞl;| | `'",;_,i`'"|;i |　 バグを出さない奴はよく訓練されたプログラマだ！！
　　　　 ,r''i ヽ, '~rーj`c=/　
　　 ,／　 ヽ　 ヽ`ｰ"/::　`ヽ
　 /　　　　 ﾞヽ　 ￣､:::::　　ﾞl,　ホント pthreadは地獄だぜ！ フゥハハハーハァー
　|;/"⌒ヽ,　　＼　　ヽ:　　 _l＿　　　　　　　　ri　　　　　　　　　　　　　　　　　　　ri
　l l　　　　ヽr‐─ヽ＿|_⊂////;`ゞ--―─-r| |　　　　　　　　　　　　　　　　　　 / |
　ﾞlﾞl,　　　　 l,|｀ﾞﾞﾞ''―ll＿__l,,l,|,iﾉ二二二二│｀""""""""""""|二;;二二;;二二二i≡二三三l
　| ヽ　　　　 ヽ　　　_|＿　　＿　　　　　　　"l￣￣￣￣￣￣ |二;;二二;;二='''''''''''￣ﾉ
　/"ヽ　　　　 'j＿／ヽヽ,￣ ,,,/"''''''''''''⊃r‐l'二二二T￣￣￣　　［iﾞ''''''''''''''''"ﾞﾞﾞ￣`"
／　　ヽ　　　　ー──''''''""(;;)　　 ｀ﾞ,j"　　|　 |　|

>>512
つまらん。

>>512
ハートマン先任軍曹最高だよな。

>>513
ナチュラルスレストッパーの513乙。

結局、FreeBSDもM:Nスレッドを捨てるのか……

このスレで暴れてたBSD厨はどう反応するんでしょうな。

>>515 とりあえずソースきぼん。

まともなM:Nを持っていながら、捨てた所ってないんじゃないの?
Solarisみたいにdefaultのlibraryを変えたところはあるけれど

あ、「M:Nスレッドを捨てる」ってのは言いすぎだったかも。
でもデフォルトが1:1スレッドとなり、Solarisと同じ道を歩むことになりそうだ。

>>518 やはりソースきぼん。MLのスレッドのURLとか。

M:Nがまともに動いたなら、Solarisはデフォルトを1:1に変えなかったんじゃないか?

>>520
又その話か。
まともに動いていたけど、
webサーバ等ではI/O主体なので、ユーザ空間でthreadを切り替えるメリットが少ない。
Solarisはサーバに使われることが多いから、1:1をディフォールトにした。
「サーバの速度面で」とはっきり言っていた。

FreeBSDも市場が似通っているけど、
FreeBSDは、library整備も大変なんじゃないかな。
I/O廻り、signal廻りとやることが結構あるから。
Javaが絡んでくるとさらに大変だけど、*BSDはJava遅れているしね。

>>521
> FreeBSDも市場が似通っているけど、
> FreeBSDは、library整備も大変なんじゃないかな。
> I/O廻り、signal廻りとやることが結構あるから。

いや、実装は既に出来てるよ。
現にApache2やMySQL等が動いてるし。
# まだパフォーマンス改善の余地はあるけど。

> Javaが絡んでくるとさらに大変だけど、*BSDはJava遅れているしね。

FreeBSDでのJavaの遅れは、金銭的&政治的な問題じゃないの?

少なくともスレッド周りでは、Alexey Zelkinが
> I have implemented pthread_attr_get_np() function which exported
> all required information on application level
と言ってて、garbage collectorのようなpthread APIだけじゃ扱い切れない
部分についても解決しているはず。
ttp://lists.freebsd.org/mailman/htdig/freebsd-java/2004-February/001653.html

> 現にApache2やMySQL等が動いてるし。

2chでは、apacheのマルチスレッド型MPMがまともに動かなくて
苦労しているようですが。

>>523
それは、動かすアプリケーションがマルチスレッド対応していないのが問題で、
スレッドライブラリとは無関係。

UNIX上のapacheのMPMのデフォルトはpreforkだと思うが、MTで動かす理由ってなんだ?

FreeBSD 5.3RにおいてApacheがWORKERで動作不安定なのはよく知られていることで。
一般論でひきあいに使える話ではない。

>>523
> >>523
> それは、動かすアプリケーションがマルチスレッド対応していないのが問題で、
> スレッドライブラリとは無関係。

Apache2が動いているとおっしゃるから、指摘したのですが。

>>526 とりあえずソースきぼん。

あ、FreeBSDのスレッド対応について云々言っている訳じゃないですよ。

FreeBSD+apache2は「まともには」動かない、
apache2自体はマルチスレッドで動いている、というだけです。

>>525
一番の理由は、資源の節約。
mod_perl等の巨大なmoduleを組み込むと、一つのプロセスが肥大化してメモリを圧迫するし
mod_cacheや独自モジュールも含め、キャッシュとして持てる量が大幅に増やせる。

>>530
たぶんworkerにそういうメリットは(ほとんど)ないと思うんだけど、実際に測ってみた?

>529
>FreeBSD+apache2は「まともには」動かない

文脈からするとworkerでは動かない。preforkの話はしていないということだろうけど。
とりあえずこのpc5.2ch.netはFreeBSD 5.3R+Apache2 preforkでちゃんと動作しているよ。

揚げ足取りばっかだね。
はいはい、俺が悪かったよ。

つまり、
「FreeBSDの実装が絶対正しい。互換性のないsolarisやlinuxは糞」
「apacheのマルチスレッド対応など無意味。滑稽この上ないし、対応する必要など無い」
ということですね。

http://www.newsforge.com/article.pl?sid=04/12/22/1954233
> POSIX threads are really the only thread game in town these days.

μITRONの世界から来た自分も使いにくいと思う。別の標準APIが欲しいね。

>>535
> μITRONの世界から来た自分も使いにくいと思う。別の標準APIが欲しいね。

ある意味, 日本では uITRON がデファクトな部分があるみたいだから,
作ればいいじゃん.
pthread の枠組みあれば, どんな排他/同期機構でも上に載っけられ
るっしょ?
おいらは, pthread 上に uITRON 互換のライブラリ作って, 実機ができ
るまでのデバッグ用に使っているが...

で、結局>>515,518の真偽についてはどうなんだ?

本人に聞いてくれ。

M:Nが複雑な上に通常のアプリケーションで性能がでなければ、路線変更はありそうな話ではある。

>>534
そんなキモいBSD厨はもうさすがに淘汰されたろ

ただ、一連の流れの中では FreeBSD で Apache2 のマルチスレッド MPM がまともに動かないのは
Apache 側に問題があるからだ、と言わんばかりの人もいるようだけど・・・

Apache側というか、mod_perl等のモジュールによってはworkerでは動かなかったり
不安定だったりする。

>>535
具体的にはどういうところ?
バカチョン系API(over pthread)なら幾つかあるよ。

>>534
FreeBSDにとっては、Solarisのthread周りは目指すべき目標って認識じゃなかったっけ？
だからこそSolarisがデフォルトをM:Nから1:1にしたときに衝撃が走ったわけで。

ネタにマジレスばかりのスレですね

>>544
順番、逆でしょ。

solarisのlibthreadはバグの宝庫なので、プロダクションシステムでは
使うな！というのがsolaris使いの常識です。

>>547 とりあえずソースきぼん。

じゃあ Solaris 向け商用アプリなんかはみんなシングルスレッドなんかい

いや、pthreadじゃないスレッドライブラリが先にある。

オラクルはスレッドを使っていないです。
スレッドを使っているのは、sybaseとか、某アプリケーションサーバ
の類の負け犬ソフト。JDKだってトラブッてばっかりで全然直らない。
だいたいunixの基本コマンドにはthreadを使っているものってあまり
ないですよね。

>>547=>>551=低能プログラマ@底辺システム開発会社

そういやLotus Notesのsolaris版もmulti-threadだったんですが、
見事に撤退してしまいましたね。あれは6CPU以上は見事にスケール
しなかった。
　私は、自分のお客さんには、multi-threadには手を出すな！と薦めて
います。並列（ただしくは並行）プログラミングは、アプリプログラ
マには無理なんですよ。上級の制御屋さん以外は手を出すべきではない。
。

いや、今はCOBOLすらマルチスレッドで動く時代。

>>554
うわっ、驚きました。汎用機の世界の話ですか？世の中進んでいますね。
COBOLをマルチスレッドで動かしてなにが楽しいんでしょうか？unix旧世
代の私には思いつきません。

iPlanetのLDAPサーバ、libthreadでバリバリ動いてますよ。
V480、100threadくらいTLSでactiveになっても超余裕。

まあ、へたれは原始的なプログラミングしているのが無難。
ほとんどの領域ではパフォーマンスより安定性だからね。

あれはLinuxなんかにゃろくなスレッドライブラリないころからマルチスレッドで
書いてあったよね。

V480って4wayだから、>>553への反例にはなっていないんだが。

>>558
(ﾟДﾟ)ﾊｧ?

あんた頭悪すぎ。
LotusがスケールしないのはSolarisが悪いのか。
Directory関係はE系の64CPUでもスケールしているぞ。

俺、そんな必死にさせるようなこと書いた? すまん。

FreeBSDもLinuxもMTアプリ動かすだけ無駄。
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044565.html

Solarisでいいじゃん。無料なんだし。

FreeBSD5.3のbetaじゃ問題外でそ。5.3Rだってアレだというのに。FreeBSDは
スケジューラがULEになってからが勝負でそ。5.4RでULEが復活するのか、6-stable
待ちなのかはわからんけど。

Linuxも2.6.4じゃちと古すぎる。2.6系は2.6.10になってようやっとまともに安定して
きたんだし。

HP-UX 上で pthread プログラミング中なんですが、
プロセス内のLWP(カーネルスレッド)の数を、
コマンドで調べることはできないのでしょうか？

ps で表示できると思い込んでいたのですが、
HP-UX の ps は、そういう機能はないようで、
驚きました。

>>562
linuxだけstable版はずるいよな(w

>> 563
LinuxのpsにはLWPを表示してしまうバグがあるのに驚きました。

>>565
昔のLinuxは、threadが特殊なprocessとして実装されてました。
今は、そうではありませんが、ps(1)には、

THREAD DISPLAY
-L show threads, possibly with LWP and NLWP columns
-T show threads, possibly with SPID column
-m show threads after processes
H show threads as if they were processes
m show threads after processes

というoptionがあります。

>>566
ん？最近のLinuxってclone(2)じゃなくなったの？

cloneはもちろん使ってる。カーネル内のプロセスの意味が変わった。

なるほど。

勝手にプロセスの定義を変えるな。思い上がりもいい加減にしろ＞linus

だが、それがいい。

>>567
flagで指定すれば、、
古い特殊なprocessも作れるし、(rfork(2)みたいなやつ)
pthread的なthreadも作れる。

非常に高度な議論を交わされてる皆さんに質問です。

どんな会社に勤めてらっさるのですか？
ぶっちゃけイメージが沸きません。検討も付きません。

別に高度でもないし。嫌味のつもりだったらいいけど。
まあ２ちゃんだし。

>>574
嫌味のつもりは無かったです
高度でないなら、私のレベルが低かったということですね
変な質問してすみませんでした

勤めている会社の問題じゃなくて、好きなんですよ。

そうそう。自分で色々やるのが楽しい。

漏れはwindowsでもpthread使う。せっかく書くなら、移植性高くしておきたいし。
というか、普段Linux(たまにSolaris)を使う事が多いので、そっちで書いて持ってくだけ。
性能とか求められれば話は別。

pthreadと言うより、素人にスレッド扱わせたのを見る方が地獄。
JavaでもWindowsのスレッドでも。

こないだ、pthread使った糞プログラム見たよ
やっぱ素人にthread使わせちゃダメだ

>>577
そだね。ただ、プリミティブAPIなpthreadは素人には扱いづらいぶん
より地獄になりやすい傾向が強いかと。

初歩的ですみません。
ソケットプログラムをまだ組んだこと無いのですが、forkよりselectを
使った方が良いという文書を良く見ますが、selectって結局シーケンシャ
ルにコードが実行されているような気がします。forkは並列処理されてい
と思いますが。こういう理解で良いでしょうか？
＃よくよく考えるとselectとforkを混在させた方が良いのでは？などと
＃思うこともあります。
またpthread使った方がforkやselectより動作は早いのでしょうか？

あなたはとっても頓珍漢なことをいっています。
四の五の言わずに、まずは本を買って勉強してください。

故Richard Stevens著「詳解UNIXプログラミング」をすすめておく

>>580は壮大な釣りと見た

>>583
一見頓珍漢だが、よく読めば何とか意味は分かるぞ。
おそらく>>580は、複数のsocketを同時待ちしたいんだろう。
それで、 select() を使うか、 fork() して新しいプロセスを作って待つか、
それとも pthread を使うか…てな感じかな。

> selectって結局シーケンシャルにコードが実行されているような気がします。
あんまりこういうときにシンケーシャルなんて言葉は使わないが、
並列実行されないという意味では正しい。

> forkは並列処理されていと思いますが。こういう理解で良いでしょうか？
いちおう正しい。(ただし個人的には、あなたが正しく理解しているかどうかは
非常に怪しいと思う。)

> またpthread使った方がforkやselectより動作は早いのでしょうか？
多くの場合はそう。ただ select を使うか pthread を使うか fork するかは
速度で決めるもんじゃない。

>>584
我々が>>580が見たというものの内容を推測することはできるが、
それをしても580のためにはならんと思うぞ。

kqueue 使えとでも書いとくか。

実は kqueue (や、スケーラビリティのの点で劣るけど select) を
使って continuation passing みたいなスタイルで書くのが一番
効率がいい。コンテキストが一番軽くて済むからね。でもこういう
スタイルで全てを並列に動かそうとすると、 resolver みたいなの
ものまで自分で書かないといけないのでかなり大変。resolver と
かは諦めても良くて、かつ制御構造が簡単なら continuation
passing でいいけど。
そうじゃない場合は、pthread や fork を 使う方がずっと簡単。
pthread と fork なら pthread の方が効率が良い。
でも、pthread は素人が使うもんじゃないから、性能が本当にクリティ
カルじゃない限り、fork で書くほうが簡単でお勧め。バグっていても、
それが他のコネクションに影響しにくしね。

>>580
forkは並列処理されていると思いますが。こういう理解で良いでしょうか？

ただしくは「並列」ではなく「並行」、concurrencyだ。「並列」に処理される
ためにはマルチプロセッサシステムが必要。シングルプロセッサだったらス
ループットは変わらない。I/O待ちが無いようにCPUを有効活用できるが。。。

蘊蓄垂れたがる奴が多いな。

なにせここは真・Ｍａｃ板だからな。

poll(2)最高。

薀蓄と言うほどのものではないでしょう。
ある段階においては常識的に知っていなければならないことが
多いですよ。経験を重ねることで自然に身についていくので
それほど心配しないでもOK。

関係なければもちろん知らなくても大丈夫だし。

常識をわざわざ長文でぶちまけてるから「垂れたがる」と言ったわけだが。

常識的事項が長文で書かれていて、何かあなたに不都合が?

"垂れたがる"ではなく"薀蓄"につっこまれているんだと思うんだが...。

それなら常識を垂れたがると言えばよかろう。

スレ違い。

>>591
pollよりkqueueの方がソースの見通しを良くしやすいと思うよ。

そうなんだけどさ。
kqueueとかepollは使える環境限られるし。

私はスレッド使っちゃ駄目と言われない限り、スレッド使う派。
select/pollより素直に書ける。forkよりも速い。
並列度を上げようとすると、lock/unlockがわかりにくくなるけど。
まあスキルがないだけかもしれんが。

なぜか、rwlockってあまり使われていない気がする。
知らなくて自分で似たのを作りそうになった。

>>598
漏れもスレッド使う派。
デッドロックはできるだけスレッド間で大域データを持たないように設計することで回避

thread使うとatom周りの移植でグダグダにならない？

デッドロックは、ふつー、複数のロックのロックする順序を決めることで回避
するのでは？

>>599 が言いたいのはデッドロックというよりロックによるコンカレンシー低下とかかな？

並行・並列なんて言葉よりデッドロックこそ正しく使おうね

このスレがデッドロックしますた。

基本的なことですみません。
どなたか教えていただける方いらっしゃいますでしょうか。

fork()で子プロセスの終了を待たない場合、ゾンビにならないよう
signal(SIGCHLD, SIG_IGN)で子プロセスからのSIGCHLDを無視する必
要があると思いますが、pthreadの場合はこんなことしなくても良い
のでしょうか？そもそもpthreadにはゾンビなど無いのでしょうか？

ひょっとして pthread_detach() するだけで良いのでしょうか？

zombieってのはプロセスの死骸で埋葬待ちのものをいう。
スレッドはプロセスじゃない。
これらの前提から、結論は

まぁスレッドでゾンビって概念があるかはともかく、JOINABLE なスレッドを
pthread_join() しないまま放っておくとリソースリークは発生するな。
その回避には >>606 の方法でもいいし、あるいはスレッド生成の段階で
DETACHED なものとしておくか、だな。pthread_attr_setdetachstate() 参照。

pthread_cond_timedwait()で、pthread_cond_broadcast()によるイベント取りこぼす場合があるようなのですが、
詳しく解説しているページをご存知の方いませんか？

一般論としてない。

ただし、async-signal safeではない。

ライブラリのバグか、ユーザの書いたコードが悪いのか。
まさにpthread地獄。

>>609
小さいプログラム書いて検証してみればいいやん。

必ずしも再現できるものではないのが厄介。
コンパイラのバグを追うより性質が悪い。

仕様を把握しないで使うから、そういう事になるんじゃねーの？

仕様を把握するなんて泥臭いことは底辺コーダがやることだし。
おれっちは優雅にアルゴリズムを練りたいの。

DQNえせEがあらわれた!
プログラマAは 逃げ出した!
プログラマBは 逃げ出した!
プログラマCは 逃げ出した!
会社は 傾いている!

>>616
あれ？おかしいな？メール欄にsageって書いてある……

>>616
posixの仕様も把握せずに使う冒険野郎ですか？

>>619
違っ！ orz
posix → pthread

pthreadのpはPOSIXのPなんだから、あながち間違いでもなかろ。

dual CPU,ハイパースレッディング環境で main thread の他に演算
作業用スレッドを 4個作って処理させています。 4個のスレッドがそれぞれ
異なる4つの(論理)CPU に割り当てられた時はとても速く動作するのですが、
同じ CPU に２つのスレッドが割り当てられたりすると、1つのCPUが遊んで
しまい、処理が遅くなってしまう事があります。このような事を防ぎ、
確実に異なる CPU にスレッドを割り当てたいのですが、よい方法は
ありませんでしょうか？お詳しい方がいらっしゃいましたらぜひご教授
よろしくお願いいたします。

OS に何使っているのか分からんけど、CPU に thread を割り当てちゃえば良いんでないの。

affinity cpu thread

さらにスレッドを分割して、常に4つ以上のthreadをrunnableにする。

>>623
おい、それＯＳ依存だろ。

>>624
何それ？どういうこと？

>>622
実際には、その考えをアプリケーション層ですること自体が間違ってる。
アプリが「このCPUを使いたい」って言っても、カーネルのスケジューラを困らす(複雑化する)だけだと思うぞ。

結局は、ＯＳのスケジューラに依存する問題（空いているCPUに割り当ててくれない）ってことだな。

>>623
pthread_setaffinityが使えるOSってなに？

Linux 2.5.8以降のLinuxとか。
sched_setaffinity(2)だけど…

sched_setaffinity(2)は、プロセスに対してだよね。
pthread..は特定のスレッドに対してのCPU割り当てだから違う気がするな。

違わないな。ごめん。

sched_setaffinityが使えるなら、pthreadライブラリのpthread_setaffinity
（実装されていれば）は機能するだろう。
ってことだよね。了解。そうですね。さんくす。

E言語ができた場合
英語とE言語を言い分ける自信がありません。
どうしたらいいですか？

>>630
スレ違い。
くだ質スレへ行け。

　　　　　　　,r-'''""￣￣"'-,_
　　　 _,.-'^γ´　　　　　　　　　 ｀i,
　　 ,r'　,.r'"ヽヽ、（ （　ｿノノ彡、　i
　　,i'　｛　　　　　"'''''''''''''　　　ﾐ　　.i　[￣二.￣|　[二⌒二]　　　 ／￣7　[二￣二]　 [二二￣|
　　i　　i　　　　　　　　　　　　 ミ　　i　＼＼/ /　 [二__二] 　 ／ 　 l´　　 　 |　|　 　　　　／／
　　|　　i　　　二 二 二 二　　 ﾐ　　i..　　>　く.　 ┌──┐ く,／!　 !　　　　 |　|　 　　 ／　く
　 .i　　 i　　　　　　ハ　　　　　 ﾐ　 i.　∠／＼＞ l_二二_｣　　　 |＿|　　 [二＿_二] ∠／＼_＞
　　|　 ノ {｛|iiiiiiilll;ﾉ,,,,,ヽ;liiiiiiii||｝}　ゝヾ
　　 | .ミ >='^◎≫,i'^'i,≪◎'=､< ミﾍ
　　,ﾍ ﾐ　~こ二ヲ　i　i; .'ﾐ二こ、 ﾐ　}
　　 {　ﾚ　　　ノ　　i　i;　 ヽ､_,　';,ﾉ ﾉ　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　Li,;'ゝ　　 　,イ　 ト、　　';,　i'~　 |　 唯　　　一　　　神　　　又　　　吉　　　イ　　　エ　　　ス　　　！
　　　　i,　i　._,ノ^-0し0-ﾍ,_　　｝| 　　|　腐った日本を救えるのはネ申しかいない。９月11日は又吉イエスに投票すべきだ！　
　　　　　ゝ,ｲ'<ー--ﾆ---ｰ>|ﾉｿ 　＜　 投票しない者は！唯一神・又吉イエスが地獄の火のなかに投げ込むものである！！
　　　　　　ゝ.i　　｀'ー-'´　 i,ｲ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　 |..ヾ、　,.......、,i'.,ｿ |　　　
　　　　　　,|.　ヾヽ_＿___ﾚ'ｿ　.|、　　

世界経済共同体党 †
http://www.matayoshi.org/index.html

キリストが神だと本気で思ってるんだ、ふーん

最近の FreeBSD pthread ってどう？age

>>634
http://lists.mysql.com/mysql-ja/151
http://lists.mysql.com/mysql-ja/157

上の2つを見る限りではkseがすばらしいとはいえないと思う。

>>635
ん〜面白い結果。
以前 slashdot に出ていた scalability のベンチマーク結果を
受けて改良した結果が NetBSD に現れた雰囲気が出てるね。
FreeBSD に関しては 6.0 で vfs がだいぶ良くなった噂なのでその辺含めて
再チェックはして欲しいところ。ただもうちょっと地道な改良は必要そうな感じ？

こうなると MySQL 以外も気になってくる。
apache prefork vs pthread とかどこかに落ちてないかな。

あーでも、よく見ると、どのOSも最近とは言えなくなってきてる時期のデータ……
暇人による最近のデータｷﾎﾞﾝﾇしたいところだ……

>>636
実際に試したわけじゃないからわからないけど、

プロセスベースとスレッドベースを比べたら
スレッドベースが早いのは当たり前かな。

ただ、そのスレッドがどのOSが早いかという話かなと。

kseとかM:Nスレッドモデルだし早そうなのになー
何で遅いんだろ。

ちなみにMySQLはスレッドバリバリ使うアプリです。

こういうのもある。
ttp://lists.freebsd.org/pipermail/freebsd-threads/2005-January/002789.html


まあ、MySQLはLinuxをメインターゲットとしていて、Linux上で最高のパフォーマンスが
出せるようにチューニングされているんだから、それに勝つのは難しい
…なんて意見もあるようで。

>>639
これはまた見難いドキュメントですね・・・
まとまりがorz

すいません、あげまくってしまった

>>635
FreeBSD5.3のKSE(M:N)とlinuxthread(1:1)が
たいしてベンチの結果が変らないのはどう評価すればいいんだろう。
・KSEのスケジューラが頑張っている。(1:1に負けてない)
・GiantLockがボトルネックになっていて頭打ちになり差が出ない。
のどちらなんだろう。

http://www.freebsd.org/smp/によれば、
6.xではほぼGiantLock問題が解決しているようだから、またベンチして欲しいところ。

>>639
> Linux上で最高のパフォーマンスが出せるようにチューニングされているんだから、

ソースきぼんぬ

CPU数より多いスレッドを動かすっていうのは
プログラマの手抜きだよな。本当に性能を追求
するのなら、スレッド数はCPU数と同じにすべきだ。

>>643はアホ

すべてのスレッドが絶対にブロックしないなら、だね

>>643
じゃあ、使えるCPUの数を実行時に知るpthread並にポータブルなやり方を
教えてくれ。

しかも、実行中に異常なCPUを切り離せるような商用UNIXサーバを考えると
それに対応してスレッド数を増減するプログラムを書かないとな。

実行時間とスレッド数の関係からシステムのCPU数を推定するheuristicを開発して
スレッド数を動的に変化させないのはプログラマの手抜きだよな。

↓ここで「手抜きの何が悪い」とか正論ながら斜め上のレス

手コキの何が悪い！

でも、スケジューリングやらコンテキストスイッチやらの面倒な部分を
ほとんどライブラリにお任せして手軽に並列プログラミングをしよう、
ってのがマルチスレッドプログラムの本質だと思う。
それが嫌ならselectやその眷族を使うか、fiberみたいなので頑張れ。

>>648
すごいなw
仮に数百CPUレベルまで通用するようなCPU数を推定するheuristicsが開発できたとして、
スレッド数をシステムのCPU数ぴったりに動的に変化させると、CPU数など無視して適当な
数スレッド作るプログラムより性能上がるのか？

ありえねぇ。

たとえばN次行列の積を計算するのに、N^2個のスレッドを作れば
プログラムは楽だろう。でも、N=1000の時、1M個のスレッドを
作るヤシは馬鹿だ。敢えて言おう、クズであると！
ずっと昔にnastranのソースを見たことがあるが、昔の人は行列
の性質を利用して、計算を軽くしていたよ。

ただ、まじめな話をすると、>>643の言うことにも一理あるよ。
つまり、可能な限り、プロセッサ数とアクティブなスレッド数は
一致する方が望ましいでしょ。

で、そういうのを希望する人は、WindowsでIOCPを使いましょ。
これは、スレッドとジョブを管理する仕組みとしては
おそらく最強だよ。少なくとも、理論上は。
>>647みたいなのに対応してるかは知らんけど。

おまいらは、自分が動かしたアプリだけが
同時に各CPUに分散して使用してるはずだとでも思っているのでしょうか？

「他のアプリが動いているかもしれないから、CPU数よりスレッド数を少なくしておく」より
100倍まともな考え方だと思うよ。
サーバーの場合には、占有していると考えてしまっても良いだろうし。

まあ、どのスレッドがどのCPUに割り当てられるかはスケジューラ依存で、
スレッドがCPUより多いのに(長時間)idleなCPUが出てしまうとしたら
それはスケジューラがタコなだけだし。

>「他のアプリが動いているかもしれないから、CPU数よりスレッド数を少なくしておく」より
>100倍まともな考え方だと思うよ。
もちろん、そりゃそうだ。

だから結局、>>646,>>647って事になるのでは？

だから>>654

つうか、ＩＯ待ちになる箇所をちゃんと把握して、スレッド化してるんでしょうね？
まさか、シングルスレッドにしたら満足に動かないようなのを、マルチにして「おせぇ」「ウゴカネェ」とかいってんじゃないでしょうね？
・・・そんなことないよね、ごめんね。

>>658
つうか、それ板違い

>>658は頭大丈夫でしょうか？

入門書をもう少し丁寧に読んだ方がよろしいかと思われます。

どの入門書が適当ですか？

>>661
どこが変ですかね？
Windowsを出すのはこのスレにふさわしく無いのは当然だけど
プロセッサ数とスレッド数の関係が間違ってますか？
それとも、IOCPがソケットだけを扱うものだと言いたいのですかね？
もしかしたらIOCPを最強というのがお気に召しませんか？

まあ、入門書を読めとのことなので、pthreadの入門書は読んでますから
お勧めの「IOCPの入門書」とやらを教えてくださいな。

IOCP最強なら、IOCP使った最強サーバがあっていいはずだが、ない。

でも俺にはなぜほかのOSがIOCPを採用しないかがわからないから
何ともいえない。

>>642

>http://www.freebsd.org/smp/によれば、
>6.xではほぼGiantLock問題が解決しているようだから、またベンチして欲しいところ。

なんかネットサーフィンしてたらFreeBSDとlinuxどっちが素敵か気になるから
ベンチしてみたくなった。

誰かベンチのルール決めて。

>>665
Microsoft Windowsで動く最強サーバは?
例えばZeus Web Serverのように、マルチスレッド、SMPで、
突出した性能を示すサーバがありますか?

>>666
とりあえずSMP性能がどれだけ向上してるか知りたいな。

http://pc.watch.impress.co.jp/docs/2005/1102/intel.htm
↑これを積んだ4wayサーバーを用意してくれ。

>>668
それ以前に, 勝手にそれなりに粒度上げてくれるコンパイラ.

>>669
意味わかんね

IIS

>>664
少なくとも、性能という面でWindows+IISは
(Apacheは論外としても)PC-Unix系の、並の"高速"httpdを上回るよ。
それこそ、カーネルでhttpdを動かすくらいでないと。
ただ、プロセッサ数が二桁以上になるような環境で性能が出せるのか
(Windows自体の性能も含めて)は知らない。

>>665
一つめの理由は簡単。
IOCPは、カーネルレベルでスケジューリングを行っているので
m:nスレッドではあまり意味がない(性能が出せない)。
もう一つの理由としては
select(とその拡張)系のシステムコールは、読み書き等のイベントが
"可能"になることを知らせる(待つ)のに対し
WindowsのOVERLAPPED系(IOCP含)は、イベントの"終了"を待つ仕様のため。


いや、普通に「性能」を求める場合、
ボス/ワーカー、或いは生産者/消費者みたいなモデル
これとスレッドプールを使ってジョブをキューにためて
ワーカースレッドが非同期に実行するって形を取るでしょ？
IOCPの場合は、その仕組みがOSに備えてあって(キューの排他制御等も不要)
さらに、スケジューリング(I/O待ちが発生したら別のスレッドを動かす等)までやってくれるから
「理論上の」仕組みとしては、間違いなく最強だって。

まあ、スレ違いなのでこの辺にしておくけど
興味のある人はちょっと読んでみて。
スケジューラ部だけを利用する場合、Create...でのHANDLEとの関連づけを無くして
Post...でジョブを登録する感じ。
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_GetQueuedCompletionStatus.asp
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_createiocompletionport.asp
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_postqueuedcompletionstatus.asp

>>672
理解が浅いね

>>661さんですかね？
私は何という入門書を読むべきで、何について理解を深めるべきですか？

>>672
IOCPしか知らない人ﾊｹｰﾝ(w

えーと、「自分が絶対正しい」なんて全然思っていません。
それに、知識がないこと自体は恥とは思わないし
むしろ、新しい知識を得られるのでうれしいのですが、、

「どこが間違っていて」「正しくはこうである(この方が良い)」というのを教わらないで
「おまえは間違っている」とだけ言われるのが一番嫌なんですが。
今のところ、自分ではどこが間違っているのか分からないので。


もしかして、kqueueとか/dev/pollにもスケジューラ機能があったりしますか？
それとも、スケジューラ機能付きのイベント告知システムが他に存在するということですか？

あ、もしかして「同時にアクティブになるスレッド数を制限する方法」がpthread標準にあったりとか？
これがあれば、CPU数さえ把握できればコンテキストスイッチを減らせるし。

>>672

> IOCPは、カーネルレベルでスケジューリングを行っているので
> m:nスレッドではあまり意味がない(性能が出せない)。
Linuxの2.6とかで使われてるNPTLは1:1モデルなんだけど、
何で使わないの？
その理屈だと、それほど実装が
難しいわけじゃない気がするけど。


まあたしかにIISは速い。うん。のかな？

>>676
スレッド使うとプログラミングは簡単になるが、スレッド間の
コンテキストスイッチが必要なので、効率は若干犠牲になる。
aioだとコンテキストスイッチが不要なので、スレッド使う
よりも軽い。コンテキストスイッチしないから、スケジューラは
必要ない。

>>676
AS/400とか
IBMもLinuxのpatch作ってた。(そもそもNTPLすら本家に入らなかったが…)

>>672
> それこそ、カーネルでhttpdを動かすくらいでないと。

IISだって散々Windowsいじってるじゃん(w
それでも同じ構成で動かしているIBM機のTUXやZeusに勝てずに、
IBMはTUXやZeusを売り出しているのが現状。
しかもCPU増えると悲惨。
そんなにいい設計ならCPU増えてもスケールするはずだけど。
IOCPのスレッド数制限はthread boostと一緒でdirty hackに過ぎないと思う。

Linuxのsendfile(2)とかいい加減にしろと思うけど、
ああいう汚いのは特定の場面では有効だわね。

スレッドを使う理由を理解していない人が約一名いらっしゃるようでつね。

ﾋﾝﾄ：多種多様、適材適所

「マルチスレッドのスケジューリングのやり方」が
「理論上は」IOCPが優れているという話では無かったのか。

sendfile、或いはwritevなんかもそうだけど
こういうのって、非同期ソケットだと若干効率悪くない？
要は、すぐに戻らなくちゃいけないから、結局全部送るまでに何度も行き来することになって。
もしくは、ブロッキングソケットを使って(非同期でもブロックする仕様だとして)も、
そのスレッドはsendfileに占有されちゃって、他の事が出来なくなるから
「select系使って単一スレッド」には向かなくて
「select系使ったスレッドで、ワーカースレッド群を管理する」という形にしないと。

この点(sendfileの効率)に関してだけは、
Windowsの完了待ちの方が向いてるとは思う。
逆に、「acceptしたら必ずrecv」という形になるから
そっちの面で効率が悪い(バッファが非ページメモリ上に必要等)けど。

Completion portはSolarisにもあるよ。

>>681
その行を引用していながら、TUXを例に挙げるのは何故？

>>685
>この点(sendfileの効率)に関してだけは、
>Windowsの完了待ちの方が向いてるとは思う。
なんで？
詳しく！

>>685
acceptしたらthread_createすればいい。ポートとthreadが
１：１になるから簡単だ。selectいらね。

> なんで？

システムコールの回数を気にしているじゃない？

> 「select系使って単一スレッド」には向かなくて
> 「select系使ったスレッドで、ワーカースレッド群を管理する」という形にしないと。

ここは pthread スレだから、それでいいと思われ。

「select系使って単一スレッド」をしたい場合には、aio を使えば問題なし。
Solaris って、確か送信側は sendfile を使わなくても zero copy
になるから、mmap() しておいて aio_write すれば、sendfile は
使わなくても構わないでしょ。
完了は非同期に通知されるから、ブロッキングモードのままで OK。

>>689
システムコールの回数やコンテキストスイッチの回数まで気にするような
シビアなサーバーでは
コネクション毎に１スレッド占有するような造りは
(たとえスレッドプール使ってても)あり得ないよ。

>>690
> システムコールの回数を気にしているじゃない？

なんで?
sendfile(2)は一回だから最小の一つでしょ?

もうわけわかなんですけど。

>>692
ノンブロッキングモードで動かすと、引数で指定した
サイズを送信し終える前に、送信バッファが一杯に
なって返ってくる。だから、一回じゃなくて、小さい
サイズずつ細切れに送信することになる。

へ？

>>694
(ﾟдﾟ)ﾊｧ?

>>693
俺も俺も。脳みそ足んね

>>696
partial write になる可能性があるってこと

>>694
>ノンブロッキングモードで動かすと、引数で指定した
>サイズを送信し終える前に、送信バッファが一杯に
>なって返ってくる。だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。
言ってる事おかしくね？

どこら辺が？
いや、俺、ノンブロッキングモードで sendfile を使ったことないから、
本当にこうなるかどうかは知らないんだけどね。でも、理屈はあってる筈。
それに、もしこうならなかったとしたら、sendfile で指定しただけのサイズ
の出力が終るまで他のディスクリプタに対する処理が問答無用で待たされる
ことになるので、それはそれで問題の筈。

>ノンブロッキングモードで動かすと、引数で指定した
>サイズを送信し終える前に、送信バッファが一杯に
>なって返ってくる。
なんで送信バッファが一杯になって返ってくるの？

で、それが何故下記の文につながるの？
>だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。

> なんで送信バッファが一杯になって返ってくるの？

TCP コネクションでの送信速度よりも速い速度で送信しようとすると、
送信のためのシステムコールの最中で待たされる (ブロックする)。
でも、ソケットをノンブロッキングモードで使っている場合は、ブロック
するわけにはいかないので、SO_SNDBUF を越えて書き込みが溜ると、そこ
までで書き込みシステムコールをいったん打ち切って、システムコール
から返ってくる。これが partial write。

で、それが何故下記の文につながるの？

>だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。

partial write が起きれば当然細切れになるでしょ。

When using a socket marked for non-blocking I/O, sendfile() may send
fewer bytes than requested. In this case, the number of bytes success-
fully written is returned in *sbytes (if specified), and the error EAGAIN
is returned.

NTのTransmitFileは送り終わるまでカーネル内で処理が完結するのにたいし、
sendfileでは、細切れ毎に呼び出すコンテキストスイッチが要るから、
ちょっと効率が悪いね、って話でしょ？

>>702
なんでそんなに自信をもって間違えるの？

>>704
>NTのTransmitFileは送り終わるまでカーネル内で処理が完結するのにたいし、
それブロッキングモードと何が違うの？

>sendfileでは、細切れ毎に呼び出すコンテキストスイッチが要るから、
>ちょっと効率が悪いね、って話でしょ？
何か論点おかしくない？

TransmitFileを呼び出したスレッドで、ファイル送信中に他の処理ができる。
ブロッキングだと、スレッドは占拠されてしまう。

ソケットバッファ広げてノンブロックモードでsendfile使用すればいいだけじゃん。
終わり。

ファイルと同程度のサイズのソケットバッファをとるならともかく、
ファイルよりも有意に小さいサイズのソケットバッファだと、
ファイルのディスクからの読み込みが、TCP の送信速度よりも
速ければ、結局、ブロックしてしまうので駄目。
ソケットバッファは実メモリを消費するので、ファイルと同程度の
サイズのソケットバッファをとるのは非常に無駄。

UNIX 系でシングルスレッドでやるなら、>>690 のやり方で解決する
のがベストじゃない？

>>705
どこら辺が間違ってると思うの？

> ファイルのディスクからの読み込みが、TCP の送信速度よりも
> 速ければ、結局、ブロックしてしまうので駄目。

ここ、分かりづらいかな。
もうちょっと解説しよう。
たとえば SO_SNDBUF で 1MB を設定して、ノンブロッキングモードで
sendfile すると、
1. バッファに 1MB 溜ってしまったので、partial write になって、
　sendfile(2) から戻る。返り値 *sbytes == 1MB。
2. 1パケット送信。バッファが 1.5KB ほど空く。
3. select(2) で調べると、送信可能であることが分かる (1.5KB 空き
　があるから) ので、sendfile(2) を呼ぶ。
4. バッファに 1.5KB つけたすと、1MB に達するので、partial write
　になって sendfile(2) から戻る。返り値 *sbytes == 1.5KB。
以下、2〜4 繰り返し。

というシナリオがありうるから駄目なの。

じゃあ、あれか、TransmitFileって奴は
ディスクからの読み込みでブロックすることは無いのか？

>>709
>ソケットバッファは実メモリを消費するので、ファイルと同程度の
>サイズのソケットバッファをとるのは非常に無駄。
別に必要であれば有効に使用すればいいだけでは？
何故、無駄と言いきる？

別にファイルサイズと同程度で無くとも良いではないか。

TransmitFile() って、sendfile(2) の aio 版みたいなもんじゃないの？
でも aio_write(2) が zero copy で動く OS なら、そんなもの使わなく
ても mmap(2) + aio_write(2) で十分と、そういうことでは？
aio_write(2) が常にコピーする OS では aio_sendfile(2) みたいなのが
あった方がいいのかも。

>1. バッファに 1MB 溜ってしまったので、partial write になって、
>　sendfile(2) から戻る。返り値 *sbytes == 1MB。
>2. 1パケット送信。バッファが 1.5KB ほど空く。
>3. select(2) で調べると、送信可能であることが分かる (1.5KB 空き
>　があるから) ので、sendfile(2) を呼ぶ。
>4. バッファに 1.5KB つけたすと、1MB に達するので、partial write
>　になって sendfile(2) から戻る。返り値 *sbytes == 1.5KB。
>以下、2〜4 繰り返し。
>
>というシナリオがありうるから駄目なの。
っていうかそんなのsendfile使う奴が気を付ければいいだけじゃん。

では、聞くが駄目でない方法とはなんなんだ？

> 別に必要であれば有効に使用すればいいだけでは？
> 何故、無駄と言いきる？

そんなに大きなバッファは、本当に必要なわけじゃないからメモリの無駄なの。
>>690 のやり方なら、ずっと小さなバッファで済む。

> 別にファイルサイズと同程度で無くとも良いではないか。

sendfile(2) + ノンブロッキングソケットの場合、>>710 の問題にハマるので駄目。

> では、聞くが駄目でない方法とはなんなんだ？

>>690 に既に書いてあるのでは?

ディスク読み込みの発生しない、
魔法のOSなんかありません。

> ディスク読み込みの発生しない、魔法のOS

誰もそんな話はしてないけど…

zero copyはな、メモリに存在するからできるんだよ。
知らんのか？

何故、>>690のやり方が>>710にならないと言いきっているの？
その根拠は？

>>710 が生じるのは、ノンブロッキングモードで動かしているせい。
>>690 の方法は、ブロッキングモードで動作するから大丈夫。
ってゆうか、既にそう書いてあるじゃん。どこ読んでるの？

それがaioだから、としか言いようがないと思うが。
というか、このスレに、aioとノンブロッキングとブロッキングが
理解できない人間が混ざっているのか？

>Solaris って、確か送信側は sendfile を使わなくても zero copy
>になるから、mmap() しておいて aio_write すれば、sendfile は
>使わなくても構わないでしょ。
これでも、>>710になるだろ。

つうかさ、ネットワーク越しなんだろ？
ならソケットバッファの容量が影響するじゃん。

> これでも、>>710になるだろ。

もしそう思ってるなら、ブロッキングモードとノンブロッキングモードの
動作の違いから勉強し直した方がいいと思うよ。マジで。

> ならソケットバッファの容量が影響するじゃん。

ノンブロッキングモードの場合は関係する。
だから何度も SO_SNDBUF って言葉が出てるわけでしょ。
今ごろ何言ってるの？

>>725
>もしそう思ってるなら、ブロッキングモードとノンブロッキングモードの
>動作の違いから勉強し直した方がいいと思うよ。マジで。
ならば、どんなファイルサイズでも>>710にならないと言うのか？

いまだかつてこんなにも活気のあるこのスレを見たことがない。

漁スレの予感

この問題ってファイルサイズに依存しないか？

>>726, >>729
動作を理解していれば、自分で答は分かる筈。
っていうか、自分が理解してないことが分かったなら、人に答を
聞くんじゃなくて、地道に勉強すべきじゃないのかね。でないと
プログラミングはできないよ。
OS の優劣をカタログスペック的に暗記したいだけなら話は別だけど。

まあ、勉強しなくても、既に答は書いてあるけどね。

そもそも、何が言いたいのかわからない。

>>730
ROTFL

ファイルサイズには無関係で、partial writeにならずに転送なんてできるのでしょうか？

>>730
>>726の答えになってない。

>>733
ソケットバッファを越えるファイルサイズであるなら、partial writeになってしまう。

>>735
勉強不足。ブロッキングモードでの write(2) は、たとえ
ネットワークへの書き込みでも partial write にはならない。
(ただし、書き込み中に signal が生じた場合などは例外)

>>690のやり方も、完璧な解ではないんじゃないかな。
もちろん、よほどの事がない限り問題になることは無いけれど。

>>690って、mmapした領域は１回読み出したらページアウト可能なんだけど
さすがにそれを類推できるOSって普通無いでしょ？
で、mmapした領域で、かつ読み込みのあった領域ってのは
ページアウトの優先順位が低いとすると
巨大なファイルの場合だとメモリ使用量に無駄が出て
他のプロセス等に影響が出る場合もあるかな、って気も。

やっぱり、可能ならaio_sendfileがあった方がうれしいケースも出てくるような。
まあ、mmap後は読み込みだけだから(ディスクに実体があるから)
ページアウトの優先順位は高いかもしれないので
机上の空論かもしれないけど。

> 巨大なファイルの場合だとメモリ使用量に無駄が出て
> 他のプロセス等に影響が出る場合もあるかな、って気も。

このケースの場合、madvise(2) で MADV_SEQUENTIAL しておけばページング
に関する問題はない筈。たいていの OS では、MADV_SEQUENTIAL の場合の
ページング方針の最適化をしてるので。(Solaris は間違いなくやってる)

> やっぱり、可能ならaio_sendfileがあった方がうれしいケースも出てくるような。

でも、まあこれは同意。特に Web サーバで、たくさんのファイルをサービス
する場合、>>690 だと mmap() と munmap() を繰り返すことになるけど、
aio_sendfile(2) があれば、それも省けるので、若干効率はいいはず。
aio と sendfile(2) の両方の機能がある OS にとっては自然な拡張だから、
そのうち、いろんな OS で実装されても不思議はないね。

>>707
> TransmitFileを呼び出したスレッドで、ファイル送信中に他の処理ができる。

ソースきぼん！

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/transmitfile_2.asp
ほれ。
OVERLAPPEDを渡せば呼び出しからすぐ戻り、完了が非同期で通知されるようになる。

>>685
>sendfile、或いはwritevなんかもそうだけど
>こういうのって、非同期ソケットだと若干効率悪くない？
>要は、すぐに戻らなくちゃいけないから、結局全部送るまでに何度も行き来することになって。
その場合の非同期ソケットを使うことの意義って効率うんぬんよりも、
別作業で他の作業をさらに続けたい時に、便利であるという物だけなのでは？

>>736
>>735ではノンブロッキングモードである事を想定して書いた。
がそれを明記しなかった。スマソ

sendfile() の意義って効率だけなんだから、sendfile() 使ってて
効率が悪くなるなんて大問題。sendfile() の存在意義がなくなる。

>>743
>sendfile() の意義って効率だけなんだから、sendfile() 使ってて
>効率が悪くなるなんて大問題。sendfile() の存在意義がなくなる。
確かにそうなんだけどなw

恐らくそれをする(nonblock & sendfile)人は効率を悪くしてでもやりたい事があるんだろうなw

だから効率の悪くて嫌だって話だろ。
そもそも、select系でノンブロッキングソケットを使う理由は
マルチスレッドのコンテキストスイッチすら嫌うからだよ。

>>672
>IOCPの場合は、その仕組みがOSに備えてあって(キューの排他制御等も不要)
>さらに、スケジューリング(I/O待ちが発生したら別のスレッドを動かす等)までやってくれるから
>「理論上の」仕組みとしては、間違いなく最強だって。
最強って言うのはどうかわからんが、ようするに便利だって事だけでしょ。

同時接続1000-2000程度しか想定しなくて良いなら
１スレッド１接続でも大丈夫だろうが
万単位まで視野に入れるには、select系(の拡張)のノンブロッキングを使うんだよ。
もちろん、マルチプロセッサやI/Oブロックを考慮して
マルチスレッドも併用してね。

なぁこのスレでそもそも何に関して議論してるの？
全然、話がつかめないんだけど。

>>746
> 最強って言うのはどうかわからんが、ようするに便利だって事だけでしょ。

便利なだけじゃなくて、
ちゃんとアクティブなスレッド数を調整してくれる機能があるって。
これがあるから、コンテキストスイッチが最小限に抑えられるの。

>>747
で、そのIOCPを使用して万単位のすごいパフォーマンス結果はどこかで見れるのかね？

間違った。
>>750は以下に変更

>>749
で、そのWindowsのOVERLAPPED系(IOCP含)のパフォーマンス結果はどこかで見れるのか？

まあ普通そこまで考えなければいけないのは
MMOとかストリーミング系とかだろうな。
実際に何を使っているかは知らないが。

Web鯖ではそこまでの規模が必要なら
単に分散するだけだろう。

そういえば、windowsupdateが数ヶ月前くらいにトラブってたな。
あそこは定期update時に数百万以上の同時接続があるのは確か。
まあ、何台使っているかは知らないが、Win鯖を一万台使って
一台当たり1000接続だったら大笑いだけどね。

>>747
senndfile＆ノンブロックが非効率だろって事はどうなるの？

>>749
>ちゃんとアクティブなスレッド数を調整してくれる機能があるって。
>これがあるから、コンテキストスイッチが最小限に抑えられるの。
詳しくは知らんけど、これってSolarisやLinuxでも出来そうじゃね。

>>754
効率重視のサーバーではノンブロッキング+selectを使いたい
当然、ファイルを送るためには、効率の良いsendfileを使いたい
けど、sendfileはノンブロッキングとの相性がイマイチ
という流れでは。

>>755
スレッドプールにタスクを渡し、どのスレッドがいつタスクを実行するかはOSが管理する
というシステムは作れるんじゃないかと。
現状のシステムの組み合わせで出来るかは知らない。
単純にスレッドプールを使うだけだと、
待ちを考慮してCPU数より多くのスレッドをプールすることになり
ピーク時に同時実行スレッドが増えてしまってコンテキストスイッチが発生する
というのが問題(?)点だから。

スレッド間のコンテキストスイッチってそんなにコストかかるもんなの？
ページ変換テーブルとか切替える必要なさそうだし、たいしたコストは
ないもんだと思ってた。
スタックが分散するから、キャッシュは無駄になりそうだけど。

キャッシュに関しては、量よりも直接のヒット率の方が影響あるんじゃないかな。
中断したタスクを再開したときに、同じプロセッサが割り当てられるとは限らないわけで
全部読み直しに近い場合もあるだろうし。
ただ、その辺はカーネルのスケジューラが出来る限りのことはしてくれると思うし
どの程度差がでるかはわからんね。

> ただ、その辺はカーネルのスケジューラが出来る限りのことはしてくれると思うし

Windowsはこれやってくれないんだよねえ…。
重いプロセスをSMPマシンで動かすと、複数CPU間を行き来して余計に遅
くなったりする。

UNIXで、そのへんちゃんと考慮してくるのって、ある？

アフィニティを手動設定して終わりじゃないの？

>>746
せいぜい「便利なときがある」くらいでしょ。
マイクロソフトお得意の場当たり的スケジューラ特殊化だから。

>>759
一つのプロセス(スレッド)を特定のCPUに割り当てたければ、
processor setを使うのがSolaris流儀。

>>749
> ちゃんとアクティブなスレッド数を調整してくれる機能があるって。

何をどう調節するの?
アクティブじゃなくていいかどうかはどう判断するんでしょう?
後回しにされたスレッドの立場は?

>>760
手動で設定しないと上手くいかない状況は、スケジューラが考慮してい
るとは言えないのなの。

>>763
同時に実行される必要がないタスクだからIOCPに管理されたスレッドを使うのであって
後回しにされるタスクが出るのが嫌なら
普通のスレッドを使えばよいだけ。

>>765
要するに、静的に分類して、優先順位をつけるわけですね?

素のWindows + IISで速い例なんてあるの?
IBM, NEC辺りのはカーネルが素のWindowsとは違う独自バージョンだよ。
奴等ソースコードいじっているから。Databaseの時もそう。

は？

まあいいや。「とりあえずWindowsを叩いときゃいいや」って人は相手にしないどこ。
説明しても理解する気無さそうだし。

大半の人は「良いところもあれば悪いところもある」ってのは分かってるんだから。

おまいら捨てハンぐらい付けたらいかがでしょうか。
何人いるの?

まず自分からつけなよ。
今後全部読み飛ばすようにするから。

あ、全然別の人だったかな。
自分以外で ? を使っている人って事で勘違いしたかも。
だったらごめんね。

すまん、>>772は771

IOCPが理論的に最速であることを説明してくれる人きぼんぬ

>>764の言っていることは、
>>765にあらかじめ答えているようなもんだな。

用途の問題だけど。
4CPUとして、
5つの計算をして最後に同期を待つ必要があるのなら
普通のスレッドで並列に実行させれば、1つの計算の1.25倍+αで終わるけど
非同期に1000個のリクエストが来るサーバーでは
最大4つ以上は同時実行せず、1つづつ完全に終了するまで待つ方が
オーバーヘッド分効率が良いというだけ。

あと、IOCPを使ったサーバーでも、普通はlistenするスレッドは独自に動いてるし。

タスク処理時間に偏差がある場合、
平均待ち時間が悪くなるスケジューリングポリシーですね。
処理時間が見積もりやすい科学技術計算辺りが得意分野なのでは?

タスク処理時間の偏差はいいですけど
タスク開始時間の偏差はいかがですか？

>>777
コンテキストスイッチのオーバーヘッドに比べて、
デメリットの方がずっと大きいような…
# webサーバの場合、客を待たせる時間になっちゃうから。

総処理時間合計のベンチマークではいい性能に見えるんだろうけど…

ネットワークの遅延の方が大きいような。
それ以外にも、例えばnagleが有効ならば数百msの遅延が簡単に発生するわけで。

で、結局は道具の使い方の問題だと思うし。

例えば、秒単位の遅延が見込まれる処理(CGIの実行など)は
別にスレッドを動かして、「実行が終わったよ」というシグナルをポストして
他のリクエストと同等のタスクとして終了処理などをするという手もあるし。

そもそも、計算だけで秒単位の時間がかかる処理をWeb鯖が行うというのは
一般的なのかどうか。
(ディスクI/OやDBとの交信など、スレッドがブロックした場合には
次のタスクの実行が開始される、という仕様だから)

>>769
この板でそんな物説明する奴が悪い。シッシッ！

>>１の想像を越えた良スレになりつつある件について

久々に伸びてると思ったが、
unix板の悪い面が出まくりだな。
windowsアレルギーってまだあるんだ。

>>784
具体的に

windows機雷

IOCPがUNIXで実装されないことについての具体的な答えはなかったな。
実装されないことについての必然的な理由が必要というわけではないけど。

乙

と思ったらSolarisにはあるんだな。
http://developers.sun.com/solaris/articles/event_completion.html

これちょっと調べて見るか。

>>789
>>686

pthread_createして生成されたスレッドが死んでってのを
何十回か繰り返すとpthread_createからENOMEMが帰ってくるんだけど
何が足りないの？
空きメモリは有るみたいだし，生きてるスレッドは１個だけで
RHL9なんすけど．

>>791
detachかjoinしてる?

>>792
>detachかjoinしてる?
791がそれをしてないに、10000 マルク。

すっかり忘れてた．

pthread をソケット通信で試しに使い始めてみたんですが、どうやらリークしてるっぽくて、

mtrace の結果と objdump を元に、glibc のソースから pthread.c や specific.c をつき合わせたら、
int __pthread_initialize_manager(void)
の
  /* Setup stack for thread manager */
  __pthread_manager_thread_bos = malloc(THREAD_MANAGER_STACK_SIZE);
↑↑↑↑　こいつが１度だけ呼ばれて 8160 byte かかえたまま free されてないっぽいんです。
また実行中に
int __pthread_setspecific(pthread_key_t key, const void * pointer)
の
void *newp = calloc(PTHREAD_KEY_2NDLEVEL_SIZE, sizeof (void *));
も free されないので、accept の回数を重ねるたびにどんどん膨らんでいきます。

これについて何か既出の情報ってありますか？

うおぉぉぉ 真上に解決策が書いてあるじゃまいか orz

pthread_detach し忘れてますた
スレ汚しすまそ

そういえば、joinでは複数のスレッドを待てませんが、
どこかでデッドロックを避けるためだと読んだことがあるのですが、
具体的には書いてありませんでした。
知ってる人いますか？

>>797
どこに書いてあった？

>>798
どこだったか思い出せないのですが
「昔はwaitallだかwaitanyの様なのがあった」らしいです。
ゾンビネタを読んで疑問を思い出しました。

<ちら裏>
pthread を使ったソケットプログラム。

accpet したソケット fd を子スレッドに void* で渡す、定番のコードのつもりだったんだけど、
void * のポインタなんだからと思って

fd=accept(listen, &addr, &addr_len);
pthread_create(&id, NULL, child_func, (void *)&fd);

と参照渡しをしたところ、同時多数アクセスがあったとき、親スレッドと子スレッドで異なる
fd にアクセスする奇怪現象に悩まされた。子スレッドが fd を実際に読むする前に、
親側では次の accept が呼ばれて fd が書き換わってたというオチ。素直に

pthread_create(&id, NULL, child_func, (void *) fd);

と値渡しにすることで解決。

お粗末。
</ちら裏>

粗末だな……

accept() してから pthread_create() よりも、

「まずは listen() したソケット用意して、
そいつを非ブロックモードに設定して、
同時接続最大数のスレッドを pthread_create() して、

生成されたスレッドそれぞれで mutex 獲得して、
listen ソケットを accept() して、
mutex を解放。

accept() の戻り値が 0 以上だったら、その戻り値を接続相手との通信ソケット記述子に使用する。
通信終了したら accept() の戻り値を close() する。

mutex 獲得に戻る。」

が、いいんじゃないの? ちがうの? いつも、こーゆーふーにしてたよ…

>>802
非ブロックモードにしないでみんなで
acceptでスリープするのはどう？
あとmutexは短時間の排他に最適化されるのでmutex+acceptはまずい。
sem_wait/postか、condvarをつかう。

>>803
そのやり方は、設計に依存するんじゃね？

>>802
おいおい……それ思いっきりビジーループしてるじゃねえか。

却下だ、却下。

>>805
802が暗黙の了解で select/poll してると想像してみるテスト

>>805
> >>802
> おいおい……それ思いっきりビジーループしてるじゃねえか。
> 却下だ、却下。
mutex の獲得で待ち合わせしててもダメなの?

>>807
mutexをそういう風に使ってはいけないと婆さんが言ってました。

acceptしてそのまま処理するのが普通なの?

私はaccept専用スレッドつくって、acceptしたら別スレッドに処理させるかな。
そしたらacceptスレッドは、接続があるまで(acceptでもselectでも)寝てればいいし。

どうでもいいのなら、1接続1スレッドでスレッド使い捨て、
まじめに作るなら、1スレッドで複数の接続を扱うようにする。
スレッド数はCPU数とかに応じて適当に決める。


でも、みんなでacceptするやり方だと、
acceptすべきかどうか判断するのが簡単になりそう。
自分が上限まで接続を扱ってたら、acceptしなければ良いだけだし。

acceptして放置するのと、acceptしないのってどっちが良いんだろうか…

ヘビーロード、特に接続到着について、サーバは両者の組み合わせ。

>>809
確か、accept()をすると、SynAck返したはず
だから、実行するのとしないのとでは挙動に違いがでるよ。

うん。そこまではわかるんだけど、
いずれ処理してやれるなら、とりあえずacceptした方が良いのかな。

>>812
いやだからさ、TCPコネクションにタイムアウトさえしなければ
どっちでもいいと思うぜ。

>>812
listen状態のsocketのbacklogを伸ばす方法もある。

>>811
ACKは、acceptしなくても返すんじゃないのか？
listenのバックログに余裕がある間は。
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-3.html#ss3.3
って、その事だと思うんだけど。

とすれば、単位時間に処理できる限界を超えない限り、
accept自体は急ぐ必要は無いでしょ。

>>815
あう。
そうだったね。ｽﾏｿ > 809

といっても、accept()を思い出したように処理してるアプリなんて今まで見た事ないなぁ。

「accept自体は比較的重い処理なので
listenしているスレッドではacceptableというイベントのみを検知して
accept自体はワーカースレッドに投げて処理させる」
という方式は、どこかで見たよ。

「acceptが重い処理」というのは、たぶんWinsockのIOCPとかAcceptExとかその辺を調べている時に
見たんだと思うけど、accept時のカーネル内部での処理の重さは、
Windowsでもそう変わらないでしょ、たぶん。

acceptが重いんじゃなくて、
acceptをたくさん動かすためにはその分プロセスが必要だからでしょ?

Solarisなんかはthread単位で大丈夫だけれど、それでもselect/pollよりリソース食う。
apache2はその辺いろいろカスタマイズできるよね。

なんでacceptとプロセスが関係あるのさ？
>>818がWindowsの話なら、マルチプロセス型のサーバーなんか絶対あり得ないのに。

>>818
他のOSは知らんけど、Linuxに限って言うとacceptはそんなに重い処理では無いよ。

>>821
どんな OS でもおおむね以下のような処理になると思われる.

受信割り込みから起こされた処理が, コネクション確立を確認
したら, その情報を listen queue につないで, accept してる
奴を起こす

accept は
while (listen queue が 空)
寝る
socket 作って listen queue から取り出した情報を設定(これ
は受信側でやってもいいし...)
該当 socket をプロセスなりファイルディスクリプターなり
に関連付する
上記 socket から peer address 情報引っ張ってきて引数で
指定された場所に書き込む

結局 accept って寝てるだけじゃん

>>822
他のOSも似たような実装だと思うけど、
そうすると、818がWindosにおいてacceptが比較的重いと言ってるのが謎。

名前欄間違った。
818でなくて、821ね。

>>822
> while (listen queue が 空)
> 寝る

signal_wait(listen_queue);

とevent駆動型になっている

>>823
あんなの>>818の勘違いでしょ。

>>825
> signal_wait(listen_queue);
やってること(つかセマンティック)はいっしょじゃん.
要は寝てると...

whileで書くとbusy waitみたいだからいくない

>>828
寝るって書いてあるのに busy wait も何もあったもんじゃないような気が...

>>828
>whileで書くとbusy waitみたいだからいくない
それ既成概念にとらわれているよ。
オープンソースなカーネル見ればわかるよ。