真夜中の並行処理トーク

へいこうしょりはおもしろいなぁというおはなしです。
33
SKS rep @repeatedly

. @kumagi_bot @nobu_k ってことは今のconccurent向けのデータ構造を提供しているライブラリで木の実装って全部STMでおすか?

2011-01-23 22:52:29
Nobuyuki Kubota @nobu_k

@repeatedly STM以前に、そもそも広く使われてる並列木の実装あんのかな・・・。大体順序がいらないからhash使ってたりして、純粋に木を遣ってるやつはあんまりなさそうな気がするけどどうなんでしょう。俺も知りたい。skip listなやつは結構あるけど。

2011-01-23 22:54:18
kumagi @kumagi_bot

@nobu_k 研究レベルだとSTMでもHTMでもすぐにこれみよがしに赤黒木のスケーラビリティを持ち出してくるんですけどね…。実用レベルのものは見たことないです。haskellのようにSTMが浸透してきている場所ならあるかもしれません。

2011-01-23 22:59:18
Nobuyuki Kubota @nobu_k

@kumagi_bot ですよねー。。。確かにHaskellだったらあってもおかしくなさそうですねー。

2011-01-23 23:04:08
Hideyuki Tanaka @tanakh

STMやりたい人は、HaskellかClojureどうぞ。

2011-01-23 23:00:16
Hideyuki Tanaka @tanakh

Haskellがいけてるのは、型システムで副作用のある動作を排除できること。Clojureがいけてるのは、共有リソースに対してトランザくショナルアクセスしか提供していないところ。

2011-01-23 23:02:41
Hideyuki Tanaka @tanakh

いずれにせよ、STMをまともに言語に組み込むには、それ相応の型システムが必要だと思います。

2011-01-23 23:03:37
SKS rep @repeatedly

しかしSingle Giant LockでScaleしない状態ってかなりシビアだな.細かな粒度のLockも限界があるのは確かというか作りたいアプリケーションによっては厳しい…

2011-01-23 22:54:53
kumagi @kumagi_bot

@repeatedly 今のところ細粒度ロックの木は見たことないです。何で木の実装が無理かっていう話はケンブリッジ大学の博士論文みたいなところで語ってた気がします。javaのutil.concurrentパッケージにもskip listしかないし…。

2011-01-23 22:57:18
kumagi @kumagi_bot

@repeatedly Single Giant Lockってスケールしない共有方法のお手本みたいな例なのでシビアでもなんでもないと思います。

2011-01-23 22:57:50
Nobuyuki Kubota @nobu_k

@repeatedly むしろそれでスケールする状況がない気がする。スケールしなくても良いところで荒くロック取ってるんじゃないのかな。俺はそう。かといって細かくロック取り始めるとオワタ感がすごいことに。ずいむー。だったらSTMでryってなっちゃう人が俺。

2011-01-23 23:00:01
SKS rep @repeatedly

. @nobu_k @kumagi_bot ああいや,アプリ毎に分割してイベント的にやればそれなりに動くんじゃないかなぁと勝手に思ってました.CRuby with EventMachineとかNode.js的な.

2011-01-23 23:02:30
kumagi @kumagi_bot

実際赤黒木のSTM実装が欲しい場面って"パフォーマンスは二の次"かつ"メモリは節約したい"かつ"スケールして欲しい"ぐらいしか想像がつかないのでニッチな分野だと思う。

2011-01-23 23:02:53
SKS rep @repeatedly

まぁでもさっきのは共有メモリへの操作バリバリなコードだと関係なかった…

2011-01-23 23:03:48
Nobuyuki Kubota @nobu_k

@repeatedly 確かにアプリが状態を持ってなければそれで十分だとおもす!

2011-01-23 23:06:04
SKS rep @repeatedly

http://bit.ly/gH3n4z にはないのか? > なんで木の実装が細粒度で無理なのか

2011-01-23 23:06:23
kumagi @kumagi_bot

@repeatedly 僕はそこで読んだ記憶です。

2011-01-23 23:07:44
SKS rep @repeatedly

@kumagi_bot ということはこれの中のどれかか…

2011-01-23 23:09:10
kumagi @kumagi_bot

@repeatedly 早い話が「他に木の探索してるスレッドが居る最中で木を回転させたら探索空間をかってに変更しちゃって見つかるものも見つからなくなるじゃんね。回転させないように各節にカウンタ付ける?ご冗談を」みたいな内容でした。

2011-01-23 23:14:58
kumagi @kumagi_bot

@repeatedly 木の回転後も探索空間が保証されるようにポインタをマーキングしてどうのこうの…ってのを一時期考えてたのですが、保証の為にかかるコストが凄まじいことになるのでダメそうだなぁと捨てました

2011-01-23 23:15:59
SKS rep @repeatedly

Atomic操作 and 共有メモリ勉強会の開催が待たれる

2011-01-23 23:11:57
SKS rep @repeatedly

java.util.concurrentにも木がない… http://bit.ly/gVJkfA

2011-01-23 23:16:54
SKS rep @repeatedly

なるほど.粒度を大きくすれば回転のための保証コストは下がるけどパフォーマンスが出ない.粒度を小さくすると今度は回転のための保証コストが馬鹿にならなくなるのか…

2011-01-23 23:23:10
kumagi @kumagi_bot

Lock freeなtreeといえばD言語でも有名なあのandrei先生による論文があったな。要約すると「めったに書き換えない二分木ならRCUで実装すれば最強じゃね?GC無しだと寿命管理の為にカウンタ付けることになってスケールしないだろうけど変に苦労するよりはずっと時間の節約だ」

2011-01-23 23:31:45