Mutex捨てたいとしばしば思う
TM (Transactional Memory) をサポートする（モデルも一部ある）Haswellも出たことだし，それでなくともSTM実装はGCC 4.7に既に入ってることだし，そろそろ本気でTMを勉強して実用に投入し，mutexは捨てたい... と，しばしば思うが，夢想のレベルから一切進んでない．正直 mutexと条件変数を手でしこしこ操作してる限りデッドロックの恐怖から逃れられないので，これは切実な欲求である．
しかしこないだ上司に指摘されて冷や汗と脂汗をかいたデッドロック*1は，TCP通信と共有メモリIPCを（意味論的に）またいだものだった．工数と実行時パフォーマンスの都合から，無条件にデッドロック・フリーまでは保証できないものの「所定の条件を守って使う限り」デッドロックしないはずのモジュールを作って渡したんだが，その条件下でもデッドロックが起きていた．私がTCP通信と共有メモリIPCを（意味論的に）またいだロック待ちを想定していなかったためだった．どっちもTMが苦手とする外部I/Oである... 巻き戻しの効く部分と効かない部分を最初から分けたデザインが必要になるが，そこのメンタル・モデルが自分の中にまだ無いので実験レベルですら書き換えに手が付けられない．
後は「クリティカル・セクションに入る順番の制御は複数mutexのお手玉でなんとか可能なんだがSTMのリトライはその辺どうなるんだ？」とかも困る．
- http://stackoverflow.com/questions/11666610/ c++ - How to give priority to privileged thread in mutex locking? - Stack Overflow
まぁ，今までmutexベースで構築してきたミノタウロスの迷宮をいきなり全て一息にTMベースへと翻訳し切ることを考えるのではなく，TMの演習問題を愚直にこなしてメンタル・モデルを私の中に構築することから始めるのが，結局は一番の近道なのだろうな．
