De concurrencia, opiniones y la última moda...

Opté por compartir mi opinión como un blog post ya que el sistema de comentarios del sitio consideró como spam la respuesta que había escrito hace un par de días sobre la segunda parte de la serie de concurrencia que @ezamudio ha estado compartiendo. Y vaya que no juzgo a la inteligencia del sistema de comentarios, yo también consideraría lo que leerán a continuación spam, pero eso no me impedirá compartirlo. :)

En efecto como lo menciona @bferro, a veces la posición de una persona en torno a una tecnología, modelo o técnica puede llegar a ser radical o extrema, pero no deja de ser un simple punto de vista. Tuve la oportunidad de leer la versión electrónica del libro Programming Concurrency on the JVM de Venkat Subramaniam cuando era aún versión beta en The Pragmatic Bookshelf, incluso mucho antes de que incluyera mención de Akka (y vaya que el texto era algo diferente en cuestión a actores y otros modelos mencionados).

Volviendo al punto, la verdad decir que synchronized es un insulto a la concurrencia es realmente radical en varios aspectos. En los últimos años y en las diferentes versiones liberadas de la JVM, se han empleado justamente muchas técnicas para mejorar el rendimiento a bajo nivel de dichas construcciones, incluyendo las de intrinsic locking y obviamente la inclusión de primitivas CAS (compare-and-swap) con soporte a nivel hardware para obtener así algoritmos libres de candados o lock-free, tal es el caso de varias de las colecciones disponibles en java.util.concurrent. No muchas de estas cosas son por gusto sino también por mantener el suporte a aplicaciones legadas que utilizan dichos modelos para sincronizar acceso compartido a recursos. Por ejemplo, Intel tiene un sitio especializado a cuestiones de programación concurrente y paralela, dónde comparten desde noticias, artículos y herramientas para evaluar niveles de concurrencia y/o paralelismo en aplicaciones: Concurrency Improvement Center. A qué voy con esto? Si bien los procesadores no han mejorado en cuestiones a velocidad y frecuencias de reloj, lo han hecho en cantidad de núcleos y tecnologías afines para poder ejecutar más de una instrucción en cierto instante, mejorando incluso cuestiones de concurrencia a muy bajo nivel.

Los modelos que presenta Venkat justamente no son nada nuevos (pero son geniales); últimamente los creadores de lenguajes de programación quieren implementar dichos modelos de concurrencia como parte del núcleo del lenguaje mismo, cómo es el caso de Clojure, Scala y obviamente Erlang, que en mi opinión tiene mención especial ya que la mayoría de los lenguajes y algunos frameworks modernos intentan también basar su modelo de actores y concurrencia en general en este lenguaje. Caray, incluso puedo decir que el conocer estos modelos y otros ya se está volviendo mainstream :)

Por otro lado, los modelos mencionados: Software Transactional Memory (STM) y Actors son unos de tantos, que como ya mencioné, explotan ciertos aspectos de la concurrencia que hace innecesario el uso de candados y/o el model clásico de sincronización, ya que la premisa primordial es el uso de variables u objetos inmutables para evitar efectos colaterales durante el ciclo de ejecución, incluso cada uno otorgando peculiaridades en cuestión a tolerancia a fallos, escalabilidad, etc. Como ya @ezamudio también mencionó, no todas las aplicaciones, y sobre todo aquellas que son altamente transaccionales pueden beneficiarse simplemente de usar dichos modelos y esperar que magicamente sucedan las cosas; no se diga cuando se trata de un entorno masivamente distribuido con acceso compartido a datos. Se me ocurre como ejemplo mencionar lo que hace Terracota, compañía que ha trabajado por los últimos 5+ años en otorgar soluciones empresariales para crear un entorno distribuido sobre varias JVMs, extendiendo las características de básicas como synchronized o intrinsic locking de manera distribuida y transparente al usuario. Otro caso es el del uso de candados distribuidos, dónde tecnologías como las de las bases de datos de Oracle para sincronizar recursos entre RACs utilizan; qué hay de técnicas utilizadas para garantizar entrega única o incluso eliminar duplicados de colas de mensajes distribuidas?

Otra técnica que tampoco es nada nueva y es ampliamente utilizada es el uso de co-rutinas o la de light threads, que lenguajes como Ruby, Erlang o incluso el framework Akka implementan para crear threads que funcionan por medio de un ciclo de eventos (event loop) logrando así la creación de menos threads por parte del sistema operativo, permitiendo que el CPU tenga menos busy-waiting y cambios de contexto en ellos, aún ante la presencia de operaciones o procesos que usan E/S intensivamente. Otra cosa no mencionada (o al menos que no he leído que se haya mencionado en su charla) es el uso de Dataflow variables, que fueron tomadas del lenguaje Oz (como por ejemplo) e implementadas en Akka, pero que obviamente tampoco es una técnica moderna y el ingrediente secreto en ella es el crear un entorno de ejecución determinístico (similar a Futures, pero mezclado con el uso de light threads las hace aun más poderosas).

Moraleja de la historia? Venkat definitivamente le dió al clavo diciendo que no todo es synchronized en Java, y me da gusto que incitó a muchos a investigar y analizar otros modelos de concurrencia. Yo soy de la idea de que entre más técnicas y modelos conoces y aprendes, más fácilmente puedes tomar comentarios como los que hizo sobre synchronized o el de dejar de utilizar Java sin necesidad de asustarte. Este tipo de comentarios hay que tomarlos con un grano de sal y no siempre creer al 100% lo que se escucha y lee sin antes uno no hacer la tarea de profundizar en ello y formarse su propio criterio.

Pero, qué hay de la parte distribuida de estos modelos? esa es otra historia, diría mi nana, pero definitivamente otro reto que lenguajes como Erlang ha implementado y madurado satisfactoriamente en alguno de ellos. Me pregunto si algún día algún lenguaje se atreverá a implementar Linda/Tuple Spaces de manera nativa :P

Bueno ya me extendí demasiado y lo único que quería decir era que no se tomen todo tan a la ligera y mejor aprendan a formularse su propio criterio.

Saludos,