|
>open の時点で $file が破壊されるってことですね。 はい，あと引数'2'だと，待っている間何も出来なくなるので マズイ，ということで2箇所...としました． シグナル起こしはあてにならないということで． >デッドロックを回避できるからこそ flock の価値があるんではないでしょうか？ デッドロックは起きます． flockには価値なんかありません．BSDでの互換性だけです． 言葉遊びでなく，確率というか危険度と考えてください． flockして成功したプロセスが無限ループに入ったとき， 解除にはたいがいプロセス殺しが必要です．うまく殺せるか どうかは不確実なので，この時点でデッドロックといえます． symlinkやmkdirでの排他処理だとまだ通常のファイル操作で済みます． >それとも、セマフォとかの待ち行列の状態が検知できないという意味でしょうか？ はい，検知と制御ができません．同じ意味でfcntlやセマフォも 使うのは難しいです．OSリソースを隠れて消費し，工夫しないと システム全体の速度が低下します． OSに付属する排他処理機構を，よく検証せずに使うのはまずいです． 私の経験だと， - いつどのプロセスが何をロックして - それを参照する何個のプロセスがどれくらいの時間待機しているか 外から判るようにしなければだめな感じです． >訳の分からない排他制御手段を考える人が出て来るような気が 他人の手法を参考のうえ，排他処理の仕組みを自分で考えるのは 結構なことだと思います． |
|
>解除にはたいがいプロセス殺しが必要です．うまく殺せるか >どうかは不確実なので，この時点でデッドロックといえます． なるほど、もし解除できないということが起こるなら、 確かにデッドロックですね。 unixを触ったことがないため、そのヘンは、何となくシステムを 信頼していました(^^; >flockには価値なんかありません．BSDでの互換性だけです． う〜ん、それが現状だとすると、問題ありそう… >言葉遊びでなく，確率というか危険度と考えてください． 確かに、私の先の書き込みは、スパゲッティを食べる哲学者のレベルでの 話かも知れません(^^; >OSに付属する排他処理機構を，よく検証せずに使うのはまずいです． 検証する能力がない人間が下手なことをするよりは、 システムが用意した機能をそのまま利用した方がマシ、 というスタンスでいたのですが、少なくともflockに関しては、 考え直さないといけないみたいですね。 >symlinkやmkdirでの排他処理だとまだ通常のファイル操作で済みます． 今後は、作成時からの経過時間検査による解除機能付きsymlink/mkdirあたりで 検討してみたいと思います。 >他人の手法を参考のうえ，排他処理の仕組みを自分で考えるのは >結構なことだと思います． これは、あくまでもっと低次元の話です。 「他人の手法」を正確に理解し、問題点を的確に把握した上で、 「自分で考える」のであれば、仰る通りすばらしいことだと思います。 |
|
Netboy さんは、ノンブロッキングの flock なら OK、 という立場ですよね? で、いくつか疑問があります。 > flockには価値なんかありません． fcntl には価値がある、という話でしょうか。それとも 両方価値がない、という話ですか? > flockして成功したプロセスが無限ループに入ったとき， という状況って、起こり得ますか? (現象事態は root が SIGSTOP 送れば容易に発生しますが) Netboy さんは、どういうプログラムを想定しておられます? ちなみに僕が考えたのは、カウンタとか web BBS とかです。 > Perl で普通にflockを使っていると，たいがいまともに > ロックできないうえ処理速度が遅くなります． 僕の環境では「まともにロックできない」というのは 経験したことはありません (1000回カウントアップしたつもりが、 カウンタデータファイルを見ると998回しか実行されていない というのはあった。原因は不明)。 それと flock は、symlink・mkdir よりは速かったです。 しつこいですが、僕の環境では、です。 # あと、排他処理はいつも symlink でやるので、flock を # 使いこんだことはないです。 > 訳の分からない排他制御手段を考える人 http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm (笑) |
|
>http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm (笑) あはは、どもです。どこだったか忘れてました。 |