INFOLINUXBLOG.com

-->

En la vida y al mismo tiempo en los ordenadores las cosas son concurrentes. Una palabra muy poco corriente en el lenguaje no informático, que viene a ser multihabilidad, lo que los ingleses denominan multitask y nosotros multitarea. Consiste en eso en la envidiada por mí capacidad de hacer varias cosas a la vez. Aquí explicaré su uso y evolución en la informática con palabras profanas, para que espero que todo el mundo pueda seguirme.

Resulta que no se me da muy bien hacer dos cosas, menos tres, a la vez y a los ordenadores tampoco. Realmente un ordenador habitual, de esos con un solo procesador (ya no están muy de moda vale. Pero hay que empezar por el principio para entender las cosas), no es capaz de hacer dos cosas a la vez. Nos engaña, ejecutando pequeñas porciones de cada tarea tan deprisa que parece que las hace a la vez, pero no.

Este pequeño detalle hace que un sistema operativo, ya sea Linux o Windows, cambie de tarea cuando le da la gana, lo que recibe el nombre de cambio de contexto. Estos cambios de contexto están muy bien planeados y pensados (a lo mejor más en Linux ), nada queda al azar en esto de la informática. Resulta que hay complejas técnicas para decidir en qué orden ir ejecutando los procesos o aplicaciones.

Bueno que me pierdo, estos días estoy estudiando “sincronización de procesos” y “comunicación entre procesos”. Algo que siempre me ha parecido divertido, supongo que por su dificultad. Los lenguajes de programación en un principio estaban pensados para ejecutar instrucciones a machete, una tras otra. Pero resultó que apareció el paradigma (uno más) de la programación concurrente y demostró que a lo mejor dos tareas si se dividen el trabajo sucio son más rápidas. Hasta aquí todo parece lógico, el problema es que si “realmente” no se ejecutan a la vez como ya he dicho, no queda claro que velocidad se gana. El tiempo se gana en pequeñas “trampas” internas al núcleo.

Ahora todo el mundo habla de ordenadores multiprocesador, o multinúcleo, o las dos juntas. Resulta que a partir de ahora esto de la concurrencia es cada vez más eficaz. Sin embargo no muchos softwares y aplicaciones que existen hacen uso de este ventaja. Luego no se aprovechan estas tecnologías al 100%. Cierto es que si tenemos dos procesadores, el núcleo (el cerebro del sistema operativo) se encarga de hacer dos cosas a la vez, esta vez sí. ¿pero y si estas dos tareas se subdividen en otras?

Volviendo a los lenguajes, a muchos se les hizo un arreglo para adaptarse a los nuevos tiempos, lo cierto es que ya a finales de los 90 todo el mundo se frotaba las manos alegando que esto iba a ser la leche. Pero los paradigmas nuevos tardan en cuajar, díganselo a la programación orientada a objetos, pero eso es harina de otro costal.
El caso es que esos lenguajes “maquillados” son un infierno para el sacrificado programador, que dispone de lenguajes que fueron creados con este propósito.

Me gustaría mencionar 3 de estos lenguajes:

- ADA: Este lenguaje en sintaxis tan similar al Pascual, perdón Pascal, me marcó mentalmente. Fue el primer lenguaje que usé para esto de la concurrencia. Este lenguaje recibe su nombre en tributo a la que muchos consideran la primera informática, y es que sí también hay mujeres en este campo, Ada Lovelace. A esta mujer, que según las malas lenguas de la época se daba el lote con Babbage, debemos unas cuantas cosas los informáticos.
Bueno el caso es que lo utilizan fuertemente para lo que fue diseñado, aplicaciones geográficas y aeronáuticas. Hay satélites orbitando con sistemas operativos hechos en este lenguaje, aeropuertos usándolo… El caso es que este lenguaje es socialmente desmerecido a mi juicio, por su dificultad y lo rígido que es.

- LINDA: Este lo crearon 2 tipos de la universidad yankee de Yale. Se integra muy bien con otros lenguajes, lo que le permite hormonarlos para que sean concurrentes. Sus creadores lo llamaron así en honor a la actriz porno Linda Lovelace (que comparte apellido con Ada) famosa por su aparición en la película garganta profunda (Esto último lo he sacado de la Wikipedia avispaos). Parece ser que los dos fumaos no estaban muy contentos con el lenguaje ADA o con la persona en sí misma.

- ERLANG: Este lenguaje fue desarrollado por Ericsson y liberado antes de ayer como quien dice, 1998. Diseñado para funcionar, funcionar y funcionar. Es decir para que no deje de funcionar pase lo que pase, y que se puedan hacer cambios en caliente sin tener que reiniciar, está claro quien no ha usado mucho este lenguaje
En algunos de los blogs y páginas de algunas de las mentes más privilegiadas de la programación he leído que este lenguaje es potente e imparable. Sin embargo no debe ser comprensible por más de la mitad de la población mundial informática, ya que a la vez de tener el paradigma concurrente tiene otro que ocasiona fuertes dolores de cabeza a todo estudiante de Informática, el funcional ¡sí señor!

A partir de aquí me desmarco un poco, para los informáticos o aficionados muy serios. Entender la concurrencia es complejo al principio, en sí se basa en ideas felices que siempre que las tenemos nosotros suelen ser incompletas o inconclusas. Todos los mecanismos de concurrencia acaban resumiéndose en uno, los semáforos. Entender los semáforos, es entender la concurrencia. Luego ya vendrán: los monitores, mutexes o locks (semáforos binarios con nombre bonito), contadores de eventos, colas de mensajes, tuberías con nombre, sockets…

Ya que yo un día estuve perdido en esto y tuve que emplear mucho tiempo y esfuerzo quiero aclarar un par de cosas que pueden ahorrar quebraderos de cabeza. Para entender los semáforos el mejor libro que existe que haya caído en mis manos es:

“The Little Book of Semaphores” en la lengua de Shakespeare sí. Pero si no la manejas y estás en este gremio, deberías empezar con el inglés antes que con esto.
Este libro contiene la mayor colección de ejercicios sobre concurrencia, plantea los problemas habituales del principiante y además añade una metodología de aprendizaje que si se sigue, obliga a pensar hasta entender. Es un ejemplar fantástico.

Para entender la concurrencia conviene entenderla en sí misma, sin centrarse en ningún lenguaje específico, cada uno con sus ajustes y vericuetos. Después ya se puede uno embarcar en otros menesteres:

• Programación en Ada Wikilibros
• Threads C POSIX
• Concurrent programming with stackless Python. Y es que la pila en Python puede ser nuestra enemiga.

Hay que recordar también que “sincronizar” y “comunicar” procesos son dos cosas distintas. Pero se suelen hacer a la vez, ya que para comunicar muchas veces es necesario sincronizar. También es importante no perder de vista que concurrente no es lo mismo que distribuido, aunque parecido.

Si alguien llega hasta aquí, y aguanta el tostón y lo encuentra útil o entretenido, por favor no dudes en dejar un comentario para que lo pueda saber.

Artículos relacionados:

• No hay artículos relacionados.