Objetos concurrentes y en red.

Antes de abordar la implementación de aplicaciones paralelas y eminentemente estructuradas en un entorno orientado a objetos es preciso abordar las metodologías existentes para evitar caer en peligros de diseño que luego obligan a reescribir todo el código. Así lo primero que abordaré será un estudio de los patrones de diseño.
“Con la excepción de la música, se suele pensar que los patrones son diseños estáticos, de hecho es más sencillo y más cómodo pensarlos así -también mas absurdo-. La forma correcta de pensar en diseños que nos permitan evolucionar es pensar en una amalgama de componentes que interactúan entre si, unidos con algún tipo de marco normativo -restricciones o limites-.”
Durante los diez últimos años se han experimentado avances en el nivel de integración -VLSI- y en la fibra óptica que han impulsado la capacidad de cómputo hasta tres o cuatro órdenes de magnitud, y las velocidades de enlace en las redes hasta 6-7 niveles de magnitud -eso sin contar con lo que nos espera con las 10GB-Eth (ver siguiente post comentando esto). Asumiendo que estos ritmos de crecimiento en los órdenes de magnitud fueran constantes, al final de esta década podríamos tener:
a) Procesadores en nuestros equipos de sobremesa cercanos a los 100GHz.
b) Redes locales con tasas de transferencia cercanas a los 100Gbits/segundo.
c) Enlaces inalámbricos casi rozando los 100Mb/seg
y……..
d) Los BACKBONES con unas transferencias que superarían los 10Terabits/segundo.
Es más habrá billones de dispositivos enlazados en red deseando transimitir información que ha de ser procesada. Estos super ordenadores que esperamos tener, habrán de ser accesibles por todos nosotros y ser construidos con componentes relativamente comunes (cosa que hoy por hoy es imposible). Para maximizar los beneficios de estos supuestos avances en la tecnología hardware, la calidad y la productividad de las tecnologias empleadas para desarrollar el software concurrente y en red deben verse igualmente incrementadas. Aqui nos encontramos con dos aspectos opuestos, el hardware tiende a ser cada vez más estable, más reducido y más rápido, en contraste con las tecnologias sw que pretendo crear que son concurrentes y en red, que en su lugar son cada vez más grandes, menos probadas, más lentas y más expuestas a errores que sus predecesoras tecnologías (sin ser detallistas, la tecnología orientada a objetos está con nosotros desde los 60 y aún hoy dia no se puede considerar una tecnología estable).
Aunque las tecnologías hw han aliviado relativamente la necesidad de optimizaciones guiadas por operaciones a bajo nivel desde la capa software, el coste del ciclo de vida y el esfuerzo necesario para desarrollar software se sigue viendo como una magnitud en alza. La disparidad entre la tasa tan rápdida de crecimiento que encontramos en el hardware y el lento progreso por el que se caracteriza el software proviene de los sisguientes puntos:
———–
a) Complejidades inherentes y complejidades accidentales: En el software concurrente y orientado a la red podemos encontrar complejidades inherentes y relacionadas con el entorno como deadlocks distribuidos (si los deadlocks que se generan en un proceso ya son complejos, añadele red al problema), fallas parciales, el QoS …. Complejidades accidentales, provienen de las limitaciones impuestas por las herramientas de desarrollo, la tecnología empleada, como las APIS no portables o los depuradores de código en sus versiones paralelas / distribuidas que dejan mucho que desear. Irónicamente, muchas de las complejidades accidentales provienen de las decisiones técnicas que los mismos desarrolladores adoptan (ejemplo: decantarse por lenguajes de bajo nivel y herramientas que escalan mal al afrontar los entornos distribuidos y concurrentes).
b) Métodos inadecuados y técnicas inadecuadas : Antes de abordar el cambio de la aplicacion me encuentro que las técnicas de desarrollo de software que me han enseñado y los métodos de análisis de software que me han enseñado se centraban siempre en construir aplicaciones orientadas a un proceso sin concurrencia (single threaded) y siempre pensando que la relación QoS era la mejor -vamos que no se requerían optimizaciones ulteriores para que la aplicación fuera operativa- así pues es necesario bucear por patrones de diseño y acuñar para mi los resultados de los que han aprendido a base de prueba – error y tras mucha lucha con detalles especificos de las plataformas. (Otra excusa para usar patrones).
c) Continua aparicion de conceptos y técnicas clave : No es la primera vez que me encuentro con tecnicas incompatibles para problemas ya resueltos. Un ejemplo es la cantidad de sistemas operativos en tiempo real o de propósito general que gestionan los mismos recursos hardware (esta “incompatibilidad” extrema es tambien gran origen de problemas) y si menciono la cantidad de apis que se hayan en los sistemas operativos y que entre ellas son incompatibles …..
————–
Si se hubiera dedicado esfuerzo a mejorar las solucioes ya existentes en lugar de abrir un amplio campo de soluciones, los que ahora nos enfrentamos a la concurrencia distribuida quizás tendríamos menos complicaciones.
Un patrón es una solución recurrente para un problema determinado, es una planitlla para un tipo de problemas. Los patrones ayudan a capturar y reutilizar la estructura dinámica y estática y la colaboración de los componentes clave en los diseños software.
Cuando varios patrones ya creados y que se relacionan en algún modo -o para alguna solución más compleja- entonces se crean un vocabulario especifico para hablar sobre los problemas en el desarrollo del software y proporcionan un proceso para la resolución ordenada de estos problemas.
Aplicando y estudiando patrones y lenguajes basados en patrones, podemos -eso espero- escapar a los errores de los que sólo se escapaba tras un proceso largo y costos de aprendizaje.
Hasta hace poco los patrones para los desarrollos concurrentes sólo existían enterrandos entre complejas marañas de código fuente. Ahora inicio la búsqueda de patrones que puedan tejerse para dar luz a un marco de trabajo en el área de la reconstrucción tridimiensional de imágenes médicas.