c# .net async-await .net-4.5

c# - Creación de un método asíncrono en.NET 4.0 que se puede usar con "esperar" en.NET 4.5



async-await .net-4.5 (3)

Tengo un proyecto .NET que usa C # en .NET 4.0 y VS2010.

Lo que me gustaría hacer es agregar algunas sobrecargas asíncronas a mi biblioteca para facilitar la programación asíncrona para los usuarios en .NET 4.5 con la palabra clave await. En este momento, los métodos que se están sobrecargando no son asíncronos. Tampoco quiero usar ningún método asíncrono, solo crear otros nuevos y ponerlos a disposición.

¿Es posible crear métodos asíncronos en .NET 4.0 y VS2010? En caso afirmativo, ¿cómo debería ser el método asíncrono .NET 4.0?

Debido a que estoy usando VS2010, no tengo acceso a la palabra clave "async", ¿qué debo hacer para emular ese comportamiento en .NET 4.0? Por ejemplo, ¿debe devolver algún tipo en particular, y es necesario que ocurra algún código dentro del método para hacer que el código actualmente no asíncrono al que está llamando suceda de forma asíncrona?


La forma más sencilla de hacerlo es devolver una Task o una Task<T> . Eso será suficiente.

Sin embargo, esto solo tiene sentido si su método realmente se ejecuta de forma asíncrona.

También le recomiendo que siga el patrón habitual de nombrarlos como AbcAsync (sufijo "Async"). Las personas que llaman no notarán ninguna diferencia con respecto a un método asíncrono creado con C # 5 (porque no hay ninguno).

Sugerencia: solo agregar async al método no hace nada. Su método se ejecutará secuencialmente y devolverá una tarea completada. Hacer que el método devuelva una tarea debe tener un cierto propósito: generalmente esto se hace porque el método se ejecuta de forma asíncrona (como una llamada de servicio web o un archivo IO).

Si su método solo contiene computación pero no IO (o solo IO de bloqueo) generalmente es mejor no hacerlo asíncrono porque no gana nada haciendo eso. Los métodos asíncronos no siempre se ejecutan en un hilo separado. Si la última oración le sorprendió, tal vez quiera profundizar un poco en este tema.


Siempre que devuelva una Tarea que se complete de alguna manera (ya sea en un hilo o de forma asíncrona), apoyaría el modelo asíncrono.

Tener una tarea ejecutada de forma asíncrona es otra historia. Si tuviera acceso a la palabra clave asíncrona y a la API, simplemente podría basar su método en llamadas asíncronas a otros métodos asíncronos ya provistos. Pero en este caso, tienes que realizar manualmente tus tareas asíncronas.

Puede haber mejores maneras de hacerlo, pero la forma más elegante que puedo ver (y he usado) es utilizar System.Threading.Tasks.TaskCompletionSource para construir una tarea, use el modelo Begin / End de métodos asíncronos para ejecutar lo que necesite. ejecutar. Luego, cuando tenga el resultado a la mano, publíquelo en la instancia de Task construida anteriormente utilizando su fuente de finalización.

Sin duda será asíncrono, pero no tan elegante como los que se publicarán próximamente.

Descargo de responsabilidad: no estoy cerca de un experto en esto. Acabo de hacer algunos experimentos en.


Como han dicho otros, usted comienza con un método que devuelve Task o Task<TResult> . Esto es suficiente para await su resultado en .NET 4.5.

Para que su método se adapte lo mejor posible al futuro código asíncrono, siga las pautas en el documento de Patrón asíncrono basado en tareas (también disponible en MSDN ). Proporciona convenciones de nomenclatura y recomendaciones de parámetros, por ejemplo, para respaldar la cancelación.

Para la implementación de su método, tiene algunas opciones: