*nix系のロック方式をトイレにたとえる。

で、Lock ContentionがLinux並になるのマダー？
開発者のマンパワーが同じだとして4年ちょっとだよね。
じつはもっと進んでる！というなら(2.3の後半とか？)あと何年かかるか予想できますか？

-----------------------------------------------------------------------------------
> で、Lock ContentionがLinux並になるのマダー？
基本はspinlockマンセーなLinuxと、極力blocking lockを使おうとしている
FreeBSD5では方向性が全然違うんで、
「Lock ContentionがLinux並になる」ってのはあまり意味のない比較だということを
あらかじめ念を押しておく。
で、FreeBSDのロックの細粒度化については以下の文書を見るといい。
ttp://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/major-issues.html#SMPNG
残っている大物というと、やはりVMとVFSまわり。
とはいえ、これも今年中にはほとんどGiant freeなところまで持っていけると
俺は思っている。

-----------------------------------------------------------------------------------
すまん 
spinlock 
やさしく説明してくれ。 

-----------------------------------------------------------------------------------
小便しに行って便器が全て使用中だった場合に便器の後ろで 
ウロウロするのがspinlock。大便しに行って、全ての個室が使用中で 
別の便所に移動するのがblocking lock。 
どちらを使うと得であるかは、待たされる時間がどの程度かによって異なる。 

-----------------------------------------------------------------------------------
すまん 
想像力が働かず 
より一層わからん。 

-----------------------------------------------------------------------------------
Linux: ウンコは家でするのが基本 
FreeBSD: ウロウロするのは「ダサい」 
Solaris: 便所は十分用意してある 

-----------------------------------------------------------------------------------
吹き出したよ。なんとかしてくれ 

-----------------------------------------------------------------------------------
何故Spin Lockが何故有効かは、
lockが競合したとき、lockを取れなかった側が 
その場でbusy loopして待ち続けるのがspinlockで、 
lockの取得を一旦あきらめて別のrunnableなスレッドに 
コンテキストスイッチするのがblocking lock。 
spinlockでは、競合が起こっている時間が 
即CPU時間の浪費につながるので、 
lockの競合はできるだけ避けなければならない。 
一方blocking lockでは、runnableなスレッドが他にいる限り 
そちらの実行を続けられるので、spinlockよりは競合を受け入れやすい。 
(とは言え、コンテキストスイッチにはコストがかかるので 
競合しないに越したことはないが……) 
何年か前までは、spinlock主体のアーキテクチャは 
「原始的」でありscalabilityがないと言われていたんだが、 
Linuxは徹底的なlockの細粒度化やlockに頼らないデータ構造(RCU)の導入とかで 
見事その定説を覆してみせたようだ。 

-----------------------------------------------------------------------------------
Solarisにあるアダプティブロックとは、 
ある一定数スピンして、それでもロックされているなら 
コンテキストスイッチ、という意味なんでしょうか？ 

-----------------------------------------------------------------------------------
単純なblocking lockでは、競合が発生した場合 
すぐにコンテキストスイッチの動作に移るんだが、 
*対象のlockがすぐに解放される見込みがある場合*は 
しばらくの間spinを試みた方がトータルコストを下げられる可能性がある。 
(コンテキストスイッチ自体がコストの高い操作なので) 
で、この「spinをした方が得かどうか」の判断材料として 
「対象のlockを保持しているスレッドが、現在他のCPU上で実行中である」 
かどうかを見るのがadaptive lock。 
blocking lockの仕組みがちゃんとできていればadaptive lockへの改造は簡単。 
実際FreeBSDにもかなり前からadaptive lockのコードが入っている。 
(現在はデフォルトでoffになっているが…) 
ttp://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_mutex.c#rev1.92 

-----------------------------------------------------------------------------------
つまりこういうことか。 
単純なblocking lockでは、個室に先客がいるばあい、便意はとりあえず置いておいて 
飯を食いにいったり煙草を吸いに行ったりするわけだが、*対象の個室がすぐに空く見込みがある 
場合*は、しばらくの間ドアの前でもじもじしていた方がトータルでは楽になる可能性がある。 
(気分を切りかえること自体がかなり無理なことなの)で、この「もじもじしていた方が得かどうか」 
の判断材料として「対象の便器を占有している香具師が、現在ちゃんと起きて力んでいる」か 
どうかを見るのがadaptive lock。 

-----------------------------------------------------------------------------------
自分下痢で最大リミットの時ドアを蹴り破るとか 
先行者をケツも拭かせず追い出すとかの実装は 
在りませんか？ 

-----------------------------------------------------------------------------------
ドアを蹴り破ったりするわけじゃないけど、 
「優先度継承」って仕組みがそれに近いかな。 
例えるなら、いつもはマターリと新聞を広げながら便器に座っているような人が 
先客として入っているとき、下痢の人がドンドンとドアを叩くと 
中の人ももの凄い勢いで踏ん張って早く用を済ませるようになる機能だな。