STMよくわかりません＞＜

@ashigeruさん謹製のsmalltable_toyのソースを読み解く基礎知識として、Beautiful CodeのSubversion解説につづき、@ashigeruさんとの会話で教えていただいたSTM(Software Transactional Memory)の論文をちろっと読んでみました（pdfをkindleに入れて、子供とガーラ湯沢で雪遊びした帰りの新幹線で読んでました）。

2/3くらい読み進んで、理解度は50%くらいだとは思うのですが、これまでの疑問点：

• 要するにメモリやオブジェクトを（悲観的ロックの代わりに）バージョニングで楽観排他するってことだと思うのだけとどうか？（helpingとか最適化手法はいろいろあるようだけど）
• 元ネタであるHardware Transactional Memoryは、つまりメモリチップのレベルでメモリ内容の書き換えをバージョン管理してtx排他するってことで、これは確かに面白いと思う
• けどSTMが提案している（と私が思っている）ソフトウェアレベルでメモリとかオブジェクトにバージョニング番号付けてtx楽観排他するという方法は、例えばEJB2のEntity Beanインスタンスのtx排他等で2000年代に普通に実装されてたし（私はJBossでがしがし使っていた）、90年代のOODBのキャッシュや分散オブジェクト等でも研究されていたはず（CORBAやDCOMのtransactional componentなどはその方向を目指してたのでは？）
• ということで、特にobject-based STMの新規性がよくわかりません＞＜

理解度を高めるためにつっこみよろです！

ところで、STMについて調べてたら、@repeatedlyさんの書き込みを通じてデータフロー変数なるものを知ってふむふむでした。

追記

@ashigeruさんからSTMの意義について参考になるつぶやきをいただきました：

object-based STMとかってSunが盛んに研究してたので、EJBと比較した新規性が…といわれるとちょっと分からないですね

私：お読みthxです！なぜ最近盛んに研究されてるかがよく分からなかったのと、もし本質的にあまり変わりないなら分散オブジェクト系の引用があってもいいはずだなあと。

stealingとかのコンフリクト回避が分散オブジェクトのコンテキストだと合わない前提とかじゃないですかね。

私：ふむ、つまりSMPとかマルチコア環境での排他というコンテキストが前提なのかな。コアのキャッシュ間の整合性確保の延長で。。

そう思います＞SMP等。積極的に相互通信するモデルは分散だとちょっと相性悪そうですね