Hace unos meses que Apple sacó a la venta la última versión de su sistema operativo, Mac OS X 10.6 Snow Leopard.
Esta versión es principalmente una versión de, como dicen ellos, afinamiento. No se han incorporado características nuevas sino que se han refinado las actuales dándole al sistema una mayor velocidad y estabilidad. Lo que sí han hecho es incorporar en el núcleo del sistema una tecnología que no se ve pero que sí se nota: Grand Central Dispatch.
GCD es una nueva tecnología que lo que hace es distribuir las tareas que tienen que hacer las aplicaciones en tareas más pequeñas para así aprovechar toda la potencia de las máquinas que tienen varios procesadores o varios núcleos por procesador, como viene siendo habitual en los ordenadores de hoy en día, no sólo los Apple.
Esta tecnología viene a solucionar el problema de la escasez de paralelismo con la que contaba Mac OS X, pero, más que por su incapacidad, por la desidia de los desarrolladores a incorporarlo en sus aplicaciones. Aunque tienen sus razones, claro, es bastante complicado sincronizar hilos cuando no tienes un API que te ayude a hacerlo.
GCD añade dos cosas al nuevo sistema operativo de Apple. La primera es lo que se conoce como un pool de hilos, es decir, en lugar de que cada vez que queramos realizar una acción de forma paralela creando un hilo para así aprovechar los diferentes procesadores, lo que hacemos es indicar al sistema que queremos realizar tareas paralelas. Es el propio sistema el encargado de crear los hilos correspondientes y de ejecutarlos con una de las tareas a realizar.
La diferencia con los hilos tradicionales es que los hilos de GCD ni se crean ni se destruyen (esto me suena), simplemente existe una o varias listas de estos hilos (el pool) donde cada tarea se va a asociando a cada uno de estos hilos hasta que termine. Una vez terminada la tarea, el hilo no se destruye, sino que vuelve a la lista correspondiente. Además, estas listas de hilos tienen diferentes prioridades con lo que se puede tener más precisión a la hora de ejecutar tareas.
Lo bueno que tiene esto es que el programador no tiene que preocuparse de nada más que de indicar cuáles son las tareas a realizar de forma paralela. El sistema se encargará de distribuirlas entre las distintas listas de hilos disponibles.
Pero para lograr esto, Apple se ha tenido que sacar de la manga una extensión para el lenguaje C de su compilador Clang. Esta extensión es lo que se conoce en otros lenguajes, como Java o Javascript, como closures. Las closures son funciones anónimas o funciones lambda, algo así como los punteros a funciones de C pero con capacidades extras, como el acceso a variables locales, que se puedan devolver por otra función o que se puedan declarar en línea.
A esto, los desarrolladores de Apple le llamaron bloques. Entonces un bloque sería un trozo de código ejecutable que se parece a una función pero que no tiene nombre (función anónima) y que puede acceder a las variables locales del ámbito donde se ha declarado. Y la sintaxis que han hecho es al mejor estilo de C: austera. Veamos unos ejemplos, aunque la forma de trabajar es similar a Java y Javascript pero con distinta sintaxis:
int b = 3
multiplicar = ^ int (int a) { return a * b; };
int x = multiplicar(2);
typedef void ( ^ my_block_type)(int count);
void repeat(int times,my_block_type block) {
for(int i = 0; i < times; i++) {
block(i);
}
}
repeat(10, ^ (int count) {
printf(“count = %d\n”,count);
});
Gracias a esta nueva extensión, con apenas trabajo por parte del desarrollador, se puede aprovechar toda la potencia de las máquinas multiprocesador. Y, realmente, cuando se dice con “pocas líneas” es cierto. Basta con identificar las tareas (ese es el trabajo difícil) y usar las funciones dispatch_* de la nueva API pasando como parámetro un bloque de código con la tarea a ejecutar. Es el sistema, de forma transparente, el que se encarga de distribuir las tareas en los distintos procesadores creando los hilos necesarios para ello o utilizando los que están en el pool.
La verdad es que hay que agradecer a Apple que por fin se pusiese las pilas en cuanto al rendimiento de sus sistema, que ya iba bien de por sí, pero siempre puede ir mejor, sobre todo por facilitar el paralelismo de tareas a los programadores. Y aunque esto está muy bien, todavía no he visto por ningún sitio cómo han solucionado el problema de la sincronización/comunicación entre tareas (a parte de la memoria compartida y semáforos, claro), ya que esta extensión es sólo para aprovechar las máquinas multinúcleo.
Y es que, a mi entender, creo que esta solución que tan bien les está yendo, es un parche para un problema que viene de lejos. Venga, va, aquí los abucheos por criticar el Mac OS X. Pero expongo mis razones:
Esta solución crea un pool de threads con los que, a partir de un momento dado, se empiezan a realizar tareas sin la necesidad de estar creando y destruyendo hilos continuamente sino reaprovechándolos. Existe más de un pool con diferentes prioridades para así gestionar mejor las tareas. Esta solución es así porque la forma en Apple que implementó los hilos en Mac OS X no es la de lightweight threads (hilos ligeros) sino la de hilos más parecidos a procesos que a hilos en sí.
Esta solución implica que la creación de cada hilo sea bastante costosa, aproximadamente unos 512 KB por cada uno, mientras que la solución de hilos ligeros, la que implementan BeOS y Haiku (sí, ha salido BeOS, ¿raro en este blog? 
) es la de verdaderos hilos ligeros, con lo que la creación de los mismos apenas lleva 50 KB (32 KB de memoria de pila y el resto de estructuras internas del kernel).
512 KB por hilo creado es mucha memoria utilizada. Y más teniendo en cuenta la cantidad de aplicaciones y servicios que se están ejecutando en un sistema operativo actual según se inicia. Por pocos hilos que crees estás consumiendo mucha memoria y hay que tener en cuenta que cuantos más hilos (ojo, con un límite), más paralelismo y mayor aprovechamiento del hardware. Y vale que ahora la memoria es barata, pero ¿los nuevos sistemas funcionarán en hardware antiguo? Quizás esto no sea una prioridad para Apple, pero siempre hay que pensar en todo.
Como comenté antes, tampoco sé exactamente como se sincronizan las tareas en Mac OS X, mientras que en BeOS/Haiku tenemos tres mecanismos muy ligeros para ello: semáforos, comunicación entre hilos y puertos. El problema es la complejidad a la que se enfrenta el programador para hacer esta sincronización, aparentemente solucionada en Mac OS X, pero que no debería ser un problema si existe una buena API dentro del sistema que lo facilite.
En conclusión (y ya para terminar este ladrillo de entrada) creo que Apple ha mejorado mucho su sistema con esta característica, tanto para los usuarios, aprovechando el hardware al máximo, como para los programadores, haciendo que con escasas líneas de código aprovechen mejor dicho hardware, pero sigo pensando que la solución inicial de hilos pesados no es tan buena como la solución de hilos ligeros.
