Linuxでマルチスレッド
1 ：名無しさん＠お腹いっぱい。：
を使って書いてる人いらっしゃいますか。
Linuxだとマルチプロセスのプログラムが多くてスレッドを使っている
例はあまり無いようですが、何か不都合があるのでしょうか。
マルチプロセスで性能が出ないならマルチスレッドにすれば良いか
と考えるところですが、使っている人があまりいないようなので
使って良いのか不安です。
ちなみに、当方Linuxには詳しくありません。
識者の方、よろしくお願いします。
Linuxだとマルチプロセスのプログラムが多くてスレッドを使っている
例はあまり無いようですが、何か不都合があるのでしょうか。
マルチプロセスで性能が出ないならマルチスレッドにすれば良いか
と考えるところですが、使っている人があまりいないようなので
使って良いのか不安です。
ちなみに、当方Linuxには詳しくありません。
識者の方、よろしくお願いします。
|
|
|
2 ：名無しさん＠お腹いっぱい。：2000/12/03(日) 22:11
ライブラリやら関数やらが，「本当にスレッドセーフなの？」って
のがわからん場合が多い(Solaris の man には載ってたりするんだ
が)。いちいちソースを見て確認するのは面倒ですな。
のがわからん場合が多い(Solaris の man には載ってたりするんだ
が)。いちいちソースを見て確認するのは面倒ですな。
3 ：1：2000/12/03(日) 22:35
ソースまで見ないと分からないのでは非常に不便です。
マルチスレッド用のライブラリを明示的にリンク指定すれば全て
解決、といった具合に行くかと思っていました。
Linuxではこのあたりが改善される見込みはないのでしょうか。
マルチスレッド用のライブラリを明示的にリンク指定すれば全て
解決、といった具合に行くかと思っていました。
Linuxではこのあたりが改善される見込みはないのでしょうか。
4 ：名無しさん＠お腹いっぱい。：2000/12/03(日) 22:48
FreeBSDだけどlibc_rはスレッドセーフなんではなかろうか。
5 ：4：2000/12/03(日) 22:50
それと、マニュアルにスレッドセーフと書かれていない場合は
スレッドセーフでない。と考えておくべきかも。
スレッドセーフでない。と考えておくべきかも。
6 ：名無しさん＠お腹いっぱい。：2000/12/03(日) 23:05
UNIXにスレッドが入ったのは「最近」で、まだまだ改善途上にあるから、
不便なのは仕方ない。
ついでに言うと
> マルチプロセスで性能が出ないならマルチスレッドにすれば良いか
この程度の考えならやめとけ。UNIXのマルチプロセスは、
Windowsのマルチプロセスよりはよっぽど効率良く動く。
マルチスレッド化の前に、アルゴリズムの改善とか、やることはいっぱいある。
全部検討してそれでもマルチスレッド化がベストだと思ったなら、
「pthreads programming」でも読んどけ。
http://www.amazon.co.jp/exec/obidos/ASIN/4894710978/
不便なのは仕方ない。
ついでに言うと
> マルチプロセスで性能が出ないならマルチスレッドにすれば良いか
この程度の考えならやめとけ。UNIXのマルチプロセスは、
Windowsのマルチプロセスよりはよっぽど効率良く動く。
マルチスレッド化の前に、アルゴリズムの改善とか、やることはいっぱいある。
全部検討してそれでもマルチスレッド化がベストだと思ったなら、
「pthreads programming」でも読んどけ。
http://www.amazon.co.jp/exec/obidos/ASIN/4894710978/
7 ：1：2000/12/03(日) 23:38
> 6
ありがとうございます。さっそく注文しました。
たしかに、Windowsはマルチプロセス処理が遅いのでスレッド
にするしかない、という面があります。
ありがとうございます。さっそく注文しました。
たしかに、Windowsはマルチプロセス処理が遅いのでスレッド
にするしかない、という面があります。
8 ：名無しさん＠お腹いっぱい。：2000/12/03(日) 23:39
つーか、むやみやたらにマルチスレッド化したって変わらんよ。
ボトルネックがどこなのかちゃんと分析しな。
ボトルネックがどこなのかちゃんと分析しな。
> 4
Linuxもそのような仕様だとありがたいです。Windowsがそうなので。
> 8
留意します。
Linuxもそのような仕様だとありがたいです。Windowsがそうなので。
> 8
留意します。
10 ：名無しさん＠お腹いっぱい。：2000/12/03(日) 23:50
glibcはスレッドセーフなはずだよ。
>pthread
オイラはここを参考にしたよ。
http://centaurus.cs.umass.edu/~wagner/threads_html/tutorial.html
あと、確かスレッドって生成するとプロセスの優先度が下がったよね？
だからidleがほとんど無いようなマシンで実行してもそう速くならんかも。
>pthread
オイラはここを参考にしたよ。
http://centaurus.cs.umass.edu/~wagner/threads_html/tutorial.html
あと、確かスレッドって生成するとプロセスの優先度が下がったよね？
だからidleがほとんど無いようなマシンで実行してもそう速くならんかも。
> 10
参考にさせていただきます。glibcについては確認します。
先々CPU個数を増やして競争力を維持しようとする可能性があります
ので、その時には効いてくるかもしれません。今のところはおっしゃ
る通りです。Linux自身、現段階では複数のCPUを使い切れなさそうな
気もします。
参考にさせていただきます。glibcについては確認します。
先々CPU個数を増やして競争力を維持しようとする可能性があります
ので、その時には効いてくるかもしれません。今のところはおっしゃ
る通りです。Linux自身、現段階では複数のCPUを使い切れなさそうな
気もします。
12 ：6：2000/12/04(月) 00:24
とりあえずさっき挙げた本読んどけ
UNIXおよびLinux/glibcでのpthreadsの仕組みを知らずに
パフォーマンスあげようたってとんちんかんなことになるぞ。
UNIXおよびLinux/glibcでのpthreadsの仕組みを知らずに
パフォーマンスあげようたってとんちんかんなことになるぞ。
13 ：8：2000/12/04(月) 00:34
LinuxThreadsはLinux特有のclone()システムコールを使って実装されて
いるので、スレッドというよりはライトウェイトプロセスというイメージかな。
データ領域を共有してるプロセス。
それぞれのスレッドはあくまでプロセスとしてスケジューリングされる
ので、ちゃんとしたkernel level threadの実装と比べるとコンテキスト
スイッチの切り替え等、あまり効率は良くないという話をどっかで見た
覚えがある。真面目に確認した事はないけど。
いるので、スレッドというよりはライトウェイトプロセスというイメージかな。
データ領域を共有してるプロセス。
それぞれのスレッドはあくまでプロセスとしてスケジューリングされる
ので、ちゃんとしたkernel level threadの実装と比べるとコンテキスト
スイッチの切り替え等、あまり効率は良くないという話をどっかで見た
覚えがある。真面目に確認した事はないけど。
14 ：6：2000/12/04(月) 01:00
clone()と同等のシステムコールは*BSDにも既にあるので、名前以外は特にLinux特有というわけではない。
glibcの実装の詳細は不勉強なのでよくわからないのだが、kernel threadsの得失は、
既出の本以外にも、たとえばここを読むとわかるかもしれない。
http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html
glibcの実装の詳細は不勉強なのでよくわからないのだが、kernel threadsの得失は、
既出の本以外にも、たとえばここを読むとわかるかもしれない。
http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html
15 ：名無しさん＠お腹いっぱい。：2000/12/04(月) 01:03
どうなんだろ。
実行が移る以上はPCその他関連データは退避しなきゃいけないのは同じだろうし。
kernel level になると何をサボれるようになりますか？
実行が移る以上はPCその他関連データは退避しなきゃいけないのは同じだろうし。
kernel level になると何をサボれるようになりますか？
16 ：8：2000/12/04(月) 01:04
> 13
スレッドとしてのメリットがないかもしれません。
clone()というのは初めて聞きました。調べてみます。
Unixは少し知っていますが、Linuxに触れたのは最近のことで。
> 12
何か特殊な事情があるらしいことはわかりました。
Win32のスレッドは良くできていたので、あんな具合に動いて
くれるとありがたいです。
以前にさらっと調べたところでは、スレッドの同期手段として
多面待ちのAPIが見あたらなかったのですが、PThreadでは
ポーリング併用とするしかないのでしょうか。
Windowsであれば WaitForMultipleObjects()＠｀SystemVの
APIであればsemop()、対象がディスクリプタであればselect()や
poll()でいずれかの条件が成立するまでブロックする処理を実現
できますが、POSIXスレッドの同期手段では多面待ちは推奨されな
いのでしょうか。あるいはAPIを見落としている?
全くの勘違いであれば遠慮無くご指摘下さい。
スレッドとしてのメリットがないかもしれません。
clone()というのは初めて聞きました。調べてみます。
Unixは少し知っていますが、Linuxに触れたのは最近のことで。
> 12
何か特殊な事情があるらしいことはわかりました。
Win32のスレッドは良くできていたので、あんな具合に動いて
くれるとありがたいです。
以前にさらっと調べたところでは、スレッドの同期手段として
多面待ちのAPIが見あたらなかったのですが、PThreadでは
ポーリング併用とするしかないのでしょうか。
Windowsであれば WaitForMultipleObjects()＠｀SystemVの
APIであればsemop()、対象がディスクリプタであればselect()や
poll()でいずれかの条件が成立するまでブロックする処理を実現
できますが、POSIXスレッドの同期手段では多面待ちは推奨されな
いのでしょうか。あるいはAPIを見落としている?
全くの勘違いであれば遠慮無くご指摘下さい。
18 ：6：2000/12/04(月) 01:15
>>15
LinuxThreadsのようにprocess baseだと、スレッドコンテキストの切替の度にkernelのコードが走る。
スレッドをuserlandで実現した場合に比べると、このコストは馬鹿にならない。
LinuxThreadsのようにprocess baseだと、スレッドコンテキストの切替の度にkernelのコードが走る。
スレッドをuserlandで実現した場合に比べると、このコストは馬鹿にならない。
19 ：6：2000/12/04(月) 01:20
20 ：8：2000/12/04(月) 01:21
もう6がフォローしてるけど。
14のリンクによると、LinuxThreadsの欠点としては
>Switching between threads is a very expensive operation.
>It requires switching to kernel mode＠｀ switching the old thread
>(process) out＠｀ and then running the new thread (process).
>There is no solution to this problem except to optimize process
>switching＠｀ which defies optimization beyond a certain point.
>This problem is aggravated by cache locality considerations.
>Each thread (process) requires all the kernel resources
>typically associated with a process. This includes a kernel
>stack＠｀ which means that applications with many threads require
>large amounts of kernel resources.
辺りみたいだね。前者は18で書かれてる事と同じかな。後者は、プロセス
扱いだからリソース喰うで、という話か。
14のリンクによると、LinuxThreadsの欠点としては
>Switching between threads is a very expensive operation.
>It requires switching to kernel mode＠｀ switching the old thread
>(process) out＠｀ and then running the new thread (process).
>There is no solution to this problem except to optimize process
>switching＠｀ which defies optimization beyond a certain point.
>This problem is aggravated by cache locality considerations.
>Each thread (process) requires all the kernel resources
>typically associated with a process. This includes a kernel
>stack＠｀ which means that applications with many threads require
>large amounts of kernel resources.
辺りみたいだね。前者は18で書かれてる事と同じかな。後者は、プロセス
扱いだからリソース喰うで、という話か。
21 ：8：2000/12/04(月) 01:31
PthreadにはWin32のWaitForMultipleObjects()のような便利な物は
ない上に、SysV IPCなんて使うと、そいつの為だけに待ち合わせ
スレッド起こす羽目になって、非常にいらいらする。
基本的にPthreadってほんとにbasicな所しか管理してくれないので、
Win32のEventみたいな物が欲しければ自分で実装しなきゃいけなくて
面倒くさい。
で、やっぱり面倒くさいと思う奴は他にもいるようで、GNU Pthという
threadライブラリでは、thread間でメッセージ使って同期取るとか、
色々面白い機能が付いてる。
ただ、Pthはノンプリエンティブマルチスレッドなんだよな。自分でyeild()
するか、Pthが皮を被せているselect()＠｀ read()等のシステムコールを
呼ばないとスレッドが切り替わらないので、その辺意識してコード書かない
といけない、というのがちょっとね。
まぁそのかわりライブラリがスレッドセーフでなくてもおっけー、という
メリットもあるんだけど。
ない上に、SysV IPCなんて使うと、そいつの為だけに待ち合わせ
スレッド起こす羽目になって、非常にいらいらする。
基本的にPthreadってほんとにbasicな所しか管理してくれないので、
Win32のEventみたいな物が欲しければ自分で実装しなきゃいけなくて
面倒くさい。
で、やっぱり面倒くさいと思う奴は他にもいるようで、GNU Pthという
threadライブラリでは、thread間でメッセージ使って同期取るとか、
色々面白い機能が付いてる。
ただ、Pthはノンプリエンティブマルチスレッドなんだよな。自分でyeild()
するか、Pthが皮を被せているselect()＠｀ read()等のシステムコールを
呼ばないとスレッドが切り替わらないので、その辺意識してコード書かない
といけない、というのがちょっとね。
まぁそのかわりライブラリがスレッドセーフでなくてもおっけー、という
メリットもあるんだけど。
22 ：名無しさん＠お腹いっぱい。：2000/12/04(月) 01:39
というわけでマルチプロセスで再検討するというのはいかがでしょう。
土俵が違うことですし。
土俵が違うことですし。
23 ：名無しさん＠お腹いっぱい。：2000/12/04(月) 05:38
Linux の mozilla を起動すると同じメモリ使用量の
プロセスが大量にできて＠｀ 96M しかない僕のマシンでも
みかけ上 300M 近く使っているように見えます.
これが clone() とかマルチスレッドの例ですか?
プロセスが大量にできて＠｀ 96M しかない僕のマシンでも
みかけ上 300M 近く使っているように見えます.
これが clone() とかマルチスレッドの例ですか?
24 ：名無しさん＠お腹いっぱい。：2000/12/05(火) 12:25
POSIX threadの場合は、提供されているタスク間通信手段を使ってより抽象度の
高い通信手段を自作してから、それを利用してＡＰを書くのが良さそうです。
SystemV上でもそのようなことはしていましたが、POSIX threadの場合は不可避
となりそうです。これは本を参考にしてみます。
多面待ちが用意されていないのは不便そうですが、何か重要な理由があって外した
のかもしれません。
どうもありがとうございました。
高い通信手段を自作してから、それを利用してＡＰを書くのが良さそうです。
SystemV上でもそのようなことはしていましたが、POSIX threadの場合は不可避
となりそうです。これは本を参考にしてみます。
多面待ちが用意されていないのは不便そうですが、何か重要な理由があって外した
のかもしれません。
どうもありがとうございました。
26 ：名無しさん＠お腹いっぱい。：2000/12/08(金) 12:57
age
27 ：名無しさん＠お腹いっぱい。：2000/12/10(日) 00:12
>>25
多面待ちって、condition variableを待ってる連中を全員broadcastで起こす
とかいう話ですか？ 外してたらごめんなさい。pthreadのAPIは
primitiveだけど、複雑な同期をこれを元に実現する手段は全部
揃ってるはずなので。
あと、抽象度高い通信、同期機構を..というのは全くおっしゃる
通りだと思います。
あと、書籍としてはこれまで紹介されてたの以外だと、
D.Butenhof氏のPOSIXスレッドプログラミング(翻訳版で読みました＠｀www.aw.com)
が深くてよいです。DECのスレッド実装に長く関わられた方だと聞いてます。
comp.programming.threadsでもよく質問に答えられています。
あと、一般にプロセス間の通信という観点でみるには、
UNIX Network Programming の2版のVolume2も良いですよ。翻訳も前に
出てたはず。POSIX IPCやPOSIX thread＠｀SystemV IPCの解説、比較があります。
マルチスレッドでなくプロセスの方が良いケースが多いこともわかりますし。
上記の本を読んで、ここ2年くらいSolarisでプログラムしてますが、
時々、Linuxスレッドも触ると、あれもない、これもない状態で、
結構苦労しますね。苦労しないように貢献しないといけないのですが...
多面待ちって、condition variableを待ってる連中を全員broadcastで起こす
とかいう話ですか？ 外してたらごめんなさい。pthreadのAPIは
primitiveだけど、複雑な同期をこれを元に実現する手段は全部
揃ってるはずなので。
あと、抽象度高い通信、同期機構を..というのは全くおっしゃる
通りだと思います。
あと、書籍としてはこれまで紹介されてたの以外だと、
D.Butenhof氏のPOSIXスレッドプログラミング(翻訳版で読みました＠｀www.aw.com)
が深くてよいです。DECのスレッド実装に長く関わられた方だと聞いてます。
comp.programming.threadsでもよく質問に答えられています。
あと、一般にプロセス間の通信という観点でみるには、
UNIX Network Programming の2版のVolume2も良いですよ。翻訳も前に
出てたはず。POSIX IPCやPOSIX thread＠｀SystemV IPCの解説、比較があります。
マルチスレッドでなくプロセスの方が良いケースが多いこともわかりますし。
上記の本を読んで、ここ2年くらいSolarisでプログラムしてますが、
時々、Linuxスレッドも触ると、あれもない、これもない状態で、
結構苦労しますね。苦労しないように貢献しないといけないのですが...
28 ：1：2000/12/10(日) 01:08
紀伊国屋から「Pスレッドプログラミング」が届きました。
この本の内容は、４年位前に読んだASCIIから出ていた本（もう手元
にありません）に良く似ています。調べてみると・・著者・訳者が同
じです。もしかして出版社が変わったとか。
私が「多面待ち」と書いたのは、この本の「第７章 複雑な同期」
の「複数待機セマフォ」(P117)に相当する機能です。
ここには、以下の記述があります。
「Win32では、(a)同期変数の集合の１つ、あるいは、(b)その集合の
全てを待つことが可能です。POSIXでは、別の方法でプログラムを書き
ますし、複雑な条件で待機する条件変数があります」
私の意図は(b)で、行いたいのは以下です。
(1)複数の条件変数のうちどれかがシグナル状態になったら待ちが解ける。
待ちが解けた直後に、どの条件がシグナル状態となったのかを調べて
分岐する。
mutex×1 + 条件変数×1 + ビットセット の組をクラスでラップすれ
ば同様のことは実現できそうですが、「POSIXでは別の方法で・・・」
が気になります。
ITRONでもビットマスク待ちはあるのにPスレッドにないのは、他の
やり方を採用することにメリットがあり、それが推奨されているから
なのかと考え込んでしまいます。
この本の内容は、４年位前に読んだASCIIから出ていた本（もう手元
にありません）に良く似ています。調べてみると・・著者・訳者が同
じです。もしかして出版社が変わったとか。
私が「多面待ち」と書いたのは、この本の「第７章 複雑な同期」
の「複数待機セマフォ」(P117)に相当する機能です。
ここには、以下の記述があります。
「Win32では、(a)同期変数の集合の１つ、あるいは、(b)その集合の
全てを待つことが可能です。POSIXでは、別の方法でプログラムを書き
ますし、複雑な条件で待機する条件変数があります」
私の意図は(b)で、行いたいのは以下です。
(1)複数の条件変数のうちどれかがシグナル状態になったら待ちが解ける。
待ちが解けた直後に、どの条件がシグナル状態となったのかを調べて
分岐する。
mutex×1 + 条件変数×1 + ビットセット の組をクラスでラップすれ
ば同様のことは実現できそうですが、「POSIXでは別の方法で・・・」
が気になります。
ITRONでもビットマスク待ちはあるのにPスレッドにないのは、他の
やり方を採用することにメリットがあり、それが推奨されているから
なのかと考え込んでしまいます。
29 ：名無しさん＠お腹いっぱい。：2000/12/11(月) 06:14
Linuxで沢山スレッドを立ててpsで見ると同じコマンドの
プロセスがずらーっと並んで気味悪くありません？
プロセスがずらーっと並んで気味悪くありません？
30 ：名無しさん＠お腹いっぱい。：
現状のLinuxのPスレッドどうよ？
Vine2.0でスレッドの個数によっては
待機から永久に目覚めないスレッドが
できたりして怪しいよ。
フリーソフトのソースでも
createとjoinしか使ってなくて
glibc2.xに注意とかコメントが目に付くし。
Vine2.0でスレッドの個数によっては
待機から永久に目覚めないスレッドが
できたりして怪しいよ。
フリーソフトのソースでも
createとjoinしか使ってなくて
glibc2.xに注意とかコメントが目に付くし。