問題タブ [synchronizationcontext]

ASP.Net MVC と WebAPI プロジェクトがいくつかあります。それらのほとんどは最新です (MVC 5 / WebAPI 2)。システム全体のセキュリティを統一するためにグローバル フィルター (MVC 用) と委任ハンドラー (WebAPI 用) を実装しているので、セキュリティの前提を再確認してきました。

その文脈で、私はいくつかの記事や投稿 (以下を参照) に出くわしました (以下を参照UseTaskFriendlySynchronizationContext) 。MVC 5 および WebAPI 2 の新しいプロジェクト テンプレート (および ASP.Net WebForms テンプレート) を使用する VS2013 でも、このアプリ設定がまったく設定されていないため、これは奇妙に思えます。truefalse

この設定に関する MSDN ドキュメントは実質的に存在せず、非同期プログラミングに必要であると述べている投稿は、WebForms のコンテキストにあるようです。

だからここに私の質問があります：

1. この設定はすべての ASP.Net に適用されますか、それとも ASP.Net のページ ライフサイクルに固有のものですか (あまり使用していません)。
2. 最新の非同期プログラミングにとって非常に重要である場合、チュートリアルやテンプレートで参照されないのはなぜですか?
3. ConfigureAwait(false) を使用する参照ライブラリで Thread.CurrentPrincipal のクレームを使用すると、問題が発生しますか、それとも ExecutionContext の論理呼び出しコンテキストの流れによって処理されますか? （これまでの私の読書とテストは、そうであることを示しています）

に関して私が見た記事のいくつかを次に示しますUseTaskFriendlySynchronizationContext。

• Thread.CurrentPrincipal を非同期に設定しますか?
• MSDN の ASP.NET appSettings 要素
• 「UseTaskFriendlySynchronizationContext」の意味は何ですか?
• SynchronizationContextMarcus van Houdt による ASP.NETの理解
• Thread.CurrentPrincipal が正しくフローするために「await Task.Yield()」が必要なのはなぜですか?

このすべてがどのように機能するかを理解するのに本当に役立ったいくつかの記事は、言及されていませんUseTaskFriendlySynchronizationContext:

• Stephen Toub による ExecutionContext と SynchronizationContext の比較
• SynchronizationContext がすべてです by Stephen Cleary

SynchronizationContext.Current.NET 4.0 のメイン スレッドで が予期せず nullになる問題の回避策は何ですか? 見る：

• メイン UI スレッドの継続で SynchronizationContext.Current が null である

私のチームは、C# 5.0 で async/await を使用してマルチスレッド アプリケーションを開発しています。スレッド同期を実装する過程で、何度か繰り返した後、次のような内部ロックを備えた新しい SynchronizationContext 実装にたどり着きました。

1. Post を呼び出す場合:
   • ロックを取得できる場合、デリゲートはすぐに実行されます
   • ロックを取得できない場合、デリゲートはキューに入れられます
2. Send を呼び出す場合:
   • ロックを取得できる場合、デリゲートが実行されます
   • ロックを取得できない場合、スレッドはブロックされます

いずれの場合も、デリゲートを実行する前に、コンテキストはそれ自体を現在のコンテキストとして設定し、デリゲートが戻るときに元のコンテキストを復元します。

これは珍しいパターンであり、そのようなアプリケーションを作成したのは明らかに私たちが最初ではないので、私は疑問に思っています:

1. パターンは本当に安全ですか？
2. スレッド同期を実現するためのより良い方法はありますか?

SerializingSynchronizationContext のソースとGitHubのデモを次に示します。

使用方法は次のとおりです。

• 保護が必要な各クラスは、ミューテックスのようなコンテキストの独自のインスタンスを作成します。

• コンテキストは awaitable であるため、次のようなステートメントが可能です。

  await myContext;

  これにより、残りのメソッドがコンテキストの保護下で実行されるようになります。

• クラスのすべてのメソッドとプロパティは、このパターンを使用してデータを保護します。await の間では、一度に 1 つのスレッドのみがコンテキストで実行できるため、状態は一貫したままになります。await に到達すると、次にスケジュールされたスレッドがコンテキストで実行できるようになります。
• 待機中の式でも原子性を維持する必要がある場合は、カスタム SynchronizationContext を AsyncLock と組み合わせて使用​​できます。
• クラスの同期メソッドは、保護のためにカスタム コンテキストを使用することもできます。

彼の回答で Stephenは、 が呼び出されたときConfigureAwait(false)にメソッドの残りの部分がスレッド プール スレッドで実行されることを説明Taskしましたawait。

明確なこと:ConfigureAwait(false)非同期呼び出しの後に実行されるすべてのものを使用すると、スレッド プール スレッドで実行されるため、UI SynchronizationContext では実行されませんtextBox1.Text = data.Property。

私が理解していないのは、メソッドが実行される前に、私が待っていることが常にawait完了するという意味ではありませんか? では、タスクを続行する前に完了できないのはなぜでしょうか?Task

私は英語が苦手なので、質問を簡単に説明し、ここにコード スニペットを貼り付けて問題を説明します。

問題は、winForm アプリケーションのマルチスレッドの問題です。次のコードサンプルのようにロジックを単純化します。

テスト コードには、1 つの mainForm Form1 と、mainForm 内に「Start」という名前のボタンがあります。ユーザーがボタンをクリックすると、2 つのフォーム form2 と form3 が 2 つのバックグラウンド スレッドから表示されます。form2 が閉じられた後、Form1 が閉じられます。ただし、ここには form3 が表示されているため、ユーザーが自分で form3 を閉じる必要があります。そこで、form.Closing イベントを処理し、Application.DoEvents() を使用して、ユーザーが form3 を閉じられるようにしました。それは念頭に置いているように見えます。しかし実際には、form3 はユーザーのアクションを受け入れることができますが、form3 は期待どおりに閉じられません。

ここで form3 を閉じることができない理由と、ユーザーの閉じる操作が機能するようにコードを変更する方法を説明してください。