| ■65782 / inTopicNo.12) | Re[3]: ExecutionEngineExceptionについて |
| ■No65780 (もんた さん) に返信 > 上記のBeginInvokeは単なる予防ですね。 > それと個人的にまずそうな部分を見つけたのですが、BeginInvoke内でInvokeを呼び出すのはまずいでしょうか？ > 上記のBeginInvoke内でウィンドウの描画部分だけDispatcher.Invokeを呼び出すようにしています。 > （WPFではUIスレッド以外からコントロールを操作できないため） > Dispatcher.BeginInvoke() は、渡したデリゲートをDispatcherを作るときに指定したスレッドコンテキスト上で呼び出し時とは異なるタイミングで実行します(一般的にこの異なるタイミングでの実行を非同期的に実行するといいます)。 Dispatcher.Invoke() は、渡したデリゲートをDispatcherを作るときに指定したスレッドコンテキスト上で呼び出したタイミングで実行します。もちろん処理が終了するまで戻ってきません。 で、サンプル的に書かれているコードですが、 lock (lockObj) で、渡しているこのlockObjは、呼び出す先のコンテキストと同期させたいために用意したものではありませんか？ そのタイミングで、非同期的に呼び出しを行っているにもかかわらず(BeginInvoke) 終了を待機する(op.wait) ということをしています。 時々例外を吐き出すのとは別にデッドロックになっているタイミングがかなりの頻度で発生しうる気がするんですが。。。 ExecutionEngineException が、デッドロック時に発生するかはわかりませんが おそらく、現状の上記処理を行うのなら、 Dispatcher.FromThread(_thread).Invoke( <TestMethodから、Invokeしている先のデリゲート> ); としてやれば、おそらくほかの処理は全く必要ないと考えます。 スレッドコンテキストに絡む排他制御はほとんどの場合5Wがきちんと把握できていないことに起因します。 いつ(when)、どこで(where)、だれが(who)、なにを(what)は(5W1HのうちのWhy,howを除く４つ)、複数同時に実行する場合非常に重要です。 もちろん、lockObj で排他制御している部分が何かわからないので本当にこれが正しいかはわかりません。 もしかしたら、単に BeginInvoke でよくて、非同期のままでいいのかもしれません。 このあたりは、なぜ(why)、どうやって(how)マルチスレッド化したのか?という部分がわからない以上、だれも回答を持ちえない どころか、ヒントになるような情報すら提供できないといえます。 |