平鍋です．
On Wed, 27 Sep 2000 20:06:05 +0900,
tetsuya@....jp said:
> 栗原です。
> 自分で、ファイルのロックが必要と懸念点をあげているならば、
> その懸念を払拭してから進むべきですよね。
> # 不明点を明らかにしないとタスクを見積もれませんから。
> で、並行処理時のファイルロックユーティリティを作ってみました。
すばらしい．非常に美しいですね．(XP では美しさに惚れるのは禁物ですが)
幾つかコメントさせてください．
1) これは栗原さん自身もおっしゃってますが，Mutex という名前
がすこし一般的すぎると思います．割り切って，FileLock という
ほうがより具体的でよい気がします．プロセス間(inter-VM)同期に
使える，ということを示している名前を選ぶほうがよいでしょう．
また，Doug Lea の util.concurrent パッケージのクラス名とも
バッティングしますし．
＃ そういえば，Doug Lea の Concurrent Programming in Java,
＃ 2nd Edition という名著の日本語訳が出てますね．
＃ Doug Lea は JDK1.2 Collection が出る前に独自の
＃ collectionsパッケージを実装したり，ソフトウェアパターンの
＃ FAQを書いたり，今年の OOPSLA の program chair をしたり，
＃ C 言語の malloc 実装を書いたり，というスーパーな人です．
> attemptメソッドで、ロックファイルの作成を試みます。
> 引数には、ロックファイル作成までの最大待ち時間をミリ秒単位で指定
> します。
> もしも待ち時間を過ぎても、別プロセスによって作成されたロックファ
> イルが存在しているときは、例外AttemptTimeOutExceptionが投げられ、
> ロックが失敗します。
引数なしの attempt() もあるとよいですね．wait() や join()の
使用と同じで，引数なしは，引数 = 0 と同じで「永遠に」を示し
ます．その方が java.lang.Thread/Object と対称性があって一貫
性のある API になると思います．
＃ う〜ん，やはり util というか，汎用的なクラスを作る時，そのAPIは
＃ YAGNI ではいかんだろうなぁ，と思っている自分を発見しています．
> Mutex mutex = new Mutex("lock");
> try {
> mutex.attempt(100000);
> try {
> // 原子的に行われる処理
> } finally {
> mutex.release();
> }
> } catch (MutexException e) {
> // ロック獲得に失敗！
> }
2) 私は，以下のほうが好きです．
Mutex mutex = new Mutex("lock");
try {
mutex.attempt(100000);
// 原子的に行われる処理
} catch (MutexException e) {
// ロック獲得に失敗！
} finally {
mutex.release();
}
release() が，取得できなかったロックに対しても無害になること
を利用して(C++ の delete の仕様と似ている)，try ブロックネス
トを減らせます．また，必ず attemptを含む try ブロックの
finaly にrelease を書け，と言う風にスタイルを強制しやすい仕
様と思います．
＃ う〜ん，やはり API は美しく，と考える自分がいます．
＃ XP っぽくないですね．
> 並行処理のテストの良いアイデアは何かありませんでしょうか？
> アドバイスお願いします、識者の方々。
確か，JUnit のドキュメントに並行性テストに関する記述がありま
したが，どなたかご存知ないですか?
以上