Slashdot Mirror
Apple's Grand Central Dispatch Ported To FreeBSD
bonch writes "Apple's Grand Central Dispatch, which was recently open sourced, has been ported to FreeBSD and is planned to be included by default in FreeBSD 8.1. Also known as libdispatch, the API allows the use of function-based callbacks but will also support blocks if built using FreeBSD's clang compiler package. There's already discussion of modifying BSD's system tools to use the new technology." The port was originally unveiled last month at the 2009 Developer Summit in Cambridge. Slides from that presentation are available via the Dev Summit wiki.
Apple maintains their own gcc fork which supports blocks/closures.
Do you even lift?
These aren't the 'roids you're looking for.
Grand Central is not introducing multithreading - it's introducing comprehensive thread management. So, how many threads are you going to spin for that task? Too many, and you waste a lot of time on thread management and preemption. Too few, and you have processors sitting idle. Now how will you handle this with multiple CPU's? Multiple cores? Hyperthreading? Different cache amounts and layout? OpenCL and GPU processing? Do you know what the rest of the operating system is doing to plan appropriately?
In short, your program can at best make a stab at these issues, and possibly even do a reasonable job if you put a lot of time, effort, and profiling into it. Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
It's good stuff. And Apple gave it to the community (much like WebKit enhancements, launchd, etc).
I don't know what kind of crack I was on, but I suspect it was decaf.
While you certainly don't deserve a "Troll" rating, the real improvement GDC brings over current implementations of concurrency is that one central authority is aware of all GDC enabled applications, and can therefore make decisions with knowledge of the entire system load and its capabilities when spinning of threads. When you spin of threads independently in each app you have to guess what the rest of the system looks like. You also have to either guess, investigate or have the user configure the general capabilities of the system.
Ars Technica has a great overview of what GCD is, and why it's important.
I haven't done much multithreaded programming in C, although this looks like an absolute godsend to those who do. Maybe someday we can actually have a modern desktop as responsive as BeOS was...
The article also contains a bit of information about Apple's compiler strategy and refinements to the C language itself. Most of these have been open-sourced under a permissive license, which is pretty damn cool.
-- If you try to fail and succeed, which have you done? - Uli's moose
Yep, apple didn't give back all their code on WebKit, or all of Darwin, or all of launchd, or all their patches on zfs, or their code on MacPorts, or darwin streaming server, or CalDav, or iCal format, or their Calander server, or their code on their X server, or their code on ruby, or a bunch of code on smart card services...
Wait, yes they did.
In your zeal to take one statement out of context, you missed the point of the framework. Using dispatch queues, I don't have to create threads, an expensive operation, and I don't have to agonize over performance profiles to determine the right number of threads to use. The operating system automatically maintains a global pool of worker threads based on available system resources, and you submit an asynchronous block of code which the system will assign to a thread and run for you based on current system state--that's what the "automatically distribute their work across all available cores" part means. Quite different from merely creating a pthread. Your code will run in an optimal number of threads for the system it's on, whether it's a Mac Mini Core Solo or an eight-core Mac Pro.
You can even distribute the iterations of a for-loop across queues using dispatch_apply(). Imagine doing a lot of expensive work on items in a collection, automatically threaded for the cores of the system it's running on. Here's an intro to Grand Central Dispatch. The followup articles on the site are also recommended.
The API to submit a block for asynchronous execution is very simple:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
do_something_computationally_expensive();
});
Posting anonymously since my "bonch" account has been modbombed.
A massive case of NIH from the GCC team with regard to Apple. See also the patches that Apple submitted well over a year ago adding declared property support to GNU gcc. I found it easier to write all of the code required for clang to support the GNU Objective-C runtime than make even small changes to Objective-C support in GCC (in spite of not having used C++ for a few years and really hating the language).
Oh, and I've had blocks working with clang on FreeBSD for quite a while (since several months before Apple publicly released an OS supporting them, in fact). I added the required runtime library support into Etoile's ObjectiveC2 framework a while ago, which also provides the run time support for most of the Objective-C 2 features. This framework is going to go away soon, because I'm now maintaining a fork of the GNU Objective-C runtime in the GNUstep repository, which merges these improvements and also incorporates most of the ideas from my experimental Objective-C runtime library (without breaking backwards compatibility, although you don't get all of the features if you don't use the new ABI).
By the way, porting to *BSD is much easier than porting to Linux. Libdispatch is based around the kqueue mechanism for unifying kernel event sources, and there is currently no in-tree equivalent for Linux. There are four out-of-tree sets of patches providing equivalent functionality (that I know of, there may be more), as is common with Linux development. On Solaris you can do the same thing with completion ports, which are roughly semantically equivalent but have a different interface.
I am TheRaven on Soylent News