5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

pthread地獄

1 :亡者1:02/01/13 23:52
Posixな糸に群がる亡者どものスレ。地獄の底でsage進行。
徳の高い人はpthread天国でも可。

2 :1の罪状:02/01/13 23:55
サーバを開発する事になった

select(2)を使うのはイヤだったのでpthreadを使ってみる事にした

OSの選択権があったので、*BSD, Linuxのpthreadの実装を調べてみた

FreeBSD 3.xとOS標準のユーザレベルpthreadを使う事にした

その時一番慣れていた言語だったのでC++を使う事にした

C++の例外処理を本格的に使った事がなかったので、評価を兼ねてバンバン使ってみた

3 :1の罪状:02/01/13 23:56
かなり完成に近付いてから、何かおかしい事に気付いた

調べてみた

libgccでpthreadと例外フレームがふしぎなおどりをおどっていた

( ゚д゚) ポカーン

まぜるな危険

ガ━━(゚Д゚;)━━ソ!

4 :名無しさん@お腹いっぱい。:02/01/14 00:25
そうなん?pthread(3)には何も書いてないな。

5 :名無しさん@お腹いっぱい。:02/01/14 00:28
libgcc2.c はpthreadを意識してるよなあ…
どの辺みればふしぎなおどりの詳細がわかるの?>1

6 :1:02/01/14 00:39
>>5
まさにそのあたりだった。libgcc_r.aをデッチあげてごまかした。

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

7 :名無しさん@お腹いっぱい。:02/01/14 00:46
ああ、そういえば昔、C++とpthread絡みで
Mozillaがbrokenでどうのこうのとかいろいろあったような気が…

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

8 :1:02/01/14 01:01
>>7
> 結論としては「まともなthread使いたかったら商用UNIX使え」だね。

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

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

9 :名無しさん@お腹いっぱい。:02/01/14 01:04
そもそもpthread自体がいまいちだと思うんだが。
同期にしてもプリミティブな物しかないから、mutex使って自分でちまちま
実装しなきゃいかんし。

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

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

10 :1:02/01/14 01:14
9はpthreadの規格自体がいまいちと思ってるんだよね?

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

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

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

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

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

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

14 :1:02/01/15 02:14
Pth API見たよ。event facility イイ!

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

IBMの努力でNGPTがLinux標準の座をGET

なし崩し的に他OSもAPI取り入れ

Posix標準化

てなシナリオキボン

15 :名無しさん@お腹いっぱい。:02/01/16 00:55
FreeBSD 5-current にて実装中の KSE の解説
http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html

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

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

17 :1:02/01/19 22:25
今日のpthread探訪。pthread規格の一次情報源はこれでいいのかな?

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

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

18 :1:02/01/24 21:43
忘れないうちにメモしとく。全12ページ。気が向いたら読もっと。

NetBSD Scheduler Activations:

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

19 :1:02/01/24 21:47
間違った。"Scheduler Activations on BSD"だ。>>18

20 :1:02/02/06 01:49
保守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がリリースされたら尻に火をつけます。イヤでも。

21 :cthread実験中:02/02/06 08:20
亡者1さん、応援してます。
簡単でもいいので報告頼みます!

22 :1:02/02/06 08:57
んじゃ、プチ地獄情報。NetBSD-currentのnathanw_sa branchでは
Apache2のコンパイルが通る模様。

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

23 :名無しさん@お腹いっぱい。:02/02/06 10:09
>>17
SUSで我慢。

>>22
sigwait は?


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

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

25 :名無しさん@お腹いっぱい。:02/02/06 12:48
最近C系の言語でマルチスレッドプログラミングしてねえなあ。
Javaでおもちゃつくるぐらいしかしてないからなあ。


26 :23:02/02/06 12:54
>>24
SUS は
ttp://www.unix-systems.org/version3/
このへん。


27 :亡者23:02/02/06 12:57
>>25
java は楽でええよね。


28 :亡者1:02/02/06 13:41
Single Unix Specificationか。ありがと。>>23

29 :名無しさん@お腹いっぱい。:02/02/06 15:24
ヲレは Ruby thread…。DOS でも使える thread なんだい! と強がる。

30 :1:02/02/06 22:16
>>29
RubyのThreadはいいよね。1.0の頃から超ラクチン生活だったよ。

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

32 :名無しさん@お腹いっぱい。:02/02/06 23:07
18に出てる奴は、中身を読むと、全然 scheduler activations じゃないので、
見ないほうがいい。書いた人間は、本質を全然分かってないと思われる。
オリジナルの Thomas E. Anderson のペーパーを読んだ方がいい。


33 :亡者23:02/02/06 23:21
>>32
そう言われるとむしろ読みたくなるなあ。
後で読もっと(w


34 :1:02/02/06 23:23
>>31
おお、ありがと。もう動いてるのか。

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

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

35 :1:02/02/06 23:26
>>32
オリジナルのURLキボン

36 :名無しさん@お腹いっぱい。:02/02/06 23:36
>>35

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


37 :亡者1:02/02/06 23:47
やっぱりリンク貼りは1の仕事か…
ググッて参りました。

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

38 :名無しさん@お腹いっぱい。:02/02/07 03:13
地獄に仏とはまさにこれのこと

39 :亡者23:02/02/07 08:49
>>31
イイ!

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


40 :名無しさん@お腹いっぱい。:02/02/07 11:06
>>31
なんかnathanw_saのlibpthreadとあんまり変わらないね。
当たり前だけど(w


41 :亡者1:02/02/07 22:35
>>40
あんまり変わらないのは仕組み? それとも開発の進み具合?

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


43 :亡者1:02/02/23 10:17
地獄の底で保守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
--------

44 :亡者40:02/02/24 10:45
Linus さんって、むかーし 2level thread なんていらねーYO! とか
言ってなかったっけ。まあいいか。


45 :亡者1:02/02/24 23:26
プロジェクトリーダーが前言を飜せるのはいい事だと思うな。実際の現
場はどうだか知らないけど。

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

46 :それは聞かないで:02/02/26 14:10
>>37
> http://www.cs.berkeley.edu/~brewer/cs262/Scheduler.pdf

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

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


47 :名無しさん@お腹いっぱい:02/02/26 19:32
Scheduler Activationて、感覚的には、あるスレッドがread/writeなどの
システムコールでブロックしたら、OSが新しいスレッドを作って、この
プロセスの特定のエントリポイント(たぶんユーザレベルスケジューラの
入り口)をアップコールする、でいいの?


48 :それは聞かないで:02/02/26 20:47
>>47
その時新たに作るか、幾つかあるkernel threadをうまく使い回すかは、
thread API libraryが決める。Scheduler Activationはそのための機構を提供。

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

49 :名無しさん@お腹いっぱい。:02/02/26 21:23
>>48

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

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



50 :それは聞かないで:02/02/26 21:52
>>49
> これはどっちかっていうと実装の詳細に入る話だな。

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

51 :49:02/02/26 22:04
> 挙動が変わってくるから仕様の範疇じゃん

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

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

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


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

53 :名無しさん@お腹いっぱい。:02/02/27 00:18
> ところで、Solarisでは、ユーザレベルのM:Nスレッドをやめてカーネル
> スレッドの方向に行っています。

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


54 :名無しさん@お腹いっぱい。:02/02/27 00:31
> 1:1のlibthreadが用意されているし、

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

55 :名無しさん@お腹いっぱい。:02/02/27 01:18
>>54
solarisのlibpthreadには実装の実体は有りません。pthreadの関数も実際には
libthread内で実装されています。

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

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

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

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

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

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


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



58 :名無しさん@お腹いっぱい。:02/02/27 02:03
>>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)

以下略


59 :それは聞かないで:02/02/27 02:52
これですかねぇ。
http://www.sun.de/Partner/Softwarepartner/Oracle/Technik/pdf/oracle_on_Solaris.pdf

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

60 :名無しさん@お腹いっぱい。:02/02/27 03:03
> solarisのlibpthreadには実装の実体は有りません。pthreadの関数も実際には
> libthread内で実装されています。

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

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

なるほど。どうもありがとう。
ふーん、現在の 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 関係者


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

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

62 :亡者1:02/02/27 14:52
うお、何かいっぱい書き込まれてる!

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

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

64 :名無しさん@お腹いっぱい。:02/02/27 18:21
>>62
M とか N とかは
整数という程度の意味かと。


65 :名無しさん@お腹いっぱい。:02/02/27 20:38
>>62
M:Nは、2レベルスケジューリングで、たとえばM個のユーザスレッドをN個の
カーネルスレッドの上でユーザレベル(ライブラリ)でスケジューリングします。
(通常のカーネルのスケジューラは、この下の階層となり、カーネルスレッド
をスケジューリングします)

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

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


66 :亡者1:02/02/27 21:31
>>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

スレ違いな話題スマソ。

67 :名無しさん@お腹いっぱい。:02/02/28 01:30
>>65
>プロセスのスケジューリングと同じくカーネルまかせになります。

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

68 :名無しさん@お腹いっぱい。:02/02/28 01:53
調べてないからなんとも言えないけど、ユーザスレッドがロック取った
ときにCPUのpinをしているのかなァ?(勉強不足で必然性がわかりません)

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

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

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

69 :名無しさん@お腹いっぱい。:02/02/28 04:13
Solarisの話しでなくて申し訳ないですが、
M:NはAIXにもあるこれら↓と同等ですよね?
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365a81.htm

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

70 :名無しさん@お腹いっぱい。:02/02/28 04:53
Compaq (旧DEC)Tru 64 UNIXもそう。
Tru 64は、thread framwork(バカチョンアプリスケルトン)もあるよ。
MacOSXはkernel threadのみだな。

71 :名無しさん@お腹いっぱい。:02/02/28 08:10
>>68
68を書き込んだ者です
良く考えてみると、カーネル内のlock(排他制御)の話と、ユーザス
レッドに提供されているのロックの話はレベルが全く異なるので、 
68の書き込みは無視して下さい。

72 :名無しさん@お腹いっぱい。:02/02/28 19:17
>>56>>63
あの本は麻薬だ!
スチーブンス先生の霊がのりうつってます。

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

73 :名無しさん@お腹いっぱい。:02/02/28 20:52
72に、そんなに高速なIPCが必要なんか。
もしそうなら、全体設計を見直した方がいいと違うんか、
と問い詰めたひ…

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


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

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

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


75 :名無しさん@お腹いっぱい。:02/03/01 01:15
>>74
>比較的密な分散システムって、何で書くのがしぇいかいですか?
CORBAはどうですか?これならCも逝けますよ。

76 :    :02/03/01 01:26
>>74
Apollo Domain はどうよ。

77 :茶々:02/03/01 01:29
>>75
分散オブジェクト地獄の予感…

78 :名無しさん@お腹いっぱい。:02/03/01 04:12
>>74
あの本、訳者も訳者だしねぇ。クソ訳本書いている人は、あの本読んで
反省して欲しいところ。

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

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

79 :名無しさん@お腹いっぱい。:02/03/01 04:17
やっぱJavaが一番いい答えだな

80 :名無しさん@お腹いっぱい。:02/03/01 16:46
>>79
俺みたいな初心者にとっては何するにも楽な言語。それがJava

81 :名無しさん@お腹いっぱい。:02/03/02 01:36
この間C++でCORBA client作ったんだけど、各ORBで色々こまかーい違いが
多くてうんざりしたよう。minor codeの取得方法くらい統一しとけ。

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

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

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

82 :亡者1:02/03/09 14:31
すごい勢いで沈んでるので保守sage。
新ネタないのでリンク集を貼ってみる。

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

83 :仕様書無しさん:02/03/09 16:48
1さんの意向に反してあげちゃいまーす

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


85 :名無しさん@お腹いっぱい。:02/03/18 18:26
忘れたころにこのスレを見るのが
ひそかなたのしみな今日このごろ。
>>1さん頑張って。


86 :亡者1:02/03/20 22:22
>>85
ありがとう。忘れられた頃にがんばるよ。

87 :名無しさん@お腹いっぱい。:02/03/21 01:59
ageとくよ

88 :名無しさん@お腹いっぱい。:02/03/23 04:41
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


89 :88:02/03/23 04:42
/* テストプログラム */
#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;
}


90 :仕様書無しさん:02/04/09 23:34
apache2.0出ましたねぇ
ベンチの結果とかどんどん出てくるのかな?
Linuxも2.5系のスケジューラはかなり強力そうだし
Solarisと比べてどうなんだろ。

91 :名無しさん@お腹いっぱい。:02/04/10 01:42
worker MPMってずいぶん変則的という気がするのですが(1プロセスあたりの
スレッド数固定で,プロセス数を増減させる).
perchild MPMの方が本来のmultithreadingのやり方に近いと思うのですが
(プロセス数固定で,スレッド数を増減させる),
  This MPM does not currently work on most platforms. Work is ongoing to
  make it functional.となっているのは,multithreadサポートが完全ではないOSのためで,
worker MPMというのはある意味苦肉の策なのかな?

92 :亡者1:02/04/10 06:00
ああ、とうとうApache2.0出ちゃった。

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

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

93 :亡者1:02/04/10 06:03
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

94 :亡者1:02/04/10 06:06
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で確認した。

95 :亡者1:02/04/10 06:07
つづき。

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で確認した。

96 :亡者1:02/04/10 06:09
もう一発。

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

97 :亡者1:02/04/10 06:13
以下の関数は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

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

98 :亡者85:02/04/26 01:39
忘れたころに見に来ました。
あなた〜かわりは〜ないですか〜♪


99 :亡者1:02/04/26 01:42
日ごと〜疲労がつのります〜♪

100 : :02/04/27 06:12
面白い

135 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)