Tag: threads

September 8, 2009 Technology 9 Comments

When to use NSOperation vs. GCD

Mac OS X has a number of concurrency mechanisms, and that increases with Snow Leopard. In addition to run loops, threads (both Cocoa and POSIX) and operations, Snow Leopard adds **Grand Central Dispatch** (GCD), a very lightweight way to represent units of work and the style of concurrency they need, and have the system figure out how to schedule them.

But wait, don’t we have that already in NSOperation? It shouldn’t surprise you in the least to learn that NSOperation, on Snow Leopard, is built atop GCD. However, there are a number of differences between the two, and for that reason people have started to ask “How should I decide which to use when?”

The straightforward answer is a general guideline for all application development:

> **Always use the highest-level abstraction available to you, and drop down to lower-level abstractions when measurement shows that they are needed.**

In this particular case, it means that when writing Cocoa applications, you should generally be using NSOperation rather than using GCD directly. Not because of a difference in efficiency, but because NSOperation provides a *higher-level abstraction* atop the mechanisms of GCD.

For example, you can set up a dependency between two NSOperations such that the second will only be run after the first is complete — even if they’re run on different queues. You can use KVO to observe the completion (or cancellation) of different operations — and you can create operations that support being cancelled in the first place. You can set a completion block to run after an application has finished. And you can, of course, create operations from blocks using *NSBlockOperation*.

You’ll also fit in better with Cocoa by using NSOperation in your high-level code. If you take a look at new Snow Leopard API on NSNotificationCenter, you’ll see one where you specify the NSOperationQueue on which you wish a notification to run a block.

Ultimately, you spend a little bit of overhead to use NSOperation instead of GCD, but you gain significant additional functionality that will be useful as you start to compose operations together. And that’s the biggest benefit of NSOperation: You can break up your application in terms of units of work that can not only be run on a queue, but also canceled, observed, and depended upon. This lets you easily define your data dependencies and ensure that you aren’t simply running code serially as a side-effect of locking.

March 12, 2006 Technology Post a Comment

Cooperative User Threads vs. Preemptive Kernel Threads

James Robertson, Cooperative Threading:

> Well, in Cincom Smalltalk, this model gives you predictability –
> you know exactly what a thread is going to do. The issue with runaway
> threads rarely comes up for a simple reason – most processes end up
> pausing for I/O (user input, db access, file access, sockets –
> what have you). That wait for I/O state is what prevents a problem
> from arising.

This is a classic problem and I’m honestly surprised to find out that Cincom Smalltalk implements cooperative user-level threads rather than supporting preemptive kernel threads.

Here’s what I posted in response to James, unattributed thanks to the torturous comment interface on his blog:

> One issue with cooperative threads relative to preemptive
> OS-supplied threads is that you get far less opportunity
> for true concurrency within an application. In an era when
> multi-core processors are becoming significantly more common,
> this is becoming exceptionally important to application
> developers. It’s not just about doing I/O concurrently with
> other operations or allowing an application to perform
> multiple tasks at once; it’s about allowing a task to be
> completed faster because more efficient use is being made
> of machine resources. This is why I take an extremely
> skeptical view of user-level threading packages, especially
> in software built on platforms that have reasonable
> kernel-level threading.

You’ll note that the various threading APIs in Mac OS X are all built on kernel threads.

Furthermore, the Mach microkernel schedules exclusively in terms of threads. The microkernel doesn’t even have a conception of processes! It only knows about collections of resources — *tasks* — such as address spaces and IPC ports, and flows of control — *threads* — that it can schedule on processors.