[過去ﾛｸﾞ] マルチスレッドプログラミング相談室 (986ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
98(2): 01/10/14 00:44 AAS
>>94
>2についてはsynchronizedで待っているスレッドは原則として中断できない。
>(Thread#stopで停止はできるが、これは危険!)
Thread#stopで、lockの獲得を待っているスレッドを停止できる、とは言えないのでは？
例えば、スレッド１がロック１を持ち、スレッド２がロック２を持っていて、
スレッド１がロック２を獲得しようとして、同時にスレッド２がロック１を獲得しようと
する、いわゆるデッドロックの状態で、別のスレッドからスレッド１のstopを呼んでも、
スレッド１は停止(中断)しない。結局、デッドロックは解消しない。
元の問いが、synchronizedで待っているスレッドを中断する、ということだから、これは
stopでもできないというのが正解では？
mutexなどの利用については、その通りだと思うけど。
101(1): 01/10/14 10:32 AAS
>>98
もしかして、デッドロックが起こるような状況でしか
synchronizedで待つことはないと思ってる?
102: 98 01/10/14 11:34 AAS
>>101
何かお互いに誤解があるようだね。
漏れは、「synchronizedで待つ」、の意味を、例えば、
synchronized void doSomething(){}
というメソッドをあるスレッドが実行しようとして、thisのロックを他の
スレッドが持っているために、待たされている状況を想定している。
もちろん、ロックを持っているスレッドが、そのロックを手放せば、問題ないけど
そうでない場合に、どうか、ということ。
それ以外に、synchronizedで待つことを、問題にする理由がわからない。
synchronizedがロックの獲得を待つのは、問題、ではなく仕様。ただし、
タイムアウトの手段はない。例え推奨されないstopメソッドでもね。
デッドロックの例をあげたのは、この点を理解しやすいと思ったからだよ。
それを問題として捉えるかどうかだけど、タイムアウトが必要な場合は、
mutexとかで対応すればいい。
逆に、synchronizedの手軽さは、javaのメリット、というのが漏れの判断。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s