我很清楚 GCD 是如何工作的，但我想更多地了解所谓的“操作系统管理”内部结构。似乎几乎所有关于 Grand Central Dispatch 如何与“操作系统”一起工作的技术解释都是完全不同的。我将解释一下我的一些发现。
“它是操作系统全局的守护进程
将任务分配给许多人
核心。”
我还没有傻到相信这一点。
“内核内置了支持
了解所有 GCD 应用程序。 GCD
应用程序与
内核做出逻辑决策
如何管理内部的线程
应用程序。”
听起来这种同步方案比仅管理应用程序内的逻辑要慢得多。
“GCD仅存在于
应用程序并使用当前系统
加载作为其行为方式的指标。”
这对我来说听起来更现实，但我只在一个地方看到这样的声明。
？它只是一个库，还是一个完整的“系统”？
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"?
发布评论
评论（1）
它是一个库，但有一些内核优化以允许系统级控制。特别是，有一个附加接口 pthread_workqueue 允许 GCD 告诉内核它想要一个线程运行某些特定函数，但实际上并不启动一个线程（它基本上是一个继续）。此时，内核可以根据系统负载选择是否启动该延续。
所以是的，有一个全局系统范围的基础设施来管理内核中的 GCD 线程，第二个答案是正确的。您所犯的错误是认为那里正在进行同步，这会付出一些代价。无论如何，调度程序都会运行，GCD 所做的是使用了一个新的接口，它让调度程序不仅可以根据线程的相对优先级来决定是否运行线程，还可以根据线程的相对优先级来决定是否创建或销毁线程。出色地。
这是一个（重要的）优化，但并不是绝对必要的，而且 FreeBSD 端口实际上并不支持系统范围的东西。如果你想查看实际的接口，这里是 pthread_workqueue.h，实现在Apple的pthread中.c，您可以在 start_wqthread.s。如果您确实愿意，还可以爬行 xnu 以查看它如何向上调用到存根中。
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_workqueuethat 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.