From: kjana@... (YANAGAWA Kazuhisa)
Date: 2001-07-04T21:08:51+09:00
Subject: [ruby-list:30464] Re: Mutex

In message <87y9q5a33h.wl@studly.priv.netlab.jp>
shugo@ruby-lang.org writes:

> > 現在のMutexの仕様は変えられないですかね。
> > 仕様を変えるのがまずいなら、別の名前でも良いからあるといいなー。
> 
> monitor.rbではだめですか?
> # 名前が違うだけでほとんどMutexと同じです。

sync.rb も同じようにつかえますね．おまけに reader/writer lock がついて
きますけど．....どっちがおまけやねん :-) っていうか，Sync は reentrant
reader/writer lock だっていう話．

# むかし [ruby-talk:02927] なんてかいたけど，Monitor の説明は generic
# 過ぎるし Sync が reentrant なのは書くの忘れてる....


> 普通、mutexという名前が付くものは、ロックしているスレッドで再びロッ
> クするとデッドロックするものみたいです。
> # 並列オブジェクトでも、自分自身にメッセージパッシングするとデッド
> # ロックしてしまうというのは驚き。(fj.comp.parallel)

一度に一つのメッセージを処理っていう動作を想定すると実は自明 :-) 他の
メッセージはともかく，自分が返事を待ってるメッセージの末は別に受け取っ
て処理しないといけないっていう話ですね．

オブジェクト内で並列性がある場合は結局ふつうの問題におちる．


それでまあ，別の受取口を用意してみたり，鍵をもたせてやったり，一連の
メッセージ/処理をスレッドととらえた上で親子関係までわかるようなスレッ
ド識別子をつけたりしてみたりすればまあ何とかなると．

# それで何とかならないところは monitor 風に待ってやればいい，のか?


....なんていう，どこかで読んだような，っていうか書いてたらどうも参考文
献のやり方の方が良さそうにみえてきた :-P 論文を思いだしたり．

# あっちは親スレッドをおぼえておくようにするだけで，メッセージを膨らま
# せないで簡単にできるんだもんなぁ....


-- 
柳川和久 @ 東大阪市 . 大阪府                                   July 4, 2001
Abstract should not be abstract.