- PR -

Forms.Control継承型のファイナライゼーション

«前のページへ 1|2|3
投稿者投稿内容
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2007-01-12 20:48
引用:

Window は，作成されたスレッドからしか破棄できない(できるのかな?)ので，


廃棄できるはずだと思ってましたが、DestroyWindow() のヘルプには「別スレッドのウィンドウを廃棄できない」とありますねぇ。

ただし、User32 や Gdi32 には、ヘルプには「ｘｘｘしてはならない」と説明されているにも関わらず、稀に Windows 自身や M$ 社製アプリに、思わず「やってんだろ！？」と突っ込みたくなるような動きをしてる場面があったりするわけですが。


[ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2007-01-12 21:09 ]
yayadon
常連さん
会議室デビュー日: 2003/07/23
投稿数: 41
投稿日時: 2007-01-14 06:31
finalizeメソッド内でlockすると，
すでにロックされた状態だと，
finalizer thread が待機状態になってしまいます。

で，よく考えたら，

引用:

なちゃさんの書き込み (2007-01-12 11:49) より:

これは、lockなどでロックされている箇所でも、同じオブジェクトをロックする、
後から来た優先度の高いスレッドによって、割り込まれる可能性があるということ
でしょうか？


すみません，自分が誤読して，

　すでにロック済みの状態でも，finalizer thread の方が優先される

のように書いてしまっていました。

引用:

稍丼さんの書き込み (2007-01-12 14:59) より:
一応
Threading Model
の部分の Reentrancy and Locking の箇所をよりどころにしています。

簡訳:

CLRのロック機能は，皆さんが予想するのとはちょっと違った振る舞いをします。
ロックを要求する時，スレッドは実行を完全に止めると思うでしょう。
実際は，そのスレッドは，high priorityメッセージを受け続け処理続けます。


すみません，訳が間違っていました。

引用:

ロックを要求する時


は，when requesting a lock となっているんですが，補うと，

　when the thread is requesting a lock

となり，

　その該当のスレッドがロックを要求している時

さらに，正確に訳すと，

　その該当のスレッドがロックを要求しているその状態の時

でした。
つまり，ロックに関しては，

sync block index を見に行き，負の数(-1) なのを確認し，
sync block配列 から 空いている sysc block を確保し，
その index を sync block index に設定

というごく限られた間で，
finalizer thread からのお願いが割り込んできて，
UI thread側は，それに即座に反応してしまう可能性がある。

ということでした。
(また，finalizer thread 側がロック可能になるという話しではない)

リンク先のページにある図の表現とも一致するのでそういうことでしょう。


WPF では，即座に反応しないように，
ロックを要求しに行って，実際に要求が完了されるまでは，
Dispatcher queue を止めておく? ために DisableProcessing というものを呼ぶ場面がある。
(reentrancy-free lock : reentrancyのないロック)

という流れになっています。


[ メッセージ編集済み 編集者: 稍丼 編集日時 2007-01-14 09:06 ]
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）