Multithread and event driven (SMP / Multi Thread)
Yasushi Shinjo
もう、Unix じゃないから、どうしますかね、Followup-To:
fj.comp.parallel にしますか。
In article <3988708...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
> そうかも。一方で、GUIとかはEvent driven/Call backで組まれている
> わけでマルチスレッドはたくさん使われているんですよね。
イベント駆動のマルチスレッドは明確に分けて考えたいという話が
あります。次の話は、面白いですよ。
J.K.Ousterhout: "Why Threads Are A Bad Idea (for most
purposes)", Invited Talk at the 1996 USENIX Technical
Conference (January 25, 1996).
http://home.pacbell.net/ouster/
http://home.pacbell.net/ouster/threads.pdf
スライドの５ページ目の図が印象的です。こんな感じ。
------------------------------------------------------------
What's Wrong With Threads?
casual all programmers wizards
>>==========================================>
<------- Visual Basic programmers -------->
<----- C programmers ------->
<-- C++ programmers -->
<-->
Threads programmers
Too hard for most programmers to use.
Even for experts, development is painful.
------------------------------------------------------------
私も、スレッドのエススパートと言ってもいいのでしょうが、最後
の最後は、これで本当にあっているのかは分からないです。これは
間違っている、というのは、だいぶ気が付くようにはなりましたが。
学生さんにレポートを出させると、とりあえず動くプログラムが返っ
ては来るんだけれど、本当にこれで大丈夫とは保証できません。な
んか怪しいけれど、ダメとも言えない。
ＯＫというのは、あるこなれたパタンがあって、それにあっている
のは、ＯＫというかんじです。マスタスレーブとかね。
それで、マルチスレッドに抗するのが、イベント駆動プログラミン
グ。スライドの9ページ目あたり。
------------------------------------------------------------
Event-Driven Programming
One execution stream: no CPU concurrency.
Register interest in events Event (callbacks).
Event loop waits for events, invokes handlers.
No preemption of event handlers.
Handlers generally short-lived.
------------------------------------------------------------
> かなり丁寧にカーネルリソースの排他制御をしないとだめで、しか
> も、リソースの使い方に応じて様々なロックを使い分けないとだめ
> ですからね。でも、それだけなんじゃないかって気もしますが...
カーネルも、スレッド意識しないで書ける所を増やしてあげればい
いんだと思います。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Shinji KONO
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> イベント駆動のマルチスレッドは明確に分けて考えたいという話が
> あります。次の話は、面白いですよ。
Call back はイベント駆動のインタフェースなんだけど、実は必ず
マルチスレッドである必要があると思います。そうでないのは、さ
ぼっているだけ。
ただ、今の pthread API は、たこすぎだと思います。ちょっと低
レベル過ぎ。カーネルも同じで、実は lock API が低レベル過ぎな
ところが問題なのだと思う。このあたりのレベルを上げてやると、
> カーネルも、スレッド意識しないで書ける所を増やしてあげればい
> いんだと思います。
ということになるのだと思います。ただし!
ライブラリ呼び出し
オブジェクト指向
lock の構造の隠蔽
みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
意識しないで書けるようにすることは、実は出来ないんだと思いま
すね。
じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
チしかないと思うんだけど。新城さんもそう思うでしょ?
> もう、Unix じゃないから、どうしますかね、Followup-To:
> fj.comp.parallel にしますか。
そういうのはどうかなぁ。元のニュースグループも、尊重した
方がいいと思う。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
MOCHIDA Shuji
持田＠NETside です。
>> カーネルも、スレッド意識しないで書ける所を増やしてあげればい
>> いんだと思います。
>
> ということになるのだと思います。ただし!
>
> ライブラリ呼び出し
> オブジェクト指向
> lock の構造の隠蔽
>
> みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
> 意識しないで書けるようにすることは、実は出来ないんだと思いま
> すね。
なるほどです。
> じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
> チしかないと思うんだけど。新城さんもそう思うでしょ?
＃ 新城さんじゃないですが
なるほどです。でも、これって、うまいデバッグ方法が確立された上で、という
条件が付きますよね?
--
持田 修司 NETside Technologies Inc.
-- Equal Opportunity for All Good Architectures, NetBSD. --
Yasushi Shinjo
In article <3988719...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
> Call back はイベント駆動のインタフェースなんだけど、実は必ず
> マルチスレッドである必要があると思います。そうでないのは、さ
> ぼっているだけ。
並行オブジェクト指向みたいに、１オブジェクト１スレッドにして、
イベントはスレッドが好きな時に取りに行くようにすれば、どうで
しょうか。
> ということになるのだと思います。ただし!
> ライブラリ呼び出し
> オブジェクト指向
> lock の構造の隠蔽
> みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
> 意識しないで書けるようにすることは、実は出来ないんだと思いま
> すね。
シングルスレッドにして同期を「書かない」と同期の抽象化をあげ
るは、ちょっと違うかなあ。
> じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
> チしかないと思うんだけど。新城さんもそう思うでしょ?
プログラム変換。。。ちょっとイメージがつかめません。
並列プログラムの自動生成ならイメージできるんだけど。
Shinji KONO
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> 並行オブジェクト指向みたいに、１オブジェクト１スレッドにして、
> イベントはスレッドが好きな時に取りに行くようにすれば、どうで
> しょうか。
そんなに嫌いじゃないんですけどね。実際やってみると、オブジェ
クト単位で低レベルの並列制御をするようになっちゃうんだよな。
Bounded Buffer とか Condition Variable とかを書いてみようと
すると、そんなことになります。オブジェクトとかメッセージとか
に順序が入ってないのでDead Lockしまくるし。
> シングルスレッドにして同期を「書かない」と同期の抽象化をあげ
> るは、ちょっと違うかなあ。
シングルスレッドは、同期をかかないんじゃなくて、同期以外のも
のを書いているんでしょ? 同期は同期で、thread of control とか
compuational data flow とかとは別なものを書いているんだよね。
> プログラム変換。。。ちょっとイメージがつかめません。
> 並列プログラムの自動生成ならイメージできるんだけど。
ま、そんなものだ。
スケジューラを自分で書けないようなものだと同期を抽象化するこ
とはできないんだと思います。なので単純な並行オブジェクト(ア
クターみたいなやつ)はだめなんだと思う。
Yasushi Shinjo
In article <3988736...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > 並行オブジェクト指向みたいに、１オブジェクト１スレッドにして、
> > イベントはスレッドが好きな時に取りに行くようにすれば、どうで
> > しょうか。
>
> そんなに嫌いじゃないんですけどね。実際やってみると、オブジェ
> クト単位で低レベルの並列制御をするようになっちゃうんだよな。
> Bounded Buffer とか Condition Variable とかを書いてみようと
> すると、そんなことになります。オブジェクトとかメッセージとか
> に順序が入ってないのでDead Lockしまくるし。
バッファをオブジェクトで書く所に問題があるんじゃないですか。
それは、システムで用意することにして。もちろん、システム作る
人には、ガリガリがんばってもらうことにして、残りの９５％くら
いの人は楽をすると。
人間は、なかなかデッドロックはしないからね。何なんでしょうね。
マルチスレッドは、ななかできないけれど。
> > シングルスレッドにして同期を「書かない」と同期の抽象化をあげ
> > るは、ちょっと違うかなあ。
>
> シングルスレッドは、同期をかかないんじゃなくて、同期以外のも
> のを書いているんでしょ? 同期は同期で、thread of control とか
> compuational data flow とかとは別なものを書いているんだよね。
同期にも、データフローの待ちみたいなものなら、Unix のパイプ
みたいにすれば、書かなくても平気になります。lock-unlock のよ
うに、処理の都合で入れる同期は、なんかかっこいい抽象化があれ
ば、かなり消せるはずです。
lock-unlock を消した例としては、Linda があります。
Japa Spaces は、現在どんな感じかなあ。