While I'm sure the scheduler had to be changed to accommodate it, it's not primarily a new scheduler. It's really a sophisticated thread pool system implemented in the kernel and exposed to programmers through language extensions.

See http://en.wikipedia.org/wiki/Thread_pool_pattern for the basics on the idea - which has been around for a long time.

Thanks - this makes more sense. Just a scheduler wouldn't explain how "With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between."

Yeah, that sounds about right. It's a thread API that relies on applications providing "blocks" of work to the OS, and transferring their arguments and results around in message queues. So if you have five applications running, each of which has 8 threads to handle the needed parallelism on a Nehalem box, you don't need 40 separate threads and their stacks. The OS just spawns 8 threads.

That sounds OK, if kinda unexciting. I'd like to see some benchmarks vs. traditional threading before I commit to liking it. History is littered with cute new IPC mechanisms that didn't turn out to have the benefits promised. This sounds a lot like a combination of sysv message queues and solaris doors, neither of which managed to drive much real innovation.

The thread pool approach allows you to exploit much finer grain parallelism than explicitly fork/joining your own threads. So, an application that makes good use of this would probably have hundreds, if not thousands, of discrete work tasks (which I normally call "units of work," but Apple calls "blocks.")

What a thread pool infrastructure buys us is the separation of tasks (the bundle of information passed around the queues) from their execution context (in this case, a kernel thread). It puts a level of abstraction between what is executed and how that's executed.

At the risk of belaboring a point, this is an old idea - this is traditional multithreading. Java has a library for doing it, as does C++ (in Boost). A library for this kind of parallelism was, in fact, the first C++ library, written by Stroustrup. Even the Linux kernel uses this technique internally (by which I mean it's not exposed to applications at the user level). Cilk (the MIT project that spawned the company Cilk Arts which was recently acquired by Intel) is probably the best known example of providing language-level abstractions for this technique. (I reccomend their paper "The Implemention of the Cilk-5 Multithreaded Language": http://supertech.csail.mit.edu/papers/cilk5.pdf)

By pointing out that this is an old idea, I don't mean to denigrate what Apple has done. Execution matters, and from the looks of it, they've executed this well - they've got something working at the language and kernel level, which is non-trivial.