asincrona - async await c# ejemplos
¿Es asincrónico y espera exclusivamente para la programación asincrónica basada en GUI? (4)
Así que, básicamente, no puede usar async y esperar sin tener una GUI que use el ciclo de mensajes estándar de WinForms y WPF.
Eso no es absolutamente el caso.
En Windows Forms y WPF, async / await tiene la práctica propiedad de volver al hilo de la interfaz de usuario cuando se completó la operación asíncrona que estaba esperando, pero eso no significa que sea el único propósito.
Si un método asíncrono se ejecuta en un subproceso de grupo de subprocesos, por ejemplo, en un servicio web, la continuación (el resto del método asincrónico) simplemente se ejecutará en cualquier subproceso de grupo de subprocesos, con el contexto (seguridad, etc.) conservado adecuadamente. Esto sigue siendo realmente útil para mantener baja la cantidad de subprocesos.
Por ejemplo, supongamos que tiene un servicio web de alto tráfico que en su mayoría envía solicitudes a otros servicios web. Pasa la mayor parte del tiempo esperando otras cosas, ya sea debido al tráfico de la red o al tiempo real en otro servicio (por ejemplo, una base de datos). No debería necesitar muchos hilos para eso, pero con las llamadas de bloqueo, naturalmente termina con un hilo por solicitud. Con async / await, terminarías con muy pocos subprocesos, porque muy pocas solicitudes necesitarían realmente algún trabajo realizado para ellos en un momento determinado, incluso si hubiera muchas solicitudes "en vuelo".
El problema es que async / await se demuestra más fácilmente con el código UI, ya que todos conocen el dolor de usar subprocesos de fondo correctamente o de hacer demasiado trabajo en el hilo de la interfaz de usuario. Sin embargo, eso no significa que sea el único lugar donde la característica sea útil, ni mucho menos.
Varias tecnologías del lado del servidor (MVC y WCF, por ejemplo) ya tienen soporte para métodos asíncronos, y espero que otros sigan su ejemplo.
He estado leyendo sobre la nueva async y await operadores en C # e intenté averiguar en qué circunstancias podrían ser útiles para mí. Estudié varios artículos de MSDN y esto es lo que leo entre líneas:
Puede utilizar async para Windows Forms y controladores de eventos WPF, para que puedan realizar tareas largas sin bloquear el subproceso de la interfaz de usuario mientras se ejecuta la mayor parte de la operación.
async void button1_Click(object sender, EventArgs e)
{
// even though this call takes a while, the UI thread will not block
// while it is executing, therefore allowing further event handlers to
// be invoked.
await SomeLengthyOperationAsync();
}
Un método que usa await debe ser async , lo que significa que el uso de cualquier función async en algún lugar del código fuerza a todos los métodos en la secuencia de llamadas desde los manejadores de eventos UI hasta el método async nivel más bajo para que también sea async .
En otras palabras, si creas un hilo con un buen punto de entrada de ThreadStart (o una aplicación de consola con una buena static int Main(string[] args) ), entonces no puedes usar async y await porque en un punto tendrías para usar await , y haga que el método que lo utiliza sea async , y por lo tanto, en el método de llamada también debe usar await y hacer que una sea async y así sucesivamente. Pero una vez que alcanzas el punto de entrada del hilo (o Main() ), no hay ningún interlocutor al que un await ceda el control.
Así que, básicamente, no puede usar async y await sin tener una GUI que use el ciclo de mensajes estándar de WinForms y WPF. Supongo que todo eso tiene sentido, ya que MSDN afirma que la programación async no significa multiprocesamiento, sino el tiempo libre del subproceso de la interfaz de usuario; cuando se utiliza una aplicación de consola o un subproceso con un punto de entrada definido por el usuario, sería necesario realizar subprocesos múltiples para realizar operaciones asíncronas (si no se utiliza un bucle de mensajes compatible).
Mi pregunta es, ¿son estas suposiciones exactas?
Mi pregunta es, ¿son estas suposiciones exactas?
No.
Puede utilizar async para Windows Forms y controladores de eventos WPF, para que puedan realizar tareas largas sin bloquear el subproceso de la interfaz de usuario mientras se ejecuta la mayor parte de la operación.
Cierto. También es cierto para otras aplicaciones de interfaz de usuario incluyendo Silverlight y Windows Store.
Y también es cierto para ASP.NET. En este caso, es el hilo de solicitud HTTP que no está bloqueado.
Un método que usa await debe ser asincrónico, lo que significa que el uso de cualquier función asíncrona en algún lugar del código fuerza a todos los métodos en la secuencia de llamadas desde los manejadores de eventos UI hasta el método asincrónico de nivel más bajo para que también sea asincrónico.
Esta es una buena práctica (" async hasta el fondo"), pero no es estrictamente obligatorio. Puede bloquear el resultado de una operación asincrónica; muchas personas optan por hacer esto en las aplicaciones de consola.
un viejo y ordinario punto de entrada de ThreadStart
Bueno ... Tengo que discrepar con "ordinario bueno viejo". Como explico en mi blog, Thread es prácticamente la peor opción que tienes para realizar operaciones en segundo plano .
Te recomiendo que revises mi introducción a async y await , y sigas con las preguntas frecuentes async / await .
Un método que usa await debe ser asincrónico, lo que significa que el uso de cualquier función asíncrona en algún lugar del código fuerza a todos los métodos en la secuencia de llamadas desde los manejadores de eventos UI hasta el método asincrónico de nivel más bajo para que también sea asincrónico.
No es cierto: los métodos marcados como no sincronizados solo significan que pueden usar espera, pero los llamantes de esos métodos no tienen restricciones. Si el método devuelve Task o Task<T> entonces pueden usar ContinueWith o cualquier otra cosa que pueda hacer con las tareas en 4.0
Un buen ejemplo que no es UI es MVC4 AsyncController.
En última instancia, async / await se trata principalmente de obtener la reescritura del compilador para que pueda escribir lo que parece un código sincrónico y evitar todas las devoluciones de llamada como tenía que hacer antes de agregar async / await. También ayuda con el manejo SynchronizationContext, útil para escenarios con afinidad de subprocesos (framework UI, ASP.NET), pero incluso sin ellos, sigue siendo útil. Main siempre puede hacer DoStuffAsync().Wait(); por ejemplo. :)
- async-await es solo un contenedor para las manipulaciones de la clase Tarea, que es parte de la denominada Biblioteca paralela de tareas - TPL (publicada antes de la tecnología de generación automática de códigos async-await).
- Por lo tanto, es posible que no use ninguna referencia a los controles UI dentro de asincronización - aguarde.
- Normalmente async-await es una poderosa herramienta para cualquier relación web y de servidor, cargando recursos, sql. Funciona con datos de espera inteligentes con interfaz de usuario activa.
- Por lo general, la aplicación TPL: desde un ciclo simple de gran tamaño hasta varias etapas, cálculos paralelos en cálculos complejos basados en datos compartidos (ContinueWith, etc.)