河野真治 @ 琉球大学情報工学です。

In article <bgqnb3$12d$1@newsserv.ics.es.osaka-u.ac.jp>, SAITOH akinori <saitoh@ist.osaka-u.ac.jp> writes
> デッドロックはしなくなりますが、ロックしている時間が必要
> 最低限よりも長くなってしまいますね。

kernel 内部でロックが長く待たされる状況って実は「ない」んじ
ゃないでしょうか? (giant lockみたいなのはひどいと思うけど 
(動かすためには理解できます)) Linux は、いまいち、そのあたり
見通し良く作っているようには見えなかった。こまめにlock/unlock
を繰り返しているコードがたくさん入っている感じですね。
そりゃだめだろと読んでいるときに思った記憶があります。

> 数サイクルのspinwaitでロックが成功するような資源しか
> ないのならそれでかまわないでしょうが、たとえばメモリブロック
> などのように得られなければblock/sleepするような資源が
> 混じっているとパフォーマンスがメタメタになるのでは？

そりゃそうなんだけど、kernel 内でlockで待つ必要はないですよ
ね。lock の対象がswap outされていたりするなら避けようがない
かも知れないけど。

そもそもパフォーマンスを要求するようなアプリケーションはメモ
リを頻繁に取得解放なんてしちゃだめだよね。いや、もしかして、
現実は、そういうことを意識してないアプリケーションをなんとか
速く動かすのがOSの役割ってことなのか?! X Window System とか 
WWW Browser、WWW Server なんて、その典型だものなぁ。

> なお、教科書的に言うと、こうなっています。
(a)
> ・ロックする順序を守れば、ひとつずつ時間をおいてロックして
> 　いってもデッドロックしません。
(b)
> ・atomicな手続きで複数の資源がロックできるなら、必要な資源を
> 　一気にえるようにすることでデッドロックを回避できます。
> 　この場合は資源の順番は気にしなくて良い。
(c)
> ・資源R1が得られなくてブロックする時、ロック済みの他の資源を
> 　一旦開放して、最初から資源ロックをretryするならば、
> 　デッドロックは起こりません。この場合も資源の順序は気にしな
> 　くてよし。

(大変良くできました(桜))

ってことは、OS全体の構成を見て、

   アクセスされる資源の組みと、swapされないlockの対象

を有限個用意して、それを atomic にlockするってのが効率良さそ
うな気がします。これは、割りと、micro kernel 的な感じになり
ますよね。おそらく、「アクセスされる資源の組み」は、OS内部の
serverに対応するから。なので、究極には micro kernel の方がSMP
ではパフォーマンスが出るってことになるはずなんだが... 
(しかし、そんなにうまくはいかんのだろうな)

(c) はライブロックしそう...

(昔は、こういう議論をしていると mohta 氏が解説してくれたもんだが...)

---
Shinji KONO @ Information Engineering, University of the Ryukyus, 
              PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科, 
           科学技術振興事業団さきがけ研究21(機能と構成)