Programación Concurrente
Tengo en mis manos la revista Dr.Dobbs de Marzo 2005, cuyo tema principal es la computación a 64bits.

La nota escrita por Herb Sutter titulada "Un giro fundamental hacia la concurrencia en el software" muestra un tema que se relaciona mucho con la temática de este blog.

Y el subtítulo dice "Los días de la comida gratis están por terminar" (Your free lunch will soon be over), refiriendose al fenómeno de los procesadores y el software, "No importa que tan rápidos sean los procesadores, el software constantemente encontrará nuevas formas comerse la velocidad extra". "Si tenemos un procesador 10 veces más rápido, nos daremos la libertad de hacer el software 10 veces menos eficiente".

Si tu eres un desarrollador de software, seguramente haz leido, comentado o creido que no importa que tu aplicación sea un poco lenta, los futuros procesadores serán más rápidos.

La Ley de Moore ha contribuido en gran medida a este autoconvencimiento y hemos dejado de lado la optimización de los programas.

Todo crecimiento exponencial se corta en algun momento. En el 2001 salieron los primeros procesadores de 2Ghz y según la Ley de Moore, en este año ya se debería estar anunciando un procesador de 10Ghz, o con 4 veces la potencia de aquel procesador. El lanzamiento del procesador de 4Ghz ya no tiene fecha probable de salida.
Es correcto que lo importante no es la velocidad, sino la potencia.

¿Pero cómo se logra más potencia sin aumentar la velocidad ?

Las 3 cosas que se usarán para ello serán:

1. Hyperthreading (ya existen)
2. Multiprocesador (Alpha y PowerPC tienen, Intel y AMD sacaran este año)
3. Mayor cache (en constante crecimiento)

Hoy en día la mayor parte de los programas son de un solo proceso (single-thread) y sólo una de las 3 formas de mejorar la potencia de procesamiento beneficia a este tipo de programas, el aumento de cache (la principal diferencia entre los procesadores económicos y los de alta gama es una mayor cache).

Por supuesto que para poder aprovechar un multiprocesador será necesario contar con un sistema operativo acorde, WinNT, 2000 o superior, Linux, Novell o algún Unix.

De todas formas, los programas de un solo thread se beneficiarán porque el sistema operativo podrá repartir algo de carga dandole tareas al otro procesador, pero de todas formas nuestro programa no podrá ir más rápido que el caso ideal de que el programa tuviera todo el poder de un solo procesador para el solo.

Cuál es la solución ?

Como primer medida, dedicarle tiempo a la optimización, los procesadores futuros no nos darán mucha más velocidad para combatir nuestra inoperancia. De todas formas, podremos tener un software bien optimizado y aún así con problemas de performance.

Como segunda medida, la programación concurrente. Esto no es algo nuevo, pero hoy en día sólo una mínima parte de los programas lo son. Herb Sutter comenta que las verdaderas revoluciones de software no se basan en un producto determinado de una gran empresa de software, sino en tecnologías que tienen años e incluso décadas de desarrollo.

La POO surgió en los años 60 con Simula, pero no llegó a una revolución hasta los 90.

Las nuevas tecnologías pueden ser muy interesantes, e incluso beneficiosas, pero las revoluciones que cambian la forma de escribir los programas llevan años de desarrollo.

La concurrencia será la próxima gran revolución de como debemos escribir los programas.

Beneficios y costos de la concurrencia.

El primer y natural uso y beneficiario de la concurrencia es la separación de flujos de ejecución lógicamente independientes. Ej un servidor web atiende a cada solicitud de página en un hilo de ejecución separado.

El segundo uso es el de lograr una mejor performance al hacer tareas paralelas.

Sin embargo, en la ejecución, la concurrencia tiene costos.

1. La sincronización del acceso a los recursos compartidos por medio de bloqueos.
2. No todos los procesos pueden dividirse en tareas concurrentes o usar rutinas concurrentes o ser usados concurrentemente.
3. Pero el gran problema es que la concurrencia no es tan sencilla de diagramar, programar y probar como la programación serial.

La programación concurrente es probablemente tanto o más dura de aprender que la programación orientada a objetos.
Es necesario aprender y comprender muchos nuevos conceptos (que es una race conditions, que es un deadlock, que construcciones actualmente serializadas se pueden ejecutar en paralelo, etc. )

La conclusión de Herb Sutter es que éste es el momento de tomarse un buen tiempo a revisar el diseño de su aplicación y determinar que operaciones pueden beneficiarse de la concurrencia.

Muy pocas aplicaciones son naturalmente concurrentes, La mayoría no lo son. Incluso cuando sepa exactamente donde está limitado por la CPU, se encontrará con dificultades para encontrar como paralelizar tales operaciones. Son todas suficientes razones para comenzar lo antes posible a pensar en la concurrencia.

Algunos compiladores podrán ayudar reordenando instrucciones y detectando zonas paralelizables, pero no debemos esperar mucho.

Nada puede ser mejor que un buen trabajo de paralelización de su programa secuencial haciendo verdaderas rutinas que se ejecuten en forma concurrente.
- escrito por Walter Negro @ 1:47 a. m.