70-526 Resumen 5/8: Operaciones Asíncronas.

Quinto resumen de 8 del temario para el examen 70-526 de la certificación MCTS Windows Applications 2.0. Esta, es una de las nuevas certificaciones Microsoft para .NET 2.0. Lo prometí no? Vuelve el modelo asíncrono … pero en plan repaso Engloba el tema 13.Asynchronous Programming Techniques del libro oficial de Microsoft.

70-536 Resumen 4/7: Threading, dominios de aplicación y servicios Windows.

Cuarto repaso de 7 del temario para el examen 70-536 de la certificación MCTS en .NET. Esta, es una de las nuevas certificaciones Microsoft para .NET 2.0. Engloba los temas 7.Threading y 8.Application Domains and Services del libro oficial de Microsoft. A quien le guste la programación concurrente como a mi, le gustará el tema 7. En breve escribiré un par de artículos sobre sincronización avanzada de tareas concurrentes, con unos ejemplos de buenas prácticas y de como se diseñan clases thread-safe.

Servidor y cliente TCP SSL asíncrono.

Desde que conozco el modelo de desarrollo asíncrono en .NET, siempre que he tenido que trabajar con sockets he echado mano de dos ejemplos de MSDN, un ejemplo de servidor TCP asíncrono y otro ejemplo de un cliente TCP asíncrono. Aunque implica un poquito más de complejidad a la hora del diseño y de las pruebas, el resultado lo compensa, mayor escalabilidad y mejor rendimiento. De la mano del blog de Jon Cole, otro artículo que pasa a formar parte de mis bookmarks, ejemplos de servidor y cliente TCP SSL asíncrono. SSL es un protocolo que provee de autenticación segura y cifrado extremo a extremo, usado por ejemplo por los protocolos seguros HTTPS (¿no lo usa tu banco? ) y FTPS. A ver si paso el examen 70-536 y tengo tiempo de probarlo a fondo

Modelo Asíncrono. Parte VI, deadlocks.

Siguiendo con el modelo asíncrono, un deadlock (bloqueo mortal ó de la muerte) sucede cuando dos ó más hilos intentan acceder a recursos que siempre estarán bloqueados, quedando ambos bloqueados en espera, pudiendo también causar el cuelgue total ó parcial de la aplicación. Este diagrama de secuencia muestra el ejemplo más simple de deadlock, el hilo A bloquea el recurso X para su acceso exclusivo e intenta acceder a el recurso Y, a su vez el hilo B bloquea el recurso Y para su acceso exclusivo e intenta acceder al recurso X, esto provoca que ambos hilos queden esperando el uno al otro de forma indefinida.

Modelo Asíncrono. Parte V, modificando controles desde otros hilos.

Siguiendo con el modelo asíncrono y cuestiones de serialización de accesos, es también importante destacar que por norma general, los controles gráficos (System.Windows.Forms) no pueden ser modificados desde un thread distinto al propio de la GUI, provocando una InvalidOperationException si lo hacemos, por ello debemos realizar estas modificaciones haciendo que el mismo formulario principal invoque la modificación ejecutándola con su propio thread. Primero, vamos a reproducir el problema para ser más conscientes de la solución, este código provoca la susodicha excepción al intentar modificar un ListBox que se encuentra en el formulario Form1:

Modelo Asíncrono. Parte IV, sincronización.

Siguiendo con el modelo asíncrono, hoy voy a explicar una de las dos cuestiones básicas de sincronización, la primera el como serializar el acceso a un objeto de forma que solo un hilo pueda acceder a la vez usando la clase Monitor y la sentencia lock. Es importante saber controlar como nuestros hilos acceden a objetos y/ó datos en común, puesto que si un hilo modifica un objeto mientras que otro lo esta leyendo puede entorpecer ó incluso corromper los datos que ese hilo lee, hasta podría dejar el objeto en un estado inconsistente. Además veremos el uso de la palabra clave volatile y de otros métodos de sincronización no administrada. En el siguiente artículo explicaré como modificar un control visual desde un hilo distinto del de la GUI.

Interactuando con la consola. Parte I, obtener la salida de un comando.

Este artículo ha sido migrado a mi nuevo blog:

Obtener la salida de un comando de consola

Modelo Asíncrono. Parte III, espera y finalización.

Siguiendo con el modelo asíncrono, hoy explicaré como esperar a un thread en concreto y como realizar una finalización síncrona de forma adecuada.
Para finalizar una operación asíncrona de forma síncrona (bloqueando el hilo actual hasta que el secundario termine) podemos hacerlo de dos formas, llamando al método .EndInvoke del objeto delegado, con el inconveniente de que si tenemos definido un AsyncCallback y hay otro .EndInvoke allí recibiremos una “InvalidOperationException” en alguno de los dos sitios con el mensaje “EndInvoke can only be called once for each asynchronous operation.” que viene a decir “EndInvoke solo puede ser llamado una vez por cada operación asíncrona” con la molestia que ello conlleva; la forma elegante es utilizar el método “IAsyncResult. AsyncWaitHandle.WaitOne” que causará la finalización síncrona pero sin modificar el comportamiento que habíamos previsto en un principio, de esta forma podemos forzar la espera a la finalización de un determinado hilo ó grupo de hilos que por ejemplo realizasen tareas que habría que completar inevitablemente para poder continuar, con la ventaja de que se ejecutarían de forma paralela.

El ejemplo esta basado en el del ejemplo anterior, Modelo Asíncrono. Parte II, control.

Modelo Asíncrono. Parte II, control.

Como continuación de Modelo Asíncrono. Parte I, invocación, hoy ejemplificaré como controlar el flujo de operaciones asincrónas asegurando el que no haya más de cierto número de operaciones en ejecución al mismo tiempo. Como anteriormente, recomiendo leer la documentación sobre el modelo asíncrono de MSDN.

¿Cómo controlar el nº de operaciones asíncronas que están en ejecución? Si estamos sobre una máquina SMP y cada thread (cada operación asíncrona se lanza en un thread en segundo plano) consume una CPU por completo por tratarse de una operación local (ie: manejo de archivos de texto, descifrar archivos, etc..) ó cada thread provoca que un servicio de la máquina consuma una CPU entera (ie: realizar una conexión a Oracle y lanzar una query tremebunda) es importante poder controlar en todo momento cuando son lanzadas esas operaciones, que número de operaciones concurrentes hay en cada momento y cuando lanzar más.

Modelo Asíncrono. Parte I, invocación.

Una de las cosas que definitivamente más me gustan de programar en .NET es el modelo asíncrono de desarrollo. No solo es una técnica para poder ejecutar tareas en segundo plano, es todo un planteamiento a la hora de diseñar el comportamiento de nuestras aplicaciones. Da más escalabilidad que el modelo multithreading tradicional y sobre todo deja un código más claro (a mi gusto claro ). Atrás quedan aquellas largas líneas con ParameterizedThreadStart, los objetos Thread, los eventos para devolver resultados y otras perlas que hacian un poco tediosa la programación multihilo tan necesaria cuando trabajamos con máquinas SMP ó/y cuando hacemos uso de recursos con una latencia considerable.

Como no puedo ni extender ni completar más la excelente documentación sobre el tema que existe en MSDN, escribiré una serie de artículos con pequeños ejemplos explicados, que muestren la sencillez del proceso y los truquillos que he ido aprendiendo con el tiempo. Colgaré aquí también los proyectos comprimidos en .Zip para quien lo quiera descargar. Si necesitais una explicación más profunda sobre el tema teneis un excelente artículo en MSDN titulado Llamar a métodos sincrónicos de forma asincrónica.

En este primer ejemplo, mostraré lo básico, como llamar a una función de forma asíncrona y obtener un resultado de salida.

Consumir webServices asíncronamente.

Cuando se trabaja con webservices por ejemplo en una SOA, es importante tener en cuenta que desconoceremos cuanto tiempo va a tardar en respondernos un servicio en un momento determinado ya que desconocemos tanto el estado de la red (latencia, convergencia routing, ancho de banda, etc…), como el estado del servidor, como el estado de los servicios secundarios de los que depende el servicio (SQLServer, ActiveDirectory, Exchange,..etc..), solo hay que ver las 8 mentiras de la computación distribuida .

Como desconocemos este tiempo de respuesta, una espera larga puede dejar nuestra aplicación cliente aparentemente “colgada” esperando una respuesta del servidor, para evitar esto se pueden hacer llamadas asíncronas a la hora de consumir un webservice como explicaré a continuación y ser notificados de la finalización del método por medio de un evento como en muchas clases de la BCL que implementan el método .BeginXXX() y el evento .EndXXX.