// jumping-off point: draw the Mandelbrot set
- (void) drawThatPuppy {
    [self makeBitmapContext: self.bounds.size];
    CGPoint center =
        CGPointMake(CGRectGetMidX(self.bounds), CGRectGetMidY(self.bounds));
    [self drawAtCenter: center zoom: 1];
    [self setNeedsDisplay];
}

// create (and memory manage) instance variable
- (void) makeBitmapContext:(CGSize)size {
    if (self->_bitmapContext)
        CGContextRelease(self->_bitmapContext);
    // ... configure arguments ...
    CGContextRef context = CGBitmapContextCreate(nil, /* ... */);
    self->_bitmapContext = context;
}

// draw pixels of self->_bitmapContext
- (void) drawAtCenter:(CGPoint)center zoom:(CGFloat)zoom {
    // .... do stuff to self->_bitmapContext
}

// turn pixels of self->_bitmapContext into CGImage, draw into ourselves
- (void) drawRect:(CGRect)rect {
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGImageRef im = CGBitmapContextCreateImage(self->_bitmapContext);
    CGContextDrawImage(context, self.bounds, im);
    CGImageRelease(im);
}

// final memory managment
- (void) dealloc {
    if (self->_bitmapContext)
        CGContextRelease(self->_bitmapContext);
}

The simple way to create a thread manually is to send performSelectorInBackground:withObject: to some object containing a method to be performed on a background thread. Even with this simple approach, there is additional work to do:

We’ll rewrite MyMandelbrotView to use manual threading. Our drawAtCenter:zoom: method takes two parameters (and neither is an object), so we’ll have to pack the argument that we pass into the thread, as a dictionary. Once inside the thread, we’ll set up our autorelease pool and unpack the dictionary. This will all be made much easier if we interpose a trampoline method between drawThatPuppy and drawAtCenter:zoom:. So our implementation now looks like this (ignoring the parts that haven’t changed):

- (void) drawThatPuppy {
    [self makeBitmapContext: self.bounds.size];
    CGPoint center =
        CGPointMake(CGRectGetMidX(self.bounds), CGRectGetMidY(self.bounds));
    NSDictionary* d =
        @{@"center": [NSValue valueWithCGPoint:center], @"zoom": @1};
    [self performSelectorInBackground:@selector(reallyDraw:) withObject:d];
    // [self setNeedsDisplay];
}

// trampoline, background thread entry point
- (void) reallyDraw: (NSDictionary*) d {
    @autoreleasepool {
        [self drawAtCenter: [d[@"center"] CGPointValue]
                      zoom: [d[@"zoom"] intValue]];
    }
}

So far so good, but we haven’t yet figured out how to draw our view. We have commented out the call to setNeedsDisplay in drawThatPuppy, because it’s too soon; the call to performSelectorInBackground:withObject: launches the thread and returns immediately, so our _bitmapContext instance variable isn’t ready yet. Clearly, we need to call setNeedsDisplay after drawAtCenter:zoom: finishes generating the pixels of the graphics context. We can do this at the end of our trampoline method reallyDraw:, but we must remember that we’re now in a background thread. Because setNeedsDisplay is a form of communication with the interface, we should call it on the main thread. We can do that with easily with performSelectorOnMainThread:withObject:waitUntilDone:. For maximum flexibility, it will probably be best to implement a second trampoline method:

// trampoline, background thread entry point
- (void) reallyDraw: (NSDictionary*) d {
    @autoreleasepool {
        [self drawAtCenter: [[d objectForKey:@"center"] CGPointValue]
                      zoom: [[d objectForKey:@"zoom"] intValue]];
        [self performSelectorOnMainThread:@selector(allDone)
                               withObject:nil waitUntilDone:NO];
    }
}

// called on main thread! background thread exit point
- (void) allDone {
    [self setNeedsDisplay];
}

This code is specious; the seeds of nightmare are already sown. We now have a single object, MyMandelbrotView, some of whose methods are to be called on the main thread and some on a background thread; this invites us to become confused at some later time. Even worse, the main thread and the background thread are constantly sharing a piece of data, the instance variable _bitmapContext; what’s to stop some other code from coming along and triggering drawRect: while drawAtCenter:zoom: is in the middle of filling _bitmapContext?

To solve these problems, we might need to use locks, and we would probably have to manage the thread more explicitly. For instance, we might use the NSThread class, which lets us retain our thread as an instance and query it from outside (with isExecuting and similar). Such code can become quite elaborate and difficult to understand, even with an extremely basic implementation. It will be easier and safer at this point to use NSOperation, the subject of the next threading approach.

The essence of NSOperation is that it encapsulates a task, not a thread. The operation described by an NSOperation object may be performed on a background thread, but you don’t have to concern yourself with that directly. You describe the operation and add the NSOperation to an NSOperationQueue to set it going. When the operation finishes, you are notified, typically by the NSOperation posting a notification. You can query both the queue and its operations from outside with regard to their state.

We’ll rewrite MyMandelbrotView to use NSOperation. We need a property, an NSOperationQueue; we’ll call it queue. And we have a new class, MyMandelbrotOperation, an NSOperation subclass. It is possible to take advantage of a built-in NSOperation subclass such as NSInvocationOperation or NSBlockOperation, but I’m deliberately illustrating the more general case by subclassing NSOperation itself.

Our implementation of drawThatPuppy makes sure that the queue exists; it then creates an instance of MyMandelbrotOperation, configures it, registers for its notification, and adds it to the queue:

- (void) drawThatPuppy {
    CGPoint center =
        CGPointMake(CGRectGetMidX(self.bounds), CGRectGetMidY(self.bounds));
    if (!self.queue) {
        NSOperationQueue* q = [NSOperationQueue new];
        self.queue = q; // retain policy
    }
    MyMandelbrotOperation* op =
        [[MyMandelbrotOperation alloc] initWithSize:self.bounds.size
                                             center:center zoom:1];
    [[NSNotificationCenter defaultCenter] addObserver:self
        selector:@selector(operationFinished:)
        name:@"MyMandelbrotOperationFinished"
        object:op];
    [self.queue addOperation:op];
}

Our time-consuming calculations are performed by MyMandelbrotOperation. An NSOperation subclass, such as MyMandelbrotOperation, will typically have at least two methods:

MyMandelbrotOperation has three instance variables for configuration (_size, _center, and _zoom), to be set in its initializer; it must be told MyMandelbrotView’s geometry explicitly because it is completely separate from MyMandelbrotView. MyMandelbrotOperation also has its own CGContextRef instance variable, _bitmapContext, along with an accessor so MyMandelbrotView can retrieve a reference to this graphics context when the operation has finished. Note that this is different from MyMandelbrotView’s _bitmapContext; one of the benefits of using NSOperation is that we are no longer sharing data so promiscuously between threads.

Here’s the implementation for MyMandelbrotOperation. All the calculation work has been transferred from MyMandelbrotView to MyMandelbrotOperation without change; the only difference is that _bitmapContext now means MyMandelbrotOperation’s instance variable:

- (id) initWithSize: (CGSize) sz center: (CGPoint) c zoom: (CGFloat) z {
    self = [super init];
    if (self) {
        self->_size = sz;
        self->_center = c;
        self->_zoom = z;
    }
    return self;
}

- (void) dealloc {
    if (self->_bitmapContext)
        CGContextRelease(self->_bitmapContext);
}

- (CGContextRef) bitmapContext {
    return self->_bitmapContext;
}

- (void)makeBitmapContext:(CGSize)size {
   // ... same as before ...
}

- (void)drawAtCenter:(CGPoint)center zoom:(CGFloat)zoom {
    // ... same as before ...
}

- (void) main {
    if ([self isCancelled])
        return;
    [self makeBitmapContext: self->_size];
    [self drawAtCenter: self->_center zoom: self->_zoom];
    if (![self isCancelled])
        [[NSNotificationCenter defaultCenter]
            postNotificationName:@"MyMandelbrotOperationFinished" object:self];
}

The only method of interest is main. First, we call the NSOperation method isCancelled to make sure we haven’t been cancelled while sitting in the queue; this is good practice. Then, we do exactly what drawThatPuppy used to do, initializing our graphics context and drawing into its pixels.

When the operation is over, we need to notify MyMandelbrotView to come and fetch our data. There are two ways to do this; either main can post a notification through the NSNotificationCenter, or MyMandelbrotView can use key–value observing (Chapter 13) to be notified when our isFinished key path changes. We’ve chosen the former approach; observe that we check one more time to make sure we haven’t been cancelled.

Now we are back in MyMandelbrotView, hearing that MyMandelbrotOperation has finished. We must immediately pick up any required data, because the NSOperationQueue is about to release this NSOperation. However, we must be careful; the notification may have been posted on a background thread, in which case our method for responding to it will also be called on a background thread. We are about to set our own graphics context and tell ourselves to redraw; those are things we want to do on the main thread. So we immediately trampoline ourselves out to the main thread:

// warning! called on background thread
- (void) operationFinished: (NSNotification*) n {
    [self performSelectorOnMainThread:@selector(redrawWithOperation:)
                           withObject:[n object] waitUntilDone:NO];
}

As we set MyMandelbrotView’s _bitmapContext by reading MyMandelbrotOperation’s _bitmapContext, we must concern ourselves with the memory management of a CGContext obtained from an object that may be about to release that context:

// now we're back on the main thread
- (void) redrawWithOperation: (MyMandelbrotOperation*) op {
    [[NSNotificationCenter defaultCenter]
        removeObserver:self
        name:@"MyMandelbrotOperationFinished"
        object:op];
    CGContextRef context = [op bitmapContext];
    if (self->_bitmapContext)
        CGContextRelease(self->_bitmapContext);
    self->_bitmapContext = (CGContextRef) context;
    CGContextRetain(self->_bitmapContext);
    [self setNeedsDisplay];
}

Using NSOperation instead of manual threading may not seem like any reduction in work, but it is a tremendous reduction in headaches:

The coherence of MyMandelbrotView’s _bitmapContext does depend upon our obedience to an implicit contract not to set it or write into it anywhere except a few specific moments in MyMandelbrotView’s code. But this is always a problem with data sharing in a multithreaded world, and we have done all we can to simplify the situation.

If we are concerned with the possibility that more than one instance of MyMandelbrotOperation might be added to the queue and executed concurrently, we have a further defense — we can set the NSOperationQueue’s maximum concurrency level to 1:

NSOperationQueue* q = [NSOperationQueue new];
[q setMaxConcurrentOperationCount:1];
self.queue = q;

This turns the NSOperationQueue into a true serial queue; every operation on the queue must be completely executed before the next can begin. This might cause an operation added to the queue to take longer to execute, if it must wait for another operation to finish before it can even get started; however, this delay might not be important. What is important is that by executing the operations on this queue completely separately, we guarantee that only one operation at a time can do any data sharing. A serial queue is thus a form of data locking.

Because MyMandelbrotView can be destroyed (if, for example, its view controller is destroyed), there is still a risk that it will create an operation that will outlive it and will try to access it after it has been destroyed. We can reduce that risk by canceling all operations in our queue before releasing it:

- (void)dealloc {
    // release the bitmap context
    if (self->_bitmapContext)
        CGContextRelease(self->_bitmapContext);
    [self->_queue cancelAllOperations];
}

In our code, we are still using the potentially confusing trampoline technique. Our operationFinished: method is called by a notification on what may be a background thread, so it calls redrawWithOperation: on the main thread. By a neat trick involving a block, we can actually eliminate the trampoline and both of those methods.

Recall, from Chapter 11, the NSNotificationCenter method addObserverForName:object:queue:usingBlock:. The queue: argument here is an NSOperationQueue — the queue on which we’d like our block to be called. I said in Chapter 11 that this will usually be nil, signifying the same thread that posted the notification, which will usually be the main thread. In this case, though, the thread that posted the notification might not be the main thread, so we can request explicitly that the block be called on the main thread. In other words, NSNotificationCenter will perform the trampolining for us.

As I said in Chapter 12, we have to take precautions to avoid a retain cycle; addObserverForName:object:queue:usingBlock: returns an observer which retains us, so we mustn’t retain it in turn. We don’t want to keep our observer as an instance variable because there might be multiple conflicting simultaneous observers. So we declare it as __weak to prevent the retain cycle, and we declare it as __block so that we can see its future value (the value it will have after the call to addObserverForName:object:queue:usingBlock: returns) inside the block and use it to deregister when the notification arrives:

MyMandelbrotOperation* op =
    [[MyMandelbrotOperation alloc] initWithSize:self.bounds.size
                                         center:center zoom:1];
__block __weak id observer = [[NSNotificationCenter defaultCenter]
    addObserverForName:@"MyMandelbrotOperationFinished"
    object:op queue:[NSOperationQueue mainQueue]
    usingBlock:^(NSNotification *note) {
        MyMandelbrotOperation* op2 = note.object;
        CGContextRef context = [op2 bitmapContext];
        if (self->_bitmapContext)
            CGContextRelease(self->_bitmapContext);
        self->_bitmapContext = (CGContextRef) context;
        CGContextRetain(self->_bitmapContext);
        [self setNeedsDisplay];
        [[NSNotificationCenter defaultCenter]
            removeObserver:observer
            name:@"MyMandelbrotOperationFinished"
            object:op2];
}];
[self.queue addOperation:op];

That’s pretty elegant, but in the next section we’ll go even further — we’ll effectively eliminate data sharing entirely by using Grand Central Dispatch.

Grand Central Dispatch, or GCD, is a sort of low-level analogue to NSOperation and NSOperationQueue (in fact, NSOperationQueue uses GCD under the hood). When I say GCD is low-level, I’m not kidding; it’s effectively baked into the operating system kernel. Thus it can be used by any code whatsoever and is tremendously efficient.

Using GCD is like a mixture of the manual threading approach with the NSOperationQueue approach. It’s like the manual threading approach because code to be executed on one thread appears together with code to be executed on another; however, you have a much better chance of keeping the threads and data management straight, because GCD uses Objective-C blocks. It’s like the NSOperationQueue approach because it uses queues; you express a task and add it to a queue, and the task is executed on a thread as needed. Moreover, by default these queues are serial queues, with each task on a queue finishing before the next is started, which, as we’ve already seen, is a form of data locking.

We’ll rewrite MyMandelbrotView to use GCD. The structure of its interface is very slightly changed from the original, nonthreaded version. Our makeBitmapContext: method now returns a graphics context rather than setting an instance variable directly; and our drawAtCenter:zoom: method now takes an additional parameter, the graphics context to draw into. Also, we have a new instance variable to hold our queue, which is a dispatch queue; a dispatch queue is a lightweight opaque pseudo-object consisting essentially of a list of blocks to be executed:

@implementation MyMandelbrotView {
    CGContextRef _bitmapContext;
    dispatch_queue_t _draw_queue;
}

In MyMandelbrotView’s implementation, we create our dispatch queue as the view is created:

- (id)initWithCoder:(NSCoder *)aDecoder {
    self = [super initWithCoder: aDecoder];
    if (self) {
        self->_draw_queue =
            dispatch_queue_create("com.neuburg.mandeldraw", nil);
    }
    return self;
}

A call to dispatch_queue_create must be balanced by a call to dispatch_release. New in iOS 6, however, ARC understands GCD pseudo-objects and will take care of this for us (and in fact calling dispatch_release explicitly is forbidden).

Now for the implementation of drawThatPuppy. Here it is:

- (void) drawThatPuppy {
    CGPoint center = ❶
        CGPointMake(CGRectGetMidX(self.bounds), CGRectGetMidY(self.bounds));
    dispatch_async(self->_draw_queue, ^{ ❷
        CGContextRef bitmap = [self makeBitmapContext: self.bounds.size];
        [self drawAtCenter: center zoom: 1 context:bitmap];
        dispatch_async(dispatch_get_main_queue(), ^{ ❸
            if (self->_bitmapContext)
                CGContextRelease(self->_bitmapContext);
            self->_bitmapContext = bitmap;
            [self setNeedsDisplay];
        });
    });
}

That’s all there is to it. No trampoline methods. No performSelector.... No packing arguments into a dictionary. No autorelease pools. No instance variables. No notifications. And effectively no sharing of data across threads. That’s the beauty of blocks.

The benefits and elegance of GCD as a form of concurrency management are stunning. The bitmap variable is not shared; it is local to each specific call to drawThatPuppy. The nested blocks are executed in succession, so any instance of bitmap must be completely filled with pixels before being used to set the _bitmapContext instance variable. Moreover, the entire operation is performed on a serial queue, and _bitmapContext is touched only from code running on the main thread; thus there is no data sharing and no possibility of conflict. Our code is also highly maintainable, because the entire task on all threads is expressed within the single drawThatPuppy method, thanks to the use of blocks; indeed, the code is only very slightly modified from the original, nonthreaded version.

You might object that we still have methods makeBitmapContext: and drawAtCenter:zoom:context: hanging around MyMandelbrotView, and that we must therefore still be careful not to call them on the main thread, or indeed from anywhere except from within drawThatPuppy. If that were true, we could at this point destroy makeBitmapContext: and drawAtCenter:zoom:context: and move their functionality completely into drawThatPuppy. But it isn’t true, because these methods are now thread-safe: they are self-contained utilities that touch no instance variables or persistent objects, so it doesn’t matter what thread they are called on. Still, I’ll demonstrate in a moment how we can intercept an accidental attempt to call a method on the wrong thread.

The two most important GCD functions are:

Examples in this book have also made use of dispatch_after (Chapter 11, Chapter 15, Chapter 20, Chapter 23) as an alternative to performSelector:withObject:afterDelay:.

Another useful GCD function is dispatch_once, a thread-safe way of assuring that a block is called only once; it’s often used to vend a singleton. I showed an example in Chapter 3.

Besides serial dispatch queues, there are also concurrent dispatch queues. A concurrent queue’s blocks are started in the order in which they were submitted to the queue, but a block is allowed to start while another block is still executing. Obviously, you wouldn’t want to submit to a concurrent queue a task that touches a shared resource — that would be throwing away the entire point of serial queues. The advantage of concurrent queues is a possible speed boost when you don’t care about the order in which multiple tasks are finished — for example, when you want to do something in response to every element of an array. The built-in global queues (available by calling dispatch_get_global_queue) are concurrent; you can also create a concurrent queue by passing DISPATCH_QUEUE_CONCURRENT as the second argument to dispatch_queue_create.

An interesting tweak is that you can queue up a barrier block on a concurrent queue; a barrier block has the property that it won’t be dequeued until all the blocks preceding it on the queue have been not only dequeued but fully executed, and that no blocks following it in the queue will be dequeued until it itself has fully executed (rather like Benjamin Britten’s “curlew sign,” signifying that every musician must wait here until all the other musicians have reached the same point).

A frequent use of concurrent queues is with dispatch_apply. This function is like dispatch_sync (the caller pauses until the block has finished executing), but the block is called multiple times with an iterator argument. Thus, dispatch_apply on a concurrent queue is like a for loop whose iterations are multithreaded; on a device with multiple cores, this could result in a speed improvement. (Of course, this technique is applicable only if the iterations do not depend on one another.)

Arbitrary context data can be attached to a queue in the form of key–value pairs (dispatch_queue_set_specific) and retrieved by key. The dispatch_queue_get_specific function retrieves a key’s value for a queue to which we already have a valid reference; dispatch_get_specific retrieves a key’s value for the current queue, the one in whose thread we are actually running. In fact, dispatch_get_specific is the only valid way to identify the current queue (a function formerly used for this purpose, dispatch_get_current_queue, has been shown to be potentially unsafe and is now deprecated).

We can use this technique, for example, to make certain that a method is called only on the correct queue. Recall that in our Mandelbrot-drawing example, we may be concerned that a method such as makeBitmapContext: might be called on some other queue than the background queue that we created for this purpose. If this is really a worry, we can attach an identifying key–value pair to that queue when we create it. Both key and value should be pointers, so let’s start by defining some static C strings:

static char* QKEY = "label";
static char* QVAL = "com.neuburg.mandeldraw";

We then create the queue like this:

self->_draw_queue = dispatch_queue_create(QVAL, nil);
dispatch_queue_set_specific(self->_draw_queue, QKEY, QVAL, nil);

Later, we can examine that identifying key–value pair for the queue on which a particular method is called:

- (CGContextRef) makeBitmapContext:(CGSize)size {
    NSAssert(dispatch_get_specific(QKEY) == QVAL, @"Wrong thread");

Note that we are comparing the values purely as pointers; the fact that either one of them is a C string is irrelevant. A common device, where threads generated by different instances of the same class need to be distinguished, is to attach to a queue a key–value pair whose value is the instance itself.