From: matz@... (Yukihiro Matsumoto)
Date: 1997-01-31T14:10:08+09:00
Subject: [ruby-list:1992] Re: Mutex_m

まつもと ゆきひろです．

In message "[ruby-list:1991] Mutex_m"
    on 97/01/31, Keiju ISHITSUKA <keiju@shljapan.co.jp> writes:
|
|けいじゅ＠SHLジャパンです. 
|
|Mutexのモジュール版(Mutex_m)を公開します. モジュールはmutex_m.rbのまま
|でもいいですし, thread.rbに入れて下さってもかまいません.

とりあえず mutex_m.rbで追加しておきます．

|あと, メソッド名の競合についてはまだ対応していません. 名前が一般的なの
|で気になるは気になりますので, ある程度の競合の対応に関しては,
|object_extendの仕様が変更され次第対応しようと思っています.

これもどういう仕様にするのかかんがえないといけませんね．
extendするより先に呼んだ方が良いのかなあ．

|質問:
|[1] lockについて

|whileのなかで Thread.critical = TRUEをしたまま Thread.stopしますが,
|Thread.stopすると, Thread.criticalはFALSEになるものなのですか? それと
|も, この状態はThread毎に持っている?

Thread.stopするとcriticalはFALSEになります．これは分かりにく
い仕様ですが，こうしないと面倒な問題が回避できなかったので高
なってます．threadは難しい．

|[2] Thread.critical = TRUE
|としなくては行けなくなるのはどういう時なのでしょう? つまり, スレッドの
|スイッチの粒度はどのくらいなのでしょう? 
|
|それとかかわるのですが, 共有オブジェクトにアクセスする時には必ず
|Thread.critical = TRUEとしなくてはいけない? それとも書き込む時だけでしょ
|うか?

基本的に共有オブジェクトへのアクセスは保護する必要があります．
読み出しの場合は書き込みほどシビアではないですが，信頼性が低
くなります(取り出した値が次の瞬間には変わっているかも知れな
い)．

|  def locked?
|    Locked.key?(self.id)
|  end
|
|がありますが, 問題ありますか?

たぶん．ないです．というのもlocked?というのは本質的に信頼性
が低いからです．

|[3] lockのタイムアウト
|これはMutexの仕様にも関わるのですが, lockのタイムアウトも指定できた方
|が嬉しい時もあると思うのですが... 実現は面倒ですね(^^;;;

そうですねえ．threadのプライオリティ同様将来への課題ってとこ
ろですか? 当面，実装の予定はないです．

                                まつもと ゆきひろ /:|)