アダプティブロック
毎度楽しみにしている、Linux Kernel Watch。今回はこんなお話が出てきました。
スケジューラの挙動は三巨頭会談で決まるのだ？（1/2） − ＠IT
ついにLinuxにもadaptive lock導入か?!
adaptive lockとは、Solarisなどで採用されているロック方式で、一定時間ビジーウェイトで待った後、通常のブロック型のmutexに縮退するというハイブリッド型のロックです。Linuxにおいても、過去何回かSolarisスタイルのadaptive lockが提案されてきましたが、どれも性能がイマイチだったこととLinuxカーネルの設計方針に合致しなかったため、マージされませんでした。
この提案は過去の提案とは異なり、時間によってspinとblockを切り替えるのではなく、ロック保持タスクが別CPUで動いているときはspinに、寝ているときはblockにと切り替えるというポリシーになっており、Linusの嫌いな、根拠のないヒューリスティクス（注10）が排除されているのが特徴。
ん？何を言っているのかさっぱり分かんねーぞ。(難しすぎという意味ではなく)
オイラ以上に何を言っているのかさっぱりな人は、下記をどうぞ。全部読めばコンピュータ屋さんなら分かるはず。
Spinlock と便器 - 笑わないプログラマ
単純なblocking lockでは、競合が発生した場合
すぐにコンテキストスイッチの動作に移るんだが、
*対象のlockがすぐに解放される見込みがある場合*は
しばらくの間spinを試みた方がトータルコストを下げられる可能性がある。
(コンテキストスイッチ自体がコストの高い操作なので)
で、この「spinをした方が得かどうか」の判断材料として
「対象のlockを保持しているスレッドが、現在他のCPU上で実行中である」
かどうかを見るのがadaptive lock。
まともな Adaptive Lock ならロック保持タスクが他のスレッドで実行中かどうかを見るのが普通じゃねーのか？
便器の話で説明するのもどうかと思うので、久々に「Solaris インターナル」を引っ張り出してきました。
Solarisインターナル―カーネル構造のすべて
アダプティブ・ロックのメカニズムは簡単である。スレッドが獲得しようとしているロックがすでに保持されている場合、まずロックを保持しているスレッドの状態を調べる。そして、ロックの保持者(所有者)が他のプロセッサ上で現在実行中であれば、ロックを獲得しようとしているスレッドをスピンさせる。一方、ロックを保持しているスレッドが他のプロセッサ上で実行中でない場合は、ロックを獲得しようとしているスレッドをブロックする。
ほら、ね。なにが「Solaris スタイルの adaptive lock の問題点」やねん。アダプティブ・ロックってのはそもそも他のCPUで実行中ならスピンし、そうじゃなきゃブロックするロックだっつーの。謝れ！Solaris に謝れ！
まあどうでもいいや。こんなだからやっぱり Linux って好きになれんのですよね。。。
