すべてのサーバー側コードに対してConfigureAwaitを呼び出すベストプラクティス

サーバー側コード（つまり一部ApiController）があり、関数が非同期であるため（それらが返さTask<SomeObject>れる場合）、呼び出す関数を待機するときは常にベストプラクティスと見なされますConfigureAwait(false)か？

スレッドコンテキストを元のスレッドコンテキストに戻す必要がないため、パフォーマンスが向上することを読みました。ただし、ASP.NET Web Apiでは、リクエストが1つのスレッドで受信され、関数ConfigureAwait(false)の最終結果を返すときに別のスレッドに入る可能性がある関数と呼び出しを待機している場合ApiController。

私が話していることの例を以下に入力しました：

public class CustomerController : ApiController
{
    public async Task<Customer> Get(int id)
    {
        // you are on a particular thread here
        var customer = await SomeAsyncFunctionThatGetsCustomer(id).ConfigureAwait(false);

        // now you are on a different thread!  will that cause problems?
        return customer;
    }
}

更新： ASP.NET CoreにはがありませんSynchronizationContext。ASP.NET Coreを使用しているConfigureAwait(false)場合は、使用するかどうかは関係ありません。

ASP.NETの「フル」または「クラシック」などについては、この回答の残りの部分が引き続き適用されます。

元の投稿（非コアASP.NET用）：

ASP.NETチームによるこのビデオには、ASP.NETでの使用asyncに関する最良の情報が含まれています。

スレッドコンテキストを元のスレッドコンテキストに戻す必要がないため、パフォーマンスが向上することを読みました。

これは、「同期」する必要があるUIスレッドが1つしかないUIアプリケーションにも当てはまります。

ASP.NETでは、状況は少し複雑です。ときにasyncメソッドが実行を再開し、それがASP.NETスレッドプールからスレッドをつかみます。を使用してコンテキストキャプチャを無効にすると、ConfigureAwait(false)スレッドはメソッドの直接実行を継続します。コンテキストキャプチャを無効にしない場合、スレッドは要求コンテキストに再度入り、メソッドの実行を続行します。

したがってConfigureAwait(false)、ASP.NETでのスレッドジャンプを節約できません。リクエストコンテキストを再入力する必要はありませんが、通常は非常に高速です。ConfigureAwait(false) 可能性がありますが、要求の並列処理の少量をしようとしているが、実際TPLは、これらのシナリオのほとんどのためのより良いフィット感がある場合に便利です。

ただし、ASP.NET Web Apiでは、リクエストが1つのスレッドで受信され、ApiController関数の最終結果を返すときに、いくつかの関数を待ってConfigureAwait（false）を呼び出すと、別のスレッドに入る可能性があります。 。

実際には、それを行うawaitことができます。あなたいったんasyncメソッドがヒットしawait、この方法は、ブロックされたが、されたスレッドは、スレッドプールに戻ります。メソッドを続行する準備ができると、すべてのスレッドがスレッドプールから奪取され、メソッドの再開に使用されます。

ConfigureAwaitASP.NET の唯一の違いは、メソッドを再開するときにそのスレッドが要求コンテキストに入るかどうかです。

MSDNの記事SynchronizationContextとasync紹介ブログの投稿に、より多くの背景情報があります。

あなたの質問への簡単な回答：いいえConfigureAwait(false)。そのようなアプリケーションレベルで呼び出すことはできません。

長い答えのTL; DRバージョン：コンシューマーを知らず、同期コンテキストが必要ないライブラリーを作成している場合（これは私が信じているライブラリーには必要ありません）、常にを使用する必要がありますConfigureAwait(false)。そうしないと、ライブラリのコンシューマは、非同期メソッドをブロック方式で使用することにより、デッドロックに直面する可能性があります。これは状況によって異なります。

ここでは、ConfigureAwaitメソッドの重要性についてもう少し詳しく説明します（私のブログ投稿からの引用）。

awaitキーワードを使用してメソッドを待機している場合、コンパイラはユーザーに代わって一連のコードを生成します。このアクションの目的の1つは、UI（またはメイン）スレッドとの同期を処理することです。この機能の重要なコンポーネントはSynchronizationContext.Current、現在のスレッドの同期コンテキストを取得するコンポーネントです。 SynchronizationContext.Current現在の環境に応じて入力GetAwaiterされSynchronizationContext.Currentます。タスクのメソッドはを検索し ます。現在の同期コンテキストがnullでない場合、その待機者に渡される継続は、その同期コンテキストにポストバックされます。

新しい非同期言語機能を使用するメソッドをブロック方式で使用する場合、利用可能なSynchronizationContextがあると、デッドロックが発生します。このようなメソッドをブロック方式で使用している場合（Waitメソッドでタスクを待機するか、タスクのResultプロパティから直接結果を取得する）、同時にメインスレッドをブロックします。最終的にタスクがスレッドプールのそのメソッド内で完了すると、SynchronizationContext.Currentが利用可能でキャプチャされているため、継続を呼び出してメインスレッドにポストバックします。しかし、ここに問題があります。UIスレッドがブロックされ、デッドロックが発生します！

また、あなたの質問にぴったりの記事が2つあります。

• 足元で自分を撃つための完璧なレシピ-C＃5.0非同期言​​語機能を使用してデッドロックになる
• HTTP APIの非同期.NETクライアントライブラリとasync / awaitの悪い影響の認識

最後に、このトピックに関するLucian Wischikのすばらしい短いビデオがあります。非同期ライブラリメソッドはTask.ConfigureAwait（false）の使用を検討する必要があります。

お役に立てれば。

ConfigureAwait（false）を使用して見つけた最大の欠点は、スレッドカルチャがシステムのデフォルトに戻されることです。文化を設定した場合など...

<system.web>
    <globalization culture="en-AU" uiCulture="en-AU" />    
    ...

カルチャがen-USに設定されているサーバーでホストしている場合は、ConfigureAwait（false）が呼び出される前にCultureInfo.CurrentCultureがen-AUを返し、en-USが取得されたことがわかります。すなわち

// CultureInfo.CurrentCulture ~ {en-AU}
await xxxx.ConfigureAwait(false);
// CultureInfo.CurrentCulture ~ {en-US}

アプリケーションでデータのカルチャ固有のフォーマットが必要な処理を行っている場合は、ConfigureAwait（false）を使用するときにこれに注意する必要があります。

の実装について、いくつかの一般的な考えがありますTask。

1. タスクは使い捨てですが、使用することは想定されていませんusing。
2. ConfigureAwait4.5で導入されました。Task4.0で導入されました。
3. .NETスレッドは常にコンテキストをフローするために使用されますが（CLRブックを介したC＃を参照）、Task.ContinueWithそれらのデフォルト実装ではb / cは行われません。コンテキストスイッチが高価であり、デフォルトでオフになっていることがわかりました。
4. ライブラリ開発者は、クライアントがコンテキストフローを必要とするかどうかを気にする必要がないため、コンテキストをフローするかどうかを決定するべきではありません。
5. [追記]権威ある回答や適切な参照がなく、私たちがこれに対抗し続けるという事実は、誰かが自分の仕事を正しく行っていないことを意味します。

私はこの件についていくつかの投稿をしましたが、私の考えは-Tugberkの素晴らしい答えに加えて- すべてのAPIを非同期にして、理想的にはコンテキストをフローする必要があるということです。非同期を実行しているので、待機する代わりに継続を使用することができます。ライブラリで待機が行われず、フローが維持されるため、コンテキストが保持されるため（HttpContextなど）、デッドロックは発生しません。

問題は、ライブラリが同期APIを公開しているが、別の非同期APIを使用している場合です-したがって、コードでWait()/ を使用する必要がありますResult。