読者です 読者をやめる 読者になる 読者になる

Software Transactional Memo

STM関係のことをメモっていこうと思います。

ClojureのSTM

Software Transactional Memory Should Not Be Obstruction-Free

この論文がClojureのSTMの基礎になっているらしい。

Benchmarking Contention Management Strategies in Clojure’s Software Transactional Memory Implementation

という修士論文ClojureのSTMのベンチマークを行なってる。

論文を軽く眺めてみるとDSTMをベースに書き込み制御に2phase-lockすることで通常の参照に必要な間接参照を0回に減らしているのだとか。値を獲得した時についでにキャッシュラインに載ってるというのは好ましい性質ですね。そして楽観的な並行制御でありつつもEagerな衝突検知を行うという事で、書き換えにはすこぶる弱そうな特性が揃っています。だってEagerに書き込みロックを取ってしまう以上デッドロックは避けられない問題なので、タイムアウトなどの戦略を選ぶわけですし。

早期にロックを取る分のコストをRead-Write-Lockにすることで軽減してるようですがあんまりいただけない気がします。最小時間のロックでコミット時にまとめて解放するのなら、普通のSpin-Mutexを使う事でアトミック命令の数を半分に減らせます。

その点でTL2なんかは、コミット時にまとめて順序ロックを取るのでデッドロックしないですし素敵ですね。LazyというのはOptimisticな物とよくなじむんじゃないかと思います。設計方針がまとまってて素敵です。

それに引き換えClojureのSTMは設計の方針がブレてるような印象があります。

 

ですがそもそもClojureのSTMはJVMに載ってるので、JVMの実装によって如何様にでも高速化され得ます。

例えばintelはHaswell世代からHTMを載せるとかいう話も漏れ聞こえてますし、JVMがそれにさえ対応すれば同一のClojureコードがすごく効率の良いHybridSTMで実行される可能性もあるわけで、早々にこの実装のSTMを試した人が「STM遅いわ―ダメだわ―」って話すのはちょっと違う気がします。