![\"Asincron\u00eda](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/08\/Asincron\u00eda-en-Tasks.-Bloqueos-contextos-y-tareas..png\")
<\/h2>\n<\/h2>\n\u201c\u00a1Rec\u00f3rcholis! \u00a1Mi fant\u00e1stico m\u00e9todo HagoCosasChulasAsync<\/em> bloquea mi aplicaci\u00f3n!\u201d.<\/p>\n Si has utilizado la Asincron\u00eda basada en Tasks<\/em><\/strong> (TAP<\/a>) en aplicaciones algo complejas, esta frase te sonar\u00e1. Posiblemente, despu\u00e9s de entrar en p\u00e1nico y ojear Stack Overflow<\/em> hayas dado con la panacea a todos tus problemas: el m\u00e9todo ConfigureAwait<\/em> que nos expone la clase Task<\/em>. Pas\u00e1ndole a este m\u00e9todo \u00abfalse\u00bb como par\u00e1metro y a\u00f1adi\u00e9ndolo a lo largo de todas las Tasks<\/em>, todo vuelve a funcionar como esperabas.<\/p>\n <\/p>\n Aunque esto solucione nuestros bloqueos, no est\u00e1 de m\u00e1s saber por qu\u00e9 suceden. Tambi\u00e9n es importante el porqu\u00e9 la soluci\u00f3n pasa por a\u00f1adir este m\u00e9todo a nuestras llamadas as\u00edncronas. En este post vamos a intentar aclarar algunos de los conceptos claves del TAP<\/strong> para ahorrar dolores de cabeza (y canas) a los desarrolladores que tienen la fortuna de usarlo en sus aplicaciones.<\/p>\n Cuando creamos una Task<\/em> de cualquier forma que no sea mediante constructor, tambi\u00e9n la iniciamos, es decir, empezar\u00e1 a ejecutarse en segundo plano autom\u00e1ticamente y el flujo de ejecuci\u00f3n del programa no se bloquear\u00e1.<\/p>\n Para esperar a que esta tarea finalice y recuperar su resultado (si lo tiene), debemos utilizar la palabra clave await<\/em>. Nunca usaremos el m\u00e9todo Wait<\/em> ni accederemos al resultado mediante Result<\/em>, ya que esto es una causa com\u00fan de bloqueos.<\/p>\n Por un lado, tenemos la palabra clave async<\/em>, que a\u00f1adimos a la definici\u00f3n de nuestro m\u00e9todo y que lo marcar\u00e1 como as\u00edncrono. Esto nos permite utilizar la instrucci\u00f3n await<\/em> en su c\u00f3digo. Ni optimiza nada, ni hace magia con el compilador. Simplemente informa que await<\/em> puede o no aparecer en el c\u00f3digo contenido en el m\u00e9todo.<\/p>\n Por otra parte, aparece la fant\u00e1stica await<\/em>. Aqu\u00ed ya hay un poco m\u00e1s de miga. El uso de esta palabra clave delante de una llamada as\u00edncrona que devuelve un Awaitable (una operaci\u00f3n as\u00edncrona, que normalmente ser\u00e1 una Task<\/em>), detiene la ejecuci\u00f3n del m\u00e9todo as\u00edncrono actual y hace un return<\/em> del m\u00e9todo.<\/p>\n Este m\u00e9todo se parar\u00e1 hasta que nuestro Awaitable<\/em> finalice y s\u00f3lo entonces retomar\u00e1 su ejecuci\u00f3n. Para poder continuar, recapturar\u00e1 el contexto en el que se ejecutaba el m\u00e9todo antes de dicha parada.<\/p>\n De forma muy resumida no es m\u00e1s que una especie de mensajero que permite a hilos de ejecuci\u00f3n comunicarse entre si. Cada parte del framework puede necesitar que este contexto se comporte de forma diferente, as\u00ed que se nos proporcionan varias implementaciones de este contexto. Por ejemplo, tenemos AspNetSynchronizationContext<\/em>, que es propio de AspNet o DispatcherSynchronizationContext<\/em>, que es el que se utiliza en aplicaciones WPF o Silverlight.<\/p>\n Para m\u00e1s informaci\u00f3n sobre esto, podemos acudir a este fant\u00e1stico art\u00edculo<\/a> de Stephen Cleary.<\/p>\n Os preguntar\u00e9is por qu\u00e9 nos importa esto. Pues bien, volvamos al principio. Hemos comentado que una de las maneras m\u00e1s efectivas para evitar bloqueos en nuestro c\u00f3digo as\u00edncrono es utilizar el m\u00e9todo ConfigureAwait<\/em> cuando esperemos el resultado de una Task<\/em>, pas\u00e1ndole false<\/em> como par\u00e1metro. Esto provoca que el awaiter<\/em> no capture el contexto de sincronizaci\u00f3n. No debemos olvidar que, al no capturar el contexto, no podremos acceder a \u00e9l en el c\u00f3digo que haya despu\u00e9s de la llamada a ConfigureAwait<\/em>.<\/strong> Esto es importante, por ejemplo, en aplicaciones de escritorio o al trabajar con Request en AspNet.<\/p>\n Aunque usar ConfigureAwait<\/em> arregle nuestros problemas de forma casi m\u00e1gica la mayor\u00eda de veces, no es la mejor pr\u00e1ctica para evitar los bloqueos.<\/p>\n \u00bfQu\u00e9 debemos hacer entonces? Pues para evitar los bloqueos, lo mejor es no bloquear<\/strong>. Aunque parezca una tonter\u00eda, realmente la manera m\u00e1s f\u00e1cil de evitarnos problemas es hacer que nuestro c\u00f3digo sea completamente as\u00edncrono. Veamos un ejemplo:<\/p>\n \u00bfPor qu\u00e9 bloquearemos al esperar a que termine \u00absaludo\u00bb de forma s\u00edncrona?<\/p>\n Pues bien, en el momento en el que llamamos a GetByUserAsync<\/em> devolvemos el control a la aplicaci\u00f3n y, como no hemos indicado mediante ConfigureAwait(false)<\/em> que no queremos ejecutar la continuaci\u00f3n de ObtenerSaludo<\/em> en el mismo contexto, se quedar\u00e1 esperando a que \u00e9ste se libere. Esa continuaci\u00f3n nunca se producir\u00e1, ya que estamos bloqueando s\u00edncronamente<\/strong> en el m\u00e9todo Get<\/em> y el contexto es el mismo.<\/p>\n Podemos solucionar este error de dos formas: usando ConfigureAwait(false)<\/em><\/strong> y diciendo as\u00ed que no queremos resumir la ejecuci\u00f3n de ObtenerSaludo<\/em> en el mismo contexto, o bien haciendo el c\u00f3digo completamente s\u00edncrono<\/strong>.<\/p>\n Hay que tener en cuenta las implicaciones de elegir la soluci\u00f3n de a\u00f1adir ConfigureAwait(false)<\/em>.<\/p>\n Si estamos bloqueando en el m\u00e9todo que est\u00e1 mas arriba hay que a\u00f1adirlo a absolutamente todas las Task<\/em> a lo largo del c\u00f3digo afectado. Y con todo, me refiero a nuestro c\u00f3digo y al de librer\u00edas de terceros, sobre las que no siempre solemos tener el control. En el caso de que seamos nosotros los que escribamos una API o una librer\u00eda de cualquier tipo, es correcto usar ConfigureAwait(false)<\/em>, ya que no podemos controlar si el que nos llama bloquea o no. Por lo tanto, lo mejor es curarse en salud.<\/p>\n Es importante no conformarnos con aplicar las soluciones de <\/strong>Stack Overflow<\/strong>. A<\/em>unque nos faciliten la vida y nos eviten caer en el alcoholismo \ud83d\ude09 \u00a0En mi opini\u00f3n es muy importante saber por qu\u00e9 suceden los fallos y por qu\u00e9 la soluci\u00f3n es la que se propone. En nuestro caso, aunque ConfigureAwait<\/em> nos arregla la mayor\u00eda de problemas con bloqueos, no es la mejor de las pr\u00e1cticas. Y si no seguimos las buenas pr\u00e1cticas no podemos presumir de ello \ud83d\ude42<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" \u201c\u00a1Rec\u00f3rcholis! \u00a1Mi fant\u00e1stico m\u00e9todo HagoCosasChulasAsync bloquea mi aplicaci\u00f3n!\u201d. Si has utilizado la Asincron\u00eda basada en Tasks (TAP) en aplicaciones algo complejas, esta frase te sonar\u00e1. Posiblemente, despu\u00e9s de entrar en p\u00e1nico y ojear Stack Overflow hayas dado con la panacea … Continue reading Qu\u00e9 es una Task<\/h2>\n
![\"\"](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/08\/At\u2013Planning_One-time_Tasks-300x265.jpg\")
\nPara comenzar a entender realmente qu\u00e9 hay debajo de nuestro fant\u00e1stico c\u00f3digo as\u00edncrono, debemos familiarizarnos con las Tasks<\/em><\/strong>. Seg\u00fan la documentaci\u00f3n, una Task<\/em> representa una operaci\u00f3n as\u00edncrona<\/strong>. En nuestro contexto, pr\u00e1cticamente es todo lo que necesitamos saber. Es una promesa de que algo se va a ejecutar y, si utilizamos Task<T><\/em>, \u00a0supone que se va a devolver un resultado tipo T. Podemos comprobar el estado de estas tareas mediante la propiedad Status<\/em> o tambi\u00e9n las propiedades IsCompleted<\/em>, IsFaulted<\/em> o IsCanceled<\/em>.<\/p>\n\r\n\/\/ Creamos una tarea\r\nTask<int> myTask = Task.FromResult(1000);\r\n\r\n\/\/ Podemos consultar el estado\r\n\/\/ Los posibles valores est\u00e1n definidos en el enum TaskStatus\r\nvar taskStatus = myTask.Status;\r\n\r\n\/\/ Existen propiedades booleanas para controlar los estados\r\nvar isTaskFaulted = myTask.IsFaulted;\r\nvar isTaskCanceled = myTask.IsCanceled;\r\nvar isTaskCompleted = myTask.IsCompleted;\r\n\r\n\/\/ Esperaremos a que terminen las tareas usando await\r\nvar awaitedResult = await myTask;\r\n\r\n\/\/ Nunca en c\u00f3digo as\u00edncrono lo haremos de esta forma\r\nmyTask.Wait();\r\nvar result = myTask.Result;\r\n<\/pre>\n
\u00bfQu\u00e9 ocurre cuando uso Async y Await?<\/h2>\n
\r\n\/\/ La palabra clave async nos permite usar await\r\n\/\/ Si la quitamos, el c\u00f3digo no compilar\u00e1\r\npublic async Task<string> HolaAsync()\r\n{\r\n \/\/ Await devuelve el control a la aplicaci\u00f3n\r\n \/\/ hasta que se complete la tarea\r\n var saludo = await SaludarAsync("Hola");\r\n\r\n \/\/ Aqu\u00ed volvemos a estar en el contexto previo\r\n \/\/ a la llamada a SaludarAsync\r\n return saludo;\r\n}\r\n\r\n\/\/ Solo podemos lanzar la tarea al no marcar\r\n\/\/ el m\u00e9todo como as\u00edncrono\r\npublic Task<string> SaludarAsync(string saludo)\r\n{\r\n \/\/ Task.Run encola una nueva tarea a partir del delegado\r\n return Task.Run(() => { return saludo; });\r\n}\r\n<\/pre>\nLa magia del SynchronizationContext<\/h2>\n
![\"Cadena](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2017\/08\/Imagen1-300x298.png\")
Hemos comentado que al retomar la ejecuci\u00f3n de un m\u00e9todo as\u00edncrono recapturamos el contexto en el que se ejecutaba. Pero, \u00bfqu\u00e9 es un<\/strong> contexto de sincronizaci\u00f3n<\/strong>?<\/p>\n\r\npublic async Task<string> HolaAsync()\r\n{\r\n \/\/ Obtendr\u00edamos el usuario sin problema\r\n var userName = HttpContext.Current.User.Identity.Name;\r\n\r\n \/\/ Hacemos la llamada con ConfigureAwait en false\r\n var saludo = await SaludarAsync($"Hola {userName}")\r\n .ConfigureAwait(false);\r\n\r\n \/\/ El c\u00f3digo fallar\u00e1 al llegar a esta linea.\r\n \/\/ Hemos especificado que no quer\u00edamos capturar el contexto\r\n \/\/ y al volver a entrar, este contexto Http no existe\r\n var isUserAdmin = HttpContext.Current.User.IsInRole("Admin");\r\n \r\n return isUserAdmin ? saludo.ToUpper() : saludo;\r\n}\r\n<\/pre>\nEvitando los bloqueos<\/h2>\n
\r\n\/\/ Capa inferior\r\npublic class GreetingService\r\n{\r\n private readonly IGreetingRepository greetingRepository;\r\n\r\n public async Task<string> ObtenerSaludo(string userName)\r\n {\r\n \/\/ Devolvemos el control\r\n return await greetingRepository.GetByUserAsync(userName);\r\n }\r\n}\r\n\r\n\/\/ Controlador random WebAPI\r\npublic class GreetingController : ApiController\r\n{\r\n public string Get()\r\n {\r\n var saludo = ObtenerSaludo(HttpContext.Current.User.Identity.Name);\r\n \/\/ Esta llamada bloquear\u00e1 la aplicaci\u00f3n\r\n return saludo.Result;\r\n }\r\n}\r\n<\/pre>\n\r\n\/\/ Nuevo m\u00e9todo Get\r\npublic async Task<string> Get()\r\n{\r\n \/\/ No necesitamos ConfigureAwait(false)\r\n return await ObtenerSaludo(HttpContext.Current.User.Identity.Name);\r\n}\r\n<\/pre>\nEn Resumen<\/h2>\n