中村和志＠神戸です。

In article <YAS.03Aug5174302@kirk.is.tsukuba.ac.jp>
yas@is.tsukuba.ac.jp writes:
>NFS では、lookup() で名前解決する時と read()/write() する時
>でタイミングがずれているので、open() できても、read() したら
>ファイルがなくて失敗するということがあります。この手の不整合
>を許容してもいいなら、まあ、やりようはいくらでもあるでしょうね。
NFSは状態を持たないのがセールスポイントなのですが、lockは本質的
に状態を持つことが前提というのが、NFSの難しい所。rpc.lockd,
rpc.statdとかデーモンでファイルの状態を管理するようになった
のですが、server側にしろclient側にしろ、突然マシンが落ちた時
とか、そもそもlockdで管理するのか、statdで管理するのかとか
(OSによっては片方しか実装されていないことが、特に商用OSだと
多い）、NFSだと問題は余り解決していない。

>> 複数の資源を待たないとデッドロックしないから、システムコール
>> の場合は単一のlockですませるだけでも良いみたいですね。
>
>こういうのは、giant lock といって、１つの方法です。Solborne 
>だったかなあ、SunOS (Solaris以前) を SMP 対応にしたのに、こ
>の方法を使っていたと思います。Linux も、FreeBSD も、当初は
>分類としてはこの方法なんでしょう。
当初ではなく、現在も安定版はgiant lockです。開発版はgiant lock
撲滅を目標に頑張っていますけど。

>Unix は、特に、ファイルＩ／Ｏが多いようなシステムでは、カー
>ネルの中の CPU 消費が大きいので、giant lock では SMP にして
>も性能が上がりません。で、ロックの単位を細かくしないといけな
>いということで、Linux も FreeBSD も、頑張っていると。
そうです。SMPにして特に16PEとかそれ以上にしても余りトランザクション
性能が上がらなくて、WebBenchでLinuxがWindowsNTに大敗を喫して
しまいました。それでgiant lock撲滅を目指して頑張っている最中
なのですが、問題山積み状態です。問題は大きく３種類有って、

1. giant lockを潰して、小さいlockに分割して、それを活かすように
  kernel内スレッドに処理を並行させられるようにしなければ意味が無い。
2. そもそもデッドロックを起こして「フリーズ」を起こしたりするのは
  lockの対象となる資源が複数有って、lockを掛ける側がlockを必要と
  する資源がまちまちなこと。つまり資源がA,B,C,Dと有って、lock
  を掛ける側がa,b,cと有る時、a,b,cが皆A,B,C,Dを必要とするなら
  A->B->C->Dの順にlockを掛ければ問題無いのだが、現実にはaはA,B,C;
  bはD;cはB,C,Dだけ必要とする処理達が有って、これらプロセス｜
  スレッドが他の処理達がどの資源を必要とするか感知せず、各々
  好きな順にlock掛けてる状況で、デッドロックしないようにlock
  を掛けるのは不可能。
3. 一番問題なのは、人。上記a,b,c共に同一人物が作っていれば、
  デッドロックの危険性に気付く可能性が有るが、現実には複数
  （多数）の人間が、各々好きに（寄ってたかって）開発している
  現状だと、他の開発者がどの資源を必要として、どの順でlock
  掛けてるかとても把握できない。

ということです。FreeBSD-currentも、KSE(kernel schedule entity),
SMP-NG(No GoodではなくNext Generation)なんかがマージされてから
各デバドラ内部で細かいlockを持つように変わってきて、結構作るのが
面倒になってきました。性能向上のためには、lock掛けてる時間を
少なくするのが、特にSMPの場合重要だとは思うのですが。
  kernel内スレッドを如何にうまく分割するかを頑張るよりも、micro
kernel上で、OSサーバをマルチで走れるようにするのが、OS設計は楽
だと思うのですが、実際に労力が必要なのは結局デバイスドライバを
揃える泥臭い作業なんですよね。そんな訳でGNU(hurd)は志の高さにも
かかわらず、なかなか進まない。そもそもhurdの名の様にOSサーバが
マルチで動くようになったんでしょうか？
-- 
中村和志＠神戸         <mailto:kaz@kobe1995.net>
NAKAMURA Kazushi@KOBE   <http://kobe1995.jp/>
- Be Free(BSD), or Die...