Software Testing Blog

Have you heard of Grand Central Dispatch?  If you’re a Mac addict, then you might know that it’s Apple’s new easy-to-use tool for parallelizing code.  If you’re not a Mac addict, then the first thing you should know is that GCD is one of the most exciting innovations in software development in years.  The second thing is that Apple just released it as a cross-platform open source project, meaning it’s coming soon to a platform near you.

Within the past several years, hardware developers have started expanding the power of computers by adding more CPUs instead of making individual CPUs faster.  This approach, called multi-core, comes with both a good and bad side.  The good side is that a computer with two CPUs is faster than a computer with one.  The bad side is that developing an application that uses two CPUs is pretty hard, meaning most pieces of software will just run on one while leaving the other unused.

For experienced developers, you’re probably thinking “well, that’s what threads are for.”  But threads have problems of their own, like knowing how many to allocate. With too few you waste resources by not using the full capability of your system.  With too many you waste resources by forcing the excessive threads to compete for valuable CPU time.

Apple created GCD to solve this problem.  GCD maintains a pool of threads – no more and no fewer than needed.  Meanwhile, an application written with GCD breaks itself into tasks.  These tasks are added to a queue where they wait for an available thread.  The whole thing is faster, lighter weight, and easier to manage than using threads alone.

So now the downsides.  First, using GCD requires “blocks” which are another Apple invented coding methodology.  Blocks are non-standard, but they’re implemented within the LLVM project.  That means that support for blocks is probably not that far from reality on platforms like Linux and other Unix flavors.

The second problem with GCD is that it doesn’t do the heavy lifting of actually breaking up your application into smaller tasks.  For some algorithms, this is a pretty easy thing to do.  For some algorithms, however, creating parallel tasks is a real challenge.

The last problem is the one that most impacts software testers: any time you introduce parallelism into code, it creates new opportunities for bugs.  Despite Apple making GCD incredibly easy to use, developers will almost cretainly create problems like race conditions and deadlocks.

GCD promises to make using multi-core platforms even easier, but only time will tell if it really proves to be the missing link between raw threads and easy-to-develop parallel code.  However, my money is on GCD becoming a must-have tool in the next few years.

[Update] – Ars Technica just posted an article about the future of GCD on Linux.  They see some future for the two, but they’re also worried about some licensing issues.