問題タブ [synchronizationcontext]

オブジェクトでコールバックを使用してSynchronizationContext、WCF サービスからクライアント UI を更新しています。

私が使用するコードパターンは次のとおりです。

このPostメソッドは、デリゲートと状態オブジェクトを受け入れます。他にサインはありません。

私は匿名メソッドを使用しているため、次のように書く傾向があります。

なぜなら：

• 短いです
• キャストを惜しまない
• ローカル変数を宣言する必要はありません

それは機能しますが、2番目のアプローチにはどのようなリスクが伴うのでしょうか.

これは安全と見なされますか? 結果パラメーターは、後続の呼び出しによって何らかの形で「破損」する可能性がありますか?

WinRT CoreDispatcher には、実際には状態変数を取らない RunAsync メソッドがあります。

翻訳: ほとんどの一般的なシナリオで Dispatcher に投稿することによって発生するすべての通知は、閉鎖のために内部的に割り当てられます。シンプルで重要なデザインが見落とされていることは非常に懸念されます。

例: INotifyPropertyChanged を実装する単純な一般的な例では、次のような結果になるメソッドが必要です。

現在、単純なプロップ変更通知が呼び出されるたびに、舞台裏でコンパイラによって新しいクラスが割り当てられますが、これは多くの通知にとってひどいことです。これにより、SynchronizationContext.Post にフォールバックします。これは、ハンドラーに状態変数があり、propertyName を一緒に渡すことができることを考慮すると、多くの通知がある場合により効率的なオプションです。

このシナリオで Dispatcher を使用する方法についての提案や考えは大歓迎です。

次の Windows フォームのコードを検討してください。

ここでは、待機後にコードが非 UI スレッドで実行されるため、3 行目で例外がスローされます。ConfigureAwait(false) はどこで役立ちますか?

SynchronizationContext一部の操作をシリアル化し、同じスレッドで実行するために (アプリケーションによって提供される) に依存するライブラリ コードがあります。このライブラリ コードは、それが実行されるアプリケーションに依存しません。

ただし、 の一部の実装のみSynchronizationContextがこれWindowsFormSynchronizationContextをDispatcherSynchronizationContext行います。

SynchronizationContextベース自体のような他の実装AspNetSynchronizationContextはフリースレッドです。操作のシリアル化は行いません。

コードに が渡された場合、SynchronizationContextこれら 2 つのケースをどのように区別できますか? 同期コンテキストが適切でない場合、明確なエラーですばやく失敗するようにします。

従来の MVVM パターンで実装された WPF アプリケーションがありますが、View、Model、ViewModel は私のソリューションでは 3 つの異なるプロジェクトです。

ViewModelにAsyncObservebleCollectionのよく知られた実装があります

bq.QueueTask(this.ExecuteCommand) -> backgroundWorker はバックグラウンド スレッドでコマンドを実行しており、ビューに入札されている Messages プロパティを更新します。

現在、AsyncObservebleCollection には UI の SynchronizationContext がないため、スレッド違反の例外が発生しています。また、ViewModel が View について認識してはならないことがわかっているため、問題を解決するにはどうすればよいですか? UI の SynchronizationContext を使用して RelayCommand を非同期に実行し、UI を更新するにはどうすればよいですか?

ありがとうございました

ホスト アプリケーションがイベント ループを実行し、ゲスト アプリケーションを別のアプリケーション ドメインにロードするカスタム フレームワークがあります。ゲスト アプリケーションには、提供された API を介してイベント ループを利用する手段があります。.NET GUI アプリケーションや UI スレッドで行われるように、ゲスト アプリケーションがすべての継続をイベント ループに自動的に伝達できるようにしたいと考えています。したがって、それが可能なカスタム同期コンテキストを作成します。

しかし問題は、この新しいコンテキストを使い始めることができないことです。設定しようとするとnull、アプリ ドメインの境界を越えた次のコールバックでリセットされます。

問題を説明するための簡単なコード スニペットを次に示します。

出力：

SynchronizationContext.SetThreadStaticContextデスクトップで利用できる場合、上記の問題を潜在的に解決できるこの方法もあります。

もちろん、他の作業を行う前に、各コールバックでコンテキストを明示的に設定する方法が常にあります。しかし、それは少しお粗末なようです。それに加えて、このニワトリが先か卵が先かという問題を解決するエレガントな方法が見当たりません。ちなみに、Monoでは期待どおりに動作します。