How does Grand Central Dispatch really use the operating system?

Question

I have a solid idea how GCD works, but I want to know more about the touted "operating system management" internals. It seems almost every technical explanation of how Grand Central Dispatch works with the "Operating System" is totally different. I'll paraphrase some of my findings.

"It's a daemon that's global to the OS that distributes tasks over many cores."

I'm not stupid enough to believe that.

"Support is built into the kernel to be aware of all GCD applications. GCD applications work in concert with the kernel to make logical decisions on how to manage threads within the application."

Sounds like this synchronization scheme would be much slower than just managing the logic within the application.

"GCD is exists solely in the application and uses current system load as a metric to how it behaves."

This sounds more realistic to me, but I only saw a statement like this in one place.

What's really going on here? Is it just a library, or is it an entire "system"?

Answer 1

It is a library, but there are some kernel optimizations to allow for system level control. In particular, what happens is that there is an addition interface pthread_workqueue that allows GCD to tell the kernel it wants a thread to run some particular function, but doesn't actually start a thread (it is basically a continuation). At that point the kernel can choose to start that continuation or not depending on system load.

So yes, there is a global system wide infrastructure that manages GCD threads in the kernel, and the second answer is the correct one. The mistake you are making is thinking that there is synchronization going on there that is going to cost something. The scheduler is going to run no matter what, what GCD has done is used a new interface that lets the scheduler not only decide whether or not to run the threads based on their relative priority, but whether or not to create or destroy the threads as well.

It is a (significant) optimization, but it is not strictly necessary, and the FreeBSD port doesn't actually have support for the system wide stuff. If you want to look at the actual interfaces, here is pthread_workqueue.h, the implementation is in Apple's pthread.c, and you can see the stub entry point the kernel uses for starting up the workqueues in their asm stubs in start_wqthread.s. You can also go crawling through xnu to see how it upcalls into the stub if you really want.