問題タブ [synchronizationcontext]

SynchronizationContextクラスを使用して、UI 更新のクロススレッド マーシャリングを実行する予定です。Application.Run(form)アイデアは、私が言えるように、メイン フォーム (つまり のフォーム) への参照を持たなくても済むようにすることです。mainForm.BeginInvoke();

ただし、ドキュメントから明確でないことの 1 つは、 を呼び出すときにSynchronizationContext.Post()、どのスレッドへの呼び出しをマーシャリングするかということです。それは常にメイン アプリケーション スレッドSynchronizationContextですか、それともオブジェクトを最初に初期化したスレッドですか、それとも何ですか?

COMコンポーネントを使用するC＃アプリケーションがあります。このCOMコンポーネントは、その処理を行うためにメッセージポンプ（Application.Run（））を必要とします。これは、メインスレッドでスタックしていることを意味します。しかし、最近、別のApplication.Runを、独自のApplicationContextを取得する別のスレッドで開始できることを発見しました。

そのため、COMコンポーネントを独自のApplication.Run（）内の独自のスレッドでホストしたいのですが、UIフォームを作成せずに、新しいスレッドで作業を開始する方法を理解できません。

スレッドと通信する必要があるWindowsFormsSynchronizationContextは、Application.Run（）まで作成されません。しかし、Application.Run（）が呼び出されると、SynchronizationContextを取得する方法がわかりません。そのスレッドで単一のイベントを発生させることができれば、それを使用して全体をブートストラップすることができます（COMオブジェクトの作成など）が、フォームなしで新しいイベントループにフックする場所はないようです。 。

メッセージフィルターのインストール（新しいスレッドでメッセージが発生しない）、実行コンテキストを別のスレッドにコピーし、そこからSynchronizationContextを取得しようとする（のExecutionContextのコピーを拒否する）など、あらゆる種類の複雑なことを試しました。すでにスレッドを実行している）、Application.Run（）を開始する前にThread.CurrentContextを取得し、DoCallbBack（）を呼び出す（DoCallbackは元のスレッドで終了します）など。私が試したことは何も機能しません。

Windows Workflow 4.0 で使用するSynchronizationContextの STA バージョンを作成しています。コールバックを Post-ing するときの例外についてどうするか疑問に思っています。

SynchronizationContextは、タイプSendOrPostCallbackのデリゲートを送信(同期的に実行) またはポスト(非同期的に実行) するために使用できます。どちらの場合も STA スレッドでデリゲートを呼び出しますが、同期的に実行するときに例外を処理する方法は簡単にわかります。呼び出しスレッドをブロックし、ワーカー スレッドでコールバックを呼び出し、例外を記録し、呼び出しスレッドのブロックを解除し、記録された例外を呼び出しスレッドでスローします。

非同期Postで何をすべきかはあまり明確ではありません。その例外を実行中のスレッドから呼び出し元のスレッドに転送するメカニズムはありません。投稿は 100% 着火して忘れます。SendOrPostCallback にはEndInvoke ()またはWaitHandleはあり ません。例外がスローされると、アプリケーションが破棄されます。

Postでスローされた例外によってアプリケーションが破棄される以外に選択肢はありませんか? これは、フレームワークのSynchronizationContextsのデフォルトの動作のようです (Reflector さん、ありがとうございます)。これがなぜなのか理解できないようです。非同期のPostがブームになるのを防ぐ方法はあるのではないでしょうか?

私はちょうどこのコードを書いた：

しかし、System.Threading.SynchronizationContext.Current は null です

私はSynchronizationContextを使用して、多くのマルチスレッドバックグラウンドタスクを実行するDLLからUIスレッドにイベントをマーシャリングします。

シングルトンパターンがお気に入りではないことは知っていますが、今のところ、fooの親オブジェクトを作成するときにUIのSynchronizationContextの参照を格納するためにそれを使用しています。

これはWPFではまったく機能しませんでした。TheUISyncインスタンスのUI同期（メインウィンドウからのフィード）が現在のSynchronizationContext.Currentと一致することはありません。Windowsフォームでは、同じことを行うと、呼び出し後に一致し、正しいスレッドに戻ります。

私が嫌う私の修正は、次のようになります

したがって、このサンプルが十分に理解できることを願っています。

Functional Programming For Everyday .NET Developmentでの Jeremy Miller の優れた作業のおかげで、必要なことすべてを実行するコマンド エグゼキュータが動作しています (スレッド プールで重い処理を実行し、結果またはエラーを同期コンテキストに送り返し、さらにポストすることさえできます)。同期コンテキストに戻ります)、しかし、スレッドプールからSynchronizationContext.Sendを使用し、重い作業を行うメソッドに渡されたSynchronization.Postを使用する理由を説明できません。Funcドキュメントを何度か読んだことがありますが、違いが何であるかについての直感を得ることができません。Send1 つが呼び出され、もう 1 つが呼び出されるという事実から、私は何を得るべきPostでしょうか? 私は魔法が実際にあると感じますSend「同期要求を開始する」およびPost「非同期要求を開始する」が、両方の要求がスレッド プールから送信され、UI スレッドに送信/ポストされる必要があります。

誰かが違いを説明できますか?それは、どちらをいつ選択するかを知らせる単なるニーモニックデバイスであっても?

重要な場合に備えて、これは進行状況を UI に戻すために使用するテスト コードです。Post

その_ExecuteCommandメソッドは、command以下のパラメーターとして渡されます。ほとんどは元の記事からのもので、Send完了メッセージとエラー メッセージを UI に送り返すために使用されます。

Can somebody tell me when to use a Dispatcher and when to use the SynchronizationContext class?

For a while now I have been using the Dispatcher to queue up tasks from a background thread, then I discovered the SynchronizationContext.

Dispatcher（.net 3.0）をWindowsサービス（.net 2.0で実行）に使用するための代替手段が必要です。そのようなことを達成する方法を教えていただけますか、それともリンクを教えていただけますか？

ディスパッチャにSynchronizationContext遅れがあることは知っていますが、サービスにどのように使用できるかわかりませんSynchronizationContext。

Dispatcher（.net 3.0）に固執する必要があると思われる場合...どうすれば操作できますか（ OnServiceStop、OnServiceStart）

編集済み： 詳細（...こちらも参照）

アイデアは、メソッドを介して相互に通信するいくつかの拡張機能/プラグインをWindowsサービスにホストしたいということExecuteCommand(type, params)です。

このメソッドは、プラグイン内から実行された場合に結果を受け取るために、サービスにイベントを発生させます。各プラグインは、このメソッドを呼び出す場所から独自のスレッドを持つことができるExecuteCommandため、結果を適切に返すために、すべての呼び出しを1つのスレッド（メインサービススレッド）に集めて同期させたいと思います。

これが、Dispatcherが登場した理由です。しかし、おそらく.net 2.0に何かを入れたいのですか、それとも私の場合はDispatcherが良いと思いますか？

ありがとう。

私は次のコードを持っています：

Post()このコンテキストのメソッドを呼び出すため、最後のメソッドが最初のスレッド、つまりSynchronizationContextが取得される最初のスレッドで実行されることを期待しています。つまり、次のようなものです。

それはSynchronizationContextの意味ではありませんか？しかし、実際には次の出力があります。

何が問題ですか？彼らはSynchronizationContextに何か問題がありますか、それとも私はいくつかの誤解を持っていますか？

更新：このメソッドを、Resharperテストランナーを使用した単体テストと呼びます。

SynchronizationContext与えられたものを取得する方法が見つからないようですThread：

なぜそれが必要なのですか？

フロントエンドアプリケーション全体のさまざまな場所からUIThreadに投稿する必要があるためです。そこで、。というクラスで静的プロパティを定義しましたUIConfiguration。このプロパティをProgram.Mainメソッドで設定します。

その瞬間、正しいスレッドがあることを確認できますが、次のような静的プロパティを設定することはできません。

そのクラスのWinForms実装はまだインストールされていないためです。Thread各スレッドには独自のSynchronizationContextがあるため、特定のオブジェクトからスレッドを取得できる必要がありますか、それとも完全に間違っていますか？