[Fswiki-dev] Re: ファイルロックに関する処理

Back to archive index

あき attin****@kk*****
2006年 2月 10日 (金) 10:20:10 JST


あきです。

typer殿のメッセージへの回答
----------------------------
> ファイルの内容が消えてしまう原因ですが、確かに書き込みが競合すると「一部
> 分」が消えてファイル内容が壊れてしまう可能性があります。ただ、すべて消え
> てしまう可能性の高いのは、「読み込みと書き込み」が競合する場合です。実際
> の動作で言うと、
> 
> 1. プロセスA:open(CONFIG,">$fullpath")→ファイルクリア
> 2. プロセスB:open(CONFIG,$fullpath)→空のファイルを読んでしまう
> 3. プロセスA:print CONFIG $text;→ファイル出力(実際にはclose(CONFIG)時)
> 4. プロセスB:空のデータを元に一行だけのデータを保存
> 
> と言うわけで、一番簡単な方法は読み込み時にもロックを掛けるというものです
> が、このロックは排他ロックのみですので、使用頻度が高いload_config_textに
> それをやってしまうとパフォーマンス低下が無視できなくなる気がします。

そうですね。
書き込み中に読み込まれると、欠けたデータを読み込むことになります。
そういった意味では、読み込み時にもロックをかける必要がありますね。

#言われてみれば、読み出すだけの場合は何も気にしませんが、読み書きが必要
#な場合は読み込む段階からロックをかけるようにしてました。

書き込む際に別ファイルに出力して、ファイルクローズ後にオリジナル名に
リネーム(上書き)するようにすれば、少なくとも、壊れてしまうこと(壊れた
データを読み込んでの更新)だけは防げそうですね。
もちろん、書き込みが集中した場合には先に書き込んだ方の結果が消えてしまう
可能性は残されていると思います。
ですが、全クリアされることは回避できますので、障害対策としてはこの程度
でも十分なんじゃないかと思います。

> flockの共有ロックを使えばその点はクリアできると思いますが、flockを使わず
> 実装するとなるとそこそこ面倒ですし、さらに次に上げる問題もありますので、
> 次の解決策にした方が良いと思います。

flock()を使わないのは、互換性の問題からですか?>竹添殿
私が知っている限りでは、flock()が実装されていないのは、Windows(やMac?)
の古〜いバージョンくらいで、それらは元々シングルタスクなので、

・flock()が使える場合はflock()で排他制御
・flock()が使えない場合は、排他制御そのものが不要

と割り切って考えて可、と伝え聞いていたのですが、それは誤った認識でしょう
か?(つまり、flock()をeval()で呼んで、有っても無くても動くようにする考
え)

kinsan殿のメッセージへの回答
----------------------------
> 各プラグインで別々に対処するよりは、
> ファイルロック及びセマフォに関わるライブラリーを
> 共通に使うように用意しておくか、このルーティン経由
> でアクセスしている限りではファイルロックを気にしなく
> て良いというライブラリーを用意しておく方が良いのでは
> ないでしょうか。

そうですね。私もこの考えに賛成です。

…と書いていたら、またメールが届きました。
また追ってメールします。




Fswiki-dev メーリングリストの案内
Back to archive index