平鍋です．
ファイルロックを考えていたら，XP から離れて「よい API とは」，
という視点にどうしても行ってしまいます．
On Wed, 27 Sep 2000 23:31:55 +0900,
"Tetsuya Kurihara" <kuri-t@....jp> said:
> 実は、2日ぐらい悩んでたりします(^_^;
安心しました．すらすら書けたのかと思いました．
>> 引数なしの attempt() もあるとよいですね．wait() や join()の
>> 使用と同じで，引数なしは，引数 = 0 と同じで「永遠に」を示し
>> ます．その方が java.lang.Thread/Object と対称性があって一貫
>> 性のある API になると思います．
> ？今の実装と逆ということですよね？
> 今現在は待ち時間が0以下のときは、ロックファイルが存在するときは
> タイムアウトエラーとしています。
> デッドロック状態になってしまうことはないのでしょうか？
> # ちょっと考えてみます。
ごめんなさい，少し早合点してコメントしてしまったようです．
おっしゃる通り待ち時間 0 ならタイムアウトすべき気もしてきま
した．引数無しの attempt() の仕様として，
1) ロックが取れなければ取れるまで待つ
2) ロックが取れなければ即時エラー
どちらも用途がありそうです．引数無しの attempt() を作るとし
て，どちらが自然ですかね．
>> ＃ う〜ん，やはり util というか，汎用的なクラスを作る時，そのAPIは
>> ＃ YAGNI ではいかんだろうなぁ，と思っている自分を発見しています．
> 駄目ですね(^_^;;
> なんか自分のセンスを推し量られるような気がして気合が入ります:-)
そんな意味じゃないです(^^;)．結構 API には拘る自分は，XP 的
ではないなぁ，という自戒です．
>> 2) 私は，以下のほうが好きです．
>>
>> Mutex mutex = new Mutex("lock");
>> try {
>> mutex.attempt(100000);
>> // 原子的に行われる処理
>>
>> } catch (MutexException e) {
>> // ロック獲得に失敗！
>> } finally {
>> mutex.release();
>> }
>>
>> release() が，取得できなかったロックに対しても無害になること
>> を利用して(C++ の delete の仕様と似ている)，try ブロックネス
>> トを減らせます．また，必ず attemptを含む try ブロックの
>> finaly にrelease を書け，と言う風にスタイルを強制しやすい仕
>> 様と思います．
> これなんですが、ファイル名でロックの種類が決定するために、もしファ
> イルロックに失敗したときでもファイルを削除してしまうと、別プロセスが
> 作成したロックファイルを削除しかねない実装の気がします。
ぐげ．確かにそうですね．撤回します．内部状態に依存するのは嫌
ですよね．
栗原さんが最初に書かれた，
Mutex mutex = new Mutex("lock");
try {
mutex.attempt(100000);
try {
// 原子的に行われる処理
} finally {
mutex.release();
}
} catch (MutexException e) {
// ロック獲得に失敗！
}
の方が確かによい気がしてきました．
> FileLockクラスの内部状態に依存しないかたちで実装したのですが、
> ロックファイルの作成にしたときの状態によって分岐させるようにしまし
> ょうか？
> # 例外発生時に、lockFileフィールド値をnullにする？とか。
これもいいですね．しかし，そこまですべきか，という気もします．
以上