Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider) [LWN.net]

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 13, 2009 22:58 UTC (Sun) by mikov (guest, #33179)
In reply to: Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider) by malor
Parent article: Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

I don't think it is that clear cut. What happens for example if one task in GCD blocks on slow IO?

The kernel scheduler is in a much better position to arbitrate the available CPU resources. In theory a context switch between threads should not be much less efficient that switching between tasks.

In short, this seems mainly an attempt to work around the heavyweight and relatively inefficient threads in Mac.

OTOH, I think blocks (or closures in C) are very nice. They do not violate the spirit of C. I would love to see them in mainstream GCC.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 7:22 UTC (Mon) by malor (guest, #2973) [Link] (4 responses)

The difference between GCD and a kernel would appear to be this: the kernel doesn't spawn threads sequentially based on available hardware. It's designed to run all the threads "at once". It schedules all of them for CPU time in small slices until they complete, incurring extra overhead for doing so. If you spawn 500 identical threads, they will all finish around the same time, much more slowly than they would have if you'd spawned one thread per available processor.

This is what GCD is doing; it's offering a different service. Threads don't exist or run until there's room for them on the hardware resources, so there's no contention, and throughput is maximized. It's a combination of serialization and concurrency. If you spawn 500 GCD jobs on a quadcore box, it shouldn't finish them very much slower than if you'd spawned just four, because it will only run four at a time. Apparently, GCD also offers some functionality for groups and dependencies as well.

It's a different problem domain. The kernel could obviously do something like this, and might potentially be a better place to do so, but it would be somewhat atypical for the Linux kernel team to provide a rich, highly functional interface for programmers. They don't like to maintain that stuff, so they keep it as minimalist as possible. Exporting that kind of rich ABI would seem politically impossible, no matter how much sense it might otherwise make.

Plus, Apple doesn't control any kernel but its own, so doing it one level higher makes more sense from the standpoint of trying to spread the concept and their particular interface to that concept.

With it being Apache-licensed, though, it's not going to spread very far anyway, so they pretty much shot themselves in the foot.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 16:20 UTC (Mon) by epa (subscriber, #39769) [Link] (3 responses)

Why can't the kernel provide a batch scheduling class whereby threads or processes run in sequence? So if you have 2 processors, just start 500 threads but only two are scheduled, and others don't run until one of the first two threads finishes, or blocks for IO. That seems better than guessing how many threads to start at once.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 16:32 UTC (Mon) by jzbiciak (guest, #5246) [Link]

Indeed, it sounds an awful lot like the SCHED_FIFO scheduling class, except not quite as strict about the real-time priority.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 16:48 UTC (Mon) by malor (guest, #2973) [Link] (1 responses)

just start 500 threads

That seems better than guessing how many threads to start at once.

You're still more or less guessing with that 500.

And yeah, the kernel probably would be a better place, but this kind of rich management API seems very against the minimalist Linux kernel team ethos. It strikes me that they'd insist, whether rightly or wrongly, that an API with this much management (like dependencies and subqueues) would have to be implemented in user space, which goes right back to GCD.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 16, 2009 11:58 UTC (Wed) by epa (subscriber, #39769) [Link]

I'm not suggesting any kind of rich management API - just a scheduling class that runs threads one at a time and never pre-empts one thread to run another. If they are all batch jobs and all of the same priority, there is no need for preemption.

You're right, the choice to start 500 threads is itself a bit arbitrary. What I mean is if you know that (for whatever reason) you want to start 500, why hold back for fear of overwhelming the poor kernel with too many at once? Surely you should just be able to create them, and the kernel will decide for itself when to schedule each one.