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
面白い

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 :あぼーん:あぼーん
あぼーん

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 :あぼーん:あぼーん
あぼーん

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 :あぼーん:あぼーん
あぼーん

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


286 :あぼーん:あぼーん
あぼーん

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 :あぼーん:あぼーん
あぼーん

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で変わるので気をつけて。

448 :名無しさん@お腹いっぱい。:04/05/23 18:40
>>445
そろそろNPTL使おうよ


449 :名無しさん@お腹いっぱい。:04/05/24 22:29
linux使いとしては、旧linuxthreadsやthreadごとのsetuidの
ような汚点は恥ずかしいから触れないで欲しいと感じます。
nptl使ってあげてください>>445

450 :名無しさん@お腹いっぱい。:04/05/24 22:48
そういえばNGPTはどうなるのかな?
http://www-124.ibm.com/pthreads/
ではperformance,scalabilityが向上したった書いてあるけど、
ベンチマークの結果どこかにありますかね。

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

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

452 :名無しさん@お腹いっぱい。:04/06/29 22:44
NPTL age

453 :名無しさん@お腹いっぱい。:04/06/30 00:41
>>452
板違いではないか?

454 :名無しさん@お腹いっぱい。:04/06/30 00:50
他の実装との比較とかならいいんじゃねーの


455 :名無しさん@お腹いっぱい。:04/06/30 01:07
NPTLの実装以外になんかあったっけ?
NGPL?

456 :名無しさん@お腹いっぱい。:04/06/30 01:32
他のOSとの比較とか、あとシングルCPUの場合ならユーザーレベルスレッド
ライブラリとの比較もできるね。

457 :名無しさん@お腹いっぱい。:04/06/30 05:23
>>455
> NPTLの実装以外になんかあったっけ?
> NGPL?
NGPTですな。
ttp://www-124.ibm.com/pthreads/

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

458 :名無しさん@お腹いっぱい。:04/07/01 10:22
>>454
確かに。興味ある。
各OSごとのthread実装状況を知りたいね。

459 :名無しさん@お腹いっぱい。:04/07/06 19:21
このスレ的にはどういう基準で(どういうベンチマークで)比較するのが良いの?
上で議論されてたFreeBSDのスレッド実装の話も面白げなんだけど。

460 :名無しさん@お腹いっぱい。:04/07/07 12:42
各Unixごとのthread実装解説書なんて本が出たら、
開発者とかには売れそうな感じだが。

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

461 :名無しさん@お腹いっぱい。:04/07/07 13:14
SunOSは(限定的だけど)公開してる。

462 :名無しさん@お腹いっぱい。:04/07/07 16:24
http://www.amazon.co.jp/exec/obidos/ASIN/0132075563/249-7688813-0268363
これももう最新からはだいぶ置いて行かれてるだろうしな…

463 :名無しさん@お腹いっぱい。:04/07/07 18:06
邦訳「UNIXカーネルの魔法」か。これ、そんなにpthreadについて書いてたかな…

464 :名無しさん@お腹いっぱい。:04/07/22 08:36
Solaris なら、これでしょ。そこそこ新しい。内容も楽しい。
ttp://www.pearsoned.co.jp/washo/unix/wa_uni19-j.html

465 :名無しさん@お腹いっぱい。:04/07/22 15:46
翻訳版が2001年つー事はSolaris7辺り?

466 :名無しさん@お腹いっぱい。:04/07/22 17:41
そう。Solaris 7 まで。
スレッド関係とか、vnode cache の扱いとか Solaris 8
以降でかなり変わったんだけど、まあこれらについては、
Web でも多少資料あるから…

467 :名無しさん@お腹いっぱい。:04/07/24 01:01
>>466web の多少ある資料の url きぼん

468 :not 466:04/07/24 07:06
http://developers.sun.com/solaris/articles/alt_thread_lib.html
辺りから辿ってはどうか?

469 :名無しさん@お腹いっぱい。:04/08/01 17:51
沢山CPUついてるマシンで、あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
読めることはなんかの規格で保証されていますか?
教えてください。

Solarisを主に使っています。


470 :名無しさん@お腹いっぱい。:04/08/01 17:55
アーキテクチャによる。ccNUMAだとかその辺。

471 :名無しさん@お腹いっぱい。:04/08/01 17:56
>>469
volatile 宣言してある変数のこと?

472 :469:04/08/01 18:03
>>470
> アーキテクチャによる。ccNUMAだとかその辺。
ありがとうございます。

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

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

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

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


473 :名無しさん@お腹いっぱい。:04/08/01 18:19
>>472
SMPとかccNUMAマシンではH/Wが勝手に同期してくれるという意味では。
ccってcache coherentの略だろう。

# あとは>>470にお任せ ノシ


474 :名無しさん@お腹いっぱい:04/08/01 18:27
>>472
threadの発想は1つのアドレススペースに複数のコンテキストだから、
スレッド間で自由に変数が共有できないのなら1つのアドレス空間に
する意味ないわな。
何がしたいんだ?


475 :469:04/08/01 18:33
>>474
ちゃんと共有されることが規格等で保証されているか知りたいのです。


476 :名無しさん@お腹いっぱい。:04/08/01 18:42
>>472
UNIX(POSIX準拠)が動いているマシンが、そういう(同期が保証されない)アーキテクチャな例ってあるの??


477 :名無しさん@お腹いっぱい。:04/08/01 18:44
>>471
> volatile 宣言してある変数のこと?
レジスタは関係ないとオモワレメ


478 :名無しさん@お腹いっぱい。:04/08/01 18:49
メモリ番地Xには値0が入ってる
スレッドAがXに1をカキコした
次いでスレッドBがXを読み込んだとき、1であるためには、
AやBは何をすればよいか

という話か?

479 :名無しさん@お腹いっぱい。:04/08/01 18:51
>>469
> 沢山CPUついてるマシンで、あるスッドレが更新した値(変数)を別のCPU上の別スレッドが
> 読めることはなんかの規格で保証されていますか?

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

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

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

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

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

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

です!


481 :469:04/08/01 19:28
>>479
ありがとうございます。読みました。

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

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

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

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


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

そういうこと。

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

483 :名無しさん@お腹いっぱい。:04/08/01 20:24
NUMAでpthreadに準拠したマルチスレッドライブラリを持っている
OSってあるの?

484 :名無しさん@お腹いっぱい。:04/08/01 21:46
>>483
IRIX とか AIX とか NUMA でも posix pthread じゃなかったけ?


485 :名無しさん@お腹いっぱい。:04/08/01 21:52
posix pthread
頭痛が痛い
馬から落馬

486 :名無しさん@お腹いっぱい。:04/08/01 21:54
>>484
ccNUMAじゃなくてNUMAなの?


487 :名無しさん@お腹いっぱい。:04/08/01 22:21
>>486
今時, そこそこの規模で cache coherent でない NUMA があったら教えてほしい.


488 :名無しさん@お腹いっぱい。:04/08/01 22:27
>>485
> posix pthread
すまん orz


489 :名無しさん@お腹いっぱい。:04/08/01 22:27
>>487
単にNUMAといえばccNUMAのことだということ?

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



490 :ccレモン:04/08/01 22:28
-D_POSIX_PTHREAD_SEMANTICS
-D_ACHE_HEADACHE_SEMANTICS

491 :名無しさん@お腹いっぱい。:04/08/01 22:30
いま490がいいことを言った。


492 :名無しさん@お腹いっぱい。:04/08/01 22:41
>>489
> non-cc な NUMAのアーキテクチャに規格準拠のpthreadが実装されている例はあるの?
pthread 規格が出てきた時点で, 現役で動いていた
non-cc な NUMA マシンの存在をしらんのだわ...
少なくともおいら的には.


493 :名無しさん@お腹いっぱい。:04/08/01 22:43
>>492
サンスコ.


494 :名無しさん@お腹いっぱい。:04/08/01 23:30
なんかNUMAの話題になってるけど、
>>469がNUMAでない環境に10000マルク

495 :名無しさん@お腹いっぱい。:04/08/01 23:56
>>494
どうなんでしょう。Sun Fire 4xxxになるとおもいますが。


496 :名無しさん@お腹いっぱい。:04/08/02 00:00
少なくとも>>469さんは、NUMAを知ってなかった。

497 :名無しさん@お腹いっぱい。:04/08/02 00:04
じゃぁ最終の質問を
> non-cc なアーキテクチャに規格準拠のpthreadが実装されている例はあるの?
に変更した上でだれか答えてあげればヨロシ


498 :名無しさん@お腹いっぱい。:04/08/21 20:05
だれからも返答なしかよagege

499 :名無しさん@お腹いっぱい。:04/09/30 11:52:46
Linuxのthreadで質問があります。
現在、稼働しているLinux boxがnptlに対応しているかどうかというのを
調べるためにはどうしたらいいでしょうか?
例えば誰かが構築したLinuxでLFSとかで構築されていた場合とかです。
ようするにディストロのパッケージを調べずに、そのシステムがnptl対応かどうか知る方法です。

500 :名無しさん@お腹いっぱい。:04/09/30 16:45:16
>>499
Linuxの事はよく知らないけどobjdump -pとか-Tとかで調べられない?


501 :名無しさん@お腹いっぱい。:04/09/30 21:59:57
>>499
スレッド使うプログラムを書いて、プロセスとして見えるか確認する。

502 :名無しさん@お腹いっぱい。:04/10/01 00:18:25
>>499
pthreadというよりはLinux固有の問題なので、Linux板の方が的確な答がもらえそう



503 :netafuri:04/10/07 00:04:49
http://pc5.2ch.net/test/read.cgi/tech/1037636153/834n-
誰かpthreadネタで参戦汁

504 :名無しさん@お腹いっぱい。:04/10/07 01:00:11
荒れてきた

505 :名無しさん@お腹いっぱい。:04/10/15 00:30:04
linuxでスレッドを使用したプログラムを作ってるんですが、
root権限無しで、各スレッドの優先度を変えることってできないんですか?

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

507 :名無しさん@お腹いっぱい。:04/12/24 01:19:52
wrapというのがsymbolの置き換えだったら、
libpthreadがlibcよりも先にリンクされるようにすれば
いいんじゃなかろうか

実はよく知らない

508 :名無しさん@お腹いっぱい。:04/12/24 20:34:22
>>507
Pth の pthread.h を見ると,
#define select __pthread_select
みたいなのがズラーっと並んでる.これってかなりデンジャラスな感じが.

509 :名無しさん@お腹いっぱい。:04/12/24 21:06:53
別に。

510 :名無しさん@お腹いっぱい。:04/12/29 22:32:31
GD-2.0.33を./configureしてmakeする際、
エラーがずらーっとでるのだが、これもpthreadのせいなのかな・・・?

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

511 :名無しさん@お腹いっぱい。:04/12/29 23:06:16
>>510
消えろ

512 :名無しさん@お腹いっぱい。:04/12/31 11:38:47
      ./       ;ヽ 
      l  _,,,,,,,,_,;;;;i  <いいぞ pthread!
      l l''|~___;;、_y__ lミ;l  バグを出す奴はプログラマだ!!
      ゙l;| | `'",;_,i`'"|;i |  バグを出さない奴はよく訓練されたプログラマだ!!
     ,r''i ヽ, '~rーj`c=/ 
   ,/  ヽ  ヽ`ー"/:: `ヽ
  /     ゙ヽ   ̄、:::::  ゙l, ホント pthreadは地獄だぜ! フゥハハハーハァー
 |;/"⌒ヽ,  \  ヽ:   _l_        ri                   ri
 l l    ヽr‐─ヽ_|_⊂////;`ゞ--―─-r| |                   / |
 ゙l゙l,     l,|`゙゙゙''―ll___l,,l,|,iノ二二二二│`""""""""""""|二;;二二;;二二二i≡二三三l
 | ヽ     ヽ   _|_  _       "l ̄ ̄ ̄ ̄ ̄ ̄ |二;;二二;;二=''''''''''' ̄ノ
 /"ヽ     'j_/ヽヽ, ̄ ,,,/"''''''''''''⊃r‐l'二二二T ̄ ̄ ̄  [i゙''''''''''''''''"゙゙゙ ̄`"
/  ヽ    ー──''''''""(;;)   `゙,j"  |  | |

513 :名無しさん@お腹いっぱい。:04/12/31 12:30:59
>>512
つまらん。

514 :名無しさん@お腹いっぱい。:05/01/04 23:43:27
>>512
ハートマン先任軍曹最高だよな。

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



515 :名無しさん@お腹いっぱい。:05/01/09 01:55:24
結局、FreeBSDもM:Nスレッドを捨てるのか……

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

516 :名無しさん@お腹いっぱい。:05/01/09 02:05:53
>>515 とりあえずソースきぼん。


517 :名無しさん@お腹いっぱい。:05/01/09 11:35:07
まともなM:Nを持っていながら、捨てた所ってないんじゃないの?
Solarisみたいにdefaultのlibraryを変えたところはあるけれど

518 :名無しさん@お腹いっぱい。:05/01/09 12:35:21
あ、「M:Nスレッドを捨てる」ってのは言いすぎだったかも。
でもデフォルトが1:1スレッドとなり、Solarisと同じ道を歩むことになりそうだ。

519 :名無しさん@お腹いっぱい。:05/01/09 13:13:49
>>518 やはりソースきぼん。MLのスレッドのURLとか。


520 :名無しさん@お腹いっぱい。:05/01/09 16:15:18
M:Nがまともに動いたなら、Solarisはデフォルトを1:1に変えなかったんじゃないか?

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

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

522 :名無しさん@お腹いっぱい。:05/01/09 16:51:59
>>521
> FreeBSDも市場が似通っているけど、
> FreeBSDは、library整備も大変なんじゃないかな。
> I/O廻り、signal廻りとやることが結構あるから。

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

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

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

少なくともスレッド周りでは、Alexey Zelkinが
> I have implemented pthread_attr_get_np() function which exported
> all required information on application level
と言ってて、garbage collectorのようなpthread APIだけじゃ扱い切れない
部分についても解決しているはず。
ttp://lists.freebsd.org/mailman/htdig/freebsd-java/2004-February/001653.html

523 :名無しさん@お腹いっぱい。:05/01/09 17:08:42
> 現にApache2やMySQL等が動いてるし。

2chでは、apacheのマルチスレッド型MPMがまともに動かなくて
苦労しているようですが。

524 :名無しさん@お腹いっぱい。:05/01/09 17:13:19
>>523
それは、動かすアプリケーションがマルチスレッド対応していないのが問題で、
スレッドライブラリとは無関係。

525 :名無しさん@お腹いっぱい。:05/01/09 17:13:53
UNIX上のapacheのMPMのデフォルトはpreforkだと思うが、MTで動かす理由ってなんだ?

526 :名無しさん@お腹いっぱい。:05/01/09 17:45:50
FreeBSD 5.3RにおいてApacheがWORKERで動作不安定なのはよく知られていることで。
一般論でひきあいに使える話ではない。

527 :名無しさん@お腹いっぱい。:05/01/09 17:49:19
>>523
> >>523
> それは、動かすアプリケーションがマルチスレッド対応していないのが問題で、
> スレッドライブラリとは無関係。

Apache2が動いているとおっしゃるから、指摘したのですが。

528 :名無しさん@お腹いっぱい。:05/01/09 17:50:56
>>526 とりあえずソースきぼん。

529 :名無しさん@お腹いっぱい。:05/01/09 17:52:20
あ、FreeBSDのスレッド対応について云々言っている訳じゃないですよ。

FreeBSD+apache2は「まともには」動かない、
apache2自体はマルチスレッドで動いている、というだけです。

530 :名無しさん@お腹いっぱい。:05/01/09 17:57:45
>>525
一番の理由は、資源の節約。
mod_perl等の巨大なmoduleを組み込むと、一つのプロセスが肥大化してメモリを圧迫するし
mod_cacheや独自モジュールも含め、キャッシュとして持てる量が大幅に増やせる。

531 :名無しさん@お腹いっぱい。:05/01/09 18:39:33
>>530
たぶんworkerにそういうメリットは(ほとんど)ないと思うんだけど、実際に測ってみた?

532 :名無しさん@お腹いっぱい。:05/01/09 18:41:21
>529
>FreeBSD+apache2は「まともには」動かない

文脈からするとworkerでは動かない。preforkの話はしていないということだろうけど。
とりあえずこのpc5.2ch.netはFreeBSD 5.3R+Apache2 preforkでちゃんと動作しているよ。

533 :名無しさん@お腹いっぱい。:05/01/09 18:51:34
揚げ足取りばっかだね。
はいはい、俺が悪かったよ。

534 :名無しさん@お腹いっぱい。:05/01/09 19:03:08
つまり、
「FreeBSDの実装が絶対正しい。互換性のないsolarisやlinuxは糞」
「apacheのマルチスレッド対応など無意味。滑稽この上ないし、対応する必要など無い」
ということですね。

535 :名無しさん@お腹いっぱい。:05/01/09 19:09:24
http://www.newsforge.com/article.pl?sid=04/12/22/1954233
> POSIX threads are really the only thread game in town these days.

μITRONの世界から来た自分も使いにくいと思う。別の標準APIが欲しいね。

536 :名無しさん@お腹いっぱい。:05/01/09 19:35:58
>>535
> μITRONの世界から来た自分も使いにくいと思う。別の標準APIが欲しいね。

ある意味, 日本では uITRON がデファクトな部分があるみたいだから,
作ればいいじゃん.
pthread の枠組みあれば, どんな排他/同期機構でも上に載っけられ
るっしょ?
おいらは, pthread 上に uITRON 互換のライブラリ作って, 実機ができ
るまでのデバッグ用に使っているが...


537 :名無しさん@お腹いっぱい。:05/01/09 20:43:55
で、結局>>515,518の真偽についてはどうなんだ?

538 :名無しさん@お腹いっぱい。:05/01/09 20:54:00
本人に聞いてくれ。

539 :名無しさん@お腹いっぱい。:05/01/09 21:29:40
M:Nが複雑な上に通常のアプリケーションで性能がでなければ、路線変更はありそうな話ではある。

540 :名無しさん@お腹いっぱい。:05/01/10 02:35:01
>>534
そんなキモいBSD厨はもうさすがに淘汰されたろ

541 :名無しさん@お腹いっぱい。:05/01/10 03:27:31
ただ、一連の流れの中では FreeBSD で Apache2 のマルチスレッド MPM がまともに動かないのは
Apache 側に問題があるからだ、と言わんばかりの人もいるようだけど・・・

542 :名無しさん@お腹いっぱい。:05/01/10 10:31:43
Apache側というか、mod_perl等のモジュールによってはworkerでは動かなかったり
不安定だったりする。

543 :名無しさん@お腹いっぱい。:05/01/10 14:47:00
>>535
具体的にはどういうところ?
バカチョン系API(over pthread)なら幾つかあるよ。


544 :名無しさん@お腹いっぱい。:05/01/10 15:11:16
>>534
FreeBSDにとっては、Solarisのthread周りは目指すべき目標って認識じゃなかったっけ?
だからこそSolarisがデフォルトをM:Nから1:1にしたときに衝撃が走ったわけで。

545 :名無しさん@お腹いっぱい。:05/01/10 15:32:18
ネタにマジレスばかりのスレですね

546 :名無しさん@お腹いっぱい。:05/01/10 16:26:49
>>544
順番、逆でしょ。

547 :名無しさん@お腹いっぱい:05/01/10 22:53:37
solarisのlibthreadはバグの宝庫なので、プロダクションシステムでは
使うな!というのがsolaris使いの常識です。

548 :名無しさん@お腹いっぱい。:05/01/10 22:55:03
>>547 とりあえずソースきぼん。

549 :名無しさん@お腹いっぱい。:05/01/10 23:24:39
じゃあ Solaris 向け商用アプリなんかはみんなシングルスレッドなんかい

550 :名無しさん@お腹いっぱい。:05/01/11 00:54:53
いや、pthreadじゃないスレッドライブラリが先にある。


551 :547:05/01/11 01:45:48
オラクルはスレッドを使っていないです。
スレッドを使っているのは、sybaseとか、某アプリケーションサーバ
の類の負け犬ソフト。JDKだってトラブッてばっかりで全然直らない。
だいたいunixの基本コマンドにはthreadを使っているものってあまり
ないですよね。

552 :名無しさん@お腹いっぱい。:05/01/11 01:49:59
>>547=>>551=低能プログラマ@底辺システム開発会社


553 :547:05/01/11 02:07:48
そういやLotus Notesのsolaris版もmulti-threadだったんですが、
見事に撤退してしまいましたね。あれは6CPU以上は見事にスケール
しなかった。
 私は、自分のお客さんには、multi-threadには手を出すな!と薦めて
います。並列(ただしくは並行)プログラミングは、アプリプログラ
マには無理なんですよ。上級の制御屋さん以外は手を出すべきではない。


554 :名無しさん@お腹いっぱい。:05/01/11 02:22:35
いや、今はCOBOLすらマルチスレッドで動く時代。

555 :547:05/01/11 02:42:42
>>554
うわっ、驚きました。汎用機の世界の話ですか?世の中進んでいますね。
COBOLをマルチスレッドで動かしてなにが楽しいんでしょうか?unix旧世
代の私には思いつきません。

556 :名無しさん@お腹いっぱい。:05/01/11 03:09:16
iPlanetのLDAPサーバ、libthreadでバリバリ動いてますよ。
V480、100threadくらいTLSでactiveになっても超余裕。

まあ、へたれは原始的なプログラミングしているのが無難。
ほとんどの領域ではパフォーマンスより安定性だからね。

557 :名無しさん@お腹いっぱい。:05/01/11 03:37:55
あれはLinuxなんかにゃろくなスレッドライブラリないころからマルチスレッドで
書いてあったよね。


558 :名無しさん@お腹いっぱい。:05/01/11 12:19:15
V480って4wayだから、>>553への反例にはなっていないんだが。

559 :名無しさん@お腹いっぱい。:05/01/11 13:03:41
>>558
(゚Д゚)ハァ?

あんた頭悪すぎ。
LotusがスケールしないのはSolarisが悪いのか。
Directory関係はE系の64CPUでもスケールしているぞ。

560 :558:05/01/11 13:25:31
俺、そんな必死にさせるようなこと書いた? すまん。

561 :名無しさん@お腹いっぱい。:05/01/11 14:47:50
FreeBSDもLinuxもMTアプリ動かすだけ無駄。
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044565.html

Solarisでいいじゃん。無料なんだし。

562 :名無しさん@お腹いっぱい。:05/01/11 17:23:48
FreeBSD5.3のbetaじゃ問題外でそ。5.3Rだってアレだというのに。FreeBSDは
スケジューラがULEになってからが勝負でそ。5.4RでULEが復活するのか、6-stable
待ちなのかはわからんけど。

Linuxも2.6.4じゃちと古すぎる。2.6系は2.6.10になってようやっとまともに安定して
きたんだし。

563 :名無しさん@お腹いっぱい。:05/02/03 11:10:17

HP-UX 上で pthread プログラミング中なんですが、
プロセス内のLWP(カーネルスレッド)の数を、
コマンドで調べることはできないのでしょうか?

ps で表示できると思い込んでいたのですが、
HP-UX の ps は、そういう機能はないようで、
驚きました。


564 :名無しさん@お腹いっぱい。:05/02/03 13:52:49
>>562
linuxだけstable版はずるいよな(w

565 :名無しさん@お腹いっぱい:05/02/03 23:04:20
>> 563
LinuxのpsにはLWPを表示してしまうバグがあるのに驚きました。

566 :名無しさん@お腹いっぱい。:05/02/03 23:32:15
>>565
昔のLinuxは、threadが特殊なprocessとして実装されてました。
今は、そうではありませんが、ps(1)には、

THREAD DISPLAY
-L show threads, possibly with LWP and NLWP columns
-T show threads, possibly with SPID column
-m show threads after processes
H show threads as if they were processes
m show threads after processes

というoptionがあります。

567 :名無しさん@お腹いっぱい。:05/02/04 01:45:10
>>566
ん?最近のLinuxってclone(2)じゃなくなったの?

568 :名無しさん@お腹いっぱい。:05/02/04 04:45:18
cloneはもちろん使ってる。カーネル内のプロセスの意味が変わった。

569 :名無しさん@お腹いっぱい。:05/02/04 05:12:05
なるほど。

570 :名無しさん@お腹いっぱい:05/02/04 08:43:57
勝手にプロセスの定義を変えるな。思い上がりもいい加減にしろ>linus

571 :名無しさん@お腹いっぱい。:05/02/04 09:32:25
だが、それがいい。

572 :名無しさん@お腹いっぱい。:05/02/05 01:02:35
>>567
flagで指定すれば、、
古い特殊なprocessも作れるし、(rfork(2)みたいなやつ)
pthread的なthreadも作れる。

573 :名無しさん@お腹いっぱい。:05/02/06 02:48:11
非常に高度な議論を交わされてる皆さんに質問です。

どんな会社に勤めてらっさるのですか?
ぶっちゃけイメージが沸きません。検討も付きません。

574 :名無しさん@お腹いっぱい。:05/02/06 03:30:10
別に高度でもないし。嫌味のつもりだったらいいけど。
まあ2ちゃんだし。

575 :573:05/02/06 04:36:54
>>574
嫌味のつもりは無かったです
高度でないなら、私のレベルが低かったということですね
変な質問してすみませんでした

576 :名無しさん@お腹いっぱい。:05/02/06 10:13:58
勤めている会社の問題じゃなくて、好きなんですよ。


577 :名無しさん@お腹いっぱい。:05/02/06 21:50:43
そうそう。自分で色々やるのが楽しい。

漏れはwindowsでもpthread使う。せっかく書くなら、移植性高くしておきたいし。
というか、普段Linux(たまにSolaris)を使う事が多いので、そっちで書いて持ってくだけ。
性能とか求められれば話は別。

pthreadと言うより、素人にスレッド扱わせたのを見る方が地獄。
JavaでもWindowsのスレッドでも。

578 :名無しさん@お腹いっぱい。:05/02/06 23:35:33
こないだ、pthread使った糞プログラム見たよ
やっぱ素人にthread使わせちゃダメだ

579 :名無しさん@お腹いっぱい。:05/02/08 19:03:09
>>577
そだね。ただ、プリミティブAPIなpthreadは素人には扱いづらいぶん
より地獄になりやすい傾向が強いかと。

580 :名無しさん@お腹いっぱい。:05/02/10 11:14:14
初歩的ですみません。
ソケットプログラムをまだ組んだこと無いのですが、forkよりselectを
使った方が良いという文書を良く見ますが、selectって結局シーケンシャ
ルにコードが実行されているような気がします。forkは並列処理されてい
と思いますが。こういう理解で良いでしょうか?
#よくよく考えるとselectとforkを混在させた方が良いのでは?などと
#思うこともあります。
またpthread使った方がforkやselectより動作は早いのでしょうか?


581 :名無しさん@お腹いっぱい。:05/02/10 11:21:40
あなたはとっても頓珍漢なことをいっています。
四の五の言わずに、まずは本を買って勉強してください。


582 :名無しさん@お腹いっぱい。:05/02/10 11:45:51
故Richard Stevens著「詳解UNIXプログラミング」をすすめておく

583 :名無しさん@お腹いっぱい。:05/02/10 18:37:04
>>580は壮大な釣りと見た

584 :名無しさん@お腹いっぱい。:05/02/10 19:20:32
>>583
一見頓珍漢だが、よく読めば何とか意味は分かるぞ。
おそらく>>580は、複数のsocketを同時待ちしたいんだろう。
それで、 select() を使うか、 fork() して新しいプロセスを作って待つか、
それとも pthread を使うか…てな感じかな。

> selectって結局シーケンシャルにコードが実行されているような気がします。
あんまりこういうときにシンケーシャルなんて言葉は使わないが、
並列実行されないという意味では正しい。

> forkは並列処理されていと思いますが。こういう理解で良いでしょうか?
いちおう正しい。(ただし個人的には、あなたが正しく理解しているかどうかは
非常に怪しいと思う。)

> またpthread使った方がforkやselectより動作は早いのでしょうか?
多くの場合はそう。ただ select を使うか pthread を使うか fork するかは
速度で決めるもんじゃない。

585 :名無しさん@お腹いっぱい。:05/02/10 19:32:12
>>584
我々が>>580が見たというものの内容を推測することはできるが、
それをしても580のためにはならんと思うぞ。


586 :名無しさん@お腹いっぱい。:05/02/10 19:43:27
kqueue 使えとでも書いとくか。

587 :名無しさん@お腹いっぱい。:05/02/10 22:00:07
実は kqueue (や、スケーラビリティのの点で劣るけど select) を
使って continuation passing みたいなスタイルで書くのが一番
効率がいい。コンテキストが一番軽くて済むからね。でもこういう
スタイルで全てを並列に動かそうとすると、 resolver みたいなの
ものまで自分で書かないといけないのでかなり大変。resolver と
かは諦めても良くて、かつ制御構造が簡単なら continuation
passing でいいけど。
そうじゃない場合は、pthread や fork を 使う方がずっと簡単。
pthread と fork なら pthread の方が効率が良い。
でも、pthread は素人が使うもんじゃないから、性能が本当にクリティ
カルじゃない限り、fork で書くほうが簡単でお勧め。バグっていても、
それが他のコネクションに影響しにくしね。

588 :名無しさん@お腹いっぱい:05/02/11 08:18:46
>>580
forkは並列処理されていると思いますが。こういう理解で良いでしょうか?

ただしくは「並列」ではなく「並行」、concurrencyだ。「並列」に処理される
ためにはマルチプロセッサシステムが必要。シングルプロセッサだったらス
ループットは変わらない。I/O待ちが無いようにCPUを有効活用できるが。。。


589 :名無しさん@お腹いっぱい。:05/02/11 09:45:24
蘊蓄垂れたがる奴が多いな。

590 :名無しさん@お腹いっぱい。:05/02/11 11:28:52
なにせここは真・Mac板だからな。

591 :名無しさん@お腹いっぱい。:05/02/11 12:19:15
poll(2)最高。

592 :名無しさん@お腹いっぱい。:05/02/11 12:40:01
薀蓄と言うほどのものではないでしょう。
ある段階においては常識的に知っていなければならないことが
多いですよ。経験を重ねることで自然に身についていくので
それほど心配しないでもOK。

関係なければもちろん知らなくても大丈夫だし。

593 :名無しさん@お腹いっぱい。:05/02/11 12:48:17
常識をわざわざ長文でぶちまけてるから「垂れたがる」と言ったわけだが。


594 :名無しさん@お腹いっぱい。:05/02/11 14:21:54
常識的事項が長文で書かれていて、何かあなたに不都合が?

595 :名無しさん@お腹いっぱい。:05/02/11 15:16:50
"垂れたがる"ではなく"薀蓄"につっこまれているんだと思うんだが...。

それなら常識を垂れたがると言えばよかろう。

596 :名無しさん@お腹いっぱい。:05/02/11 15:36:47
スレ違い。

597 :名無しさん@お腹いっぱい。:05/02/12 07:43:11
>>591
pollよりkqueueの方がソースの見通しを良くしやすいと思うよ。


598 :名無しさん@お腹いっぱい。:05/02/12 10:26:35
そうなんだけどさ。
kqueueとかepollは使える環境限られるし。

私はスレッド使っちゃ駄目と言われない限り、スレッド使う派。
select/pollより素直に書ける。forkよりも速い。
並列度を上げようとすると、lock/unlockがわかりにくくなるけど。
まあスキルがないだけかもしれんが。

なぜか、rwlockってあまり使われていない気がする。
知らなくて自分で似たのを作りそうになった。

599 :名無しさん@お腹いっぱい。:05/02/12 17:35:21
>>598
漏れもスレッド使う派。
デッドロックはできるだけスレッド間で大域データを持たないように設計することで回避



600 :名無しさん@お腹いっぱい。:05/02/12 18:12:15
thread使うとatom周りの移植でグダグダにならない?

601 :名無しさん@お腹いっぱい:05/02/13 01:56:00
デッドロックは、ふつー、複数のロックのロックする順序を決めることで回避
するのでは?

602 :名無しさん@お腹いっぱい。:05/02/13 05:34:52
>>599 が言いたいのはデッドロックというよりロックによるコンカレンシー低下とかかな?

603 :名無しさん@お腹いっぱい。:05/02/13 05:38:37
並行・並列なんて言葉よりデッドロックこそ正しく使おうね

604 :名無しさん@お腹いっぱい。:05/03/03 03:35:59
このスレがデッドロックしますた。

605 :名無しさん@お腹いっぱい。:05/03/16 12:21:02
基本的なことですみません。
どなたか教えていただける方いらっしゃいますでしょうか。

fork()で子プロセスの終了を待たない場合、ゾンビにならないよう
signal(SIGCHLD, SIG_IGN)で子プロセスからのSIGCHLDを無視する必
要があると思いますが、pthreadの場合はこんなことしなくても良い
のでしょうか?そもそもpthreadにはゾンビなど無いのでしょうか?

606 :605:05/03/16 12:44:19
ひょっとして pthread_detach() するだけで良いのでしょうか?


607 :名無しさん@お腹いっぱい。:05/03/16 13:21:16
zombieってのはプロセスの死骸で埋葬待ちのものをいう。
スレッドはプロセスじゃない。
これらの前提から、結論は


608 :名無しさん@お腹いっぱい。:05/03/16 14:32:57
まぁスレッドでゾンビって概念があるかはともかく、JOINABLE なスレッドを
pthread_join() しないまま放っておくとリソースリークは発生するな。
その回避には >>606 の方法でもいいし、あるいはスレッド生成の段階で
DETACHED なものとしておくか、だな。pthread_attr_setdetachstate() 参照。

609 :名無しさん@お腹いっぱい。:2005/03/28(月) 10:55:56
pthread_cond_timedwait()で、pthread_cond_broadcast()によるイベント取りこぼす場合があるようなのですが、
詳しく解説しているページをご存知の方いませんか?

610 :名無しさん@お腹いっぱい。:2005/03/28(月) 13:02:25
一般論としてない。

611 :名無しさん@お腹いっぱい。:2005/03/28(月) 13:03:36
ただし、async-signal safeではない。

612 :名無しさん@お腹いっぱい。:2005/03/28(月) 13:51:53
ライブラリのバグか、ユーザの書いたコードが悪いのか。
まさにpthread地獄。

613 :名無しさん@お腹いっぱい。:2005/03/28(月) 13:53:11
>>609
小さいプログラム書いて検証してみればいいやん。

614 :名無しさん@お腹いっぱい。:2005/03/28(月) 20:28:49
必ずしも再現できるものではないのが厄介。
コンパイラのバグを追うより性質が悪い。

615 :名無しさん@お腹いっぱい。:2005/03/28(月) 21:22:01
仕様を把握しないで使うから、そういう事になるんじゃねーの?

616 :名無しさん@お腹いっぱい。:2005/03/29(火) 00:14:17
仕様を把握するなんて泥臭いことは底辺コーダがやることだし。
おれっちは優雅にアルゴリズムを練りたいの。

617 :名無しさん@お腹いっぱい。:2005/03/29(火) 00:19:35
DQNえせEがあらわれた!
プログラマAは 逃げ出した!
プログラマBは 逃げ出した!
プログラマCは 逃げ出した!
会社は 傾いている!

618 :名無しさん@お腹いっぱい。:2005/03/29(火) 00:30:19
>>616
あれ?おかしいな?メール欄にsageって書いてある……


619 :名無しさん@お腹いっぱい。:2005/03/29(火) 01:07:29
>>616
posixの仕様も把握せずに使う冒険野郎ですか?

620 :619:2005/03/29(火) 01:09:05
>>619
違っ! orz
posix → pthread

621 :名無しさん@お腹いっぱい。:2005/03/29(火) 12:12:27
pthreadのpはPOSIXのPなんだから、あながち間違いでもなかろ。


622 :名無しさん@お腹いっぱい。:2005/06/25(土) 01:03:37
dual CPU,ハイパースレッディング環境で main thread の他に演算
作業用スレッドを 4個作って処理させています。 4個のスレッドがそれぞれ
異なる4つの(論理)CPU に割り当てられた時はとても速く動作するのですが、
同じ CPU に2つのスレッドが割り当てられたりすると、1つのCPUが遊んで
しまい、処理が遅くなってしまう事があります。このような事を防ぎ、
確実に異なる CPU にスレッドを割り当てたいのですが、よい方法は
ありませんでしょうか?お詳しい方がいらっしゃいましたらぜひご教授
よろしくお願いいたします。


623 :名無しさん@お腹いっぱい。:2005/06/25(土) 07:46:25
OS に何使っているのか分からんけど、CPU に thread を割り当てちゃえば良いんでないの。

affinity cpu thread

624 :名無しさん@お腹いっぱい。:2005/06/25(土) 22:54:03
さらにスレッドを分割して、常に4つ以上のthreadをrunnableにする。



625 :名無しさん@お腹いっぱい。:2005/07/11(月) 17:15:59
>>623
おい、それOS依存だろ。

>>624
何それ?どういうこと?

>>622
実際には、その考えをアプリケーション層ですること自体が間違ってる。
アプリが「このCPUを使いたい」って言っても、カーネルのスケジューラを困らす(複雑化する)だけだと思うぞ。

結局は、OSのスケジューラに依存する問題(空いているCPUに割り当ててくれない)ってことだな。

626 :名無しさん@お腹いっぱい。:2005/07/12(火) 11:22:50
>>623
pthread_setaffinityが使えるOSってなに?


627 :名無しさん@お腹いっぱい。:2005/07/12(火) 13:37:13
Linux 2.5.8以降のLinuxとか。
sched_setaffinity(2)だけど…

628 :名無しさん@お腹いっぱい。:2005/07/12(火) 15:39:01
sched_setaffinity(2)は、プロセスに対してだよね。
pthread..は特定のスレッドに対してのCPU割り当てだから違う気がするな。

629 :名無しさん@お腹いっぱい。:2005/07/12(火) 15:44:50
違わないな。ごめん。

sched_setaffinityが使えるなら、pthreadライブラリのpthread_setaffinity
(実装されていれば)は機能するだろう。
ってことだよね。了解。そうですね。さんくす。




630 :名無しさん@お腹いっぱい。:2005/07/24(日) 16:06:22
E言語ができた場合
英語とE言語を言い分ける自信がありません。
どうしたらいいですか?

631 :名無しさん@お腹いっぱい。:2005/08/10(水) 16:04:45
>>630
スレ違い。
くだ質スレへ行け。

632 :唯一ネ申:2005/09/05(月) 15:07:50


       ,r-'''"" ̄ ̄"'-,_
    _,.-'^γ´          `i,
   ,r' ,.r'"ヽヽ、( ( ソノノ彡、 i
  ,i' {     "'''''''''''''   ミ  .i [ ̄二. ̄| [二⌒二]    / ̄7 [二 ̄二]  [二二 ̄|
  i  i             ミ  i \\/ /  [二__二]   /   l´     | |      //
  |  i   二 二 二 二   ミ  i..  > く.  ┌──┐ く,/!  !     | |     / く
  .i   i      ハ      ミ  i. ∠/\> l_二二_」    |_|   [二__二] ∠/\_>
  |  ノ {{|iiiiiiilll;ノ,,,,,ヽ;liiiiiiii||}} ゝヾ
   | .ミ >='^◎≫,i'^'i,≪◎'=、< ミヘ
  ,ヘ ミ ~こ二ヲ i i; .'ミ二こ、 ミ }
   { レ   ノ  i i;  ヽ、_, ';,ノ ノ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   Li,;'ゝ    ,イ  ト、  ';, i'~  |  唯   一   神   又   吉   イ   エ   ス   !
    i, i ._,ノ^-0し0-ヘ,_  }|   | 腐った日本を救えるのはネ申しかいない。9月11日は又吉イエスに投票すべきだ! 
     ゝ,イ'<ー--ニ---ー>|ノソ  <  投票しない者は!唯一神・又吉イエスが地獄の火のなかに投げ込むものである!!
      ゝ.i  `'ー-'´  i,イ     \_______________
       |..ヾ、 ,.......、,i'.,ソ |   
      ,|. ヾヽ_____レ'ソ .|、  

世界経済共同体党 †
http://www.matayoshi.org/index.html


633 :名無しさん@お腹いっぱい。:2005/09/19(月) 22:39:51
キリストが神だと本気で思ってるんだ、ふーん

634 :名無しさん@お腹いっぱい。:2005/11/10(木) 23:09:34
最近の FreeBSD pthread ってどう?age

635 :名無しさん@お腹いっぱい。:2005/11/11(金) 00:06:45
>>634
http://lists.mysql.com/mysql-ja/151
http://lists.mysql.com/mysql-ja/157

上の2つを見る限りではkseがすばらしいとはいえないと思う。

636 :名無しさん@お腹いっぱい。:2005/11/11(金) 00:30:01
>>635
ん〜面白い結果。
以前 slashdot に出ていた scalability のベンチマーク結果を
受けて改良した結果が NetBSD に現れた雰囲気が出てるね。
FreeBSD に関しては 6.0 で vfs がだいぶ良くなった噂なのでその辺含めて
再チェックはして欲しいところ。ただもうちょっと地道な改良は必要そうな感じ?

こうなると MySQL 以外も気になってくる。
apache prefork vs pthread とかどこかに落ちてないかな。

637 :名無しさん@お腹いっぱい。:2005/11/11(金) 00:37:06
あーでも、よく見ると、どのOSも最近とは言えなくなってきてる時期のデータ……
暇人による最近のデータキボンヌしたいところだ……

638 :名無しさん@お腹いっぱい。:2005/11/11(金) 00:41:02
>>636
実際に試したわけじゃないからわからないけど、

プロセスベースとスレッドベースを比べたら
スレッドベースが早いのは当たり前かな。

ただ、そのスレッドがどのOSが早いかという話かなと。

kseとかM:Nスレッドモデルだし早そうなのになー
何で遅いんだろ。

ちなみにMySQLはスレッドバリバリ使うアプリです。

639 :名無しさん@お腹いっぱい。:2005/11/11(金) 01:37:27
こういうのもある。
ttp://lists.freebsd.org/pipermail/freebsd-threads/2005-January/002789.html


まあ、MySQLはLinuxをメインターゲットとしていて、Linux上で最高のパフォーマンスが
出せるようにチューニングされているんだから、それに勝つのは難しい
…なんて意見もあるようで。

640 :名無しさん@お腹いっぱい。:2005/11/11(金) 02:11:40
>>639
これはまた見難いドキュメントですね・・・
まとまりがorz


641 :名無しさん@お腹いっぱい。:2005/11/11(金) 02:12:09
すいません、あげまくってしまった

642 :名無しさん@お腹いっぱい。:2005/11/11(金) 06:47:17
>>635
FreeBSD5.3のKSE(M:N)とlinuxthread(1:1)が
たいしてベンチの結果が変らないのはどう評価すればいいんだろう。
・KSEのスケジューラが頑張っている。(1:1に負けてない)
・GiantLockがボトルネックになっていて頭打ちになり差が出ない。
のどちらなんだろう。

http://www.freebsd.org/smp/によれば、
6.xではほぼGiantLock問題が解決しているようだから、またベンチして欲しいところ。

>>639
> Linux上で最高のパフォーマンスが出せるようにチューニングされているんだから、

ソースきぼんぬ


643 :名無しさん@お腹いっぱい。:2005/11/13(日) 04:04:03
CPU数より多いスレッドを動かすっていうのは
プログラマの手抜きだよな。本当に性能を追求
するのなら、スレッド数はCPU数と同じにすべきだ。


644 :名無しさん@お腹いっぱい。:2005/11/13(日) 04:22:25
>>643はアホ


645 :名無しさん@お腹いっぱい。:2005/11/13(日) 04:37:18
すべてのスレッドが絶対にブロックしないなら、だね

646 :名無しさん@お腹いっぱい。:2005/11/13(日) 08:33:06
>>643
じゃあ、使えるCPUの数を実行時に知るpthread並にポータブルなやり方を
教えてくれ。

647 :名無しさん@お腹いっぱい。:2005/11/13(日) 09:01:01
しかも、実行中に異常なCPUを切り離せるような商用UNIXサーバを考えると
それに対応してスレッド数を増減するプログラムを書かないとな。


648 :名無しさん@お腹いっぱい。:2005/11/13(日) 10:02:53
実行時間とスレッド数の関係からシステムのCPU数を推定するheuristicを開発して
スレッド数を動的に変化させないのはプログラマの手抜きだよな。


649 :名無しさん@お腹いっぱい。:2005/11/13(日) 10:05:53
↓ここで「手抜きの何が悪い」とか正論ながら斜め上のレス


650 :名無しさん@お腹いっぱい。:2005/11/13(日) 11:04:04
手コキの何が悪い!


651 :名無しさん@お腹いっぱい。:2005/11/13(日) 11:10:12
でも、スケジューリングやらコンテキストスイッチやらの面倒な部分を
ほとんどライブラリにお任せして手軽に並列プログラミングをしよう、
ってのがマルチスレッドプログラムの本質だと思う。
それが嫌ならselectやその眷族を使うか、fiberみたいなので頑張れ。

652 :名無しさん@お腹いっぱい。:2005/11/13(日) 11:59:19
>>648
すごいなw
仮に数百CPUレベルまで通用するようなCPU数を推定するheuristicsが開発できたとして、
スレッド数をシステムのCPU数ぴったりに動的に変化させると、CPU数など無視して適当な
数スレッド作るプログラムより性能上がるのか?

ありえねぇ。

653 :名無しさん@お腹いっぱい。:2005/11/13(日) 19:58:42
たとえばN次行列の積を計算するのに、N^2個のスレッドを作れば
プログラムは楽だろう。でも、N=1000の時、1M個のスレッドを
作るヤシは馬鹿だ。敢えて言おう、クズであると!
ずっと昔にnastranのソースを見たことがあるが、昔の人は行列
の性質を利用して、計算を軽くしていたよ。


654 :名無しさん@お腹いっぱい。:2005/11/13(日) 20:08:04
ただ、まじめな話をすると、>>643の言うことにも一理あるよ。
つまり、可能な限り、プロセッサ数とアクティブなスレッド数は
一致する方が望ましいでしょ。

で、そういうのを希望する人は、WindowsでIOCPを使いましょ。
これは、スレッドとジョブを管理する仕組みとしては
おそらく最強だよ。少なくとも、理論上は。
>>647みたいなのに対応してるかは知らんけど。

655 :名無しさん@お腹いっぱい。:2005/11/13(日) 21:35:08
おまいらは、自分が動かしたアプリだけが
同時に各CPUに分散して使用してるはずだとでも思っているのでしょうか?

656 :名無しさん@お腹いっぱい。:2005/11/13(日) 22:06:24
「他のアプリが動いているかもしれないから、CPU数よりスレッド数を少なくしておく」より
100倍まともな考え方だと思うよ。
サーバーの場合には、占有していると考えてしまっても良いだろうし。

まあ、どのスレッドがどのCPUに割り当てられるかはスケジューラ依存で、
スレッドがCPUより多いのに(長時間)idleなCPUが出てしまうとしたら
それはスケジューラがタコなだけだし。

657 :名無しさん@お腹いっぱい。:2005/11/13(日) 22:32:46
>「他のアプリが動いているかもしれないから、CPU数よりスレッド数を少なくしておく」より
>100倍まともな考え方だと思うよ。
もちろん、そりゃそうだ。

だから結局、>>646,>>647って事になるのでは?

658 :名無しさん@お腹いっぱい。:2005/11/13(日) 22:44:30
だから>>654

659 :名無しさん@お腹いっぱい。:2005/11/13(日) 23:17:55
つうか、IO待ちになる箇所をちゃんと把握して、スレッド化してるんでしょうね?
まさか、シングルスレッドにしたら満足に動かないようなのを、マルチにして「おせぇ」「ウゴカネェ」とかいってんじゃないでしょうね?
・・・そんなことないよね、ごめんね。

660 :名無しさん@お腹いっぱい。:2005/11/13(日) 23:38:21
>>658
つうか、それ板違い

661 :名無しさん@お腹いっぱい。:2005/11/14(月) 09:29:07
>>658は頭大丈夫でしょうか?

入門書をもう少し丁寧に読んだ方がよろしいかと思われます。

662 :名無しさん@お腹いっぱい。:2005/11/14(月) 09:40:31
どの入門書が適当ですか?

663 :名無しさん@お腹いっぱい。:2005/11/14(月) 10:06:37
>>661
どこが変ですかね?
Windowsを出すのはこのスレにふさわしく無いのは当然だけど
プロセッサ数とスレッド数の関係が間違ってますか?
それとも、IOCPがソケットだけを扱うものだと言いたいのですかね?
もしかしたらIOCPを最強というのがお気に召しませんか?

まあ、入門書を読めとのことなので、pthreadの入門書は読んでますから
お勧めの「IOCPの入門書」とやらを教えてくださいな。

664 :名無しさん@お腹いっぱい。:2005/11/14(月) 10:28:01
IOCP最強なら、IOCP使った最強サーバがあっていいはずだが、ない。

665 :名無しさん@お腹いっぱい。:2005/11/14(月) 14:11:58
でも俺にはなぜほかのOSがIOCPを採用しないかがわからないから
何ともいえない。

666 :名無しさん@お腹いっぱい。:2005/11/14(月) 15:09:02
>>642

>http://www.freebsd.org/smp/によれば、
>6.xではほぼGiantLock問題が解決しているようだから、またベンチして欲しいところ。

なんかネットサーフィンしてたらFreeBSDとlinuxどっちが素敵か気になるから
ベンチしてみたくなった。

誰かベンチのルール決めて。

667 :名無しさん@お腹いっぱい。:2005/11/14(月) 16:21:45
>>665
Microsoft Windowsで動く最強サーバは?
例えばZeus Web Serverのように、マルチスレッド、SMPで、
突出した性能を示すサーバがありますか?

668 :名無しさん@お腹いっぱい。:2005/11/14(月) 20:05:47
>>666
とりあえずSMP性能がどれだけ向上してるか知りたいな。

http://pc.watch.impress.co.jp/docs/2005/1102/intel.htm
↑これを積んだ4wayサーバーを用意してくれ。

669 :名無しさん@お腹いっぱい。:2005/11/14(月) 20:29:37
>>668
それ以前に, 勝手にそれなりに粒度上げてくれるコンパイラ.


670 :名無しさん@お腹いっぱい。:2005/11/14(月) 22:27:52
>>669
意味わかんね

671 :名無しさん@お腹いっぱい。:2005/11/14(月) 23:29:43
IIS

672 :名無しさん@お腹いっぱい。:2005/11/14(月) 23:46:32
>>664
少なくとも、性能という面でWindows+IISは
(Apacheは論外としても)PC-Unix系の、並の"高速"httpdを上回るよ。
それこそ、カーネルでhttpdを動かすくらいでないと。
ただ、プロセッサ数が二桁以上になるような環境で性能が出せるのか
(Windows自体の性能も含めて)は知らない。

>>665
一つめの理由は簡単。
IOCPは、カーネルレベルでスケジューリングを行っているので
m:nスレッドではあまり意味がない(性能が出せない)。
もう一つの理由としては
select(とその拡張)系のシステムコールは、読み書き等のイベントが
"可能"になることを知らせる(待つ)のに対し
WindowsのOVERLAPPED系(IOCP含)は、イベントの"終了"を待つ仕様のため。


いや、普通に「性能」を求める場合、
ボス/ワーカー、或いは生産者/消費者みたいなモデル
これとスレッドプールを使ってジョブをキューにためて
ワーカースレッドが非同期に実行するって形を取るでしょ?
IOCPの場合は、その仕組みがOSに備えてあって(キューの排他制御等も不要)
さらに、スケジューリング(I/O待ちが発生したら別のスレッドを動かす等)までやってくれるから
「理論上の」仕組みとしては、間違いなく最強だって。

まあ、スレ違いなのでこの辺にしておくけど
興味のある人はちょっと読んでみて。
スケジューラ部だけを利用する場合、Create...でのHANDLEとの関連づけを無くして
Post...でジョブを登録する感じ。
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_GetQueuedCompletionStatus.asp
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_createiocompletionport.asp
http://www.microsoft.com/japan/msdn/library/ja/jpfileio/html/_win32_postqueuedcompletionstatus.asp

673 :名無しさん@お腹いっぱい。:2005/11/14(月) 23:54:11
>>672
理解が浅いね

674 :名無しさん@お腹いっぱい。:2005/11/14(月) 23:59:44
>>661さんですかね?
私は何という入門書を読むべきで、何について理解を深めるべきですか?

675 :名無しさん@お腹いっぱい。:2005/11/15(火) 00:10:05
>>672
IOCPしか知らない人ハケーン(w

676 :名無しさん@お腹いっぱい。:2005/11/15(火) 00:20:02
えーと、「自分が絶対正しい」なんて全然思っていません。
それに、知識がないこと自体は恥とは思わないし
むしろ、新しい知識を得られるのでうれしいのですが、、

「どこが間違っていて」「正しくはこうである(この方が良い)」というのを教わらないで
「おまえは間違っている」とだけ言われるのが一番嫌なんですが。
今のところ、自分ではどこが間違っているのか分からないので。


もしかして、kqueueとか/dev/pollにもスケジューラ機能があったりしますか?
それとも、スケジューラ機能付きのイベント告知システムが他に存在するということですか?

677 :名無しさん@お腹いっぱい。:2005/11/15(火) 00:33:25
あ、もしかして「同時にアクティブになるスレッド数を制限する方法」がpthread標準にあったりとか?
これがあれば、CPU数さえ把握できればコンテキストスイッチを減らせるし。

678 :名無しさん@お腹いっぱい。:2005/11/15(火) 04:48:21
>>672

> IOCPは、カーネルレベルでスケジューリングを行っているので
> m:nスレッドではあまり意味がない(性能が出せない)。
Linuxの2.6とかで使われてるNPTLは1:1モデルなんだけど、
何で使わないの?
その理屈だと、それほど実装が
難しいわけじゃない気がするけど。


まあたしかにIISは速い。うん。のかな?

679 :名無しさん@お腹いっぱい。:2005/11/15(火) 07:02:47
>>676
スレッド使うとプログラミングは簡単になるが、スレッド間の
コンテキストスイッチが必要なので、効率は若干犠牲になる。
aioだとコンテキストスイッチが不要なので、スレッド使う
よりも軽い。コンテキストスイッチしないから、スケジューラは
必要ない。

680 :名無しさん@お腹いっぱい。:2005/11/15(火) 07:13:29
>>676
AS/400とか
IBMもLinuxのpatch作ってた。(そもそもNTPLすら本家に入らなかったが…)



681 :名無しさん@お腹いっぱい。:2005/11/15(火) 07:49:10
>>672
> それこそ、カーネルでhttpdを動かすくらいでないと。

IISだって散々Windowsいじってるじゃん(w
それでも同じ構成で動かしているIBM機のTUXやZeusに勝てずに、
IBMはTUXやZeusを売り出しているのが現状。
しかもCPU増えると悲惨。
そんなにいい設計ならCPU増えてもスケールするはずだけど。
IOCPのスレッド数制限はthread boostと一緒でdirty hackに過ぎないと思う。

682 :名無しさん@お腹いっぱい。:2005/11/15(火) 07:53:18
Linuxのsendfile(2)とかいい加減にしろと思うけど、
ああいう汚いのは特定の場面では有効だわね。

683 :名無しさん@お腹いっぱい。:2005/11/15(火) 12:49:48
スレッドを使う理由を理解していない人が約一名いらっしゃるようでつね。

ヒント:多種多様、適材適所


684 :名無しさん@お腹いっぱい。:2005/11/15(火) 15:17:24
「マルチスレッドのスケジューリングのやり方」が
「理論上は」IOCPが優れているという話では無かったのか。

685 :名無しさん@お腹いっぱい。:2005/11/15(火) 15:43:23
sendfile、或いはwritevなんかもそうだけど
こういうのって、非同期ソケットだと若干効率悪くない?
要は、すぐに戻らなくちゃいけないから、結局全部送るまでに何度も行き来することになって。
もしくは、ブロッキングソケットを使って(非同期でもブロックする仕様だとして)も、
そのスレッドはsendfileに占有されちゃって、他の事が出来なくなるから
「select系使って単一スレッド」には向かなくて
「select系使ったスレッドで、ワーカースレッド群を管理する」という形にしないと。

この点(sendfileの効率)に関してだけは、
Windowsの完了待ちの方が向いてるとは思う。
逆に、「acceptしたら必ずrecv」という形になるから
そっちの面で効率が悪い(バッファが非ページメモリ上に必要等)けど。

686 :名無しさん@お腹いっぱい。:2005/11/15(火) 15:59:58
Completion portはSolarisにもあるよ。

687 :名無しさん@お腹いっぱい。:2005/11/15(火) 16:06:30
>>681
その行を引用していながら、TUXを例に挙げるのは何故?

688 :名無しさん@お腹いっぱい。:2005/11/15(火) 18:39:03
>>685
>この点(sendfileの効率)に関してだけは、
>Windowsの完了待ちの方が向いてるとは思う。
なんで?
詳しく!

689 :名無しさん@お腹いっぱい。:2005/11/15(火) 23:31:45
>>685
acceptしたらthread_createすればいい。ポートとthreadが
1:1になるから簡単だ。selectいらね。

690 :名無しさん@お腹いっぱい。:2005/11/15(火) 23:35:00
> なんで?

システムコールの回数を気にしているじゃない?

> 「select系使って単一スレッド」には向かなくて
> 「select系使ったスレッドで、ワーカースレッド群を管理する」という形にしないと。

ここは pthread スレだから、それでいいと思われ。

「select系使って単一スレッド」をしたい場合には、aio を使えば問題なし。
Solaris って、確か送信側は sendfile を使わなくても zero copy
になるから、mmap() しておいて aio_write すれば、sendfile は
使わなくても構わないでしょ。
完了は非同期に通知されるから、ブロッキングモードのままで OK。

691 :名無しさん@お腹いっぱい。:2005/11/16(水) 00:07:02
>>689
システムコールの回数やコンテキストスイッチの回数まで気にするような
シビアなサーバーでは
コネクション毎に1スレッド占有するような造りは
(たとえスレッドプール使ってても)あり得ないよ。

692 :名無しさん@お腹いっぱい。:2005/11/16(水) 00:28:23
>>690
> システムコールの回数を気にしているじゃない?

なんで?
sendfile(2)は一回だから最小の一つでしょ?


693 :名無しさん@お腹いっぱい。:2005/11/16(水) 00:36:49
もうわけわかなんですけど。

694 :名無しさん@お腹いっぱい。:2005/11/16(水) 00:43:37
>>692
ノンブロッキングモードで動かすと、引数で指定した
サイズを送信し終える前に、送信バッファが一杯に
なって返ってくる。だから、一回じゃなくて、小さい
サイズずつ細切れに送信することになる。

695 :名無しさん@お腹いっぱい。:2005/11/16(水) 02:28:28
へ?

696 :名無しさん@お腹いっぱい。:2005/11/16(水) 02:35:12
>>694
(゚д゚)ハァ?

697 :名無しさん@お腹いっぱい。:2005/11/16(水) 02:47:06
>>693
俺も俺も。脳みそ足んね

698 :名無しさん@お腹いっぱい。:2005/11/16(水) 04:24:52
>>696
partial write になる可能性があるってこと

699 :名無しさん@お腹いっぱい。:2005/11/16(水) 17:14:22
>>694
>ノンブロッキングモードで動かすと、引数で指定した
>サイズを送信し終える前に、送信バッファが一杯に
>なって返ってくる。だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。
言ってる事おかしくね?

700 :名無しさん@お腹いっぱい。:2005/11/16(水) 17:22:50
どこら辺が?
いや、俺、ノンブロッキングモードで sendfile を使ったことないから、
本当にこうなるかどうかは知らないんだけどね。でも、理屈はあってる筈。
それに、もしこうならなかったとしたら、sendfile で指定しただけのサイズ
の出力が終るまで他のディスクリプタに対する処理が問答無用で待たされる
ことになるので、それはそれで問題の筈。

701 :名無しさん@お腹いっぱい。:2005/11/16(水) 17:34:10
>ノンブロッキングモードで動かすと、引数で指定した
>サイズを送信し終える前に、送信バッファが一杯に
>なって返ってくる。
なんで送信バッファが一杯になって返ってくるの?

で、それが何故下記の文につながるの?
>だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。

702 :名無しさん@お腹いっぱい。:2005/11/16(水) 18:41:34
> なんで送信バッファが一杯になって返ってくるの?

TCP コネクションでの送信速度よりも速い速度で送信しようとすると、
送信のためのシステムコールの最中で待たされる (ブロックする)。
でも、ソケットをノンブロッキングモードで使っている場合は、ブロック
するわけにはいかないので、SO_SNDBUF を越えて書き込みが溜ると、そこ
までで書き込みシステムコールをいったん打ち切って、システムコール
から返ってくる。これが partial write。

で、それが何故下記の文につながるの?

>だから、一回じゃなくて、小さい
>サイズずつ細切れに送信することになる。

partial write が起きれば当然細切れになるでしょ。

703 :名無しさん@お腹いっぱい。:2005/11/16(水) 18:44:15
When using a socket marked for non-blocking I/O, sendfile() may send
fewer bytes than requested. In this case, the number of bytes success-
fully written is returned in *sbytes (if specified), and the error EAGAIN
is returned.

704 :名無しさん@お腹いっぱい。:2005/11/16(水) 18:46:29
NTのTransmitFileは送り終わるまでカーネル内で処理が完結するのにたいし、
sendfileでは、細切れ毎に呼び出すコンテキストスイッチが要るから、
ちょっと効率が悪いね、って話でしょ?

705 :名無しさん@お腹いっぱい。:2005/11/16(水) 18:53:16
>>702
なんでそんなに自信をもって間違えるの?

706 :名無しさん@お腹いっぱい。:2005/11/16(水) 18:58:02
>>704
>NTのTransmitFileは送り終わるまでカーネル内で処理が完結するのにたいし、
それブロッキングモードと何が違うの?

>sendfileでは、細切れ毎に呼び出すコンテキストスイッチが要るから、
>ちょっと効率が悪いね、って話でしょ?
何か論点おかしくない?

707 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:00:09
TransmitFileを呼び出したスレッドで、ファイル送信中に他の処理ができる。
ブロッキングだと、スレッドは占拠されてしまう。

708 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:06:52
ソケットバッファ広げてノンブロックモードでsendfile使用すればいいだけじゃん。
終わり。

709 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:16:59
ファイルと同程度のサイズのソケットバッファをとるならともかく、
ファイルよりも有意に小さいサイズのソケットバッファだと、
ファイルのディスクからの読み込みが、TCP の送信速度よりも
速ければ、結局、ブロックしてしまうので駄目。
ソケットバッファは実メモリを消費するので、ファイルと同程度の
サイズのソケットバッファをとるのは非常に無駄。

UNIX 系でシングルスレッドでやるなら、>>690 のやり方で解決する
のがベストじゃない?

>>705
どこら辺が間違ってると思うの?

710 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:27:43
> ファイルのディスクからの読み込みが、TCP の送信速度よりも
> 速ければ、結局、ブロックしてしまうので駄目。

ここ、分かりづらいかな。
もうちょっと解説しよう。
たとえば SO_SNDBUF で 1MB を設定して、ノンブロッキングモードで
sendfile すると、
1. バッファに 1MB 溜ってしまったので、partial write になって、
 sendfile(2) から戻る。返り値 *sbytes == 1MB。
2. 1パケット送信。バッファが 1.5KB ほど空く。
3. select(2) で調べると、送信可能であることが分かる (1.5KB 空き
 があるから) ので、sendfile(2) を呼ぶ。
4. バッファに 1.5KB つけたすと、1MB に達するので、partial write
 になって sendfile(2) から戻る。返り値 *sbytes == 1.5KB。
以下、2〜4 繰り返し。

というシナリオがありうるから駄目なの。

711 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:37:35
じゃあ、あれか、TransmitFileって奴は
ディスクからの読み込みでブロックすることは無いのか?

712 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:41:37
>>709
>ソケットバッファは実メモリを消費するので、ファイルと同程度の
>サイズのソケットバッファをとるのは非常に無駄。
別に必要であれば有効に使用すればいいだけでは?
何故、無駄と言いきる?

別にファイルサイズと同程度で無くとも良いではないか。

713 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:45:06
TransmitFile() って、sendfile(2) の aio 版みたいなもんじゃないの?
でも aio_write(2) が zero copy で動く OS なら、そんなもの使わなく
ても mmap(2) + aio_write(2) で十分と、そういうことでは?
aio_write(2) が常にコピーする OS では aio_sendfile(2) みたいなのが
あった方がいいのかも。


714 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:48:05
>1. バッファに 1MB 溜ってしまったので、partial write になって、
> sendfile(2) から戻る。返り値 *sbytes == 1MB。
>2. 1パケット送信。バッファが 1.5KB ほど空く。
>3. select(2) で調べると、送信可能であることが分かる (1.5KB 空き
> があるから) ので、sendfile(2) を呼ぶ。
>4. バッファに 1.5KB つけたすと、1MB に達するので、partial write
> になって sendfile(2) から戻る。返り値 *sbytes == 1.5KB。
>以下、2〜4 繰り返し。
>
>というシナリオがありうるから駄目なの。
っていうかそんなのsendfile使う奴が気を付ければいいだけじゃん。

では、聞くが駄目でない方法とはなんなんだ?

715 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:48:30
> 別に必要であれば有効に使用すればいいだけでは?
> 何故、無駄と言いきる?

そんなに大きなバッファは、本当に必要なわけじゃないからメモリの無駄なの。
>>690 のやり方なら、ずっと小さなバッファで済む。

> 別にファイルサイズと同程度で無くとも良いではないか。

sendfile(2) + ノンブロッキングソケットの場合、>>710 の問題にハマるので駄目。



716 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:49:50
> では、聞くが駄目でない方法とはなんなんだ?

>>690 に既に書いてあるのでは?


717 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:50:06
ディスク読み込みの発生しない、
魔法のOSなんかありません。

718 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:52:52
> ディスク読み込みの発生しない、魔法のOS

誰もそんな話はしてないけど…

719 :名無しさん@お腹いっぱい。:2005/11/16(水) 19:52:58
zero copyはな、メモリに存在するからできるんだよ。
知らんのか?

720 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:06:01
何故、>>690のやり方が>>710にならないと言いきっているの?
その根拠は?

721 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:10:20
>>710 が生じるのは、ノンブロッキングモードで動かしているせい。
>>690 の方法は、ブロッキングモードで動作するから大丈夫。
ってゆうか、既にそう書いてあるじゃん。どこ読んでるの?

722 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:10:21
それがaioだから、としか言いようがないと思うが。
というか、このスレに、aioとノンブロッキングとブロッキングが
理解できない人間が混ざっているのか?

723 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:17:37
>Solaris って、確か送信側は sendfile を使わなくても zero copy
>になるから、mmap() しておいて aio_write すれば、sendfile は
>使わなくても構わないでしょ。
これでも、>>710になるだろ。

724 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:19:51
つうかさ、ネットワーク越しなんだろ?
ならソケットバッファの容量が影響するじゃん。

725 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:25:56
> これでも、>>710になるだろ。

もしそう思ってるなら、ブロッキングモードとノンブロッキングモードの
動作の違いから勉強し直した方がいいと思うよ。マジで。

> ならソケットバッファの容量が影響するじゃん。

ノンブロッキングモードの場合は関係する。
だから何度も SO_SNDBUF って言葉が出てるわけでしょ。
今ごろ何言ってるの?

726 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:33:35
>>725
>もしそう思ってるなら、ブロッキングモードとノンブロッキングモードの
>動作の違いから勉強し直した方がいいと思うよ。マジで。
ならば、どんなファイルサイズでも>>710にならないと言うのか?

727 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:37:48
いまだかつてこんなにも活気のあるこのスレを見たことがない。

728 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:39:21
漁スレの予感

729 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:40:49
この問題ってファイルサイズに依存しないか?

730 :名無しさん@お腹いっぱい。:2005/11/16(水) 20:42:25
>>726, >>729
動作を理解していれば、自分で答は分かる筈。
っていうか、自分が理解してないことが分かったなら、人に答を
聞くんじゃなくて、地道に勉強すべきじゃないのかね。でないと
プログラミングはできないよ。
OS の優劣をカタログスペック的に暗記したいだけなら話は別だけど。

まあ、勉強しなくても、既に答は書いてあるけどね。


731 :名無しさん@お腹いっぱい。:2005/11/16(水) 21:57:22
そもそも、何が言いたいのかわからない。

732 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:00:52
>>730
ROTFL

733 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:03:35
ファイルサイズには無関係で、partial writeにならずに転送なんてできるのでしょうか?

734 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:04:51
>>730
>>726の答えになってない。

735 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:06:20
>>733
ソケットバッファを越えるファイルサイズであるなら、partial writeになってしまう。

736 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:19:15
>>735
勉強不足。ブロッキングモードでの write(2) は、たとえ
ネットワークへの書き込みでも partial write にはならない。
(ただし、書き込み中に signal が生じた場合などは例外)

737 :名無しさん@お腹いっぱい。:2005/11/16(水) 22:56:08
>>690のやり方も、完璧な解ではないんじゃないかな。
もちろん、よほどの事がない限り問題になることは無いけれど。

>>690って、mmapした領域は1回読み出したらページアウト可能なんだけど
さすがにそれを類推できるOSって普通無いでしょ?
で、mmapした領域で、かつ読み込みのあった領域ってのは
ページアウトの優先順位が低いとすると
巨大なファイルの場合だとメモリ使用量に無駄が出て
他のプロセス等に影響が出る場合もあるかな、って気も。

やっぱり、可能ならaio_sendfileがあった方がうれしいケースも出てくるような。
まあ、mmap後は読み込みだけだから(ディスクに実体があるから)
ページアウトの優先順位は高いかもしれないので
机上の空論かもしれないけど。

738 :690:2005/11/16(水) 23:03:55
> 巨大なファイルの場合だとメモリ使用量に無駄が出て
> 他のプロセス等に影響が出る場合もあるかな、って気も。

このケースの場合、madvise(2) で MADV_SEQUENTIAL しておけばページング
に関する問題はない筈。たいていの OS では、MADV_SEQUENTIAL の場合の
ページング方針の最適化をしてるので。(Solaris は間違いなくやってる)

> やっぱり、可能ならaio_sendfileがあった方がうれしいケースも出てくるような。

でも、まあこれは同意。特に Web サーバで、たくさんのファイルをサービス
する場合、>>690 だと mmap() と munmap() を繰り返すことになるけど、
aio_sendfile(2) があれば、それも省けるので、若干効率はいいはず。
aio と sendfile(2) の両方の機能がある OS にとっては自然な拡張だから、
そのうち、いろんな OS で実装されても不思議はないね。

739 :名無しさん@お腹いっぱい。:2005/11/16(水) 23:58:36
>>707
> TransmitFileを呼び出したスレッドで、ファイル送信中に他の処理ができる。

ソースきぼん!


740 :名無しさん@お腹いっぱい。:2005/11/17(木) 00:27:44
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/transmitfile_2.asp
ほれ。
OVERLAPPEDを渡せば呼び出しからすぐ戻り、完了が非同期で通知されるようになる。

741 :名無しさん@お腹いっぱい。:2005/11/17(木) 00:42:00
>>685
>sendfile、或いはwritevなんかもそうだけど
>こういうのって、非同期ソケットだと若干効率悪くない?
>要は、すぐに戻らなくちゃいけないから、結局全部送るまでに何度も行き来することになって。
その場合の非同期ソケットを使うことの意義って効率うんぬんよりも、
別作業で他の作業をさらに続けたい時に、便利であるという物だけなのでは?

742 :名無しさん@お腹いっぱい。:2005/11/17(木) 00:47:13
>>736
>>735ではノンブロッキングモードである事を想定して書いた。
がそれを明記しなかった。スマソ

743 :名無しさん@お腹いっぱい。:2005/11/17(木) 00:47:26
sendfile() の意義って効率だけなんだから、sendfile() 使ってて
効率が悪くなるなんて大問題。sendfile() の存在意義がなくなる。

744 :名無しさん@お腹いっぱい。:2005/11/17(木) 00:56:01
>>743
>sendfile() の意義って効率だけなんだから、sendfile() 使ってて
>効率が悪くなるなんて大問題。sendfile() の存在意義がなくなる。
確かにそうなんだけどなw

恐らくそれをする(nonblock & sendfile)人は効率を悪くしてでもやりたい事があるんだろうなw

745 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:20:11
だから効率の悪くて嫌だって話だろ。
そもそも、select系でノンブロッキングソケットを使う理由は
マルチスレッドのコンテキストスイッチすら嫌うからだよ。

746 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:24:11
>>672
>IOCPの場合は、その仕組みがOSに備えてあって(キューの排他制御等も不要)
>さらに、スケジューリング(I/O待ちが発生したら別のスレッドを動かす等)までやってくれるから
>「理論上の」仕組みとしては、間違いなく最強だって。
最強って言うのはどうかわからんが、ようするに便利だって事だけでしょ。

747 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:24:41
同時接続1000-2000程度しか想定しなくて良いなら
1スレッド1接続でも大丈夫だろうが
万単位まで視野に入れるには、select系(の拡張)のノンブロッキングを使うんだよ。
もちろん、マルチプロセッサやI/Oブロックを考慮して
マルチスレッドも併用してね。

748 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:26:03
なぁこのスレでそもそも何に関して議論してるの?
全然、話がつかめないんだけど。

749 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:26:44
>>746
> 最強って言うのはどうかわからんが、ようするに便利だって事だけでしょ。

便利なだけじゃなくて、
ちゃんとアクティブなスレッド数を調整してくれる機能があるって。
これがあるから、コンテキストスイッチが最小限に抑えられるの。

750 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:29:56
>>747
で、そのIOCPを使用して万単位のすごいパフォーマンス結果はどこかで見れるのかね?

751 :750:2005/11/17(木) 01:36:47
間違った。
>>750は以下に変更

>>749
で、そのWindowsのOVERLAPPED系(IOCP含)のパフォーマンス結果はどこかで見れるのか?

752 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:38:31
まあ普通そこまで考えなければいけないのは
MMOとかストリーミング系とかだろうな。
実際に何を使っているかは知らないが。

Web鯖ではそこまでの規模が必要なら
単に分散するだけだろう。

753 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:44:25
そういえば、windowsupdateが数ヶ月前くらいにトラブってたな。
あそこは定期update時に数百万以上の同時接続があるのは確か。
まあ、何台使っているかは知らないが、Win鯖を一万台使って
一台当たり1000接続だったら大笑いだけどね。

754 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:46:15
>>747
senndfile&ノンブロックが非効率だろって事はどうなるの?

755 :名無しさん@お腹いっぱい。:2005/11/17(木) 01:52:43
>>749
>ちゃんとアクティブなスレッド数を調整してくれる機能があるって。
>これがあるから、コンテキストスイッチが最小限に抑えられるの。
詳しくは知らんけど、これってSolarisやLinuxでも出来そうじゃね。

756 :名無しさん@お腹いっぱい。:2005/11/17(木) 02:06:59
>>754
効率重視のサーバーではノンブロッキング+selectを使いたい
当然、ファイルを送るためには、効率の良いsendfileを使いたい
けど、sendfileはノンブロッキングとの相性がイマイチ
という流れでは。

>>755
スレッドプールにタスクを渡し、どのスレッドがいつタスクを実行するかはOSが管理する
というシステムは作れるんじゃないかと。
現状のシステムの組み合わせで出来るかは知らない。
単純にスレッドプールを使うだけだと、
待ちを考慮してCPU数より多くのスレッドをプールすることになり
ピーク時に同時実行スレッドが増えてしまってコンテキストスイッチが発生する
というのが問題(?)点だから。

757 :名無しさん@お腹いっぱい。:2005/11/17(木) 04:12:04
スレッド間のコンテキストスイッチってそんなにコストかかるもんなの?
ページ変換テーブルとか切替える必要なさそうだし、たいしたコストは
ないもんだと思ってた。
スタックが分散するから、キャッシュは無駄になりそうだけど。


758 :名無しさん@お腹いっぱい。:2005/11/17(木) 06:11:58
キャッシュに関しては、量よりも直接のヒット率の方が影響あるんじゃないかな。
中断したタスクを再開したときに、同じプロセッサが割り当てられるとは限らないわけで
全部読み直しに近い場合もあるだろうし。
ただ、その辺はカーネルのスケジューラが出来る限りのことはしてくれると思うし
どの程度差がでるかはわからんね。

759 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:01:52
> ただ、その辺はカーネルのスケジューラが出来る限りのことはしてくれると思うし

Windowsはこれやってくれないんだよねえ…。
重いプロセスをSMPマシンで動かすと、複数CPU間を行き来して余計に遅
くなったりする。

UNIXで、そのへんちゃんと考慮してくるのって、ある?


760 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:17:27
アフィニティを手動設定して終わりじゃないの?

761 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:44:51
>>746
せいぜい「便利なときがある」くらいでしょ。
マイクロソフトお得意の場当たり的スケジューラ特殊化だから。

762 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:47:18
>>759
一つのプロセス(スレッド)を特定のCPUに割り当てたければ、
processor setを使うのがSolaris流儀。

763 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:49:41
>>749
> ちゃんとアクティブなスレッド数を調整してくれる機能があるって。

何をどう調節するの?
アクティブじゃなくていいかどうかはどう判断するんでしょう?
後回しにされたスレッドの立場は?

764 :名無しさん@お腹いっぱい。:2005/11/17(木) 07:54:10
>>760
手動で設定しないと上手くいかない状況は、スケジューラが考慮してい
るとは言えないのなの。


765 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:22:52
>>763
同時に実行される必要がないタスクだからIOCPに管理されたスレッドを使うのであって
後回しにされるタスクが出るのが嫌なら
普通のスレッドを使えばよいだけ。

766 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:26:12
>>765
要するに、静的に分類して、優先順位をつけるわけですね?

767 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:29:11
素のWindows + IISで速い例なんてあるの?
IBM, NEC辺りのはカーネルが素のWindowsとは違う独自バージョンだよ。
奴等ソースコードいじっているから。Databaseの時もそう。

768 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:29:17
は?

769 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:34:31
まあいいや。「とりあえずWindowsを叩いときゃいいや」って人は相手にしないどこ。
説明しても理解する気無さそうだし。

大半の人は「良いところもあれば悪いところもある」ってのは分かってるんだから。

770 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:36:42
おまいら捨てハンぐらい付けたらいかがでしょうか。
何人いるの?


771 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:40:29
まず自分からつけなよ。
今後全部読み飛ばすようにするから。

772 :770:2005/11/17(木) 08:44:23
あ、全然別の人だったかな。
自分以外で ? を使っている人って事で勘違いしたかも。
だったらごめんね。

773 :772:2005/11/17(木) 08:44:59
すまん、>>772は771

774 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:49:34
IOCPが理論的に最速であることを説明してくれる人きぼんぬ

775 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:50:29
>>764の言っていることは、
>>765にあらかじめ答えているようなもんだな。

776 :名無しさん@お腹いっぱい。:2005/11/17(木) 08:58:22
用途の問題だけど。
4CPUとして、
5つの計算をして最後に同期を待つ必要があるのなら
普通のスレッドで並列に実行させれば、1つの計算の1.25倍+αで終わるけど
非同期に1000個のリクエストが来るサーバーでは
最大4つ以上は同時実行せず、1つづつ完全に終了するまで待つ方が
オーバーヘッド分効率が良いというだけ。

あと、IOCPを使ったサーバーでも、普通はlistenするスレッドは独自に動いてるし。

777 :名無しさん@お腹いっぱい。:2005/11/17(木) 09:06:09
タスク処理時間に偏差がある場合、
平均待ち時間が悪くなるスケジューリングポリシーですね。
処理時間が見積もりやすい科学技術計算辺りが得意分野なのでは?

778 :名無しさん@お腹いっぱい。:2005/11/17(木) 09:17:56
タスク処理時間の偏差はいいですけど
タスク開始時間の偏差はいかがですか?

779 :名無しさん@お腹いっぱい。:2005/11/17(木) 10:48:15
>>777
コンテキストスイッチのオーバーヘッドに比べて、
デメリットの方がずっと大きいような…
# webサーバの場合、客を待たせる時間になっちゃうから。

総処理時間合計のベンチマークではいい性能に見えるんだろうけど…

780 :名無しさん@お腹いっぱい。:2005/11/17(木) 14:07:48
ネットワークの遅延の方が大きいような。
それ以外にも、例えばnagleが有効ならば数百msの遅延が簡単に発生するわけで。

781 :名無しさん@お腹いっぱい。:2005/11/17(木) 14:23:23
で、結局は道具の使い方の問題だと思うし。

例えば、秒単位の遅延が見込まれる処理(CGIの実行など)は
別にスレッドを動かして、「実行が終わったよ」というシグナルをポストして
他のリクエストと同等のタスクとして終了処理などをするという手もあるし。

そもそも、計算だけで秒単位の時間がかかる処理をWeb鯖が行うというのは
一般的なのかどうか。
(ディスクI/OやDBとの交信など、スレッドがブロックした場合には
次のタスクの実行が開始される、という仕様だから)

782 :名無しさん@お腹いっぱい。:2005/11/18(金) 14:21:59
>>769
この板でそんな物説明する奴が悪い。シッシッ!

783 :名無しさん@お腹いっぱい。:2005/11/21(月) 22:50:50
>>1の想像を越えた良スレになりつつある件について

784 :名無しさん@お腹いっぱい。:2005/11/28(月) 00:11:51
久々に伸びてると思ったが、
unix板の悪い面が出まくりだな。
windowsアレルギーってまだあるんだ。

785 :名無しさん@お腹いっぱい。:2005/11/28(月) 00:15:46
>>784
具体的に

786 :名無しさん@お腹いっぱい。:2005/11/28(月) 17:48:29
windows機雷

787 :名無しさん@お腹いっぱい。:2005/12/18(日) 11:26:49
IOCPがUNIXで実装されないことについての具体的な答えはなかったな。
実装されないことについての必然的な理由が必要というわけではないけど。

788 :名無しさん@お腹いっぱい。:2005/12/18(日) 11:39:30


789 :名無しさん@お腹いっぱい。:2005/12/18(日) 15:18:43
と思ったらSolarisにはあるんだな。
http://developers.sun.com/solaris/articles/event_completion.html

これちょっと調べて見るか。

790 :名無しさん@お腹いっぱい。:2005/12/23(金) 22:26:54
>>789
>>686



791 :名無しさん@お腹いっぱい。:2006/01/20(金) 17:39:54
pthread_createして生成されたスレッドが死んでってのを
何十回か繰り返すとpthread_createからENOMEMが帰ってくるんだけど
何が足りないの?
空きメモリは有るみたいだし,生きてるスレッドは1個だけで
RHL9なんすけど.

792 :名無しさん@お腹いっぱい。:2006/01/20(金) 19:33:13
>>791
detachかjoinしてる?


793 :名無しさん@お腹いっぱい。:2006/01/20(金) 19:51:05
>>792
>detachかjoinしてる?
791がそれをしてないに、10000 マルク。

794 :791:2006/01/23(月) 11:10:36
すっかり忘れてた.


795 :名無しさん@お腹いっぱい。:2006/01/26(木) 13:52:32
pthread をソケット通信で試しに使い始めてみたんですが、どうやらリークしてるっぽくて、

mtrace の結果と objdump を元に、glibc のソースから pthread.c や specific.c をつき合わせたら、
int __pthread_initialize_manager(void)

  /* Setup stack for thread manager */
  __pthread_manager_thread_bos = malloc(THREAD_MANAGER_STACK_SIZE);
↑↑↑↑ こいつが1度だけ呼ばれて 8160 byte かかえたまま free されてないっぽいんです。
また実行中に
int __pthread_setspecific(pthread_key_t key, const void * pointer)

void *newp = calloc(PTHREAD_KEY_2NDLEVEL_SIZE, sizeof (void *));
も free されないので、accept の回数を重ねるたびにどんどん膨らんでいきます。

これについて何か既出の情報ってありますか?

796 :795:2006/01/26(木) 14:20:07
うおぉぉぉ 真上に解決策が書いてあるじゃまいか orz

pthread_detach し忘れてますた
スレ汚しすまそ


797 :名無しさん@お腹いっぱい。:2006/01/27(金) 01:37:41
そういえば、joinでは複数のスレッドを待てませんが、
どこかでデッドロックを避けるためだと読んだことがあるのですが、
具体的には書いてありませんでした。
知ってる人いますか?

798 :名無しさん@お腹いっぱい。:2006/01/28(土) 13:36:33
>>797
どこに書いてあった?

799 :名無しさん@お腹いっぱい。:2006/01/28(土) 23:04:41
>>798
どこだったか思い出せないのですが
「昔はwaitallだかwaitanyの様なのがあった」らしいです。
ゾンビネタを読んで疑問を思い出しました。


800 :名無しさん@お腹いっぱい。:2006/02/23(木) 16:39:36
<ちら裏>
pthread を使ったソケットプログラム。

accpet したソケット fd を子スレッドに void* で渡す、定番のコードのつもりだったんだけど、
void * のポインタなんだからと思って

fd=accept(listen, &addr, &addr_len);
pthread_create(&id, NULL, child_func, (void *)&fd);

と参照渡しをしたところ、同時多数アクセスがあったとき、親スレッドと子スレッドで異なる
fd にアクセスする奇怪現象に悩まされた。子スレッドが fd を実際に読むする前に、
親側では次の accept が呼ばれて fd が書き換わってたというオチ。素直に

pthread_create(&id, NULL, child_func, (void *) fd);

と値渡しにすることで解決。

お粗末。
</ちら裏>


801 :名無しさん@お腹いっぱい。:2006/02/23(木) 19:59:51
粗末だな……


802 :名無しさん@お腹いっぱい。:2006/02/26(日) 01:08:49
accept() してから pthread_create() よりも、

「まずは listen() したソケット用意して、
そいつを非ブロックモードに設定して、
同時接続最大数のスレッドを pthread_create() して、

生成されたスレッドそれぞれで mutex 獲得して、
listen ソケットを accept() して、
mutex を解放。

accept() の戻り値が 0 以上だったら、その戻り値を接続相手との通信ソケット記述子に使用する。
通信終了したら accept() の戻り値を close() する。

mutex 獲得に戻る。」

が、いいんじゃないの? ちがうの? いつも、こーゆーふーにしてたよ…

803 :名無しさん@お腹いっぱい。:2006/02/26(日) 02:51:51
>>802
非ブロックモードにしないでみんなで
acceptでスリープするのはどう?
あとmutexは短時間の排他に最適化されるのでmutex+acceptはまずい。
sem_wait/postか、condvarをつかう。

804 :名無しさん@お腹いっぱい。:2006/02/26(日) 16:03:25
>>803
そのやり方は、設計に依存するんじゃね?

805 :名無しさん@お腹いっぱい。:2006/02/27(月) 02:05:15
>>802
おいおい……それ思いっきりビジーループしてるじゃねえか。

却下だ、却下。

806 :名無しさん@お腹いっぱい。:2006/02/27(月) 11:04:18
>>805
802が暗黙の了解で select/poll してると想像してみるテスト

807 :名無しさん@お腹いっぱい。:2006/02/28(火) 03:11:33
>>805
> >>802
> おいおい……それ思いっきりビジーループしてるじゃねえか。
> 却下だ、却下。
mutex の獲得で待ち合わせしててもダメなの?


808 :名無しさん@お腹いっぱい。:2006/02/28(火) 07:30:48
>>807
mutexをそういう風に使ってはいけないと婆さんが言ってました。

809 :名無しさん@お腹いっぱい。:2006/02/28(火) 08:40:23
acceptしてそのまま処理するのが普通なの?

私はaccept専用スレッドつくって、acceptしたら別スレッドに処理させるかな。
そしたらacceptスレッドは、接続があるまで(acceptでもselectでも)寝てればいいし。

どうでもいいのなら、1接続1スレッドでスレッド使い捨て、
まじめに作るなら、1スレッドで複数の接続を扱うようにする。
スレッド数はCPU数とかに応じて適当に決める。


でも、みんなでacceptするやり方だと、
acceptすべきかどうか判断するのが簡単になりそう。
自分が上限まで接続を扱ってたら、acceptしなければ良いだけだし。

acceptして放置するのと、acceptしないのってどっちが良いんだろうか…

810 :名無しさん@お腹いっぱい。:2006/02/28(火) 11:02:11
ヘビーロード、特に接続到着について、サーバは両者の組み合わせ。

811 :名無しさん@お腹いっぱい。:2006/02/28(火) 19:50:56
>>809
確か、accept()をすると、SynAck返したはず
だから、実行するのとしないのとでは挙動に違いがでるよ。

812 :名無しさん@お腹いっぱい。:2006/02/28(火) 21:51:38
うん。そこまではわかるんだけど、
いずれ処理してやれるなら、とりあえずacceptした方が良いのかな。

813 :811:2006/02/28(火) 22:22:57
>>812
いやだからさ、TCPコネクションにタイムアウトさえしなければ
どっちでもいいと思うぜ。

814 :名無しさん@お腹いっぱい。:2006/02/28(火) 22:32:10
>>812
listen状態のsocketのbacklogを伸ばす方法もある。

815 :名無しさん@お腹いっぱい。:2006/02/28(火) 22:41:43
>>811
ACKは、acceptしなくても返すんじゃないのか?
listenのバックログに余裕がある間は。
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-3.html#ss3.3
って、その事だと思うんだけど。

とすれば、単位時間に処理できる限界を超えない限り、
accept自体は急ぐ必要は無いでしょ。

816 :811:2006/02/28(火) 23:12:51
>>815
あう。
そうだったね。スマソ > 809

817 :811:2006/02/28(火) 23:21:52
といっても、accept()を思い出したように処理してるアプリなんて今まで見た事ないなぁ。

818 :名無しさん@お腹いっぱい。:2006/03/01(水) 00:01:41
「accept自体は比較的重い処理なので
listenしているスレッドではacceptableというイベントのみを検知して
accept自体はワーカースレッドに投げて処理させる」
という方式は、どこかで見たよ。

「acceptが重い処理」というのは、たぶんWinsockのIOCPとかAcceptExとかその辺を調べている時に
見たんだと思うけど、accept時のカーネル内部での処理の重さは、
Windowsでもそう変わらないでしょ、たぶん。

819 :名無しさん@お腹いっぱい。:2006/03/01(水) 00:45:59
acceptが重いんじゃなくて、
acceptをたくさん動かすためにはその分プロセスが必要だからでしょ?

Solarisなんかはthread単位で大丈夫だけれど、それでもselect/pollよりリソース食う。
apache2はその辺いろいろカスタマイズできるよね。

820 :名無しさん@お腹いっぱい。:2006/03/01(水) 01:31:00
なんでacceptとプロセスが関係あるのさ?
>>818がWindowsの話なら、マルチプロセス型のサーバーなんか絶対あり得ないのに。

821 :名無しさん@お腹いっぱい。:2006/03/01(水) 15:07:59
>>818
他のOSは知らんけど、Linuxに限って言うとacceptはそんなに重い処理では無いよ。

822 :名無しさん@お腹いっぱい。:2006/03/01(水) 20:28:05
>>821
どんな OS でもおおむね以下のような処理になると思われる.

受信割り込みから起こされた処理が, コネクション確立を確認
したら, その情報を listen queue につないで, accept してる
奴を起こす

accept は
while (listen queue が 空)
寝る
socket 作って listen queue から取り出した情報を設定(これ
は受信側でやってもいいし...)
該当 socket をプロセスなりファイルディスクリプターなり
に関連付する
上記 socket から peer address 情報引っ張ってきて引数で
指定された場所に書き込む

結局 accept って寝てるだけじゃん


823 :818:2006/03/01(水) 23:50:58
>>822
他のOSも似たような実装だと思うけど、
そうすると、818がWindosにおいてacceptが比較的重いと言ってるのが謎。

824 :823:2006/03/01(水) 23:52:32
名前欄間違った。
818でなくて、821ね。

825 :名無しさん@お腹いっぱい。:2006/03/02(木) 06:31:24
>>822
> while (listen queue が 空)
> 寝る

signal_wait(listen_queue);

とevent駆動型になっている

826 :名無しさん@お腹いっぱい。:2006/03/02(木) 06:32:29
>>823
あんなの>>818の勘違いでしょ。

827 :822:2006/03/02(木) 08:07:32
>>825
> signal_wait(listen_queue);
やってること(つかセマンティック)はいっしょじゃん.
要は寝てると...


828 :名無しさん@お腹いっぱい。:2006/03/02(木) 08:32:04
whileで書くとbusy waitみたいだからいくない

829 :名無しさん@お腹いっぱい。:2006/03/02(木) 09:38:43
>>828
寝るって書いてあるのに busy wait も何もあったもんじゃないような気が...


830 :名無しさん@お腹いっぱい。:2006/03/02(木) 15:57:49
>>828
>whileで書くとbusy waitみたいだからいくない
それ既成概念にとらわれているよ。
オープンソースなカーネル見ればわかるよ。

831 :名無しさん@お腹いっぱい。:2006/03/02(木) 16:50:43
init() の main が for(;;); で終わってるやつ?

832 :名無しさん@お腹いっぱい。:2006/03/02(木) 17:39:31
それなんの奴?FreeBSD?

833 :名無しさん@お腹いっぱい。:2006/03/02(木) 22:33:27
1) acceptするスレッドは1匹だけ
  cond varで餌待ちのワーカースレッド多数
2) 多数のスレッドみんながaccept

どっちが性能/設計的に良い?


834 :名無しさん@お腹いっぱい。:2006/03/02(木) 23:26:26
>>833
スレッドが多すぎると (1) の方が不利な希ガス

835 :名無しさん@お腹いっぱい。:2006/03/03(金) 00:04:52
でも、2)は、1接続が1スレッドを占有する方式の時じゃないと使いにくいでしょ。
細切れタスク(例えばKeep-AliveなHTTPでの1リクエスト等)をスレッドプールに渡す方式にするなら
必然的に1)になるんじゃないかな。

836 :名無しさん@お腹いっぱい。:2006/03/03(金) 06:40:31
SMP なんかだと, accept する thread 増やすと client から見た
時の応答性能は上がると思われるので, accept する thread は
CPU の個数以上/餌待ちワーカースレッド多数ってのが現実的な解
ではないかと, 愚考してみる.


837 :名無しさん@お腹いっぱい。:2006/03/03(金) 16:58:20
だから、
鯖がACKを返し、それをクライアントが受け取ってからデータを送信、という
ネットワークの往復期間内にacceptが完了するのであれば
応答性なんて全然変わらないと、>>815で指摘されてるでしょ。

838 :名無しさん@お腹いっぱい。:2006/03/03(金) 19:56:41
>>837
いや、ある条件においてはそれが覆されると思う。

それは、複数のNIC and IPを持つサーバの場合だ。
複数NICで複数IPアドレスを割り振ったら、>>836のやり方でも良いと思うよ。

839 :名無しさん@お腹いっぱい。:2006/03/03(金) 21:30:15
その辺はapache2のチューニング報告でよく語られてますよん。
カーネル内HTTPサーバのTUXではどうなのか知りたいところだが、
いいベンチマーク報告が見つからない。

840 :名無しさん@お腹いっぱい。:2006/03/03(金) 22:48:39
>>838
要するに帯域オーバの場合だな。

841 :名無しさん@お腹いっぱい。:2006/03/07(火) 16:41:21
>>820
昔は acceptしてから子プロセス作って...って感じだったから、それとごっちゃになってるんじゃね。

俺自身が関わる範囲では
>>809の「私はaccept専用スレッドつくって、acceptしたら別スレッドに処理させるかな」
で十分だ。


842 :名無しさん@お腹いっぱい。:2006/03/08(水) 07:09:55
>>841
>>昔は acceptしてから子プロセス作って

今だって、ftp、telnet みたいに子プロセスを作るのは普通にある
Webサーバみたいに短時間でコネクションが切れちゃうものは、
スレッドで済ませる場合があるだけ。

あと、>>820>>841 は accept 後の並列と、accept の並列を勘違いしてる

843 :名無しさん@お腹いっぱい。:2006/03/08(水) 10:42:30
>>842 今だって、ftp、telnet みたいに子プロセスを作るのは普通にある
そうだね。

まぁもともとの >>800 は、ローカル変数 fd をスコープはずれてからもアクセス
しようとしてるっつう並列処理以前の話だがな



844 :名無しさん@お腹いっぱい。:2006/03/08(水) 16:27:24
>>842
>>820のどこが勘違い?
勘違いしてるのは>>819だろ

845 :名無しさん@お腹いっぱい。:2006/03/08(水) 16:30:16
あ、違うな。
>>818はacceptの重さを問題(真偽はともかく)なのに
>>819がプロセスの重さに勝手に置き換えて、
それを>>820が指摘しているだけだな。

846 :名無しさん@お腹いっぱい。:2006/03/10(金) 23:44:49
linux って clone つかって pthread 実装してるでしょ?
PID も違うものが割り当てられる。。。そこまではいい。

#include <pthread.h>
void *func(void *arg)
{
 printf("child %d\n",getpid());
 while(1);
}
main()
{
 pthread_t th;
 printf("parent %d\n",getpid());
 pthread_create(&th,NULL,func,NULL);
 while(1);
}


これ動かすと、
$ ./sample
parent 29220
child 29222
$ /sbin/pidof sample
29222 29221 29220
pid が 3つ見える。29221 の正体はなぞ。なにこれ?

847 :名無しさん@お腹いっぱい。:2006/03/10(金) 23:57:56
2.6系使いなよ。

848 :名無しさん@お腹いっぱい。:2006/03/11(土) 00:07:21
>>846
noneNPTLのマネージャースレッドでは?

849 :名無しさん@お腹いっぱい。:2006/03/11(土) 00:37:53
>>848
dクス
そういうことみたい
$ getconf GNU_LIBPTHREAD_VERSION
linuxthreads-0.10


850 :名無しさん@お腹いっぱい。:2006/03/15(水) 06:53:20
SIGHUP を受けて設定ファイル等を再読み込みの要求があったときに
全てのスレッドがループの所定の位置(例えば先頭)に戻って来るまで
待つような同期処理はどうしますか?

signal ハンドリング用のスレッドを回しておいて、そいつが SIGHUP を
受けると、各ループが作業中確保していた mutex を奪取するというのが
考えられるんですが・・・・

851 :名無しさん@お腹いっぱい。:2006/03/16(木) 17:47:36
>>850
mutexをとれる保証はないのでrwlockでバリアするのがよいかと。


852 :名無しさん@お腹いっぱい。:2006/03/16(木) 19:03:57
>>851

ありがとうございます!
試してみます

853 :名無しさん@お腹いっぱい。:2006/05/31(水) 23:16:24
stl の string って MTsafe じゃないの?
g++ aaa.cpp -I /usr/pkg/include/stlport -L /usr/pkg/lib/ -lstlport_gcc
-D_PTHREADS -D__STL_PTHREADS -D_THREAD_SAFE -D_REENTRANT -g

using namespace std;

list<string> l;
pthread_mutex_t mut;

void *
do_add(void * arg) {
printf("thread arg = %s\n", (char*)arg);
pthread_mutex_init(&mut, NULL);
string aaa = "aaa";
int count_clear = 0;
while (1) {
int ret = rand() % 2;

pthread_mutex_lock(&mut);
if (ret) {
l.clear();
count_clear++;
}
l.push_back(aaa);
pthread_mutex_unlock(&mut);
printf("count_clear=%d\n", count_clear);
}
return NULL;
}

854 :名無しさん@お腹いっぱい。:2006/05/31(水) 23:18:12
つづき

int
main ()
{
pthread_t thread;

pthread_create(&thread, NULL, do_add, (void *)"t1");

while (1) {
if (!l.empty()) {
for (list<string>::iterator it = l.begin();
it != l.end();
it++) {
// printf("l->c_str() = %s\n", it->c_str());
assert(strcmp(it->c_str(), "aaa") == 0);
}
}
}
return 0;
}


855 :名無しさん@お腹いっぱい。:2006/06/01(木) 01:53:54
>>853
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_6

856 :名無しさん@お腹いっぱい。:2006/06/01(木) 01:57:46
>>853
ん? stlport ?
http://stlport.sourceforge.net/Related.shtml

857 :名無しさん@お腹いっぱい。:2006/06/01(木) 06:44:57
そのプログラムって、aaaをいじってないから、
stringがMTsafeかどうか関係ない気がするんだけど、見落としてる?

858 :名無しさん@お腹いっぱい。:2006/06/01(木) 06:56:03
containerがMT-Safeかどうかと、
containerをいじった時に、既存のiteratorが有効なままかという概念は別。

859 :名無しさん@お腹いっぱい。:2006/06/01(木) 08:48:23
どういう結果を期待してるのか書いてないけど、
aaaじゃなくてbbbと印字されるんだったらstringが(MT)Safeではないことになるかな。


860 :名無しさん@お腹いっぱい。:2006/06/01(木) 11:25:47
>>854
main() も l にアクセスするのにどうしてmain内では排他制御してないの?


861 :名無しさん@お腹いっぱい。:2006/06/01(木) 13:21:51
>>853
mutは何を保護するためのmutexですか。


862 :名無しさん@お腹いっぱい。:2006/06/01(木) 16:54:49
Goolge Summer of Code 2006で、
lock free C++ containerやるみたいね。

863 :名無しさん@お腹いっぱい。:2006/06/02(金) 23:34:46
ああ、ありがとみなさん
かいたあと、あれ、 iterator をいじってる最中に、
it がさしている先ってかわる可能性あるなと。。。
>> 857 さんの意見がそのとおりで
かきなおしました。

で、main で l をさわっているのに、Mutex してなかった理由は、ここらへんよんでいて
The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and simultaneous
read accesses to to shared containers are safe. If multiple threads access a
single container, and at least one thread may potentially write, then the
user is responsible for ensuring mutual exclusion between the threads
during the container accesses.

でなにをとちくるって読んでいたのか。。というと
read はあれか、共有していても、だいじょぶなのか?とか英語をまったく
よんでない状態でした。。。

2 行目をみればわかるとおり、access してる最中は、user は、
mutual exclusion をやらなきゃならんとかいてあったりしますです。。。
スレよごしてごめんなさいです。



864 :名無しさん@お腹いっぱい。:2006/06/02(金) 23:36:29
で、かきなおしました
int
main ()
{
pthread_t thread;

pthread_mutex_init(&mut, NULL);
pthread_create(&thread, NULL, do_add, (void *)"t1");

while (1) {
pthread_mutex_lock(&mut);
if (!l.empty()) {
for (list<string>::iterator it = l.begin();
it != l.end();
it++) {
// printf("l->c_str() = %s\n", it->c_str());
assert(strcmp(it->c_str(), "aaa") == 0);
}
}
pthread_mutex_unlock(&mut);
}

return 0;
}

これで、20 時間くらいまわしても大丈夫でした。
ありがうございました。


865 :名無しさん@お腹いっぱい。:2006/06/02(金) 23:37:34
ああ、>> 858 さんだおゆるしを。。。

866 :858:2006/06/02(金) 23:49:42
なんかおかしいと思ったw

867 :名無しさん@お腹いっぱい。:2006/06/04(日) 17:14:18
Linux で複数のスレッドから共通に呼ばれることを目的とした自前の syslog 関数 (mysyslog) を作って、
その始まりと終わりで mutex の lock/unlock をやっているのですが、負荷が小さいときは問題が
ないのですが、負荷をかけてゆくとなぜか segmentation fault してしまいます。

$ uname -a
Linux hoge 2.4.31-0vl1.12smp #1 SMP Mon Dec 26 22:01:47 JST 2005 i686 unknown
$ rpm -q glibc
glibc-2.3.3-3vl1.3

コアダンプは以下の通りです。

Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x400258b0 in sem_timedwait () from /lib/i686/libpthread.so.0
(gdb) bt
#0  0x400258b0 in sem_timedwait () from /lib/i686/libpthread.so.0
#1  0x400225cc in pthread_mutex_unlock () from /lib/i686/libpthread.so.0
#2  0x08054e50 in mysyslog (priority=7, msgformat=0x805c5c0 "send_proc() unlocking mutex_sleep")
    at syslog.c:117


868 :名無しさん@お腹いっぱい。:2006/06/04(日) 17:21:27
ソース貼れば、的確なレスがつくぞ

869 :867 続き:2006/06/04(日) 17:21:55
自前の syslog 関数です。一部省略してます。 syslogfp は別途 myopenlog で開いた状態で呼ばれています。
char hostnmame[MAX];
pthread_mutex_t mutex_log = PTHREAD_MUTEX_INITILIZER;
void mysyslog(int priority, const char *msgformat, ... )
{
 va_list args;
 char format[MAX], newname[MAX];
 time_t tsec;
 struct tm t;
 struct stat stat_buf;
 const char *mon[]={"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"};
 if(syslogfp == NULL)
    return;
 /* get time of this call */
 tsec=time(NULL);
 gmtime_r(&tsec,&t);
 /* filename */
 pthread_mutex_lock(&mutex_log);
 if (priority <= cf.loglevel){
    va_start(args, msgformat);
    sprintf(format,"%s %d %02d:%02d:%02d %s %s[%d]: %s\n",
        mon[t.tm_mon], t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec,  hostname, logident,  (int)getpid(), msgformat);
    if(priority <= LOG_INFO){
      vfprintf(syslogfp, format, args);
      fflush(syslogfp);
    }
  }
  pthread_mutex_unlock(&mutex_log);   <----  ここで seg. fault
  return;
}


870 :869 の続き:2006/06/04(日) 17:27:14
ちなみに呼び出し側 send_proc() の該当箇所は

  pthread_mutex_lock(&mutex_sleep);
  sleep_mode = 1;
  mysyslog(LOG_DEBUG, "send_proc() unlocking mutex_sleep");  <--- 呼び出し行
  pthread_mutex_unlock(&mutex_sleep);

こんな感じです。mutex のデバッグのために呼び出したログ関数で問題が起こっています。
何か助言頂けると幸いです。


871 :867:2006/06/04(日) 17:49:13
ちなみに、seg. fault は違う場所でも発生して、ホスト名解決のためにライブラリ関数を

    if ( gethostbyname_r(hostname, &host,buf, sizeof(buf), &result, &h_errnop) != 0 ){

のように呼んだ場所でも、mutex 周辺が原因のような segmentation fault を起こします。
引数は全て実体が正常に確保されています。以下、そのときのコア

Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x400259a3 in sem_timedwait () from /lib/i686/libpthread.so.0
(gdb) bt
#0  0x400259a3 in sem_timedwait () from /lib/i686/libpthread.so.0
#1  0x400225cc in pthread_mutex_unlock () from /lib/i686/libpthread.so.0
#2  0x431aeb0c in _nss_files_gethostbyname_r () from /lib/libnss_files.so.2
#3  0x4015e45b in gethostbyname_r () from /lib/i686/libc.so.6


872 :867:2006/06/04(日) 17:53:35
たびたびすいません。

>>869
pthread_mutex_t mutex_log = PTHREAD_MUTEX_INITILIZER;


pthread_mutex_t mutex_log = PTHREAD_MUTEX_INITIALIZER;

の転記ミスでした。


873 :名無しさん@お腹いっぱい。:2006/06/04(日) 18:27:17
va_end()が抜けて無いか?
原因は、負荷を与えた時にスタックが枯渇して落ちてるんじゃないかな?
恐らくgethostbyname_r()も(タイミングが悪いと)その影響で落ちてるのだと思う。


↓こうしたらどうか?

 if (priority <= cf.loglevel){
    va_start(args, msgformat);
    sprintf(format,"%s %d %02d:%02d:%02d %s %s[%d]: %s\n",
        mon[t.tm_mon], t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec, hostname, logident, (int)getpid(), msgformat);
    if(priority <= LOG_INFO){
      vfprintf(syslogfp, format, args);
      fflush(syslogfp);
    }
    va_end(args);    <ーこれが抜けてる
  }

874 :873:2006/06/04(日) 19:01:27
ん??
それ以前に可変個引数の使用方法がおかしいぞ。

875 :867:2006/06/05(月) 10:22:43
>>873-874

指摘ありがとうございます!

sem_timedwait とかに気をとられて glibc のソース解読とかを始めそうになってましたが
普通の処理でコードが間違ってそうですね・・

なんだか pthread そのものの問題じゃなさそうですが、解決したらまた報告します!


876 :名無しさん@お腹いっぱい。:2006/06/05(月) 20:45:08
>867
MAXが足りてないオチ。
だから、n付き関数呼べとあれほど(ry

877 :867:2006/06/06(火) 23:07:34
867 です。解決報告をしたいところだったんですが、指摘して頂いた点に留意してコードを以下のように変えても依然同じ場所 (sem_timedwait) で seg. fault します。
backtrace で変数の中身をを見ても、ここでは MAX があふれてるとかの問題は起きていません。あと、ulimit も全て unlimited にしてみましたが、状況は変わっていません。

void mysyslog(int priority, const char *format, ... )
{
 va_list ap;
 char msg[MAX],  buf[MAX];
 time_t tsec;
 struct tm t;
 const char *mon[]={"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"};

 if(syslogfp == NULL)  return;

 tsec=time(NULL);
 gmtime_r(&tsec,&t);

 pthread_mutex_lock(&mutex_log);
 va_start(ap, format);
 vsnprintf(buf, MAX, format, ap);
 va_end(ap);
 snprintf(msg, MAX, "%s %d %02d:%02d:%02d %s %s[%d]: %s\n",
  mon[t.tm_mon], t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec,
  hostname, logident,  (int)getpid(), buf);
 if(priority <= LOG_INFO){
  fprintf(syslogfp, "%s", msg);
  fflush(syslogfp);
 }
 pthread_mutex_unlock(&mutex_log);

 return;
}


878 :873:2006/06/07(水) 02:38:36
Valgrind を使ってみたらどうだろうか。

参考サイト
http://221.112.61.214/~kzk/column/valgrind-tools.html
http://valgrind.org/

879 :867:2006/06/07(水) 02:51:41
>>878

ありがとうございます!
色々ツールの必要性を感じてたとこなのでこの手の情報はとても助かります!


880 :名無しさん@お腹いっぱい。:2006/06/07(水) 13:59:01
>>873 >>876

867 です。

全てのコードをお見せできるわけじゃないので表現しづらいのですが、
valgrind を使ったところ、コード貼ったのとは違う場所のソケット通信の部分で
points to uninitialized buffer と出てきたので、送信バッファを隈なく
初期化するようにしたら症状が治まりました。裏で何が起きてるのか
まだ把握してませんが、スタックが侵食されてたのかもしれません。

結局のところ pthread とは全く関係ない部分の問題でスレ汚ししてしまいましたが、
おかげ様で解決しました!ほんとう、助かりました!

881 :名無しさん@お腹いっぱい。:2006/06/07(水) 14:49:42
たまたま症状が出にくくなっただけで、問題が解決されたわけではない気がするのは、気のせいだろうか。

882 :873:2006/06/07(水) 15:03:17
>>880
それはよかった。

けど、
>裏で何が起きてるのかまだ把握してませんが、スタックが侵食されてたのかもしれません。
今後の為にも、ちゃんと把握しておいた方がいいぞw

883 :名無しさん@お腹いっぱい。:2006/06/07(水) 15:21:47
その送信バッファの近所でオーバーランしてる予感

884 :867:2006/06/07(水) 16:13:04
>>881 >>882 >>883

あう、その通りですね。
valgrind 強力なんで虫つぶしに励みます。


885 :名無しさん@お腹いっぱい。:2006/06/14(水) 02:18:36
Linux 以外にしたら解決したりして。

886 :名無しさん@お腹いっぱい。:2006/07/05(水) 23:35:15
>>519
http://lists.freebsd.org/pipermail/freebsd-threads/2006-July/003562.html

887 :名無しさん@お腹いっぱい。:2006/07/07(金) 09:03:55
>>886
流し読みした限りをめちゃくちゃ乱暴に要約かつ意訳すると、

rwatoson: libpthreadにあってlibthrにない機能はもうないし、現実のアプリ
ケーションはlinuxのスレッドモデルをみんな基本にしてるし、でのベンチ
マークも上だから変更しようよ。

deischen: libpthreadにあってlibthrにない機能を追加してくれたらね。1:1モ
デルじゃ難しいだろーけど。

jb: libpthreadのその機能とかはi386以外のアーキテクチャで動いてんのかよ。

deischen: 知らない。POSIX標準に適合させたいだけだよ。他のアーキテクチャ
でのlibpthread向けの作業は誰かやって。

davidxu(libthrの作者): (最初のrwatosonメールに)賛成。デフォルトにしよう。

jb: (deischenに対して)ほとんどのlinux開発者(アプリを含むと思われる)は
たぶん、POSIXが何なのかすら知らねーよ。

devidxu: (deischenの最初のメールに対して)あんたの言うようにsystem scope
threadをlibpthreadに追加すべきじゃないと思うし(kernelの修正とかしなきゃ
現実的じゃない)、そんな機能は削除、削除。
それに、そんな方法だと現実の世界のほとんどのアプリケーション性能を改善
するためにhard realtimeが必要にだね。hard realtimeが必要ならなんで
FreeBSDを使ってんの?
あとさ、最近のCPUフレンドリーなスケジューラをユーザランド上に導入するの
って簡単じゃないと思うし。
(1:1モデルじゃ難しいと言われたことに対して)不可能じゃないし、少しずつや
ってるよ。

888 :名無しさん@お腹いっぱい。:2006/07/07(金) 09:06:57
deischen: (devidxuに対する返信)(system scope threadに関して)system
scopeじゃないよ。
(ユーザランド上のスケジューラについて)KSEが良き計らってくれるから
影響ないね。

以下 devidxuとdeischenの既に対応してるとか、hardworkだとか、その機能
はどこの担当だとかが続く中で、rwatsonのaceept, i/o, i/o, i/o, ..., close
とか、kip.macy(sun4vのport作業担当)がKSEの移植でグチったり、 Sunのエ
ンジニアがscheduler activationsやめたのは重要なアプリケーションはみん
なlinux方式を仮定してるからだけど、誰かFreeBSD方式ととlinux方式のちゃ
んとした比較教えてとかいったり、julianのKSE講座があったり、peterが
bike_schedという名前はこのスレッドのことじゃないよとかいいながら
perforceでやってるスケジューラ周りのpatchを提出してるってことでOK?

そのうちMLで結論でたら誰か報告おねがい。
俺の結論としては世の中みんなLinuxに振り回されっぱなし。
いまさらながらPOSIXの存在価値っていったい……。

889 :名無しさん@お腹いっぱい。:2006/07/07(金) 09:39:45
Linux vs POSIXじゃなくて、1:1 vs M:Nでしょ?

> 現実のアプリケーションはlinuxのスレッドモデルをみんな基本にしてるし

こういう発言が誤解を招くのだろうが。

しかもdefaultを1:1にしようって話で、
M:Nは金輪際辞めろっていうわけでもないし。

上手く両方共存していって欲しいが、人的リソースがきついかな。

890 :名無しさん@お腹いっぱい。:2006/07/07(金) 10:29:43
すまん、誤解させたようだ。結論と書いてある部分は無視してくれ。
その部分は、単になんでもLinuxが採用したものが標準なっていくっ
てグチろうとした部分の削除し忘れだ。

それとも、その部分以外でLinux vs FreeBSDに読めた?
徹夜明けで頭はたらいていないんで、そーなら、なおさらごめん。

891 :名無しさん@お腹いっぱい。:2006/07/19(水) 16:44:29
すいません。プログラム板の「マルチスレッドプログラミング相談室」から引っ越して来ました。
質問内容とこれまでの議論はこちらを見てください。
http://pc8.2ch.net/test/read.cgi/tech/1130984585/627-659
Linux での pthread と accept() の動作についてなんですが、分かる人居ますか?
(このスレの上の方で近いことが既に議論されていたようですが)

一応一つのスレッドでだけ accept() をして続きの処理は待機させておいた
スレッドにやらせるという方法で回避できたので現在は困ってはいません。
現在は何故そうなるのかという疑問だけが残った状態です。


892 :名無しさん@お腹いっぱい。:2006/07/19(水) 17:13:48
> 現在は何故そうなるのかという疑問だけが残った状態です。

Linux板の方がいいんじゃないの?



893 :名無しさん@お腹いっぱい。:2006/07/19(水) 17:37:10
>>892
それってpthreadは無関係ってこと?

894 :891:2006/07/19(水) 17:53:50
>>892
そうですかね。
Linux と pthread とネットワーク全てに絡む話なので、何ともいえない
ところなんですが。(やっぱり Linux の pthread 実装がクソだったという
結論になる可能性もないわけではないですが…)。

ところで Linux ではなく UNIX (Solaris) とかは複数スレッドからの
accept() は問題無く動くんでしょうか?
(なんとなく動きそうな気はしますが)


895 :名無しさん@お腹いっぱい。:2006/07/19(水) 19:12:54
>>891
現実逃避をかねて実験してみた. FreeBSD でやると別の fd 返してくる.
手元に Linux ないんで, 動作の比較はできなかったけど...
スレッド起こす側は下みたいな感じでいいんだろ?

main(...)
{
...
k = socket(PF_INET, SOCK_STREAM, 0);
// bind/listen する
// ioctl なり fcntl なりで nonblock にする

pthread_create(&t0, 0, thr, (void *)k);
pthread_create(&t1, 0, thr, (void *)k);
}



896 :891:2006/07/19(水) 19:59:00
>>895
そうです。そんな感じです。

そうですか。やはりうまく行きますか。
(やっぱLinux板行った方がいいかな・・・)


897 :名無しさん@お腹いっぱい。:2006/07/19(水) 20:10:39
原因がLinuxのバグだとしても、作りは相当変だよ。
だいたいnon-blockingにして闇雲にポーリングするなんてどうなのよ。
1個のスレッドでイベントのあるときだけaccept()するだろ普通。

898 :名無しさん@お腹いっぱい。:2006/07/19(水) 22:40:49
NPTLなのか?

899 :名無しさん@お腹いっぱい。:2006/07/19(水) 22:42:25
linux-2.6.17のコード見てみたけど、fdの割り当てはfd table共有してる限り、
同一のspin_lockで排他してるからだぶることなさそうなんだがなぁ。
accept()で返されてくる、第2引数のsockaddr_in(かな?)の内容まで一緒なのか
知りたいかも。

つーか、スレッド使うならソケットをnonblocking modeにしなくていいと思うんだけど、
blocking mode使わない理由があるのかな。


900 :891:2006/07/19(水) 22:58:10
すいません。単純化したプログラムを1から作りなおして Fedora Core 5
(Kernel 2.6.17-1.2145_FC5, gcc 4.1.1) でやってみたらちゃんと違うファイル
ディスクリプタを返して来ました。

ということで、これは単純に私のプログラムのバグの可能性も出てきました。
申し訳ありませんが明日プログラムを確認してみます。(今手元になくて確認
できないため)。

おさがわせしました。ということでまた明日。

>>899
Nonblocking にした理由は元のプログラムがシグナルを別スレッドで受けていて、
それによってフラグを変更してループを抜けるということをしていたので停止
させたくなかったということです。そういうのがなければ block しても同じですね。


901 :名無しさん@お腹いっぱい。:2006/07/20(木) 03:08:57
>>900
プログラム板の方にもフィードバックお願いします。

902 :891:2006/07/20(木) 16:01:45
申し訳ありません。私がバグっておりました。

accept() 後の処理を別関数でやっていたのですが、その中で
fdopen() を使って accept() で受け取ったファイルディスク
リプタから FILE * を作って fgets() や fprintf() を使って
いました。それでその関数から返る直前に fclose() をして
いますが、そうすると当然元となったソケットも close()
されます。

このことをすっかり忘れていたためこの別関数から戻って
来ても accept() で取ったファイルディスクリプタは
オープンしたままだと思い込み、別関数から帰って来てから
close() までの間に別スレッドで accept() した時の
ファイルディスクリプタと同じ値になることがあったため、
今回の疑問に繋がっていました。

ということでお騒がせしました。
Linux でも複数スレッドからの accept() は問題無くできます。


903 :891:2006/07/20(木) 16:02:16
>>901
書いておきます。


904 :    :2006/07/21(金) 21:15:16
またまたご冗談を(AA略

905 :名無しさん@お腹いっぱい。:2006/08/11(金) 02:26:30
>>902
亀レスな上に蛇足かもしれないけど、環境によって同時Acceptは挙動が
違うらしいから排他したほうがいいと何かで呼んだ。

906 :名無しさん@お腹いっぱい。:2006/08/15(火) 19:11:59
http://www.amazon.co.jp/gp/product/4900900664/ref=sr_11_1/250-8960565-6788252?ie=UTF8

pthreadsの入門書として、これはどうでしょうか?
オライリーだから難しすぎたり、訳が悪かったりしますかね?

907 :名無しさん@お腹いっぱい。:2006/08/16(水) 01:24:51
悪くないけどちょっと古い。

908 :名無しさん@お腹いっぱい。:2006/08/16(水) 10:31:03
別に古くはないけど、
銀行ATMの例に沿って進む例題形式だから、
それだけじゃ細かいことまでは分からないね。
それを通読した後、

David R. Butenhof "Programming With Posix Threads" (翻訳が出てるが酷いらしい)
スティーブ・クライマン「実践マルチスレッドプログラミング」
ビル・ルイス「Pスレッドプログラミング」
ダグ・リー「Javaスレッドプログラミング−並列オブジェクト指向プログラミングの設計原理」

辺りを読めば?

Java関係ないじゃんと思うかもしれないが、
この本が優れていることは読めば分かる。
pthreadでしかプログラミングしなくても、
設計面の話なので大いに参考になる。

909 :名無しさん@お腹いっぱい。:2006/08/16(水) 10:37:17
>>907
>>908
レスありがとうございます。
何も知らないのでとりあえず読んでみます。

910 :名無しさん@お腹いっぱい。:2006/08/16(水) 12:51:29
W.Richard Stevensの
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
http://www.amazon.co.jp/gp/product/4894712059

は高いけど買って損はないと思う。

911 :名無しさん@お腹いっぱい。:2006/08/16(水) 13:22:22
>>910
それは立ち読みして自分にはまだ難しかったので買ってないです


912 :名無しさん@お腹いっぱい。:2006/08/16(水) 16:23:57
>>910
キューや共有メモリなどのプロセス間通信の勉強に<Vol.2>は良いですか?

913 :名無しさん@お腹いっぱい。:2006/08/16(水) 16:32:04
>>908
スティーブ・クライマン「実践マルチスレッドプログラミング」
これは入門者の一冊目として適してますか?

ビル・ルイス「Pスレッドプログラミング」
は廃刊でした。

914 :名無しさん@お腹いっぱい。:2006/08/27(日) 14:20:14
>>908に挙げたのは、
「通読した後」と書いたように入門用じゃないよ。
入門は>>906でいいんじゃない?

けど読めると思えば、一冊目に、
> スティーブ・クライマン「実践マルチスレッドプログラミング」
でいいと思うけど、pthreadの細かい仕様は、マニュアルを読むことになる。
これは急所どころだけ書いてある。他のスレッドと比べたりして。

915 :名無しさん@お腹いっぱい。:2006/08/27(日) 14:25:40
とりあえず>>906が分かりやすそうだったので買いました。
これでできるところまで覚えてからクライマンのを読んで見ます。

916 :名無しさん@お腹いっぱい。:2006/08/29(火) 22:40:43
>>911
や、例にあがっているコードをほぼそのまま使っても動く
ものができてしまう上に、OSの違いによる挙動の違いや、コード
そのものの解説が付いているから、難しいというよりは身体で覚える
タイプの本だ、と個人的には思っている。

>>912
Vol.2は残念ながらあまり見ていない。必要な人には良いとは思うが。


917 :名無しさん@お腹いっぱい。:2006/09/07(木) 13:25:27
マルチスレッドのプロセスでforkするのって色々難しいですわあ

918 :名無しさん@お腹いっぱい。:2006/09/07(木) 21:19:34
するな、が正解。fork&execならともかく。

919 :名無しさん@お腹いっぱい。:2006/09/08(金) 08:22:13
スレッドを作ってからfork&execするのがやっかいなんだあ

920 :名無しさん@お腹いっぱい。:2006/09/08(金) 17:46:35
プチfork爆弾期待age

921 :名無しさん@お腹いっぱい。:2006/09/10(日) 18:58:51
質問です。

プロセス内のスレッドはグローバル変数を共有してますが、pthread_createの
最後の引数で渡した変数しかスレッドのルーチンでは読み書きできないんですか?
それとも引数で渡さなくてもグローバル変数はアクセスできるのでしょうか?

922 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:09:47
自己解決しました。引数で渡さなくてもアクセスできました。
なぜ、ポインタ引数を一つ渡せるような仕様になってるのでしょうか?
必要ないと思うのですが。

923 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:22:18
スレッドが複数あったら?

924 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:26:23
>>923
複数あってもすべてのスレッドからグローバル変数はアクセスできるので、
わざわざ引数を設ける必要が無いような気がします。。
知識たらなくてすみません。

925 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:39:19
( ゚д゚)ポカーン

926 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:48:47
>>924
知ってる人なら、「スレッドとは」と小一時間話したいけど、
知らない人だと、どんな知識をどれだけ持ってるか分からないから、困る。

927 :名無しさん@お腹いっぱい。:2006/09/10(日) 19:51:49
>>926
ご教示お願いします、ぜひとも。
入門書は読みました。

928 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:08:43
>>927
お前の氏素性がわからなきゃ無理って書いてるのに
教えてくれって言うのは、変じゃねーの。

住所氏名性別、学歴、職歴、毎日考えてる事、全部晒してくれたら
ニヤニヤする。

929 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:10:43
>>928
いやいや、会社で聞くんでいいです。

930 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:11:43
2ちゃんはカスの集まりなんで、まともに解説できる奴あいねーよ


931 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:12:38
といえば教えてもらえると思ってもムダです

932 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:16:02
>>922
深遠な理由があるわけではない。
あった方がグローバル変数だの条件変数だのを使わなくて済む場合が多いから。
でも、こう書くと次は>>800をやらかすだろうから、
とりあえずmallocしたポインタを渡すクセを付けておけ。

933 :名無しさん@お腹いっぱい。:2006/09/10(日) 20:43:23
>>932
ご教示ありがとうございます。
いろいろ考えられてそうなってるわけですね。

934 :名無しさん@お腹いっぱい。:2006/09/10(日) 21:42:33
>>922
オブジェクト指向言語(たとえばJava)でスレッドを扱う場合は
大体こんな感じになる。

public class Work implements Runnable {
private String name;
public Work(String name) {
this.name = name;
}
public void run() {
System.out.println("My name is " + name + ".");
}
public static void main(String[] args) {
Work work1 = new Work("Tom");
Work work2 = new Work("Mark");

new Thread(work1).start();
new Thread(work2).start();
}
}

このように、スレッドのエントリポイント(runメソッド)は同じでも、
処理を行うインスタンスが異なっている(work1とwork2)ために、
それぞれのスレッドが別々の処理を行うことができる。

で、pthread APIでも同様に、スレッドのエントリポイント(pthread_createの第3引数)
のほかに、スレッド処理の主体となるデータ(すなわちOOで言う「オブジェクト」)への
参照を渡せるようにしている(pthread_createの第4引数)というわけだ。

コールバック系のAPIをはじめとして、こういう任意のポインタを渡せるようように
なっているAPIは多いが、これらも処理の主体となるデータの受渡しに用いられ、
"opaque pointer"などと呼ばれる。

935 :名無しさん@お腹いっぱい。:2006/09/11(月) 08:27:09
>>934
なるほど。あえてopaqueなポインタになってるけれども、C++などでは
オブジェクトの参照渡しなど重要になってくるんですね。
ありがとうございました。

936 :名無しさん@お腹いっぱい。:2006/09/11(月) 11:35:18
・・・

937 :名無しさん@お腹いっぱい。:2006/09/11(月) 11:59:24
・−・

938 :名無しさん@お腹いっぱい。:2006/09/11(月) 22:32:32
いやいや、グローバル変数で頑張ろうよ

939 :名無しさん@お腹いっぱい。:2006/09/12(火) 00:41:08
>>935 は会社で先輩に教えてもらう時に、
途中で生悟りしないでちゃんと不明点が無くなるまで
聞けよ? でないと、迷惑掛けるぞ

940 :名無しさん@お腹いっぱい。:2006/09/12(火) 10:55:30
量産型バグ 対 シャア専用バグ

941 :名無しさん@お腹いっぱい。:2006/09/13(水) 07:29:38
グローバル変数でも、読むだけなら良いじゃん。

942 :名無しさん@お腹いっぱい。:2006/09/16(土) 17:56:26
volatileつければ排他も要らないしw

943 :名無しさん@お腹いっぱい。:2006/09/16(土) 19:32:54
volatile厨は巣にカエレ!!
http://pc8.2ch.net/test/read.cgi/tech/1157814833/

944 :名無しさん@お腹いっぱい。:2006/09/24(日) 19:23:28
volatileで排他できるわけないしw

945 :初心者 :2006/10/27(金) 22:08:21
スレッドを無限ループにしたままで、mainを終了させたらリソースは解放されないで
残るのですか?その場合detached属性つけてスレッド生成すればよい?


946 :名無しさん@お腹いっぱい。:2006/10/28(土) 00:01:13
>>945
いよいよFreeBSDもm:nスレッドを捨てる日が近付いてきたようだ。
ttp://docs.freebsd.org/cgi/mid.cgi?200610262142.k9QLgNoP035966

947 :946:2006/10/28(土) 00:02:39
# アンカミスった。無視してくれ

948 :混沌:2006/10/28(土) 03:50:29
そろそろ1000レスだな〜〜

949 :名無しさん@お腹いっぱい。:2006/10/28(土) 04:37:11
捨てると決まったわけじゃないよ。

950 :945:2006/10/28(土) 08:06:02
>>945
誰か答えろや ごっつ困ってんねん

951 :名無しさん@お腹いっぱい。:2006/10/28(土) 09:52:43
>>945
プロセスが終了したとき、そのプロセスが所有するリソースは全て
OS側に返される。
この原則はマルチスレッドで動作しているプロセスでも同じ。

952 :名無しさん@お腹いっぱい。:2006/10/29(日) 08:26:55
>>951
ありがたや〜

同期を取る必要の無いスレッド同士だからデタッチにすべきだと思った。
デタッチするとスレッドの戻り値とかをOSが管理しなくていいから少し
は効率よくなるはず?ジョイナブルでも正常にリソースが解放されるのなら、
そもそもデタッチスレッドって何のためにあるの?

953 :名無しさん@お腹いっぱい。:2006/10/29(日) 08:48:48
joinするのも只じゃないってことじゃね?

954 :名無しさん@お腹いっぱい。:2006/10/29(日) 14:05:29
>>952
 デタッチなスレッドを使用する意味・・(私の場合です)

 やっぱり、同期は必要になります!?。例えば親子関係のスレッドで、
 子供)処理を終えると親に通知する。(mutexと条件変数を使って)
 親 )通知を受けるが常時待機はしていない。(別な処理をしている)
 こんな関係だと、もし親がjoinで待ってると別な処理が出来ない。この
 待機時間がロスタイムになる。
 最後に親が死ぬ時は、子供状態を記す管理簿の内容で、
 待機するか、即死ねる判断ができる。

 これを、ある社会生活をモデルにすると・・・
 2時間飲み放題(バイキング)とします。
 店側(親)、客(子)にします。
 客)自由に飲み食いします。(酔っぱらって時間の事忘れるかもしれません)
 店)客の利用時間を監視しつつ、料理の準備や雑用をします。
   そして、2時間経過したら 客に帰れ[pthread_kill(客、強制(9))]を
   通知します。もちろん、2時間以内に帰ってくれる客もいます。
  # 客の意志を尊重しjoinで待ってると、経営が成り立ちません。ってか?



 
 

955 :名無しさん@お腹いっぱい。:2006/10/29(日) 17:14:09
>>953
>>954
大作やなあ

つまり第一にjoinはブロックされるから使用したくない。
でも、親子関係のスレッドで>>954のような処理をする場合でも
あえてデタッチスレッドにしなければならないのだろうか?という疑問が沸いた
ジョイナブルなままでもいい気がするんだけど、。

まあ精進しますわ 

956 :名無しさん@お腹いっぱい。:2006/10/29(日) 20:20:03
>>955
 954です。
 要求に合った動作ができれば、それでいいと思います。
 しかし、コストパフォーマンスを考慮すると
 そうも行かない場合があります。
 
 joinで待つ間、L2キャッシュを占有されてると迷惑な場合も
 あります。待つのもね。
 だから、用途次第だと思います。
  

957 :名無しさん@お腹いっぱい。:2006/10/30(月) 18:32:39
> joinで待つ間、L2キャッシュを占有されてると迷惑
解る人居る?

958 :名無しさん@お腹いっぱい。:2006/10/31(火) 01:01:35
>957
まったく.
意味が掴めない.
詳しくお願いします.

959 :名無しさん@お腹いっぱい。:2006/10/31(火) 01:17:13
>>957-958
そういうときはスルー力を発揮しなきゃ。

960 :名無しさん@お腹いっぱい。:2006/10/31(火) 02:33:35
まさか
joinで待つ=対象スレッドが終了するのをポーリングして監視
だと思ってるんじゃあるまいか

ごめん、スルーできなかった

961 :名無しさん@お腹いっぱい。:2006/10/31(火) 22:43:00
「スルー力」って書き込み自体をしないのが本質だと思います。
何かの記事を真に受けた伝道師みたいに思えます。

>>960
 そのポーリングは無意味で、joinの方がましですよね。

・・・
スレッドに対して、要求する処理が終了して〜スレッド消滅までの時間
正確に測る方法が知りたいんですが、だれか知りませんか?


 




962 :名無しさん@お腹いっぱい。:2006/11/01(水) 00:30:51
> joinで待つ間、L2キャッシュを占有されてると迷惑

の意味を教えてくれ
>>960 じゃないんだよな?

963 :名無しさん@お腹いっぱい。:2006/11/02(木) 23:03:12
>>962
 L2キャッシュ・・・
 CPUを基点に、データ保存の媒体として、L1,L2キャッシュ(CPU内部)、
 メモリ、HDD等とあります。
 データへのアクセス時間が最速なのは、前者から順になります。

 そこで、A=A+1 と足し算したい場合、Aはどこに保存されてると
 早く計算できると思いますか?
 
 
 
 

964 :名無しさん@お腹いっぱい。:2006/11/03(金) 03:20:01
はい、レジスタ!

965 :名無しさん@お腹いっぱい。:2006/11/03(金) 03:54:08
スルーとしけばよかった(>_<)反省

966 :名無しさん@お腹いっぱい。:2006/11/03(金) 06:11:44
で?

967 :名無しさん@お腹いっぱい。:2006/11/03(金) 08:02:55
俺はYahoo!のブリーフケースに保存している。

968 :名無しさん@お腹いっぱい。:2006/11/03(金) 10:05:43
ブリーフへのアクセス時間が最速、それはブリーフケース

969 :名無しさん@お腹いっぱい。:2006/11/03(金) 10:18:37
ブリーフケース、ベリーフケース、ベリーファスト!

なるほど

970 :名無しさん@お腹いっぱい。:2006/11/03(金) 18:03:19
↑笑えるポイントは?

971 :名無しさん@お腹いっぱい。:2006/11/03(金) 20:33:29
三段活用だろ

972 :名無しさん@お腹いっぱい。:2006/11/04(土) 00:10:07
↑解説ありがと。

笑えないけど、笑ってあげよう。


973 :名無しさん@お腹いっぱい。:2006/11/09(木) 15:07:44
>>518>>887>>888
http://lists.freebsd.org/pipermail/freebsd-threads/2006-October/003771.html
読むと対抗意識持ちつつ仲よくやってるみたいね。

974 :名無しさん@お腹いっぱい。:2006/12/12(火) 02:40:09
以下は、sem_wait/sem_post を使って同時に 2 スレッドまでしか
走行できないように排他処理を行うテストコード。
これを linux の gdb(6.4.90 系) で実行すると、なぜか assert に
引っかかってしまいます・・・。
debian etch でダメ。なぜか vine4.0 だと問題なし。

#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#define MAX_THREAD_NUM (2)
#define THREAD_NUM (8)
sem_t sem;
void thread_func(void *arg) {
int id = (int)arg;
int ret = sem_wait(&sem);
assert( ret == 0 );/* gdb だと謎エラー */
printf("%d start.\n", id);
sleep(1);
printf("%d finish.\n", id);
sem_post(&sem);
}
int main() {
int i;
pthread_t handle[THREAD_NUM];
sem_init(&sem, 0, MAX_THREAD_NUM);
for (i = 0; i < THREAD_NUM; ++i){ pthread_create(&handle[i], NULL, (void *)thread_func, (void *)i); }
for (i = 0; i < THREAD_NUM; ++i){ pthread_join(handle[i], NULL); }
sem_destroy(&sem);
return 0;
}


975 :974:2006/12/12(火) 02:55:22
debian etch 、vine4.0 ともに gdb のバージョンは 6.4.90。
ということは libc のバージョンの差が原因なのか・・・。
なんにせよ、gdb 上でセマフォがさっぱり機能しないというのは
つらいです。

976 :名無しさん@お腹いっぱい。:2006/12/12(火) 08:12:05
謎つうかerrnoは見ないの?

977 :名無しさん@お腹いっぱい。:2006/12/12(火) 08:51:37
sem_initの戻り値をまず確認しないと。

978 :名無しさん@お腹いっぱい。:2006/12/12(火) 12:57:25
>>974
これが原因じゃないような気はするけど、念のため、
sleep(1)使うのやめてpoll(NULL, 0, 1000)にしてみたら?

あとは>>976に同意。

979 :名無しさん@お腹いっぱい。:2006/12/12(火) 13:08:45
「あとは」じゃなくて、まずerrno。

980 :名無しさん@お腹いっぱい。:2006/12/12(火) 13:47:09
細かい日本語のつっこみくらいしかできない人乙

981 :974:2006/12/13(水) 01:31:19
sem_init() の戻り値は 0(=正常終了)です。
sem_wait() の戻り値は 4(=EINTR)でした。

回避方法が判明しました。
sem_wait() が EINTR で失敗した場合 while ループで
リトライする仕掛けにすると良いようです。


982 :名無しさん@お腹いっぱい。:2006/12/13(水) 03:35:57
Wait中になにかSignal来てんだろ。つか普通するだろEINTR対策

983 :名無しさん@お腹いっぱい。:2006/12/13(水) 09:18:19
SIGTRAPとか

984 :名無しさん@お腹いっぱい。:2006/12/14(木) 01:09:44
>>980
エラー処理もせずに、>>978の前半のような試行錯誤を繰り返すのは愚の骨頂。

985 :名無しさん@お腹いっぱい。:2006/12/14(木) 04:48:49
write()でエラー確認せず文句言うヒトもいます

986 :名無しさん@お腹いっぱい。:2006/12/14(木) 07:07:49
全てのsystemcallにEINTRチェックを入れるのはしんどい。

987 :名無しさん@お腹いっぱい。:2006/12/14(木) 14:40:33
>>980
>>984
あれって単なるサンプルコードじゃないの?どうでもいいけど。
サンプルコードに必死になるのはばかばかしいと思って。

988 :名無しさん@お腹いっぱい。:2006/12/17(日) 17:04:02
writeしながらwriteしたいんですけど、誰がwriteですか?

989 :名無しさん@お腹いっぱい。:2006/12/20(水) 09:55:38
埋め

990 :名無しさん@お腹いっぱい。:2006/12/20(水) 10:35:04
お尻がウンコ臭い

991 :名無しさん@お腹いっぱい。:2006/12/20(水) 11:40:41
次スレは立てますか?

992 :名無しさん@お腹いっぱい。:2006/12/20(水) 11:57:49
いらないよ。
やるならここで。

マルチスレッドプログラミング相談室 その5
http://pc8.2ch.net/test/read.cgi/tech/1157814833/

993 :名無しさん@お腹いっぱい。:2006/12/20(水) 12:42:32
埋めないと立てますよ

994 :名無しさん@お腹いっぱい。:2006/12/20(水) 13:25:49
UNIX板に一つくらいpthreadのスレがあってもいいんじゃないかしらん?
無理に他に集約する必要もないでしょう。

995 :名無しさん@お腹いっぱい。:2006/12/20(水) 13:47:18
無理に分散する必要もないよ。

996 :名無しさん@お腹いっぱい。:2006/12/20(水) 13:58:08
分散は嫌だ

997 :名無しさん@お腹いっぱい。:2006/12/20(水) 22:17:15
次スレ
http://pc8.2ch.net/test/read.cgi/unix/1166620307/


998 :名無しさん@お腹いっぱい。:2006/12/21(木) 15:23:19


999 :名無しさん@お腹いっぱい。:2006/12/21(木) 17:59:53


1000 :名無しさん@お腹いっぱい。:2006/12/21(木) 18:00:37
遂に念願の1000GET

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)