問題タブ [synchronizationcontext]

TaskScheduler（良い記事はこちら）について少し読んだ後、次のTaskSchedulerことができることがわかりました：

1. タスクのスケジュール -上記の例では、選択したタスクの実行のみを行うQueueTaskメソッドを使用してPostSynchronizationContext

2. 現在実行中のフレームワーク ( ) に関連付けられている下位レベルのスケジューラを使用して、継続をスケジュールしSynchronizationContextます。

CotninueWith2. は の方法に何らかの関連がありTaskますか? 私は明らかに 1. を理解していますが、2. がどのように に当てはまるかわかりませんTaskScheduler。それはどのような方法でTaskScheduler起こりますか？

TryExecuteTaskInline の MSDN ドキュメントには、次のように記載されています。

TaskScheduler から派生したクラスは、この関数を実装して、そのタスク オブジェクトで待機を開始するスレッドでのタスクのインライン実行をサポートします。

ただし、ソースコードを見ると、の実装TaskScheduler.TryExecuteTaskInline:

現在の同期コンテキストがインスタンス化中にキャプチャされたものと同じかどうかのみをチェックします (SynchronizationContextTaskScheduler同じソース ファイルのコンストラクターを参照してください)。複数のスレッドが 1 つの同期コンテキストを共有できるため、必ずしも同じスレッドを意味するわけではありません。

したがって、ドキュメントの内容を実際に理解していないか、間違っているかのいずれかです。誰かがそれを説明できますか？

そのメソッドのドキュメントで要求されているように、この実装が「そのタスク オブジェクトで待機を開始するスレッドでのタスクのインライン実行をサポートする」方法がわかりません。タスクの ExecuteEntry を呼び出す TryExecuteTask を呼び出すだけです (メソッド名をクリックするだけで、そのソースにジャンプできます)。

https://msdn.microsoft.com/en-us/magazine/gg598924.aspx

これは素晴らしい記事です。.NET フレームワークのソース コードを貼り付ける必要があるため、すべての詳細を取り上げることができないことは承知しています。したがって、テキストを引用します：

各スレッドには現在のコンテキストがあります。"Current" が null の場合、慣例により、スレッドの現在のコンテキストは "new SynchronizationContext()" になります。

一方、しかし：

デフォルトでは、現在の SynchronizationContext は待機ポイントでキャプチャされ、この SynchronizationContext は待機後に再開するために使用されます (より正確に は、 nullでない限り現在の SynchronizationContext をキャプチャし、その場合は現在の TaskScheduler をキャプチャします)。

これらの 2 つのステートメントは互いにほとんど矛盾しているため、これは著者が行ったいくつかの単純化の結果であると考えています (私はそれで問題ありません)。

誰でもこれを説明できますか？私の質問に答えるのに役立つかもしれないコード（変数を探すsyncCtx）、このコードは2番目の引用に関連しています。

コンソール アプリケーションがあり、最初の行は Main メソッドにあります。

しかし、ここで私のアプリケーションは でクラッシュしますSystem.InvalidOperationException: 追加情報: 現在SynchronizationContextはTaskScheduler. MSDN で検索しましたが、この方法に関するドキュメントは見つかりませんでした。私は何を間違えましたか？

SynchronizationContextWinForms と WPF の GUI スレッドに同期する手段として使用しています。最近、古いスタイルの非同期コールバックに関する問題に遭遇しました。

これは例外をスローします。これはSynchronizationContext.Current、コールバック関数の がキャプチャされたものと等しいため、UI 操作がコールバックのワーカー スレッドで実行されるためです。

このまったく同じコードを WinForms で使用すると、予想どおりに機能します。

今のところ、回避策として、ManagedThreadId代わりに現在をキャプチャし、コールバックで比較しています。これを処理する正しい方法は何ですか?

アップデート：

現在、次の構成を使用している非常に古い既存のクラスを変更していることを付け加えておきます。

このクラスのクライアントに大きな影響を与えることなく、WinForms の依存関係を削除しようとしています。はSomeFunction()イベントを発生させているため、単に uiContext.Send() または uiContext.Post() を呼び出すと、Post() は常に呼び出しをキューに入れ、Send() は常にブロックするため、実行順序が変更されます。

また、これは私の問題の根本を示すための非常に小さなコードです。実際には、Post() を実行する関数はメイン スレッドから呼び出すことができます。

これは.NET 4.0を対象としています

UI スレッドでスローされた例外が呼び出しスレッドでキャッチされない場合があります。

最初に、それは不可能だと思いました (私が見つけたすべてのドキュメントは、そこで例外をキャッチできると述べています)。いくつかの再調査の後、問題が見つかりました。私のアプリケーションは UnhandledExceptionHandler を使用しています。DispatcherUnhandledException-Eventを処理します。ユーザーとセットにいくつかの情報を表示していますe.Handled = true;：

質問: DispatcherUnhandledException-Event を処理しても -Event が発生するのはなぜですか? この状況をどのように解決しますか？