Re: SMP / Multi Thread
河野真治 @ 琉球大学情報工学です。
In article <ul8ispem2ow.fsf@pine.yorie.netside.co.jp>, MOCHIDA Shuji <mochid@netside.co.jp> writes
> カーネル内のリソース解放待を減らすにはリソースを細かい単位で
> ロックするようになるので、複数の実行単位で押えるリソースの順番
> 間違えるとデッドロックするということのつもりなんですが..
デッドロックはロックの待ち合わせ順序にループができると起きる
ので、なんらかの順序を導入して、ロックする主体が、ロックする
複数の共有資源をその順序でロックすることにより避けることがで
きます。
データベースみたいに順序が入ってないと結構面倒です。順序をい
れようと思うとinsert/deleteに時間かかるようになったりするし。
でも、IDを入れちゃうのが最近では主流じゃないかな。
> 「Processor とか Process ID とかで順序」というのはよくわからないのですが..
> ひとつのリソースからみた場合ということでしょうか?
順序はなんでも良いです。
例えばCPUだったらCPUに順序を付ければ良いだけで、だいたい、そ
うなっているはずです。なのでSMP関連のロックでデッドロックする
のは普通はないですね。
それ以外でもカーネルの資源は順序がついているのが普通なので、
カーネル内でデッドロックってのはあまり問題にならないんじゃな
いかなぁ。
> それともマイクロカーネルならロックするリソースの数も少ないし
> ロックから解放までの時間も短いのでロックを多数取得する必要もない、と
> いうことなんでしょうか?
多数ロックするってのが、ロックとアンロックを混ぜるってことだ
と、途中でエラーしたときに極めて面倒なことになるので、普通し
ないと思う。(でもないか.... アクセスカウンタみたいなのが多い
から、そういうのはエラーしても元に戻したりしないから...)
そもそもデッドロック検出なんて重すぎてカーネル内で走らせるのは
無理ですよね。なので、デッドロックしないように作るのが普通だと
思う。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735