ASP.NET Coreに関連するConfigureAwait（false）？

101

私はGitHubで問題（https://github.com/HTBox/allReady/issues/1313）に遭遇しました。そこでConfigureAwait(false)、ASP.NET Coreでコードを削除することについて主張し、それを主張しました。

への呼び出しConfigureAwait(false)は冗長であり、何もしません

私がここで見つけることができる最高のものは、答えの「補足」（Stephen Cleary、https： //stackoverflow.com/a/40220190/2805831から）であることを伝えています

ASP.NET Coreに「コンテキスト」がなくなりました

では、（完全な.Net Frameworkを使用していても）ASP.NET CoreではConfigureAwait(false)本当に不要ですか？場合によっては実際にパフォーマンスが向上するか、結果/セマンティクスに違いがあるか

編集：コンソールアプリケーションまたはIISでホストしている場合、この点で違いますか？

.net asp.net-core async-await

— ペドロロレンツ
ソース

これは、それを使用する予定の場所によって異なります。ASP.NET Coreアプリケーションで直接使用したい場合は、呼び出す必要はありません（ASP.NETレガシーでもiircでも呼び出す必要はありませんでした）。ただし、ライブラリを作成する場合は、ライブラリConfigureAwait(false)をさまざまなアプリケーション（ASP.NET Core、WPF、UWP、コンソールなど）で使用できるため、常にを使用する必要があります

— Tseng

ASP.NET Coreはデフォルトでコンソールアプリケーションとして実行され、AFAIKコンソールアプリケーションにはSynchronizationContextがないため、フレームワークが完全であっても、デフォルトのASP.NET Coreアプリケーションではこれは妥当に聞こえます。

— ジョーホワイト

@JoeWhite OK、質問を編集しました。ASP.NET CoreアプリがIISにある場合は違いますか？

— ペドロロレンツ

IISで実行されているASP.NET Coreアプリは引き続きコンソールアプリケーションとして実行されます-唯一の違いは、IISがアプリのインスタンスを起動およびシャットダウンすることです（ASP.NETワーカープロセスのインスタンスを管理するのと同じ方法で）クラシックASP.NET）。ASP.NETアプリ内のスレッド関連の動作は変更されません。（「デフォルトで」指定した唯一の理由は、たとえば、GUIアプリ内でASP.NET Coreをホストできるためです。その場合、同期コンテキストについて考える必要があります。）

— Joe White

注ConfigureAwait(false)、一方で、関連する ASP.NETの古典で、決してである必要。これはトレードオフです。同期オーバー非同期デッドロック（とにかく設計上の欠陥です。だれかが何かをしない限り存在しません）をある程度軽減し、コンテキストを再ロードしないことにより、パフォーマンスが〜マイクロ秒向上することがあります。コンテキストに依存できずConfigureAwait、コード全体を使用できるという犠牲を払って。 stackoverflow.com/questions/28221508/...

— ダックスFohl

回答:

106

ConfigureAwaitSynchronizationContextASP.NET Coreにはない（ASP.NETの「レガシー」にはある）コンテキストで実行されるコードにのみ影響があります。

汎用コードはで実行されている可能性があるため、引き続き使用する必要がありますSynchronizationContext。

ASP.NET Core SynchronizationContext

— パウロモルガド
ソース

簡単に説明すると、非コア環境のASP.NETには同期コンテキストがありますが、ASP.NETコアにはありません。

— スコットチェンバレン

@モルガド、アプリがIISでホストされている場合でも本当ですか？

— ペドロロレンツ

ASP.NET CoreアプリはIISでホストされていません。IISは、リバースプロキシとして機能しています。

— Paulo Morgado 2017

スティーブンクリアリーからの最近の投稿で回答を更新しました。しかし、はい、ASP.NET CoreはASP.NET Coreです。

— Paulo Morgado 2017

@NamNgo。これは古い投稿であることに感謝しますが、Stephen Clearyは、Pauloが上記でリンクした投稿の質問の 1つでこれを明らかにしています。「SynchronizationContextを決定するのはフレームワーク（ASP.NET ClassicではなくASP.NET Core）であり、ランタイム（.NET 4.6.2ではなく.NET Core）ではありません」

— Gavin Sutherland

これはどうですか？

現在のところ（2020年2月）MSブログの開発者は、パフォーマンスを向上させ、デッドロックを回避するために、ConfigureAwait（false）の使用を推奨しています。 https://devblogs.microsoft.com/dotnet/configureawait-faq/

.NET CoreではConfigureAwait（false）が不要になったと聞きました。ほんと？いいえ。.NET Frameworkで実行する場合とまったく同じ理由で、.NET Coreで実行する場合にも必要です。その点で何も変更されていません。

— アルフレッドセベロ
ソース

一部のユーザーコード（またはアプリが使用している他のライブラリコード）がカスタムコンテキストを設定してコードを呼び出す場合、またはカスタムTaskSchedulerにスケジュールされたタスクでコードを呼び出す場合、ASP.NET Coreでさえ、待機中に非ConfigureAwait（false）を使用するように導くデフォルトのコンテキストまたはスケジューラー。もちろん、このような状況では、同期的なブロックを回避し（Webアプリケーションでの実行を回避する必要があります）、そのような限られた発生での小さなパフォーマンスオーバーヘッドを気にしない場合は、ConfigureAwait（false）を使用せずに回避できます。。

— Alisson

それによると、ほとんどの場合それは必要ないと言うでしょう。カスタム同期コンテキストを使用しているか、そうするライブラリを使用していない限り。

— Alisson