One of the main new features in Apple's new Snow Leopard operating system has been released as open source. Apple has released the code of the userland portion of its Grand Central Dispatch technology under the Apache License, version 2. Mac OS X also has kernel support for Grand Central Dispatch, which is also released as open source via the XNU project. While we're at it, let's take this opportunity to look into exactly what Grand Central Dispatch is.
To read all comments associated with this story, please click here.
Member since:2005-07-06
How is this different/better/revolutionary from ThreadPool? Just that fact that its at the OS level instead of the runtime level?
So you ignore a 23 page article from Arstechnica; sufficient space spent to explaining GCD, and yet, you still see fit to whine on this forum that it is little more than 'marketing fluff'.
Member since:2005-06-29
Or, he's asking a legitimate question about what sets GCD apart.
Siracusa explains:
Member since:2008-12-26
dotnet certainly didn't invent threadpool ;-).
Threadpool as such is trivial. GCD manages the threadpool by looking at how busy the CPUs are, and is per-OS instead of per-application.
Member since:2006-01-25
Its more than a threadpool, but I don't if its as big of a deal as it has been made out to be... It needs a few months as least so that the tires can get kicked so to speak.
Anyway, how it is different from a .net threadpool:
1. It isn't a class instantiated in your code. It is an always running background daemon.
2. It knows the topology of the machine it is running on, i.e. how many sockets and cores are available. The primary benefit of this is that you do not have to configure the size of the pool - you just let it handle that itself.
3. In the traditional threadpool approach each application manages its own (probably differing) implementation of a threadpool, and since they do not know of each others existence they often don't have enough information to make the best decisions for the system as a whole. GC is a global threadpool, and as such it has a much broader view of the system and can therefore make better decisions.
4. It is designed to execute closures (Apple calls them blocks, same thing). While this is a restriction, some people consider it a good one because it eliminates a lot of potential blocking issues.
5. Its completely dynamic and requires no pre-planning. By that I mean your code does not (and by definition should not) be concerned with how many threads will be needed or even if your code will actually end up running in parallel or synchronous.
5. It supports FIFO queuing (not unique, but not a common attribute of most threadpool implementations)
6. As I understand it (I may be wrong) it appears to be a M:N threading model, i.e. userspace threads. As such, the GC "threads" themselves are very lightweight.
The bad (or at least potentionally bad):
1. For other platforms, if it gets adopted, it is unclear at this point how things would work, since it requires support for closures, and there are no existing C compilers (besides Apples) that support closures.
2. I may or may not be possible to use it from VM based langauges (i.e. .net, java), but frankly for those types of environments it doesn't make all that much sense either. You would probably want something like it implemented within the VM, it makes more sense there.
In my opinion, it seems like a pretty solid system (at least on paper). I think the main attraction is going to be in using it for hiding blocking behavior in UI applications, i.e. pushing code that might block the main UI thread off to the background. I don't see it as a replacement for a threadpool exactly, there are probably times you want to have application control of thread count and such... But I think its simplicity will attract a lot of users, at least on OSX. Whether it will catch on for other platforms is hard to say.
Member since:2006-03-23
This is an excellent summary of the differences between GCD and .NET's thread pool. I'm a .NET dev and I love the thread pool but I fully realize it's limitations when it comes to balancing tasks I submit to it with OS-wide task execution.
I do some OS X development for fun in my spare time and I'm looking forward to seeing what it's like. Just have to upgrade to Snow Leopard first.
Member since:2005-11-21
Anyway, how it is different from a .net threadpool:
1. It isn't a class instantiated in your code. It is an always running background daemon.
2. It knows the topology of the machine it is running on, i.e. how many sockets and cores are available. The primary benefit of this is that you do not have to configure the size of the pool - you just let it handle that itself.
3. In the traditional threadpool approach each application manages its own (probably differing) implementation of a threadpool, and since they do not know of each others existence they often don't have enough information to make the best decisions for the system as a whole. GC is a global threadpool, and as such it has a much broader view of the system and can therefore make better decisions.
4. It is designed to execute closures (Apple calls them blocks, same thing). While this is a restriction, some people consider it a good one because it eliminates a lot of potential blocking issues.
5. Its completely dynamic and requires no pre-planning. By that I mean your code does not (and by definition should not) be concerned with how many threads will be needed or even if your code will actually end up running in parallel or synchronous.
5. It supports FIFO queuing (not unique, but not a common attribute of most threadpool implementations)
6. As I understand it (I may be wrong) it appears to be a M:N threading model, i.e. userspace threads. As such, the GC "threads" themselves are very lightweight.
The bad (or at least potentionally bad):
1. For other platforms, if it gets adopted, it is unclear at this point how things would work, since it requires support for closures, and there are no existing C compilers (besides Apples) that support closures.
2. I may or may not be possible to use it from VM based langauges (i.e. .net, java), but frankly for those types of environments it doesn't make all that much sense either. You would probably want something like it implemented within the VM, it makes more sense there.
In my opinion, it seems like a pretty solid system (at least on paper). I think the main attraction is going to be in using it for hiding blocking behavior in UI applications, i.e. pushing code that might block the main UI thread off to the background. I don't see it as a replacement for a threadpool exactly, there are probably times you want to have application control of thread count and such... But I think its simplicity will attract a lot of users, at least on OSX. Whether it will catch on for other platforms is hard to say.
LLVM. End of story.
Member since:2009-02-11
I don't think that compiler support is the a problem for GCD adoption outside OS X. In UNIX, gcc is king and I expect Apple to push the blocks/closures extension support into gcc soon. Also, any compiler vendor can just copy the implementation of LLVM since it's licensed under the BSD license.
As for Windows, Microsoft is going to do whatever it wants no matter what Apple does.
Member since:2007-12-13
Member since:2006-02-05
Member since:2005-07-01
Member since:2009-06-19
Member since:2006-02-05
This isn't a thread pool, the .net equivilent would be this the TPL (and PLINQ) that is coming with .NET 4 http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
I haven't looked into GCD or TPL enough to comment, but they both (supposedly) address the same issue. IMO this isn't something you can just shoehorn in, you need it from the ground up (like scala)
Member since:2006-01-25
I had not seen this before. You are right though, it looks to be very much the same basic concept as GCD. Thanks for pointing this out.
One thing that I notice immediately: I like the TPL syntax a lot better. For example, Parallel.For is very similar to dispatch_apply, but it doesn't require you to declare a queue. It looks much less alien...
result[ i ] = doSomething(something, i);
});
just reads a whole lot nicer than
result[ i ] = doSomething(something, i);
});
of course, that is just syntactic sugar - they both do the same thing...
Member since:
2006-09-26
I had assumed this Grand Central was something magical that addressed a lot of the issues of parallel programming like concurrency and data sharing. After reading this, it sounds like it is .Net's (and I'm sure other languages) ThreadPool with a lot of Apple marketing.
How is this different/better/revolutionary from ThreadPool? Just that fact that its at the OS level instead of the runtime level?