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

In article <YAS.07Feb6185655@kirk.is.tsukuba.ac.jp>, yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> > resource id 自体は、どうやって取って来るんでしょう?
> Unix で資源の ID というと、ファイル名じゃないですか。

分散環境だとホスト名を使って資源名にするのは、もはや、
ちょっと危ないしなぁ。どうするんだろう?

> ファイル名で sort して、その順にロック。でもいいけど、なんか
> ソートするくらいなら、１度に資源を確保するでもいいかも。それ
> を実は、grmd がやっているということかな。

僕も grmd に生成させるのかなと思って質問したんですが...

> > まぁ、だから、デッドロック検出が容易なわけなんだろうけど。
> それは、どうかなあ。検出簡単なら、カーネルに入れてもいいんだ
> けれど。アルゴリズムは教科書に載っているけれど、カーネルに実
> 装はしたくない。

いや、だから、順序付け可能なresource idがあれば、デッドロッ
ク検出は、その循環依存を見つければ良いので簡単だって話です。

問題は grmd に閉じているんだから。loop 検出しても良いと思う。

例えば、block する時に、プロセス間に resource id の順序の方
向にpointerを張っておけばいいと思う。block した時に、自分の
資源からpointerをたどっていったpidと、自分が既に獲得した資源
のpointerの先のpidが同じだったら、循環性があるってことですよ
ね。そのポインタのコストが高いってなら、まぁ、仕方ありません
が。

分散しているとコストは高いけど、kernelに閉じているなら、
waiting graph でもいいし、resource order 順のlockでも
いいし...

まぁ、実際には、
    lock file 作って、そこで、atomic lock
ってのが多いとは思いますけどね。

複数の資源をlockするUnixのアプリケーションなんて、みたことない。

> なので、カーネル外でやるのは、まあ、順当とも言えるけれど、１
> つ問題がありそうなのは、アクセス制御。root の作業を一般ユー
> ザが妨害するとか、どうするのか。同じ UID 専用だと、使えない
> し。この手の話をカーネル外で安全にやろうとすると、それなりに
> 大変そうです。どうしているのでしょうね。

server に頼む方法だと、結局は、advisery lock であって、
無視することも可能ですよね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科