ConfigureAwait (falso) ¿relevante en ASP.NET Core?

101

Me encontré con un problema ( https://github.com/HTBox/allReady/issues/1313 ) en GitHub donde discutieron sobre ConfigureAwait(false)eliminar el código, afirmando que, en ASP.NET Core

la llamada a ConfigureAwait(false)es redundante y no hace nada

Lo mejor que pude encontrar aquí es una "nota al margen" en una respuesta (de Stephen Cleary, https://stackoverflow.com/a/40220190/2805831 ) que dice que

ASP.NET Core ya no tiene un "contexto"

Entonces, ¿es ConfigureAwait(false)realmente innecesario en ASP.NET Core (incluso si usa .Net Framework completo)? ¿Tiene alguna ganancia real en el rendimiento en algunos casos o diferencia en el resultado / semántica?

EDITAR: ¿Es diferente en este aspecto si lo alojo como una aplicación de consola o en IIS?

.net asp.net-core async-await

— Pedro Lorentz
fuente

Esto depende de dónde planeaba usarlo. Si desea usarlo directamente en su aplicación ASP.NET Core, entonces no, no tiene que llamarlo (no tuvo que llamarlo en ASP.NET legacy ni iirc). Pero si escribe una biblioteca, siempre debe usarla ConfigureAwait(false), ya que la biblioteca puede ser consumida por diferentes aplicaciones (ASP.NET Core, WPF, UWP, consola, etc.)

— Tseng

ASP.NET Core se ejecuta como una aplicación de consola de forma predeterminada, y las aplicaciones de consola AFAIK no tienen un SynchronizationContext, por lo que sí, esto suena razonable para una aplicación ASP.NET Core predeterminada, incluso con el Framework completo.

— Joe White

@JoeWhite Ok, editó la pregunta. ¿Es diferente si mi aplicación ASP.NET Core está en IIS?

— Pedro Lorentz

Una aplicación ASP.NET Core que se ejecuta en IIS todavía se ejecuta como una aplicación de consola; la única diferencia es que IIS está iniciando y cerrando instancias de su aplicación (de la misma manera que habría administrado instancias del proceso de trabajo de ASP.NET en ASP.NET clásico). No cambiaría ningún comportamiento relacionado con subprocesos dentro de su aplicación ASP.NET. (La única razón por la que especifiqué "por defecto" es que podría, por ejemplo, alojar ASP.NET Core dentro de una aplicación GUI, y en ese caso tendría que pensar en el contexto de sincronización).

— Joe White

Tenga en cuenta que ConfigureAwait(false), si bien es relevante en ASP.NET classic, de ninguna manera es necesario . Es una compensación: mitiga un poco algunos puntos muertos de sincronización sobre asincrónica (que son fallas de diseño de todos modos, no existen a menos que alguien haga algo tonto) y ocasionalmente tiene un aumento de rendimiento de ~ microsegundos al no recargar el contexto. A costa de no poder depender del contexto y tener ConfigureAwaittodo su código. stackoverflow.com/questions/28221508/…

— Dax Fohl

Respuestas:

106

ConfigureAwaitsolo tiene efectos en el código que se ejecuta en el contexto de un SynchronizationContextASP.NET Core que no tiene (ASP.NET "Legacy" sí).

El código de propósito general aún debería usarlo porque podría estar ejecutándose con un SynchronizationContext.

SynchronizationContext de ASP.NET Core

— Paulo Morgado
fuente

Solo quiero hacer una pequeña aclaración, ASP.NET en un entorno no central tiene un contexto de sincronización, pero ASP.NET core no.

— Scott Chamberlain

@Morgado, ¿es cierto incluso si la aplicación está alojada en IIS?

— Pedro Lorentz

Una aplicación ASP.NET Core no está alojada en IIS. IIS actúa simplemente como un proxy inverso.

— Paulo Morgado

Actualicé la respuesta con una publicación reciente de Stephen Cleary. Pero, sí, ASP.NET Core es ASP.NET Core.

— Paulo Morgado

@NamNgo. Aprecio que esta es una publicación antigua ahora, pero Stephen Cleary lo aclara en una de las preguntas sobre la publicación que Paulo vinculó anteriormente. "es el marco (ASP.NET Core en oposición a ASP.NET Classic) el que determina el SynchronizationContext, no el tiempo de ejecución (.NET Core en oposición a .NET 4.6.2)"

— Gavin Sutherland

¿Qué pasa con esto?

En este momento (febrero de 2020) los desarrolladores en el blog de MS recomiendan usar ConfigureAwait (falso) para mejorar el rendimiento, evitar puntos muertos. https://devblogs.microsoft.com/dotnet/configureawait-faq/

Escuché que ConfigureAwait (falso) ya no es necesario en .NET Core. ¿Cierto? Falso. Se necesita cuando se ejecuta en .NET Core exactamente por las mismas razones que se necesita cuando se ejecuta en .NET Framework. Nada ha cambiado en ese sentido.

— Alfred Severo
fuente

Si algún código de usuario (u otro código de biblioteca que usa su aplicación) establece un contexto personalizado y llama a su código, o invoca su código en una Tarea programada para un TaskScheduler personalizado, entonces incluso en ASP.NET Core sus esperas pueden ver un no contexto o programador predeterminado que lo llevaría a querer usar ConfigureAwait (falso). Por supuesto, en tales situaciones, si evita el bloqueo sincrónico (lo que debe evitar hacer en aplicaciones web independientemente) y si no le importan los pequeños gastos generales de rendimiento en casos tan limitados, probablemente pueda salirse con la suya sin usar ConfigureAwait (falso) .

— Alisson

Según eso, diría que en la mayoría de los casos no es necesario. A menos que esté usando un contexto de sincronización personalizado o usando una biblioteca que lo haga.

— Alisson