ASP.NET Core와 관련된 ConfigureAwait (false)?

106

GitHub에서 문제 ( https://github.com/HTBox/allReady/issues/1313 )를 발견했습니다 . 그들은 ASP.NET CoreConfigureAwait(false) 에서 코드를 꺼내는 것에 대해 논의했습니다.

에 대한 호출 ConfigureAwait(false)이 중복되고 아무 작업도 수행하지 않습니다.

여기에서 찾을 수있는 가장 좋은 것은 답변 (Stephen Cleary, https://stackoverflow.com/a/40220190/2805831 )에 있는 "사이드 노트" 입니다.

ASP.NET Core에는 더 이상 "컨텍스트"가 없습니다.

그렇다면 ASP.NET CoreConfigureAwait(false) 에서 정말 불필요 합니까 (전체 .Net Framework를 사용하더라도)? 어떤 경우에는 성능이 실질적으로 향상되거나 결과 / 의미에 차이가 있습니까?

편집 : 콘솔 응용 프로그램이나 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 애플리케이션에 합리적으로 들립니다.

— Joe White

@JoeWhite 좋아, 질문을 편집했습니다. 내 ASP.NET Core 앱이 IIS에 있으면 다른가요?

— Pedro Lorentz

IIS에서 실행되는 ASP.NET Core 앱은 여전히 콘솔 애플리케이션으로 실행됩니다. 유일한 차이점은 IIS가 앱의 인스턴스를 시작하고 종료한다는 것입니다 (ASP.NET 작업자 프로세스의 관리되는 인스턴스와 동일한 방식). 클래식 ASP.NET). ASP.NET 앱 내부의 스레드 관련 동작은 변경되지 않습니다. (I는 "기본적으로"지정된 유일한 이유는, 예를 들어, 호스트 ASP.NET 코어는 GUI 응용 프로그램 내에서, 그 경우에 당신이 할 수 있다는 것입니다 것 동기화 컨텍스트에 대해 생각해야합니다.)

— 조 화이트

주 ConfigureAwait(false), 동안 관련 ASP.NET의 고전, 결코입니다 필요 . 이것은 트레이드 오프입니다 : 그것은 약간의 동기를 통한 비동기 교착 상태 (어쨌든 디자인 결함입니다. 누군가 멍청한 일을하지 않는 한 존재하지 않음)을 완화하고 때때로 컨텍스트를 다시로드하지 않음으로써 ~ 마이크로 초의 성능 향상을 가져옵니다. 컨텍스트에 의존 할 수없고 ConfigureAwait코드를 통해 모든 것을 갖는 대가로. stackoverflow.com/questions/28221508/…

— Dax Fohl

답변:

113

ConfigureAwaitSynchronizationContextASP.NET Core에없는 (ASP.NET "Legacy"가 수행하는) 컨텍스트에서 실행되는 코드에만 영향을줍니다 .

범용 코드는 SynchronizationContext.

ASP.NET Core SynchronizationContext

— 파울로 모가도
소스

약간의 설명을 원하면 코어가 아닌 환경의 ASP.NET에는 동기화 컨텍스트가 있지만 ASP.NET 코어에는 없습니다.

— Scott Chamberlain

@Morgado, 앱이 IIS에서 호스팅되는 경우에도 사실입니까?

— Pedro Lorentz

ASP.NET Core 앱은 IIS에서 호스팅되지 않습니다. IIS는 역방향 프록시처럼 작동합니다.

— Paulo Morgado

Stephen Cleary의 최근 게시물로 답변을 업데이트했습니다. 그러나 예, ASP.NET Core는 ASP.NET Core입니다.

— Paulo Morgado

@NamNgo. 이것은 지금 오래된 게시물이라는 점을 인식하고 있지만 Stephen Cleary는 Paulo가 위에 링크 한 게시물 의 질문 중 하나에서 이것을 명확히합니다 . "그것은 프레임 워크 (.NET 4.6.2에 반대 .NET 코어)를 SynchronizationContext에 아닌 실행을 결정한다 (ASP.NET 코어 ASP.NET 클래식 반대)입니다"

— 개빈 서덜랜드

이건 어때?

현재 (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)를 사용하도록 유도하는 기본 컨텍스트 또는 스케줄러. 물론 이러한 상황에서 동기식 차단 (웹 앱에서는 피해야 함)을 피하고 이러한 제한된 발생에서 작은 성능 오버 헤드를 신경 쓰지 않는다면 ConfigureAwait (false)를 사용하지 않고도 벗어날 수 있습니다. .

— Alisson

그에 따르면 대부분의 경우 필요하지 않다고 말하고 싶습니다. 사용자 지정 동기화 컨텍스트를 사용하거나 그렇게하는 라이브러리를 사용하지 않는 한.

— Alisson