2 de septiembre de 2009

¿Grand Central Dispatch, retorno de M:N?

Como es sabido, a grandes rasgos hay dos maneras de implementar threads en los sistemas operativos, 1:1 y M:N, durante años se mantuvo que M:N era lo más apropiado, sin embargo 1:1 acabó ganando la batalla. Solaris, que era uno de los mayores representantes de M:N, hizo que en Solaris 9 cambiara por defecto a 1:1 por la simple razón de que era más rápido y tenía mucho menos código, Linux 2.6 optó tambien por 1:1 en su NTPL. Con el tiempo, NetBSD y FreeBSD, que se resistían, tambien se pasaron a 1:1.

En OS X 10.6 Apple ha implementado una serie de mecanismos con el propósito de facilitar a los programadores la utilización de todos los cores y procesadores de los sistemas modernos. Es muy recomendable leer la parte del análisis de OS X 10.6 de Arstechnica que habla sobre este tema, concretamente de la página 10 a la 14. Esos mecanismos, que son una de las cosas más interesantes que se han hecho en OS X (no faltará quien diga que eso de gestionar threads es viejo y que no tiene nada de interesante, o que me cite a BeOS sin pararse a leer la parte del artículo donde explica claramente por qué lo que ha hecho Apple es mucho más práctico y eficiente que el "pervasive multithreading"). Todo ello se basa en unas extensiones a C y en una especie de gestor de threads llamado "Grand Central Dispatch".

Este "dispatcher" se encarga de mantener unas listas de los "bloques" que las aplicaciones crean gracias a la ya referida extensión de C, y repartirlos entre unos pocos threads creados a tal efecto. Se podría decir que huele un poco a M:N, es decir, un proceso que ofrece su contexto de ejecución a threads que son controlados por una especie de gestor de procesos (Grand Central Dispatch) que funciona en espacio de usuario...¿o no?

En cierto modo, a primera vista hay analogías, pero mirado en detalle no creo que se pueda afirmar que tiene que ver con M:N. Fundamentalmente porque M:N es un diseño para implementar threads, mientras que GCD es un sistema que gestiona bloques. Aunque estos bloques podrían compararse con threads no parece apropiado hacerlo. Pretenden ser más bien una especie de subunidades de trabajo, mientras que los threads son más bien subprocesos (si alguien tiene opinión al respecto sería interesante). Se podría argumentar que un thread puede utilizarse tambien para crear "subunidades de trabajo" en un programa, pero tambien puede no serlo. Un bloque hace su trabajo y desaparece, un thread puede durar tanto como el proceso que lo creo. De ahí que GCD no sea (y quizás ni tenga) en realidad un verdadero "gestor de procesos", porque no reasigna el tiempo de ejecución de un bloque-proceso a otro dependiendo de diferentes variables, como haría M:N, tan solo se limita a asignar un bloque a un thread y esperar a que termine (aun está por ver/documentar como gestiona GCD un bloque que se queda en un loop). Pero todo este tema de GCD es muy nuevo, y habrá que ver como evoluciona con los años, y como lo imitan en otros SOs que reimplementen la idea.

5 comentarios:

  1. Anónimo1:33 p. m.

    Gracias por la info, me tenía bastante intrigado que significaba esto... Pero una pregunta: ¿Cómo de un proceso normal que, supuestamente, es indivisible en bloques de ejecución (por ejemplo, si es una ejecución secuencial...) se puede dividir en diferentes bloques?

    A partir de este hecho es sencillo corresponder a cada nucleo con un thread que ejecute estos bloques. Si han conseguido, de alguna manera, dividir un proceso así, sin más, y esto funciona como dicen... Han hecho un gran avance en el multiprocesamiento ya que, hasta ahora, los núcleos nos servían para los threads creados por los usuarios (o los threads de kernel) que nada o poco tenían que ver.

    Lo que yo pensé que era, es una ayuda a los desarrolladores para crear aplicaciones con múltiples threads y así aprovechar esta tecnología... Vamos, una "librería" guay o un entorno cómodo para trabajar con Threads...

    Siento la chapa que te he dejado de comentario, pero me interesa bastante saber si MacOS ha mejorado "algo" o solo ha puesto iconos más grandes, cosas mas bonitas y eso...

    ResponderEliminar
  2. @Anónimo: Te recomiendo leerte el enlace a la review de Ars Technica. GCD no es algo automático, los programadores tienen que identificar y crear los "bloques" ellos mismos; la diferencia es lo sencillo que resulta para cualquier programador.

    ResponderEliminar
  3. Muy bueno todo tus articulos..

    Muy bueno esto, y me acabo de enterar de algo mas:
    http://www.faq-mac.com/noticias/37213/apple-hace-open-source-tecnologia-gran-central

    ResponderEliminar
  4. Anónimo11:57 a. m.

    Caramba, lo han abierto bajo una licencia Apache 2.0.

    ResponderEliminar
  5. Anónimo12:24 a. m.

    Eso es un thread pool. Y KDE 4 desde su primera subversión ya incluye uno.

    ResponderEliminar