¿Cómo realmente utiliza Grand Central Dispatch el sistema operativo?

Question

Tengo una idea sólida de cómo funciona GCD, pero quiero saber más acerca de los componentes internos de "administración de sistemas operativos". Parece que casi todas las explicaciones técnicas de cómo Grand Central Dispatch funciona con el "Sistema operativo" son totalmente diferentes. Voy a parafrasear algunos de mis hallazgos.

"Es un demonio que es global para el sistema operativo que distribuye las tareas durante muchos núcleos."

No soy tan estúpido como para creer eso.

"El apoyo está integrado en el kernel para ser consciente de todas las aplicaciones GCD. GCD aplicaciones funcionan en concierto con el kernel para tomar decisiones lógicas en cómo manejar los hilos dentro de la aplicación ."

Suena como este esquema de sincronización sería mucho más lento que simplemente administrar la lógica dentro de la aplicación.

"GCD es únicamente existe en la aplicación y utiliza sistema actual carga como una métrica a la forma en que se comporta."

Esto me parece más realista, pero solo vi una declaración como esta en un solo lugar.

¿Qué está pasando realmente aquí? ¿Es solo una biblioteca, o es un "sistema" completo?

Answer 1

Es una biblioteca, pero hay algunas optimizaciones del kernel para permitir el control del nivel del sistema. En particular, lo que sucede es que hay una interfaz adicional pthread_workqueue que permite a GCD decirle al kernel que quiere que un subproceso ejecute alguna función particular, pero en realidad no inicia un subproceso (básicamente es una continuación). En ese punto, el kernel puede elegir iniciar esa continuación o no dependiendo de la carga del sistema.

Así que sí, hay una infraestructura global de todo el sistema que gestiona los hilos GCD en el kernel, y la segunda respuesta es la correcta. El error que estás cometiendo es pensar que hay una sincronización que va a costar algo. El planificador se ejecutará sin importar qué, lo que GCD ha hecho es utilizar una nueva interfaz que permite al planificador no solo decidir si ejecuta los subprocesos según su prioridad relativa, sino si crea o destruye los subprocesos como bien.

Es una optimización (significativa), pero no es estrictamente necesaria, y el puerto FreeBSD no tiene soporte para todo el sistema. Si desea ver las interfaces reales, aquí está pthread_workqueue.h, la implementación está en el pthread.c de Apple, y puede ver el punto de entrada del trozo que el kernel usa para iniciar las colas de trabajo en sus trozos asm en start_wqthread.s. También puede ir arrastrándose a través de xnu para ver cómo sobresale en el extremo si realmente lo desea.