Read/Upgradable/Write Lock

http://thread.gmane.org/gmane.comp.lib.boost.devel/149858/focus=149879 経由で.
あは.
あはは.
あははは.
なぜわざわざこんな upgradable mutex なんてもの導入しているかについてはこことかここ参照. upgradable lock を簡単に説明すると「排他的なロックに排他的に移行できる権利を持った共有ロック」みたいな感じ.典型的な用途はこれで,「ある共有オブジェクトに対して状態を確認(クエリ)してみて,もし状態が〜〜なら状態を変更」という(比較的良くある)コードに対して, read/write lock しかない場合,クエリする部分も含めて排他的ロックを獲得しないとならないところが, upgradable ロックならばクエリの部分は upgradable ロックを使って他の共有ロックと同時に実行できるようにしておきながら,他の write ロックの割り込みを許さずに write ロックを獲得した状態に移行して共有オブジェクトの状態を変更できる,という代物.っていうか紹介しようとしてた自分自身があまり理解していなかったという罠.
しかし,上のスレッド読んでて「また Alexander Terekhov 氏*1か!」とか思ったり.最近のマルチスレッドプログラミングな文脈ではどこにでも名前出てくる人っていう印象があるんだけれど俺の気のせいかなぁ.気のせいかも.ただ,氏は comp.programming.threads なんかでのポストではマジで必要最小限のことしか書かないので,読むときに1行1語書いてることを解読していかないと意味不明なのだけは何とかしてほしいんですががががが.

*1:マルチスレッドプログラミング周りでかなり active な人.double-checked locking idiom はメモリモデルによってはやヴぁいよね問題のときとか, boost::shared_ptr の lock-free 実装のときとかが記憶に残ってる

っていうか Boost.Threads にセマフォ semaphore 無いんですけどっ!?

副題:最近は (スレッド間で共有されるメモリに対する同期処理としては) セマフォは推奨されていなくて, mutex か, mutex と condition variable の組み合わせを使うことが推奨されている風潮があるんですけどっ!?でもそれに関する具体的な rationale がどこ探しても見つからないんですけどっ!?単に「semaphore は error prone だから」とかしか書いてなくて,それで私が納得するわけないんですけどっ!?っていうか,これに関して調べていたせいで時間がどんどん無くなっちゃてるんですけどっ!?っていうかオランダ語での頭文字を取って P とか V とか名付けてみましたって,アンタふざけてんのって書きたくなってくるんですけどっ!?っていか Dijkstra がオランダ人だなんて今初めて知ったんですけどっ!?