Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple's Grand Central Dispatch Ported To FreeBSD

ScuttleMonkey posted more than 3 years ago | from the new-toys-to-play-with dept.

Software 205

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.

cancel ×

205 comments

Sorry! There are no comments related to the filter you selected.

eat my shorts slashdot !! (-1, Troll)

Anonymous Coward | more than 3 years ago | (#29773401)

Eat my shorts slashdot !!

Bad Apple (5, Funny)

93 Escort Wagon (326346) | more than 3 years ago | (#29773419)

Always taking from the open source community, and never giving back!

No. Really? (0, Funny)

Anonymous Coward | more than 3 years ago | (#29773429)

Oh yes. Fanbois are already out?! They do it once, and Lo and Behold!!! THEY ALWAYS DO IT!!!

Re:No. Really? (5, Informative)

beelsebob (529313) | more than 3 years ago | (#29774073)

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.

Re:No. Really? (1, Redundant)

cinderblock (1102693) | more than 3 years ago | (#29774289)

You obviously know sarcasm when you see it... :-P

Re:No. Really? (1)

phantomcircuit (938963) | more than 3 years ago | (#29774351)

all their patches on zfs

Did they really have a choice there?

Re:No. Really? (1)

MMC Monster (602931) | more than 4 years ago | (#29774525)

They could have chosen not to ship with zfs support.

Given how little OS X supports zfs, they could have left it out without any big deal.

Re:No. Really? (1, Interesting)

phantomcircuit (938963) | more than 4 years ago | (#29774575)

So any modifications to ZFS that they included in their shipped product had to be distributed? GEEE THANKS FOR THAT APPLE and isnt webkit based on khtml?

Re:No. Really? (3, Informative)

zach_the_lizard (1317619) | more than 4 years ago | (#29774647)

Yes, WebKit is based on KHTML; Apple forked it, IIRC.

Re:No. Really? (0, Troll)

phantomcircuit (938963) | more than 4 years ago | (#29774771)

So we're supposed to be thankful for them following the terms of the license? yeah... that makes sense

Re:No. Really? (4, Insightful)

DurendalMac (736637) | more than 4 years ago | (#29774919)

Several things didn't need to be open sourced, such as WebObjects and GCD. Quit your crying. FOSS zealots love to whine about Apple only doing what's required, but they fail to realize that it's a symbiotic relationship. Apple can use existing code to fit their needs, and in return, the open source community gets all of the improvements made by professional coders. It's a win/win, but the mini-Stallmans will never see it that way.

Re:No. Really? (0, Troll)

postbigbang (761081) | more than 4 years ago | (#29775003)

Good grief: "professional coders"?????

Where do you think they got the code from in the FIRST PLACE????

And citing Stallman isn't a God-Win in a FOSS argument. Get real.

Re:Bad Apple (0)

Anonymous Coward | more than 3 years ago | (#29773971)

STFU...there's a reason they ported BSD rather than Linux...

Re:Bad Apple (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#29774021)

Yes, because Linux suffers from NIH something fierce, and won't use anything developed by anyone else.

Re:Bad Apple (0)

Anonymous Coward | more than 3 years ago | (#29774201)

Little touchy there, aren't we Mr. Shuttleworth?

Re:Bad Apple (0)

Anonymous Coward | more than 3 years ago | (#29774035)

Thanks for yesterday's trash.

They should use clang instead of GCC (0, Flamebait)

Anonymous Coward | more than 3 years ago | (#29773451)

I noticed in their last slide they asked how to put closures into GCC. Why bother? Just use the Apple LLVM clang front end where it is already implemented and ditch GCC altogether.

Re:They should use clang instead of GCC (4, Informative)

larry bagina (561269) | more than 3 years ago | (#29773501)

Apple maintains their own gcc fork which supports blocks/closures.

Re:They should use clang instead of GCC (1)

brass1 (30288) | more than 4 years ago | (#29774601)

Apple maintains their own gcc fork which supports blocks/closures.

The probability that Apple migrates away from gcc is approaching 1 at great speed.

Re:They should use clang instead of GCC (1)

bconway (63464) | more than 4 years ago | (#29774865)

And their fork is publicly available under the BSD license and in SVN for all to enjoy.

Re:They should use clang instead of GCC (2, Interesting)

bill_mcgonigle (4333) | more than 4 years ago | (#29775075)

Apple maintains their own gcc fork which supports blocks/closures.

why won't gcc take the patches?

Re:They should use clang instead of GCC (2, Informative)

Anonymous Coward | more than 4 years ago | (#29775189)

Because Apple is sticking with GPLv2

Apple's Grand Central Dispatch Ported To FreeBSD (-1, Offtopic)

omar.sahal (687649) | more than 3 years ago | (#29773467)

This would be interesting if BSD had not been dying. Netcraft now confirms it: It is official; One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test. You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

Re:Apple's Grand Central Dispatch Ported To FreeBS (3, Funny)

larry bagina (561269) | more than 3 years ago | (#29773513)

now it can die in parallel, optimized for the number of cores and other system activity.

Re:Apple's Grand Central Dispatch Ported To FreeBS (2, Insightful)

Anonymous Coward | more than 3 years ago | (#29773521)

Netcraft confirms it: This joke is dying.

Re:Apple's Grand Central Dispatch Ported To FreeBS (2, Funny)

omar.sahal (687649) | more than 3 years ago | (#29773607)

On September 9, 2005, *BSD was finally declared dead. The following obituary appeared in the Berkeley Observer:
  1. * BSD Obituary
  2. * BSD, 28, of Berkeley, CA died Monday, Sept. 19, 2005. Born July 3, 1976, it was the creation of a cluster of pot-smoking hippies who went to Illinois and came home with a reel of tape. Rather than smoke the tape, they uploaded it and hacked on it a little.
  3. * BSD was known for its C shell and early TCP/IP implementation. After being banished from UC Berkeley, it was ported to the x86 platform, where it fell into the hands of heavier pot-smokers who liked to argue. Soon, the project had splintered into 12 different Balkanized projects. Until its death, there was almost constant fighting in and amongst these groups, sometimes degenerating into out-and-out fistfights.
  4. * BSD is survived by its superior, Linux, as well as several commercial unix implementations. It may be missed by some who knew it, although most of them are said to be mere OS dilettante dabblers.
  5. A funeral will be held at 2 p.m. Thursday, Sept. 22, at the Berkeley Chapel on the UC campus, with interment to follow via the burning of the original *BSD tapes and scattering of the ashes over the San Francisco Bay. The Rev. Lou "Buddy" Stubbs will officiate.
  6. The family will receive friends from 7 to 8 p.m. Wednesday, Sept. 21, at the funeral home.

Re:Apple's Grand Central Dispatch Ported To FreeBS (1, Insightful)

Anonymous Coward | more than 3 years ago | (#29773975)

Meh..BSD isnt dead, pot smoking is good, and Linux is just for broke rejects who are mad cause they cant afford MS. Its hardly superior to anything, and the only reason it continues to thrive is because the developers make it easy for tards who need a GUI.

Re:Apple's Grand Central Dispatch Ported To FreeBS (0)

selven (1556643) | more than 3 years ago | (#29774271)

Linux users tend to know how to pirate, so the cost argument doesn't really work. In fact, most people who have linux installed it over (or at least beside) an existing MS system.

Re:Apple's Grand Central Dispatch Ported To FreeBS (2, Informative)

Anonymous Coward | more than 3 years ago | (#29774375)

On their stolen computer next to all the other things they stole from school. They even steal the flies from outside who swarm around their unwashed bodies. linux is the devolvement of humanity - a linux user is like an anti-human - taking the opposite form of what a real human should be. They do not know how to reproduce, they cannot interact with others and they long ago forgot the concept of personal hygiene. They believe communism is something we should strive for and believe klingon is a real language. yes... we know of your type.

Re:Apple's Grand Central Dispatch Ported To FreeBS (0)

Anonymous Coward | more than 4 years ago | (#29774683)

i could not have said it better myself. well done brother.

Re:Apple's Grand Central Dispatch Ported To FreeBS (1)

TobiasTheCommie (768719) | more than 4 years ago | (#29775147)

Don't you dare compare me to the parent.. he is certainly no commie...

Multicore Enhancements!! :) (5, Interesting)

jpedlow (1154099) | more than 3 years ago | (#29773495)

My first question was "So...what does this do?" Apparently it is a more efficient way of scheduling threads on multi-core systems http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf [apple.com] apple's site says this: "Grand Central Dispatch (GCD) in Mac OS X Snow Leopard addresses this pressing need. It’s a set of first-of-their-kind technologies that makes it much easier for developers to squeeze every last drop of power from multicore systems. 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. Once developers start using GCD for their applications, you’ll start noticing significant improvements in performance. " So this seems good then.

Re:Multicore Enhancements!! :) (1, Interesting)

turgid (580780) | more than 3 years ago | (#29773589)

That sounds like marketing-speak. That's the whole point of preemptively scheduled native threads.

GCD-enabled programs can automatically distribute their work across all available cores

Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just

#include <pthread.h>

and away you go. In fact, I spent an hour one day writing some C to automatically multi-thread those embarrassingly parallel array operations.

man 3 pthread_create - the world is your lobster.

Re:Multicore Enhancements!! :) (2, Informative)

Anonymous Coward | more than 3 years ago | (#29773643)

Ah, but the benefit of Grand Central is that you don't need to worry (as much) about thread synchronisation and message passing. Just give it the blocks of code that are independent of each other, collect the results, and you're done. Think of it as giving you a ready-made scaffold; sometimes, it's more efficient to build your own that matches your needs more closely, but usually, it's just simpler to use what's already there.

In other words, the whole point of Grand Central is that you don't need to worry as much about the "boilerplate" code around threads, and can focus more on what the code actually needs to do. This is a Good Thing. If it doesn't fit your needs, nobody is forcing you to use it ... but if it does, it makes life a hell of a lot easier.

Re:Multicore Enhancements!! :) (0)

Anonymous Coward | more than 3 years ago | (#29773747)

Did you also check how many cores the system had to determine the optimum number of threads? Did you factor in other system activity? Can you easily handle dependencies on things that aren't embarrassingly parallel?

Re:Multicore Enhancements!! :) (4, Informative)

zn0k (1082797) | more than 3 years ago | (#29773753)

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.

Re:Multicore Enhancements!! :) (0)

Anonymous Coward | more than 3 years ago | (#29774101)

Not true. Go read the spec again. libdispatch manages thread pools. It is on a per-app basis. It does not take into how multi-threaded the other applications on the system are. All it is is a way of automagically managing the per-app thread pool & cheaply assigning tasks to existing threads.

Very cool syntax, but it does not load balance the system (that's what the kernel is for).

Re:Multicore Enhancements!! :) (1)

zn0k (1082797) | more than 3 years ago | (#29774293)

It takes into account every other libdispatch enabled app. As per the spec.

Re:Multicore Enhancements!! :) (2, Informative)

Space cowboy (13680) | more than 3 years ago | (#29774295)

Parent spouts bollocks. Simon.

Re:Multicore Enhancements!! :) (0)

Anonymous Coward | more than 3 years ago | (#29773801)

There are plenty of articles about it online. It's more than what you say, and also less (i.e., at first glance it's a thread pool with queued tasks). Firstly, how do you scale your solution transparently? How do you make it cooperate with other software that's running, to get most efficient use of your resources? GCD does that, and blocks makes it simple, and adding multithreading to your application is a matter of adding a couple of lines of code (see the code examples in some of the articles), not managing entire pthreads stuff or changing entire swathes of code. It makes threading trivial, for the programmer, once the programmer has identified where to multithread.

Re:Multicore Enhancements!! :) (5, Insightful)

wootest (694923) | more than 3 years ago | (#29773835)

GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.

For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.

The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.

Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.

So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.

Re:Multicore Enhancements!! :) (5, Insightful)

Just Some Guy (3352) | more than 3 years ago | (#29774029)

Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just

#include <pthread.h>

and away you go.

Piece of cake! Of course, you have no idea how many other processes are tossing threads at their workload and so have no idea if this is a great time to spawn another 8 to really load out the CPU or whether you should just spawn 2 and let some other processes have their time. That's what GCD buys you.

Re:Multicore Enhancements!! :) (0)

Anonymous Coward | more than 4 years ago | (#29774977)

pthread_create() doesn't necessarily mean that a kernel thread was created. It's an application level concept.

http://en.wikipedia.org/wiki/Thread_%28computer_science%29#Models

The operating could choose to create a new kernel entity or not. Since the kernel knows everything that's going on, it could reduce the number of KSEs if the load is too high.

http://www.freebsd.org/kse/index.html

Re:Multicore Enhancements!! :) (2, Insightful)

buchner.johannes (1139593) | more than 4 years ago | (#29775007)

So does Linux need that, do they think about implementing something similar, porting it or what is happening?

Re:Multicore Enhancements!! :) (4, Informative)

Anonymous Coward | more than 3 years ago | (#29774319)

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 [mikeash.com] . 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.

Re:Multicore Enhancements!! :) (1)

ceoyoyo (59147) | more than 4 years ago | (#29774859)

Gee, I've used pthreads quite a bit and I didn't ever notice the nicely organized thread queue infrastructure. Or anything else in GCD, actually. And I sure don't remember parallelizing a FOR loop with one or two lines of code with it.

GCD is NOT a thread library.

Re:Multicore Enhancements!! :) (5, Informative)

moosesocks (264553) | more than 3 years ago | (#29773825)

Ars Technica has a great overview [arstechnica.com] 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.

Re:Multicore Enhancements!! :) (5, Insightful)

Stratoukos (1446161) | more than 3 years ago | (#29773979)

Maybe someday we can actually have a modern desktop as responsive as BeOS was...

BeOS was indeed very responsive, but it was also notoriously difficult to program for. Apple seems to have done a great job at creating a powerful framework, while keeping it easy enough to be actually used by the developers.

had to look it up.. (1)

TheBilgeRat (1629569) | more than 3 years ago | (#29773505)

So, basically this is a tool to streamline concurrent code on multi core machines? Did BSD not have something like this already?

Re:had to look it up.. (1)

cupantae (1304123) | more than 3 years ago | (#29773667)

It probably had a less shiny name, though, like libslcon0.8b3

Re:had to look it up.. (1)

UnknowingFool (672806) | more than 3 years ago | (#29773701)

I'm not an expert but I think this now opens up multi-core to individual applications. Before, the OS and system managed which processes should be passed to cores based on threads. Now with GCD, applications can be written that blocks of code could be flagged so that the OS can know to passed.

The example given in Wikipedia is the analyseDocument method which is used in a document to count the number of words. Without GCD, the main thread that runs this method will have to wait until the method is done. For a small document that delay is not noticeable to the user but will be with a large document. With GCD, the developer can make the method GCD aware. If it takes too long in the main thread, GCD will pass it to another core to handle.

If my understanding is correct, there are some programs that are multi-core aware but they have to be written at a very low level to take advantage of it. This new API abstracts at a higher level so that all developers have to do is write methods in a certain way.

In other news... (0)

Anonymous Coward | more than 3 years ago | (#29773565)

Package XYZ ported from Ubuntu to Debian!

Re:In other news... (0)

Anonymous Coward | more than 3 years ago | (#29773711)

The key here is the code behind grand central dispatch is not GPL compatible [arstechnica.com] , so Linux will probably never get this code. This means MOST high performance computing centers will now be looking primarily at OS X (and maybe FreeBSD) for their future needs, rather than Linux. If you are a fan of TRULY FREE software, then this is great news. If you are Richard Stallman, then its time to go cry into your beer.

Re:In other news... (5, Funny)

wootest (694923) | more than 3 years ago | (#29773865)

Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.

Re:In other news... (0)

Lars T. (470328) | more than 3 years ago | (#29774107)

Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.

Freedom is just another word for having no beer?

Re:In other news... (2, Funny)

Neurotic Nomad (1222606) | more than 3 years ago | (#29774331)

"Freedom" is what he calls his beard.

But when he shaves (1)

ClosedSource (238333) | more than 4 years ago | (#29774665)

does he get derivative works?

Re:In other news... (1)

DurendalMac (736637) | more than 3 years ago | (#29773917)

I'm sure it will come to Linux in some shape. You might not see it bundled and it may never work with every distro, but not everyone in the Linux community is as much a fanatic as RMS.

Re:In other news... (1)

Zaiff Urgulbunger (591514) | more than 3 years ago | (#29774367)

How does this fit in with Debian now also providing a FreeBSD kernel? I'm assuming that the FreeBSD kernel uses a BSD licence... but I might well be wrong... but assuming it does, I would guess GCD would be fine?

Re:In other news... (2, Informative)

harlows_monkeys (106428) | more than 3 years ago | (#29774435)

The key here is the code behind grand central dispatch is not GPL compatible [arstechnica.com], so Linux will probably never get this code

That's not quite correct. There are two parts to GCD: libdispatch and the kernel support. The kernel support is MIT license, so is compatible with GPL. Besides, the kernel component wouldn't be ported anyway--it would be rewritten from scratch if one were doing GCD Linux, so the license doesn't matter.

Libdispatch is Apache license. It runs in the applications, not the kernel, so the kernel being GPLv2 is irrelevant. What's relevant are the licenses of the applications that might want to use libdispatch. Many of those will be licensed as GPLv2 or later. Those are OK, because Apache license is compatible with GPLv3.

Finally, if libdispatch were to be included as a standard part of Linux, even GPLv2 code could dynamically link to it, because it would fall under the system library exception.

Re:In other news... (1)

DuckDodgers (541817) | more than 4 years ago | (#29774459)

There's nothing stopping the Linux kernel team or a third party from implementing an equivalent feature for Linux. It may not happen overnight, but if the interest is there it will be done.

And unless someone has benchmarks, I suspect the performance edge of Grand Central Dispatch isn't going to obsolete Linux - or for that matter, Microsoft Server - overnight.

Re:In other news... (1)

ClosedSource (238333) | more than 4 years ago | (#29774681)

Yeah, you beat me to it. Sounds like another case of confusing copyright with patents.

Comparisons? (1)

PhrostyMcByte (589271) | more than 3 years ago | (#29773569)

Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?

No because they are different (3, Informative)

SuperKendall (25149) | more than 3 years ago | (#29773625)

GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).

The other two things you mentioned are ways for programs to more easily use multiple threads, but they are still threads under the main process and not centrally managed - so you have to decide blind how much of the system you can take for your threading needs.

You can compare the Blocks syntax to ways those two systems specify work units to be done in parallel, but that is just a part of the story.

Re:No because they are different (1)

VGPowerlord (621254) | more than 3 years ago | (#29773761)

GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).

er... isn't that what modern preemptive multi-tasking OSes already do?

Re:No because they are different (2, Insightful)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#29773883)

GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).

er... isn't that what modern preemptive multi-tasking OSes already do?

Sort of, but GCD is about what application developers can do. Using current development methods the average developer decides how many threads to spawn and the OS tries to give them all equal priority. Further if you break your app into too many threads performance drops because of management issues. If you break it into fewer threads than there are cores, cores sit idle.

GCD lets app developers break up their app into chunks that can be threads or can be the same thread and let the OS decide how far to break it up and what to send to what core and what to send to the GPU. It basically lets developers who use good practices fire and forget apps and not have to really worry about profiling and optimization for cores.

Re:No because they are different (1)

init100 (915886) | more than 3 years ago | (#29774265)

and the OS tries to give them all equal priority

Um, no. At least Linux gives I/O-bound threads higher priority than CPU-bound threads, so that when a thread that is blocked waiting for I/O has some data to process, it preempts any running CPU-bound thread. Whether a thread is I/O-bound or CPU-bound is determined dynamically, by looking at the execution pattern.

Re:No because they are different (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#29774389)

Um, no. At least Linux gives I/O-bound threads higher priority than CPU-bound threads, so that when a thread that is blocked waiting for I/O has some data to process, it preempts any running CPU-bound thread.

Okay, that was an oversimplification. The point being, the app doesn't have information about the system it is running on unless it does complex polling and it doesn't have information about the OS and other application's threads, to schedule them based upon need without creating threads that only increase management overhead.

Re:No because they are different (2, Insightful)

Darinbob (1142669) | more than 4 years ago | (#29774477)

Much of what the GCD descriptions seem is "let's compare this well designed system to a badly designed system, and by implication presume that all threading schedulers are also badly designed". Ie, the comment about how Mac OS wastes so much space for each thread is entirely irrelevant here, except to say that on the Mac OS itself you will get better performance with GCD for some situations. It says nothing about better designed threading systems (ie, on embedded and real time systems where no one is storing 512K for a mere thread). It's comparing light weight threads to heavy weight threads.

It seems to solve the problem of what happens when you've got too much work for each processor is to make things more fine grained. Lots of tiny tasks spread around a few threads on just the right number of processors, rather than lots of threads. You've essentially just got a scheduling problem, you can have an academic career doing this stuff. Figuring out which sets of tasks have priority over others is not that much different than figuring out which applications threads have priority over other threads (ie, is the app with 6 threads more important than the one with 4 threads if you've only got 8 processors).

Splitting threads into smaller chunks, if you can rearrange your app structure is one approach to this. Your long running threads that talk to each other are now split into smaller units that talk to each other, only you've got more ways to arrange them. Essentially you're going from very coarse grained parallelism to a finer grained parallelism. which gives more flexibility. But people have been doing this stuff and dealing with its problems for decades. You run into the dusty deck problem again, only in a more modern context. Ie, you tell customers you can speed up their code on your parallel machine and compiler by a factor of X, only they have to rewrite things somewhat, and most customers find that too difficult or their algorithm isn't easily parallelized.

Re:No because they are different (1)

99BottlesOfBeerInMyF (813746) | more than 4 years ago | (#29775093)

Much of what the GCD descriptions seem is "let's compare this well designed system to a badly designed system, and by implication presume that all threading schedulers are also badly designed".

That was not my intention, but I can see where you'd get that idea from my oversimplification. I was trying to point out a couple of main points. One, GDC is a thread pool that is aware of all the threads from the OS and all the apps and the available hardware resources before threads are created. Two, GDC enables developers to easily make their existing applications more fine grained tasks with little work.

Essentially you're going from very coarse grained parallelism to a finer grained parallelism. which gives more flexibility. But people have been doing this stuff and dealing with its problems for decades.

Absolutely, they have, but in actual practice without really using the two items I mention above. Theoretically it would be great if each app developer wrote perfect programs with tasks broken up just right for performance on a system. Realistically, they haven't had very easy to use libraries and systems to do this. A big part of what makes GDC actually useful is the really, really simple syntax for modifying existing programs.

Re:No because they are different (1)

ClosedSource (238333) | more than 4 years ago | (#29774729)

I don't claim that Windows thread pools are equivalent to GCD, but you can have the OS handle asynchronous tasks using the thread pool without having to concern yourself with threads explicitly.

Re:No because they are different (1)

wootest (694923) | more than 3 years ago | (#29773899)

On a thread level, yes. GCD works with tasks/jobs on a smaller level. I don't know if it actually manages its operation system-wide, but it could certainly do it more efficiently with more metadata and finer-grained units of work.

Nope (1)

SuperKendall (25149) | more than 3 years ago | (#29773901)

er... isn't that what modern preemptive multi-tasking OSes already do?

Modern OS's move applications or (even threads) across different cores. But applications can have many threads, and the threads until now have been mostly managed by the applications themselves. The choice to spin off 10 or 100 threads? Up to the application. And that choice was made without the application being able to understand what choices other applications had made... the OS was left to manage as best it could with a large pile of threads, or sometimes apps with no threads that could just run on one core.

With GCD, instead you simply create as many threads as you like, and the central manager decides how many can be run across all the cores. The other part (Blocks) simply makes is easier to define the parts that can run off in separate threads, as noted that is more comparable to the other libraries because you want to encourage every app to have some parallel components. But the other approaches run back into the same problem that once you have defined the parts that can be run in parallel - how many threads should you spawn?

Re:No because they are different (3, Interesting)

norton_I (64015) | more than 3 years ago | (#29774275)

GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).

This is what most people talk about, and what is most obvious from the name, but it is not the interesting part of GCD.

The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.

The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads. This is only useful because OS X has horrendous per-thread overhead. On Linux, for instance, the correct answer is usually to create as many threads as you have parallel tasks and let the OS scheduler sort it out. Other operating systems (Solaris, Windows) have caught up to Linux on this front, but apparently not OS X. If you can get the overhead of OS threads down to an acceptable level, it is always better to avoid multiple layers of scheduling.

Re:No because they are different (0)

Anonymous Coward | more than 4 years ago | (#29774529)

>> 'If there were no Apple, it would be necessary for Microsoft to create one.' (apologies to Voltaire)

If there were no Apple, we would not have had to deal with fanbois like you.

Re:Comparisons? (1)

jhol13 (1087781) | more than 3 years ago | (#29774303)

How about Java? (Concurrent maps are very "cute").

OpenMP (1)

jipn4 (1367823) | more than 3 years ago | (#29773645)

It's unclear that this buys you much over OpenMP 3.0. GCD gives you a little bit more flexibility, but that's not needed in many applications, and GCD is quite inconvenient without closures.

Re:OpenMP (1)

Curate (783077) | more than 3 years ago | (#29773719)

True, OpenMP may be better in some cases. Apple is not aiming to optimize for every case here. Rather, they are aiming for the greatest common denominator.

Re:OpenMP (2, Interesting)

fred fleenblat (463628) | more than 3 years ago | (#29773793)

it seems like the ability to share work across machines, not just cores, would be a critical difference.

you're imagining things (2, Informative)

jipn4 (1367823) | more than 3 years ago | (#29774335)

it seems like the ability to share work across machines, not just cores, would be a critical difference.

Neither GCD nor OpenMP allow you to "share work across machines".

Re:you're imagining things (1)

ceoyoyo (59147) | more than 4 years ago | (#29774879)

No, but Apple's distributed objects implementation lets you do some pretty cool stuff on that front.

Re:you're imagining things (2, Informative)

AHuxley (892839) | more than 4 years ago | (#29774985)

yes Apples has Xgrid to 'share work across machines".
http://en.wikipedia.org/wiki/Xgrid [wikipedia.org]

GCD is not multithreading, it's thread management (5, Informative)

diamondsw (685967) | more than 3 years ago | (#29773739)

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).

Re:GCD is not multithreading, it's thread manageme (0)

Anonymous Coward | more than 3 years ago | (#29773811)

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.

I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile. It probably won't benefit single cores at all, but when we start using octal cores this kind of software will be needed, and embraced.

Re:GCD is not multithreading, it's thread manageme (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#29773961)

...It probably won't benefit single cores at all...

Actually, it should reduce management overhead for applications on a machine using a single core.

Re:GCD is not multithreading, it's thread manageme (1)

Guy Harris (3803) | more than 4 years ago | (#29774871)

I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.

Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.

(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)

Re:GCD is not multithreading, it's thread manageme (1)

mwvdlee (775178) | more than 3 years ago | (#29773985)

Do I understand it correctly if I oversimplify it as "centralized thread pool"?

Re:GCD is not multithreading, it's thread manageme (1)

wootest (694923) | more than 3 years ago | (#29774025)

It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.

What is this? (1)

RightSaidFred99 (874576) | more than 3 years ago | (#29773871)

Can someone explain how this is different from a normal OS with kernel level threads and not userland threads? What can this do that e.g. Windows threading, native posix threading (NPTL) in Linux, etc... Is this just apple "inventing" kernel level threads or is it something new?

Re:What is this? (0)

Anonymous Coward | more than 3 years ago | (#29773995)

My understanding is that this is more like a thread manager. It automatically starts up the necessary number of threads and manages what those threads do. Apple is a desktop system, so this is aimed at making it easy to build a desktop application thats automatically adapts to make the best use of available cores and CPUs. It offers nothing over other threading systems, other then being easy to use.

Re:What is this? (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#29774033)

Is this just apple "inventing" kernel level threads or is it something new?

This is Apple making optimization of threading to multiple cores and GPU's easy for developers. This is a library to take work off the shoulders of developers for making faster, more efficient programs by letting developers chunk up their app and letting the OS (which has more information) make choices for the applications as to what becomes a thread. It is not a fundamental architecture change or anything new on the level you're talking about.

Re:What is this? (0)

Anonymous Coward | more than 3 years ago | (#29774071)

You know what, I knew people were going to ask what this is, so I had a link in the original submission that went to Apple's technology page that goes into detail, but the editor removed it.

Basically, this framework allows the operating system to manage a global pool of threads based on available system resources, and your application submits blocks of work which the operating system will assign to a thread and run as needed. Normally, an application has to manage its own threads (an expensive operation) and try to figure out how many threads it needs to use. One of the difficulties of concurrent programming is that too many or too few threads can affect performance.

It's also convenient for the programmer to be able to submit a block of asynchronous code in a single function call. It's really a very easy API to use.

Posted anonymously because my account has been modbombed into oblivion and can't post anymore.

Re:What is this? (1)

ceoyoyo (59147) | more than 4 years ago | (#29774893)

It's a system of centralized thread queues combined with a nice syntax for easily creating work units to feed to those threads. Yes, bits and pieces of GCD are available in other ways but, as is usual for Apple, they've taken a bunch of existing ideas and put them together into a really nice, integrated package.

It is from APPLE, FFS!! (0)

Anonymous Coward | more than 4 years ago | (#29775009)

Similar to how iphone was the first real phone, this is the first real threading supergoo invented evaar!! Wasn't the name of Apple a dead giveaway already??

About time (0, Troll)

interval1066 (668936) | more than 3 years ago | (#29773935)

Frankly I think its a good thing. The BSD code tree is so old parts of it were rotting from the core. This may inject a vigorous new root into the tree. A sort of BSD for the 21st century perhaps.

GCD also replaces most synchronization / locking (1)

QuantumFlux (228693) | more than 3 years ago | (#29773991)

The other often-overlooked advantage of GCD is that submitting work to a queue is thread-safe, queues themselves are lightweight, and queues can be made internally-serial but parallel to all other queues. Apple's documentation has a lot of good examples of how to use this structure to eliminate almost all locking code (which is usually pretty heavyweight). If you need to serialize access to a resource, just create a serial queue and any other queue can send tasks to it without worrying about any synchronization.

As someone who's struggled with performance from trying to determine how fine-grained to make locks, this seems like an awesome approach.

Re:GCD also replaces most synchronization / lockin (2, Insightful)

setagllib (753300) | more than 4 years ago | (#29774915)

If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.

Missing Slashtod tag: "greenspun". (1)

Kaz Kylheku (1484) | more than 3 years ago | (#29774131)

Awesome! They have almost reinvented lexical closures, etc. In another ten years this will be as awesome as using continuations for UI navigation in a web framework, which was done yesterday.

Thank goodness for the GPL (4, Funny)

Anonymous Coward | more than 3 years ago | (#29774161)

Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!

Wait... what is that? Oh, nevermind then...

Thousands Of Nike Air Jordan woman Shoes For Sal (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#29774447)

                  Welcome TO Our Website: Http://www.tntshoes.com

    We are a prefession online store, you can see more photos and price in our website which is show in the photos
hi our website is see our website in the photos attached, we are a online shopping discount store, pls find the more photos and the price for our product in our website, if you are interested please email me by we take paypal as payment, . Sunglass: lv, dior, D&G channeletc $15-35 free shipping.we have large of brand new shoes,clothing, handbag,sunglasses,hats etc for sale, all of ourproduct are 100% best quality with the amazing price.

  OUR WEBSITE:
                                                        YAHOO:shoppertrade@yahoo.com.cn

                                                                MSN:shoppertrade@hotmail.com

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>