2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 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
面白い

101 :名無しさん@お腹いっぱい。:02/05/02 00:16
勉強になるのでたまにココ覗いております。
頑張って下さい。

102 :亡者1:02/05/12 23:53
コソーリ保守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

103 :何が何でも Solaris IA版存続を願う会2ch支部長:02/05/17 12:03
ただ,Solaris9だとuser-level threadをLWPに1:1にboundするスレッドライブラリ
のみになっていますね.Solaris8での"/usr/lib/lwp/libthread.so.1"(代替
スレッドライブラリ)がSolaris9では"/usr/lib/libthread.so.1"になっていて,
"/usr/lib/lwp"配下にはシンボリックリンクが置かれているだけになっています.

104 :名無しさん@お腹いっぱい。:02/05/25 17:56
性能だしにくいつーのもあったのかな? < 1:1のみ化

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

105 :名無しさん@お腹いっぱい。:02/05/26 02:15
質問と相談があります。

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

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

106 :105:02/05/26 12:11
自己レスです

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

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

107 :デフォルトの名無しさん:02/05/26 21:58
関係ない話で申し訳ないのですが、linuxにおいてm:nスレッドを
実現するには、カーネルの書き直しに近い作業をやらないといけないのでしょうか?

108 :名無しさん@お腹いっぱい。:02/05/26 22:23
>>107
102のリンク先を読もう。

109 :名無しさん@お腹いっぱい。:02/05/27 00:54
>>107
すくなくとも、カーネルスレッドの管理構造体くらいは修正せんといかんじゃなかか?


110 :名無しさん@お腹いっぱい。:02/05/29 21:17
Linux は早いとこ clone() を obsolete にせな。

111 :名無しさん@お腹いっぱい。:02/05/29 23:17
>>110
> Linux は早いとこ clone() を obsolete にせな。

そのあとどうするの?

112 :名無しさん@お腹いっぱい。:02/05/30 02:55
psしたときにスレッドがボロボロ見えたときに、
なんだかやるせない気持ちになるのはおれだけですか?

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

113 :名無しさん@お腹いっぱい。:02/05/30 08:11
solaris で ps -L するとボロボロ出ますね。
つかプロセスがボロボロ見えるのとどう違うの?

114 :名無しさん@お腹いっぱい。:02/06/02 14:56
よーしパパ NetBSD 用に clone(2) 使ったアプリ書いちゃうぞー


115 :名無しさん@お腹いっぱい。:02/06/13 13:53
NetBSD SA ぷれぜんてーしょんあげ。

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


116 :名無しさん@お腹いっぱい。:02/06/13 22:18
>>107
NGPT
http://www-124.ibm.com/pthreads/
http://www-124.ibm.com/pthreads/docs/unstable/RELEASE

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

117 :名無しさん@お腹いっぱい。:02/06/15 20:57
ports/devel/linuxthreads
使えば良いんじゃないの?>1:1thread
Linux ABIのスレッドライブラリじゃないよ。

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

118 :名無しさん@お腹いっぱい。:02/06/18 16:42
最近 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です。


119 :名無しさん@お腹いっぱい。:02/06/18 23:27
pthreadの同期機構で、実行権取得の"順序"が保証されるものは存在しないはず。
FIFOな待ち行列作るしかないんじゃあ。

120 :118:02/06/19 11:46
しかし、シグナルされたスレッドが
mutex ロックの待ち行列(たぶんあるんだろ?)の
頭に追加される事が保証されなきゃ
pthread_cond_wait
のパラメータに mutex が何のために
あるのか理解できん・・・。ほんとクソだな。

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



121 :名無しさん@お腹いっぱい。:02/06/19 12:49
>>120
> pthread_cond_wait
> のパラメータに mutex が何のために
> あるのか理解できん・・・。ほんとクソだな。
教科書読んだら? もしくは自分で簡単なthread機構を実装してみれば理解できるよ。

122 :121:02/06/19 12:55
ゴメソ。ageちゃった。

123 :名無しさん@お腹いっぱい。:02/06/19 13:52
教科書って何の?
何か学べるものがあるの?
pthread がクソなのは誰もが認める所じゃないのかなぁ?
妥協して、こんな仕様になった、と言う事が言いたかったのかな?
まあ、それならわかるけど。

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


124 :名無しさん@お腹いっぱい。:02/06/19 15:37
>>123
俺の教科書には

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

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


125 :名無しさん@お腹いっぱい。:02/06/19 16:35
>>124
お返事、ありがとうございます。
現在、SOLARIS インターナルという本で勉強中です。
この本は良書でしょうか?
あと、「俺の教科書」ってやつを教えてください。

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

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


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

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

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

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



128 :名無しさん@お腹いっぱい。:02/06/19 18:39
第2版っていうぐらいだったら、ちゃんと Vol.1 なのか、Vol.2 なのか書けYO!ヴォケ
で、Vol.1 のほうだな。

129 :名無しさん@お腹いっぱい。:02/06/19 18:43
R.Stevensの本は買いましょう。ぜったい損しないから。

130 :名無しさん@お腹いっぱい。:02/06/19 19:27
実行権取得の順番が保証される同期機構ってwindowsにもsolarisにも
ないと思うんだけど・・・

131 :名無しさん@お腹いっぱい。:02/06/19 19:46
>>126 >>127 >>130

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

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

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

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

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

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

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

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




132 :名無しさん@お腹いっぱい。:02/06/19 21:26
>>131
あなたが、これから改心できるかどうかは
あなた自身の心がけ次第です。

133 :名無しさん@お腹いっぱい。:02/06/19 21:57
>>131 >>132
氏ね

134 :名無しさん@お腹いっぱい。:02/06/19 22:51
氏ねやカス

135 :名無しさん@お腹いっぱい。:02/06/20 02:07
> 実は、やりたかった事は、Windows の WaitForMultipleObjects

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

136 :名無しさん@お腹いっぱい。:02/06/20 02:19
>>131
> 別に pthread 実装上の都合とかは興味ないです。

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

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

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


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


137 :名無しさん@お腹いっぱい。:02/06/20 02:22
unix板にもこういう困ったチャンが居るのか・・・寒


138 :名無しさん@お腹いっぱい。:02/06/20 02:23
> 実装できます。

嘘付き。

139 :名無しさん@お腹いっぱい。:02/06/20 02:29
>>130
>実行権取得の順番が保証される同期機構ってwindowsにもsolarisにも
>ないと思うんだけど・・・

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

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

140 :名無しさん@お腹いっぱい。:02/06/20 04:47
>126、131
Windowsでも隠蔽されてねーのでわ?
http://www.mtl.t.u-tokyo.ac.jp/~nminoru/pc/event.txt

141 :名無しさん@お腹いっぱい。:02/06/20 04:57
>>125
POSIXスレッド プログラミング
David R.Butenhof (ASCII Addison Wesley Series)

142 :名無しさん@お腹いっぱい。:02/06/20 09:53
>>138
thread 3本でwaitして、どれかがmutex_unlockすればいいだけでしょ?

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

143 :名無しさん@お腹いっぱい。:02/06/20 11:14
同じ様な事なら、そりゃ簡単。

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

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


144 :名無しさん@お腹いっぱい。:02/06/20 11:53
Inside NTだったかで「シグナル状態になってWaitFor〜の待機が
解けた場合、一時的にそのスレッドの優先度をageる」とか書いて
あったのを今ふと思い出した。

145 :名無しさん@お腹いっぱい。:02/06/20 12:24
>>137
学生かい?勉強頑張れや。

146 :名無しさん@お腹いっぱい。:02/06/20 22:19
>thread 3本でwaitして、どれかがmutex_unlockすればいいだけでしょ?

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


147 :名無しさん@お腹いっぱい。:02/06/20 22:51
> processのwaitでもう一本かな。
> 確かに糞だ。

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


148 :名無しさん@お腹いっぱい。:02/06/28 18:18
KSE M3 commit予告age

149 :名無しさん@お腹いっぱい。:02/06/28 21:58
糞は何本までOKでしょうか?

150 :名無しさん@カラアゲうまうま:02/06/28 22:03
漢なら一本糞。

151 :名無しさん@うんこでいっぱい。:02/06/30 23:06
ちょっとやそっとで流れないうんこをした後は充実感があります。

152 :名無しさん@お腹いっぱい。:02/07/04 00:39
正直、SOLARISイソターナルはマルチスレッダーが欲しい情報がありのまま書いてないと思われ
(穴があくほど読んで感覚的にも理屈でも理解できたらコーディングに落とせると思うけど)


153 :名無しさん@お腹いっぱい。:02/07/09 17:38
はやく徳をためなければ...。


154 :名無しさん@お腹いっぱい。:02/07/10 00:18
この板なんなの?
学生が多い為か、こんな人ばっかだな。
もっとプログラム組もうぜぇぇぇ!!本ばっか読んでるな!!

155 :名無しさん@お腹いっぱい。:02/07/10 02:52
>>153
×徳
○便

156 :名無しさん@お腹いっぱい。:02/07/10 22:01
>>144
「きっとそいつはクリティカルセクションやるんだろうなーやるんだよね?
 うわーうぜーはやくおわらせてしまえ」

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

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

157 :名無しさん@お腹いっぱい。:02/07/11 10:25
>>154 は現場たたきあげ。


158 :名無しさん@お腹いっぱい。:02/07/12 10:32
pthread 触ったあとに、
WaitForMultipleObjects 使うとなんか感動するね。
イベントを取りこぼす事がないので、安心して使える。
変な小細工いらないし。

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


159 :名無しさん@カラアゲうまうま:02/07/12 12:37
取りこぼす?
WaitForMultipleObjectsもソケットが使えりゃな。

160 :名無しさん@お腹いっぱい。:02/07/12 13:18
え?つかえるけど、、、

161 :名無しさん@お腹いっぱい。:02/07/12 23:12
でも、WaitForMultipleObjects 使うと一つのスレッドですべて出来るから
マルチスレッドにならないんだよね。
ただ、64個しか待てないないから、その場合はスレッドを分ける必要があるけど。



162 :名無しさん@カラアゲうまうま:02/07/13 04:48
>>160
詳細は忘れちゃったんだけど、blockingに関して制限がなかったっけ。

163 :名無しさん@お腹いっぱい。:02/07/13 14:33
WaitForMultipleObjectsって結局「オブジェクト指向select」だから
pthreadと比較するのはちょっと違う気がする。

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

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

164 :名無しさん@お腹いっぱい。:02/07/13 16:31
>>158
pthead生で使わずにNGPT使えばいい。

165 :名無しさん@カラアゲうまうま:02/07/16 09:39
>>160
ソケットを指定するのは実装依存と聞いたがな。
WSACreateEvent()を使わないとダメだとか。

166 :名無しさん@お腹いっぱい。:02/07/16 20:33
>>165
実装依存って、どう言う意味?
CreateEvent と WSAEventSelect で普通に使えているよ。


167 :名無しさん@カラアゲうまうま:02/07/17 06:16
>>166
WSAEventSelect抜きでソケットを直に使うという話。
オレの聞いた話でもWSAEventSelect使えってことだったけど、non-blockingに
なっちゃんだよね、たしか。
WaitForMultipleObjectsのときだけWSAEventSelect使うとかできるのかな。


168 :名無しさん@お腹いっぱい。:02/07/17 08:16
  [参考]
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

169 :名無しさん@お腹いっぱい。:02/07/17 23:58
>>167
やっぱ、言っている事わかんないや。
non-blockingになるのは当然では?
ブロックしたくないから WaitForMultipleObjects を使うんだし。
もしかして、何か勘違いしている!?

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


170 :名無しさん@お腹いっぱい。:02/07/18 04:59
アトミックな値のインクリメント/デクリメントの命令
(Win32でいうところの InterlockedIncrementとか)
って pthread とか posix とかで存在しないんでしょうかね。
イチイチmutex使うのもアホらしいんですが・・・


171 :159:02/07/18 10:07
>>169
いや、たぶんこっちの勘違いだろう。thx

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


172 :名無しさん@お腹いっぱい。:02/07/18 23:53
>>170
単一のインストラクションで実行したい、ということなら、
もろCPU依存だからPortableじゃない。よって、"P"OSIXの範囲外。

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

173 :名無しさん@お腹いっぱい。:02/07/19 16:04
>>158 WaitForMultipleObjects 使うとなんか感動するね。
イベントを取りこぼす事がないので、安心して使える。

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


174 :名無しさん@お腹いっぱい。:02/07/19 23:32
>>172
ありませんか・・・ガックシ
今のところ実行する予定のCPUは限られているので、
それで逃げとくことにしまする。

175 :名無しさん@お腹いっぱい。:02/07/20 05:51
>>174 こうすれば気分的には少し楽になるかもね(?)

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

176 :名無しさん@お腹いっぱい。:02/07/20 09:51
>>173
バカチョン系API(というかframework)だから、
スケジューラ必要な時は自分で書かないと駄目だろ。
DB journaling engineを書く時のように。

177 :名無しさん@お腹いっぱい。:02/07/20 12:43
>>176
最初に見付かったイベント以降を全部タイムアウト0でWaitForSingleObjectす
るとかかな?


178 :名無しさん@お腹いっぱい。:02/07/21 00:00
sscliにInterlocked〜系ありましたわ。あはは。
これかっぱらっとこう。

179 :名無しさん@お腹いっぱい。:02/07/21 03:59
sscliってなんだろうと思ってぐぐってみた
マイクロソフトのアレか

180 :名無しさん@お腹いっぱい。:02/08/03 04:56
64ビットアドレスのソフト環境でのPthreadは、参考書が大抵32ビット
アドレス環境にもとづいてかかれているので、よくバグをいれてしまう。

181 :名無しさん@お腹いっぱい。:02/08/03 09:35
>>180
ん、例えば?
stdint.hとかptrdiff_tとかちゃんと使えば、んなことないんじゃないの?

182 :名無しさん@お腹いっぱい。:02/08/03 12:58
LP64だとsizeof(int)!=sizeof(void*)だからねえ
むしろ旧いunixから抜けきれない人たちが苦労するんじゃないかなあ

183 :名無しさん@お腹いっぱい。:02/08/03 13:23
>>172
範囲外かどうかは解釈によると思うんだけど。

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

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

int pthread_atomic_inc(int *p);

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

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

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

184 :名無しさん@お腹いっぱい。:02/08/03 17:27
> 今の大抵のCPUならアトミックな整数演算命令持ってるし、
> もしも使えないならmutex使った実装にしとけばいいじゃん。

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

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

185 :183:02/08/03 23:33
>>184

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

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

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

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

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

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

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

186 :名無しさん@お腹いっぱい。:02/08/04 09:50
>>183
> 今の大抵のCPUならアトミックな整数演算命令持ってるし、

持ってね─よ、アフォ!


187 :名無しさん@お腹いっぱい。:02/08/04 09:51
>>185
Win32 thread APIと比べるべきなのは、
pthreadじゃなくてDEC thread(on pthread)辺りだよ? 理解できてる?

188 :名無しさん@お腹いっぱい。:02/08/04 13:38
>>187
そのDEC threadって、HP-UXやSolarisなんかで(追加ライセンスも無く)
普通に使える物?

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

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

189 :名無しさん@お腹いっぱい。:02/08/04 13:46
この板は田舎モンが多いのか、
win32がイイとか書くと噛み付かれるからやめときー>>185
つか、実用で揉まれないといいものにならないよね。

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

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

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

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

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

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

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

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

191 :名無しさん@お腹いっぱい。:02/08/04 14:35
>>185
> 1. 単純なアトミック演算関数
>  -> アプリ毎にアセンブリ言語のコード持たなきゃいけないの?

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

192 :名無しさん@お腹いっぱい。:02/08/05 00:44
>>183=185
sysV IPC って知ってる?

193 :183:02/08/05 11:17
>>192
知ってるよ。

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

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

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

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

194 :名無しさん@お腹いっぱい。:02/08/05 19:48
>>191
いや、アトミック演算って、アトミック加算みたいなやつのことでしょ。
イベントカウンタモデル(Advance/Read/Await(n))で、
Advance演算を実装するのに便利な奴。

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

195 :名無しさん@お腹いっぱい。:02/08/05 19:53
>>193
> SysV IPCはプロセスがコケた時にリソースリークするのが最低。

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

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


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

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

197 :名無しさん@お腹いっぱい。:02/08/05 21:59
Java のスレッドみたいに扱いやすくて理解しやすい簡単なスレッドって
ないかな。あんまり原始的な(pthread 的な)スレッドは使いたくない。

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

198 :名無しさん@お腹いっぱい。:02/08/06 00:56
>>196
> 他のプロセッサはatomic inc/decぐらいしか無かったような憶えがある。

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

199 :名無しさん@お腹いっぱい。:02/08/06 01:09
>>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とか)の豊富さは
真似できないですな。

200 :名無しさん@お腹いっぱい。:02/08/06 07:41
Javaみたいに楽したいなら、Javaで書きゃいいじゃん…

201 :名無しさん@お腹いっぱい。:02/08/06 07:57
Java使わせてくれるんだったらJavaで書きます。

202 :名無しさん@お腹いっぱい。:02/08/06 09:01
>>199
> ただし、mutexが普通はrecursiveでない

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

203 :名無しさん@お腹いっぱい。:02/08/06 10:23
>>201
今まさにpthread地獄?

204 :名無しさん@お腹いっぱい。:02/08/14 15:39
OpenMP Fortranがあれば、pthread を使わねばならない理由は特に
ないような気がするが、そこのところどうなんですか、解説をおねがい
します。

205 :名無しさん@お腹いっぱい。:02/08/19 08:21
>>204
何を書くのだ?
GUI applicationをOpenMP Fortranで書くのか?

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


207 :名無しさん@お腹いっぱい。:02/08/21 23:43
スタック上の構造体に初期化子を与えられる処理系なら問題ないだろ。

208 :名無しさん@お腹いっぱい。:02/08/22 12:28
pthread_mutex_init()/pthread_mutex_destroy()の戻り値は無視してもよさげ。

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

209 :名無しさん@お腹いっぱい。:02/08/22 16:42
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);


210 :名無しさん@お腹いっぱい。:02/08/30 12:05
pthread_once() に渡す関数って、なんでパラメータがないんだ?
グローバル変数を使う事を強制されているな・・・

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

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

212 :名無しさん@お腹いっぱい。:02/09/18 17:34
>>206
Cの言語仕様の制約上そうならざるを得ない。

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

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

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

213 :名無しさん@お腹いっぱい。:02/09/19 00:55
GNU CommonC++辺り参考にするとか。

214 :名無しさん@お腹いっぱい。:02/09/21 22:33
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

215 :名無しさん@お腹いっぱい。:02/09/22 20:36
http://www.egroups.co.jp/message/jvm-talk/60
http://www.egroups.co.jp/message/jvm-talk/61

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

216 :    :02/09/22 21:59
>>215
雌伏

217 :名無しさん@お腹いっぱい。:02/10/12 10:39
良スレ保守sageカキコ

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

218 :名無しさん@お腹いっぱい。:02/10/12 14:27
>>217
最近のようにCPUが高速だとカーネルに出入りする回数を減らすよりも、
スケジューラを一つにしてキャッシュミスを減らすことが効果的らしいです。

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

219 :名無しさん@お腹いっぱい。:02/10/27 18:52
>>218
へぇ。

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

220 :名無しさん@お腹いっぱい。:02/10/28 13:02
>>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の方が速いような気がするんだけど、どうだろう? 論文出てないかな?


221 :名無しさん@お腹いっぱい。:02/10/28 22:23
>>220
>> M:Nの方が速いような気がするんだけど
どういう理由で?
60読んでもわからないです。

222 :名無しさん@お腹いっぱい。:02/10/29 01:04
system callなしで、schedulerが動くわけだから、
「内部割り込み、register待避」がなくて済む。
// もちろんprocess内でCPUの受け渡しが済む場合。

223 :名無しさん@お腹いっぱい。:02/10/29 22:58
で、最近は218なんだと。

224 :名無しさん@お腹いっぱい。:02/11/05 21:54
そうかそうか。>>221 読んでやっと分かった。でも技術的には
M:N の方が高度だよなぁ。俺にはやっぱり退化しているようにしか見えない。

225 :名無しさん@お腹いっぱい。:02/11/05 23:17
>>224
CPU速度とメモリ速度の比率が退化し続けるんだものしょうがないでしょ
技術が高度だとなにか良いことあるん?

226 :名無しさん@お腹いっぱい。:02/11/06 00:13
>>218の論拠が分からないんだけど、誰か説明してくれる?

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

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



227 :名無しさん@お腹いっぱい。:02/11/08 12:04
ちょほいと識者の皆に聞いてみるよ。

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

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

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

228 :名無しさん@お腹いっぱい。:02/11/14 11:23
>>227
条件変数で良いのでは?
理由は、俺がそうしているから。
特に不便はないし。

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

230 :名無しさん@お腹いっぱい。:02/12/16 23:51
pthread_spin_xxxx( )で十分な気がするんだが。


231 :名無しさん@お腹いっぱい。:02/12/16 23:53
すまん、pthread_spin_xxxx( )って、
ADVANCED REALTIME THREADSだったわ。逝ってきます。


232 :名無しさん@お腹いっぱい。:02/12/21 12:05
>>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の事を考えると…

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

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

234 :名無しさん@お腹いっぱい。:02/12/23 23:50
期待age

235 :名無しさん@お腹いっぱい。:02/12/24 00:13
>>233
有意義な反論のできる人を「厨」と呼ぶのには違和感があると思われ


236 :名無しさん@お腹いっぱい。:02/12/24 23:50
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 :名無しさん@お腹いっぱい。:02/12/25 02:21
計算主体のくせにコンテキストスイッチが多いとしたら、
それがまず間違いだと思われ。

238 :名無しさん@お腹いっぱい。:02/12/25 21:58
>>237
スレッド沢山作って、生産者&消費者モデルでデータを受け渡すような
プログラム作ると、コンテキストスイッチが増えてしまうだよ。
シミュレーション系では良くあるアプローチだと思うが、どうよ。

239 :名無しさん@お腹いっぱい。:02/12/28 10:47
良スレsage保守カキコ

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


240 :名無しさん@お腹いっぱい。:02/12/28 15:22
けど、priority inheritanceをM:Nで実装しろって言われたら泣きたい…
User spaceだけで済むはずが、kernel spaceからもロック依存関係を、
examineする必要がある。逆も…

241 :名無しさん@お腹いっぱい。:02/12/28 15:24
>>240
> User spaceだけで済むはずが、

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



242 :名無しさん@お腹いっぱい。:02/12/28 20:17
シンプルな実装のほうが、原理的には劣るものの実際は性能も出やすかったり
するからなあ。とはいえ、せっかく M:N を実装していた Solaris が 1:1 に
戻ったのはちょっと驚きだけど。

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


244 :名無しさん@お腹いっぱい。:02/12/31 03:54
>>242
>>原理的には劣る
これはどこかの仮想計算機においてのお話でつか?

245 :山崎渉:03/01/15 13:09
(^^)

246 :新年:03/01/16 18:50
NetBSD currentにSAを組み込むとかいうメールがcurrentに来てたので記念カキコ

247 :名無しさん@お腹いっぱい。:03/01/17 21:02
スレ違いだったらすまんのだけど
SysV メッセージのmsgrcv() をpthreadのスレッド内で実行したら
エラーが発生しても errno が 0 のままになってしまう。

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


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

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

248 :名無しさん@お腹いっぱい:03/01/18 00:14
マルチスレッドなのにグローバル変数で値の受け渡しができることに
疑問をいだかないのだろうか?何かマクロ定義を忘れてはいませんか?

249 :名無しさん@お腹いっぱい。:03/01/18 01:10
>>248
最近の処理系で、errnoがスレッドセーフになってないようなものが
あるの?

250 :名無しさん@お腹いっぱい。:03/01/18 01:13
errno.h はなんのためにある?

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

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

252 :名無しさん@お腹いっぱい。:03/01/18 16:52
ふつーは#ifdef _REENTとかで、ただのグローバルerrno使うか
MT safeなerrno()使うか切り分けてたりするもんだがな。

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

253 :247:03/01/20 11:31
どうもお騒がせしました。
無事に解決しました。

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


254 :名無しさん@お腹いっぱい。:03/01/22 14:42
>>253
つーか、マクロ定義だけじゃなくて、ライブラリも、
MT safe版とそうでないのを、コンパイラのオプションで切り替える環境があるから、
error.hだけじゃなくて、コンパイラのマニュアルも読め。
# -pthreadとかね。

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


255 :名無しさん@お腹いっぱい。:03/01/23 21:18
困ったときは man !

256 :名無しさん@お腹いっぱい。:03/01/25 13:01
http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf

257 :名無しさん@お腹いっぱい。:03/02/11 17:20
pthread_spinxxxとpthread_mutexxxって何が違うのか判らないですが
mutexのほうがいろいろattrがあるのは除外して。

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

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


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

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


259 :名無しさん@お腹いっぱい。:03/02/12 06:51
NFSマウントだったときどうする気?

260 :名無しさん@お腹いっぱい。:03/02/12 08:34
>>259
普通関係無いと思うが..
flockfile で flock とかする実装があるの?


261 :名無しさん@お腹いっぱい。:03/02/14 00:46
>>259
NFSだったら何がまずい?

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

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


263 :名無しさん@お腹いっぱい。:03/02/14 12:21
正直、( ゚д゚) ポカーン

264 :名無しさん@お腹いっぱい。:03/02/17 21:16
pthread_cond_waitで多数のスレッドにお待ちいただいて、
pthread_cond_broadcastで働かせるという動きの、
単純なサンプルってないかしら。

265 :名無しさん@お腹いっぱい。:03/02/18 00:46
barrier 関係から調べたらええんでないかい?

266 :名無しさん@お腹いっぱい。:03/02/18 02:08
>>264
http://www-6.ibm.com/jp/developerworks/linux/010119/j_l-posix3.html
では?

267 :山崎渉:03/03/13 17:12
(^^)

268 :264:03/03/24 22:07
有難う御座います。

269 :名無しさん@お腹いっぱい。:03/04/07 18:33
RedHat9で採用されたNPTLって、なかなか良いのかしら。
今まではLinuxでpthreadすると各スレッドにプロセスIDが振られてたけど、
RedHat9で試すとその現象がなくなってました。
よかった おわり

270 :名無しさん@お腹いっぱい。:03/04/08 03:20
プロセスIDが各スレッドに振られると何か困るの?

271 :名無しさん@Emacs:03/04/08 23:45
>>270
シグナルの通知先に一瞬迷うこと??

272 :名無しさん@お腹いっぱい。:03/04/10 08:44
うん、シグナルの扱いが本物のpthreadとはまるで違いましたね。

273 :名無しさん@お腹いっぱい。:03/04/14 18:06
nptlのソース読むとblue threadと書いてあるね。
あの会社はなんでもかんでも青いんだね。


274 :名無しさん@お腹いっぱい。:03/04/15 05:48
聞きたいじ。

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

275 :274:03/04/15 06:05
自己レスですみません。
スタックサイズの調整でした。精進して出直してまいります。

276 :山崎渉:03/04/17 12:24
(^^)

277 :山崎渉:03/04/20 06:06
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

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


279 :名無しさん@Emacs:03/05/19 23:16
あっ、ちなみに、>>278はRedhat 7.2での話。
今だに、何故RHL7.2かは、上の人の決めた方針なので
仕方がない。

280 :名無しさん@お腹いっぱい。:03/05/20 00:51
>>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を送ることができる。

281 :動画直リン:03/05/20 01:12
http://homepage.mac.com/hitomi18/

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

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

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


283 :名無しさん@お腹いっぱい。:03/05/20 21:29
>>282
やばい


284 :山崎渉:03/05/22 01:51
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

285 :名無しさん@お腹いっぱい。:03/05/26 22:55
>>282
相当ヤバイ


286 :山崎 渉:03/07/15 11:39

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

287 :名無しさん@お腹いっぱい。:03/07/17 01:20
で結局、UlrichのNPTLて使い物になるの?

288 :33 ◆MSWG7s8tx6 :03/07/30 19:41
>>177
ワロタ

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

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

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

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

289 :名無しさん@お腹いっぱい。:03/07/30 23:25
質問なのですが、一般的に C でスレッドセーフなプログラミング
をするにはどうすればよいのでしょうか。

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

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

290 :名無しさん@お腹いっぱい。:03/07/31 00:20
>>289
> グローバル以外の普通のローカル変数はスタックに取られるから、
> こういうのは排他しなくてもいいんでしょうか。

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


291 :名無しさん@お腹いっぱい。:03/07/31 01:20
>>289
一般的というのなら「スレッド間で共有する変数、スレッド内でのみ利用する
変数をきちんと分けて管理する」ということになるんじゃないかな。
って、あんまりにも一般的すぎるか。

292 :名無しさん@お腹いっぱい。:03/08/01 00:15
>>289
漏れの理解では、
各スレッドはそれぞれのコンテキストを持っていて、
とうぜんスタックポインタも別々に持っている。
なので、スタックにとられるローカル変数は、スレッドローカルかつ関数スコープローカルになるから、
排他しなくてもいい、はず。

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

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


293 :名無しさん@お腹いっぱい。:03/08/01 06:21
>>292
> 呼び出された関数内でのローカル変数(へのアクセス)を関数スコープの外
> へ持ち出すようなのは、スレッドセーフ以前にCセーフでないから論外だし。

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

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

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

294 :_:03/08/01 06:36
http://homepage.mac.com/hiroyuki44/

295 :名無しさん@お腹いっぱい。:03/08/01 07:17
あれ、御馬鹿な疑問なんですが、スタック領域も
スレッドで共有してるんですか?今まで共有するときは
無条件でヒープに取ったメモリを共有してたのだけど。

296 :名無しさん@お腹いっぱい。:03/08/01 09:43
スタック自体は共有してないけど、おなじメモリ空間にあるんだから参照させることは当然できる。

297 :名無しさん@お腹いっぱい。:03/08/01 16:32
>>293
プププ
ねぇねぇ、ぼく、セーフの分かってまちゅかぁ?

298 :名無しさん@お腹いっぱい。:03/08/01 20:46
間違ってるのは293じゃなくて292の方だろ。

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


299 :名無しさん@お腹いっぱい。:03/08/01 22:11
>>293は、g()の暗黙の型宣言を使っている。そこがチョトセーフじゃない。

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



300 :名無しさん@お腹いっぱい。:03/08/01 22:48
8プロセッサのSMPマシンでスレッドを2つ起動して実行した場合は、各スレッドに1つずつで2つのCPUだけが使われると思うのですが、
なぜか8このCPUが少しずつ使われるという結果になってしまいました。一体どうしてでしょうか?



301 :名無しさん@お腹いっぱい。:03/08/01 23:05
>>293
>>298
あいまいな言葉でしゃしゃり出たのはスマンかった。
またいい加減な言葉づかいになるかもしれんが…。

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

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

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

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

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

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


302 :292=301:03/08/01 23:05
すまん、名前入れ忘れ。

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

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

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



304 :名無しさん@お腹いっぱい。:03/08/01 23:35
すまん、ちょっと間違えた。
lexical scopeだけじゃなく旧式lispみたいにdynamic scope
であってもscopeはscopeだから、

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

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


305 :292=301:03/08/02 02:33
>>303-304
解説thx、気をつけます。

306 :名無しさん@お腹いっぱい。:03/08/02 02:50
>>298
え〜と、スレッド間で共有するんだから気をつけなさいよってことだから、
要は>>291ってこと?

307 :ぼるじょあ ◆yBEncckFOU :03/08/02 04:56
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

308 :名無しさん@お腹いっぱい。:03/08/03 00:53
Windowsにおいては、main関数内の自動変数の方が、
グローバル変数より安全という噂は本当ですか?

309 :名無しさん@お腹いっぱい。:03/08/03 01:38
たぶんその文章は正しくないです。

310 :名無しさん@お腹いっぱい。:03/08/04 22:29
グローバル変数より危険なものってあんまり思い付かんが。

311 :名無しさん@お腹いっぱい。:03/08/05 02:26
>>308
pthread関係ある話ですか?

312 :名無しさん@お腹いっぱい。:03/08/05 05:19
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 とかもある。

313 :名無しさん@お腹いっぱい。:03/08/13 16:31


314 :名無しさん@お腹いっぱい。:03/08/14 00:33
どうでもいいけどPSPとかってぜーんぜん興味わかないんだけどw


315 :名無しさん@お腹いっぱい。:03/08/19 17:14
pipe(2) ってスレッドセーフ?
(対象は Linux, FreeBSD, NetBSD)


316 :名無しさん@お腹いっぱい。:03/09/01 21:01
なにこのスレ・・・・

317 :名無しさん@お腹いっぱい。:03/09/01 21:58
>>316
POSIX準拠なスレですが何か?

318 :名無しさん@お腹いっぱい。:03/09/02 09:12
Solaris8(gccはversion 2.95.3 20010315 (release))のpthreadを今激しく疑っているのですが、
スレッド関数の中で、fprintfを呼ぶのはやめた方が良いのでしょうか?
1年間普通に動いていたプログラムが、fprintfでcoreを吐いてしまいました。
どなたかpthreadを熟知している方、ご指導よろしくお願いします。

319 :名無しさん@お腹いっぱい。:03/09/02 11:47
>>318
> スレッド関数の内で、fprintfを呼び出すのはやめた方が良いのでしょうか?

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

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

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

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

321 :名無しさん@お腹いっぱい。:03/09/02 13:12
>>320
pにかぎらんよ。multi-thread programmingでは常に。

322 :名無しさん@お腹いっぱい。:03/09/05 15:11
>>321
FreeBSDの場合 man には MT-safeかどうか書いてないようなんだけど、
何かお勧めの情報源ってご存知ありませんか?



323 :名無しさん@お腹いっぱい。:03/09/06 00:34
>>322
正攻法の答え
・sourceを読め
余計なお節介だが正しい方向
・FreeBSDを使うのをやめろ
ここでやればいいじゃん
・FreeBSDのversionは? 2.2.6とか言ったら死刑

324 :名無しさん@お腹いっぱい。:03/09/06 00:45
>>322
ソース。
…いや冗談抜きで。


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


325 :322:03/09/06 12:52
>>323,234

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

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


326 :名無しさん@お腹いっぱい。:03/09/07 00:24
>>325
> version は 4.7 がインストールしてありまつ。
> pthreadのべんきょしたいだけなんでつが。。。

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


327 :名無しさん@お腹いっぱい。:03/09/07 04:18
http://www.jp.freebsd.org/www.FreeBSD.org/ja/releases/5.0R/relnotes-i386.html
>libc が標準でスレッドセーフになりました。

これは嘘だったのか!? _| ̄|○

328 :名無しさん@お腹いっぱい。:03/09/07 15:20
>>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.
ってのは、そういうことを言っているんじゃないか?

329 :名無しさん@お腹いっぱい。:03/09/08 10:32
>>328
> # ただし-currentの追っかけは必須。

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

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

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


330 :名無しさん@お腹いっぱい。:03/09/08 15:29
>>329
かといって、Linux-threadはまともなの?
(pthreadの勉強ができる程度に)

331 :名無しさん@お腹いっぱい。:03/09/08 18:12
>>330
素直にSolaris使えばいいやん。

332 :名無しさん@お腹いっぱい。:03/09/08 21:38
>>330
FreeBSD 4.7との比較なら圧倒的に。

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

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



333 :名無しさん@お腹いっぱい。:03/09/08 22:20
NetBSDにしなよ

334 :名無しさん@お腹いっぱい。:03/09/08 22:52
>>332
5.1-RELEASEだとまだまだ。
signalまわりでよくデッドロックしてた。

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

335 :名無しさん@お腹いっぱい。:03/09/09 01:10
>>334
> signalまわりでよくデッドロックしてた。
> でも、最近の-currentは非常に(・∀・)イイ!!

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

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

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

336 :名無しさん@お腹いっぱい。:03/09/09 01:32
NPTLで落ち着くのは決して悪いことではないような

337 :名無しさん@お腹いっぱい。:03/09/09 14:36
NetBSD-current の pthread (1.6.x にはない) は、1.2 まで入ってた
pthread とは完全に別物です。設計は格好いいけどまだ安定してない感
じなので勉強には向いてないっぽ。

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



338 :名無しさん@お腹いっぱい。:03/09/09 23:40
>>336
なんやら怪しげと思ってたんだけど、NPTLって
使い物にな(って)るの?

339 :名無しさん@お腹いっぱい。:03/09/10 00:42
>>337
そう?
今どき 2 level thread もないだろという気もするけど...。
numa とか、どうすんのよ。


340 :名無しさん@お腹いっぱい。:03/09/10 22:23
1-level だと、どういう点で NUMA のマシンで有利なの?

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


341 :名無しさん@お腹いっぱい。:03/09/10 22:53
2-levelにしたからといって、それだけで、
CPU, kernel thread, user threadのbindingが頻繁に変るわけじゃないしね。

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

342 :名無しさん@お腹いっぱい。:03/09/10 22:55
>>339
> 今どき 2 level thread もないだろという気もするけど...。

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

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

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

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

344 :名無しさん@お腹いっぱい。:03/09/14 10:32
どちらがロック変数の数と頻度が多かったの?

345 :名無しさん@お腹いっぱい。:03/09/14 15:28
>>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に流れたこともあったし。

346 :名無しさん@お腹いっぱい。:03/09/14 18:25
 結 局 、 政 治 的 問 題 か

347 :名無しさん@お腹いっぱい。:03/09/15 14:47
HP-UXやSolarisならpthreadはまともなの?
少なくとも日本の水道や電力といったインフラ系の
会社の基盤システムの実装に使っても問題なさげ?


348 :名無しさん@お腹いっぱい。:03/09/15 20:41
>>347
商用システムが、まともでなくてどうする。
UNIXでは無理にthread使わなくてもいいような気はするが・・

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

350 :名無しさん@お腹いっぱい。:03/09/16 11:35
>>349
まともなスケジューラを実装する場合は、
カーネルの世界から、ユーザレベルの世界の降りていって、
ロックを解除して(ユーザレベルスケジューラ関連事前事後処理も)、
カーネルの世界に戻ってこなければいけない場合があるからね。

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

351 :名無しさん@お腹いっぱい。:03/09/16 16:50
pthread の標準的なベンチマークプログラムってないかな?


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

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

353 :名無しさん@お腹いっぱい。:03/09/17 20:42
>>352

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


354 :名無しさん@お腹いっぱい。:03/09/19 08:07
バスが激速だったり、CPUが少なかったりする場合は
m:nでも見劣りしない性能が出る可能性がありますね。

355 :名無しさん@お腹いっぱい。:03/09/19 16:12
>>354
> バスが激速だったり、CPUが少なかったりする場合は
> m:nでも見劣りしない性能が出る可能性がありますね。

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

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

356 :名無しさん@お腹いっぱい。:03/09/19 18:22
「少数のCPU」とは1CPUのことですか?
マルチプロセッサシステムでロック変数がCPUのキャッシュ間を
移動するのがどれほど遅いか御存じですか?
CPUが多いシステムではシステムコールやプロセス間の
コンテキストスイッチより遅いんですよ?

357 :名無しさん@お腹いっぱい。:03/09/19 20:31
>>356
それは1:1でも同じでないの?


358 :名無しさん@お腹いっぱい。:03/09/19 23:46
>>356
> 「少数のCPU」とは1CPUのことですか?

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

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

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

359 :名無しさん@お腹いっぱい。:03/09/20 01:29
>> 別に1CPUでなくてもいい。
そうするとバスコンテンションによって性能が上がらない

360 :358:03/09/20 03:54
>>359
うーん、たとえが悪かったか?

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

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

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

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

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

362 :名無しさん@お腹いっぱい。:03/09/27 16:33
>>360
CPUのグループを指定出来るのは別にかまわないが
使用するメモリもローカルになるよう指定できないと不便な気がする。
カーネル任せでも、たいてい大丈夫だと思うが・

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


363 :名無しさん@お腹いっぱい。:03/09/28 14:34
その辺を一般論で話してても不毛なんじゃないの?
個別のハードウェアでどう実装されてるかって泥臭いところを
見ていかないと大して意味のある議論にならない気がするけど。

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

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

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

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

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

366 :名無しさん@お腹いっぱい。:03/10/06 01:30
とある資料によると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

367 :名無しさん@お腹いっぱい。:03/10/08 23:56
pthreadで任意のスレッドの終了って待つことできます?

368 :名無しさん@お腹いっぱい。:03/10/09 00:11
pthread_join以外に?

369 :名無しさん@お腹いっぱい。:03/10/09 00:12
あ、複数あってどれか一つでも終了したらってことかな?

370 :名無しさん@お腹いっぱい。:03/10/09 00:21
>>369
それです。

371 :358:03/10/09 01:03
>>365
> #364は「アトミックな変数」に引っかかってる?
Yes.

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

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

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

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

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

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

373 :名無しさん@お腹いっぱい。:03/10/11 12:19
>>372
brake-handle?

374 :358:03/10/12 00:20
>>373
No.

375 :名無しさん@お腹いっぱい。:03/10/16 04:09
そうなのか。俺も373と同じ考えだったのだが。
えーと、じゃ takawata?


376 :名無しさん@お腹いっぱい。:03/10/16 21:58
野暮なインターネットですね。


377 :358:03/10/16 23:02
>>375
別に、おいらが誰だっていいじゃんかよ〜
 ̄ ̄ ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
           ∧_∧
          ( ´Д⊂ヽ
         ⊂    ノ
           人  Y
          し (_)


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

379 :名無しさん@お腹いっぱい。:03/10/24 01:53
>>378
全体に時間足りず。
その上「スレッドとは..」みたいな話に時間をかけてしまったため
最後の方はとっても駆け足だった。

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

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


380 :名無しさん@お腹いっぱい。:03/10/27 21:54
linuxで動くマルチユーザのサーバでスレッドごとに各ユーザにsetuid(2)
して、ホームディレクトリを読み書きするのがあるんですが、
これって他のOSでは使えないですよね?

381 :名無しさん@お腹いっぱい。:03/10/28 00:24
>>380

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

382 :名無しさん@お腹いっぱい。:03/10/28 05:32
forkしろよなー。

383 :名無しさん@お腹いっぱい。:03/10/28 08:08
>>380
FreeBSDにあるrfork()ってのは、(*BSDはあるんだろうか…)
forkする時に共有するresourceを指定できるはず。
porting、結構簡単なんじゃないかな。むしろLinuxの方が近い将来駄目。

384 :名無しさん@お腹いっぱい。:03/10/29 12:58
>>383
うーむ…
>The clone() function call appeared in NetBSD 1.6. It is compatible with
>the Linux function call of the same name.


385 :384:03/10/29 12:59
あ、肝心な事書き忘れ。NetBSDではrfork()は無い模様。
(で、そのかわりclone()があるという…)

386 :名無しさん@お腹いっぱい。:03/10/29 21:22
Linux API互換性持たせたいのはわかるけど、なんでいまさらLinux
コミュニティでも鬼子のように嫌われているclone()なんぞ実装するのだ…。

387 :名無しさん@お腹いっぱい。:03/10/29 21:37
>>381
iiimf-skkというソフトがそういうことをやっているらしい

388 :名無しさん@お腹いっぱい。:03/10/29 22:25
>>386
wasabi の仕事で必要だったんでしょ、きっと。


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

390 :名無しさん@お腹いっぱい。:03/11/01 03:22
>>387 uidセットできなかったら読み書きしないんじゃなかったかな
むしろそういう小技使わんとsecureにできんiiimfの方が(ry


391 :名無しさん@お腹いっぱい。:03/11/01 15:52
>>390
小技を使うとsecureになるのか?

392 :名無しさん@お腹いっぱい。:03/11/01 19:00
>>390

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


393 :名無しさん@お腹いっぱい。:03/11/04 17:57
/libや/usr/libの下のスレッド対応が進んでるのは、
PC-UNIXではどれになるんでしょうか?

394 :名無しさん@お腹いっぱい。:03/11/04 18:14
「PC-UNIX」の定義を明確にされたく

395 :名無しさん@お腹いっぱい。:03/11/04 18:30
>>394
{Free,Net,Open}BSD Linuxの四つです。

396 :名無しさん@お腹いっぱい。:03/11/04 22:44
Solaris x86も忘れないでー。



397 :名無しさん@お腹いっぱい。:03/11/04 23:00
Solaris for x86 > Linux > *BSD

398 :名無しさん@お腹いっぱい。:03/11/04 23:17
UnixWareモナー

399 :名無しさん@お腹いっぱい。:03/11/04 23:28
WindowsNT > Solaris for x86 > Linux > *BSD

400 :名無しさん@お腹いっぱい。:03/11/04 23:41
値段の話かい?

401 :nanasi:03/11/05 07:10
MT対応の徹底度でいえば、確かにWindowsは大したもの。なにをやるにも
threadだもんなぁ。

402 :名無しさん@お腹いっぱい。:03/11/05 18:18
>>401
TerminateThread がクソなのが腹立つ


403 :名無しさん@お腹いっぱい。:03/11/05 18:22
TerminateThreadなんて使ってる香具師が糞だと思うが。

404 :名無しさん@お腹いっぱい。:03/11/05 19:53
TerminateThread も、それを使ってる香具師もクソということでファイナルアンサー?


405 :名無しさん@お腹いっぱい。:03/11/05 22:18
まあ、使える局面では使えばいいとは思うが、
そんなことはほとんどないのが現実だわな。

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

406 :名無しさん@お腹いっぱい。:03/11/05 22:37
TerminateThread のダメさ加減にうんざりしている人は
世の中にたくさんいるようですな。
ttp://diary.imou.to/~AoiMoe/2003.09/late.html#2003.09.29_s02

407 :名無しさん@お腹いっぱい。:03/11/05 22:42
ダメさ加減もなにも、使っちゃいけないものを勝手に使ってるだけだろ。
ものには使い方ってのものがあるんだよ。アホか。

408 :名無しさん@お腹いっぱい。:03/11/06 08:00
ただ、TerminateThreadの仕様がかなり疑問なのも事実…

409 :名無しさん@お腹いっぱい。:03/11/06 13:27
「使っちゃいけないもの」というより「使いものにならない」。
なんのために用意してあるんだか、まったくもって疑問。

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


411 :名無しさん@お腹いっぱい。:03/11/06 14:42
>>410
ここのスレの住人は実際にはスレッドなんてろくに使ってないと思われ。
ム板のスレへどうぞ。

412 :名無しさん@お腹いっぱい。:03/11/06 15:06
>>410
データベースでもスレッドでも同じだけどそれは同期の大原則

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

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

413 :名無しさん@お腹いっぱい。:03/11/06 17:29
>>411
402さん、こんばんは。

414 :名無しさん@お腹いっぱい。:03/11/07 00:39
mutex


415 :名無しさん@お腹いっぱい。:03/11/07 00:49
>>412
> オブジェクト&コンポーネント指向とスレッド同期ってすごい相性悪いと思うんだけどどう思う?

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

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

416 :名無しさん@お腹いっぱい。:03/11/07 06:38
>>415
デッドロック防止の話では?

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

417 :415:03/11/07 14:06
>>416
> デッドロック防止の話では?

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

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

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

418 :名無しさん@お腹いっぱい。:03/11/08 00:16
単純に分割統治できる場合はそうだけど、
相互に関連して呼び合う場合なんかは全体の流れを把握するのがかえって難しい。

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

だと思うが。


419 :名無しさん@お腹いっぱい。:03/11/08 00:20
スレッドに絡めて話すならいいけど、OO宗教論争やるならム板に逝ってね。

420 :402:03/11/08 13:22
>>403
クソだから使ってませんが何か?


421 :名無しさん@お腹いっぱい。:03/11/08 13:37
>>420
ひとつ上の書き込みすら読めないのか?

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

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

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

424 :名無しさん@お腹いっぱい。:03/11/12 11:08
既存のリソースに目を向けないで
独自に作ろうとする発想が既にOO的にダメな感じ

425 :名無しさん@お腹いっぱい。:03/11/12 13:02
スレッドプログラミングもろくにしたことない香具師が
何を偉そうに

426 :名無しさん@お腹いっぱい。:03/11/12 16:14
正直スマンカッタ

427 :名無しさん@お腹いっぱい。:03/11/21 06:41
TerminateThread, TerminateProcess辺りって、kill -KILLみたいな存在
なんだから普通は使わん(使えない)だろ。(DLL_THREAD_DETACHとか
DLL_PROCESS_DETACHでcleanupなんてやってたりすると…)

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

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

428 :名無しさん@お腹いっぱい。:04/02/16 15:49
mutexが他スレッドにロックされてるのか自スレッドがロックしてるのか
区別する便利な方法はありませんか?recursiveなmutexだけだとちょっと
役不足です。

429 :名無しさん@お腹いっぱい。:04/02/16 16:13
ロックしてるスレッドが何かを区別してい時ってどんな時よ。
それは設計おかしいヲカン。

430 :名無しさん@お腹いっぱい。:04/02/16 16:16
腐ったフレームワークからのコールバックの実装にどうしても必要で。
>>429

431 :名無しさん@お腹いっぱい。:04/02/16 17:44
mutexをlockした後にpthread_tの変数に自スレを代入するのじゃダメ?


432 :名無しさん@お腹いっぱい。:04/02/16 20:54
>>431
その変数の初期値に困らないか?

433 :名無しさん@お腹いっぱい。:04/02/17 00:51
やりようはあると思うが。


434 :名無しさん@お腹いっぱい。:04/02/18 23:18
どんな?


435 :名無しさん@お腹いっぱい。:04/02/19 00:29
スレッドのIDを芋ズル式に書き込んじゃだめ?

436 :名無しさん@お腹いっぱい。:04/02/19 00:44
pthread_tの実体って、システムによってunsigned longだったり
単なるポインタだったりと、まちまちだからなあ。

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

437 :名無しさん@お腹いっぱい。:04/02/19 00:58
unlockすればいいんぢゃねーか?

438 :名無しさん@お腹いっぱい。:04/02/19 01:25
ダミーのスレッド作っておくとか?

439 :名無しさん@お腹いっぱい。:04/02/19 10:18
boolな変数を一つつけて有意な値が入っているか判定すればいーんじゃねーの。


440 :名無しさん@お腹いっぱい。:04/03/08 21:42
-pthread

441 :名無しさん@お腹いっぱい。:04/03/21 13:29
-lpthread

442 :名無しさん@お腹いっぱい。:04/03/27 12:55
>>436
0にならないっていう保証なかったっけ...

443 :しゃくれ:04/04/20 01:42
スレッドを作った後sigwait()でSIGUSR2シグナルキャッチを契機にスレッドをジョインしようとしたんですが、シグナルキャッチできませんでした。なぜですか?赤帽7.3でにゅ。教えてこの世でイチバンエロイ人。

444 :名無しさん@お腹いっぱい。:04/04/20 08:28
sigunaruとsureddoは注意して扱わないと大変なことになる。マスクとか。

445 :しゃくれ:04/04/20 12:58
ウヲ JM見たら、シグナルを受けたいスレート以外全部そのシグナルをブロークしなければ確実にキャッチできなイっぽいことが書いてある。リナクススレッドってLWプロセスだからピースレッドキルではプロセスに対して(PIDで)シグナル送ってるのかとオモテターヨ。違ったのか。。 thxエロッチ!タメシテミマス。

446 : :04/05/04 23:50
pthread ----- 天国 ------ pushed .

447 :名無しさん@お腹いっぱい。:04/05/05 02:44
>>445
その辺、kernelのversionで変わるので気をつけて。

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)