¿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.