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

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

pthread地獄

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

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
値段の話かい?

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

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

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