GCD Concurrent Queues

August 6, 2014

This is the third post in a series about Grand Central Dispatch.

If serial queues are a better replacement for mutexes (and more), then concurrent queues are a better replacement for threads (and more).

A concurrent queue allows you to enqueue blocks that will start running without waiting for the previous blocks to finish.

Run the following program several times:

#import <Foundation/Foundation.h>

void print(int number) {
    for (int count = 0; count < 10; ++count) {
        NSLog(@"%d", number);
    }
}

int main(int argc, const char * argv[]) {
    dispatch_queue_t queue = dispatch_queue_create("My concurrent queue", DISPATCH_QUEUE_CONCURRENT);

    @autoreleasepool {
        for (int index = 0; index < 5; ++index) {
            dispatch_async(queue, ^{
                print(index);
            });
        }
    }
    dispatch_main();
    return 0;
}

dispatch_async() tells GCD to enqueue a block, but not to wait until the block is done before moving on. This allows us to quickly “toss” five blocks onto the concurrent queue we just created.

When the first block is enqueued, the queue is empty, so it begins running the same way it would if the queue were serial. However, when the second block is enqueued, it too will run even though the first block hasn’t finished running. The same goes for the third block, the fourth, and the fifth—they all run at the same time.

Using GCD Queues For Synchronization

August 2, 2014

This is the second post in a series about Grand Central Dispatch.

In my previous post, we learned that race conditions are a constant problem for asynchronous programs. In short, these are situations where data is simultaneously operated on by multiple threads, resulting in sometimes unpredictable results.

A classic way of solving this issue is by using a mutual exclusion (mutex) object. Here’s an example using the Posix threads API:

#import <Foundation/Foundation.h>
#import <pthread/pthread.h>

// Each player gets 100 gems to start
int playerAGems = 100;
int playerBGems = 100;

// Data structure to hold information about the mutual exclusion object
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void *thread1(void *arg) {
    // Move 20 gems from player A to player B
    pthread_mutex_lock(&mutex); // Wait until we gain access to the mutex
    playerAGems -= 20;
    playerBGems += 20;
    NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
    pthread_mutex_unlock(&mutex); // Unlock the mutex
    return NULL;
}

void *thread2(void *arg) {
    // Move 50 gems from player B to player A
    pthread_mutex_lock(&mutex);
    playerAGems += 50;
    playerBGems -= 50;
    NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
    pthread_mutex_unlock(&mutex);
    return NULL;
}

int main() {
    pthread_mutex_init(&mutex, NULL); // Initialize the mutex
    pthread_t t1; // Data structure to hold information about thread 1
    pthread_t t2; // Data structure to hold information about thread 2
    pthread_create(&t1, NULL, thread1, NULL);
    pthread_create(&t2, NULL, thread2, NULL);

    dispatch_main();
}

Why GCD?

July 31, 2014

This is the first post in a series about Grand Central Dispatch.

In short: better parallelism.

In the last decade, CPU speed improvements have hit a wall. To continue to get more performance out of the same clock speed, CPU manufacturers have been including more and more cores on their dies (my MacBook Pro has 8 cores and my Mac Pro at work has 24).

CPU speed over the years

(Source)

The problem is, programs can’t take advantage of these extra cores unless it knows how to farm out its work effectively.

Parallelism deals with the problem of doling out multiple jobs to be done at the same time. This is a very hard problem in general, but GCD makes it a little easier to manage.

You may not have a need to write a massively parallel program, but you can still use GCD to make a more responsive program by not having your UI or service wait for jobs to complete. Typically, you want to toss jobs to other cores while your main program continues serving requests asynchronously. GCD makes this, and other similar tasks, easier.

An Introduction to Grand Central Dispatch

July 28, 2014

Grand Central Dispatch is an important system library introduced in OS X 10.6 and iOS 4. It provides a set of C API that makes it easy(er) to deal with parallel programming on iOS and OS X. GCD works with C, C++, Objective C, and even Swift.

When you begin exploring GCD, you discover two things right away: its API is terse, and there is hardly anything in the way of introductory materials. Wouldn’t it be nice if there were a gentle introduction to guide you through some basic patterns that you should use or avoid?

That’s what this series of posts is intended to do. I’ve been using GCD since its early days, and I have battle scars to prove it. I hope I can act as a guide to this powerful and elegant library.

Over the next few weeks, I will post several blog posts that deal with aspects of GCD to help you get started, get comfortable, and get creative with the API.

I will be tagging the posts in this series with #libdispatch.

Posts in this series:

Block APIs are NOT harmful

July 17, 2014

Note: This is a repost of an older post that was published on my tumblr blog. Before I begin writing more posts on the subject of programming, I thought I’d practice by reposting something I’ve already written. This post has been re-edited for clarity.

I take exception to Drew Crawford’s recent post that block-based APIs introduce “harmful” surprising side effects into Objective-C, especially under ARC. Drew’s post calls attention to NSNotificationCenter in particular, but really, any block-based API is susceptible to similar kinds of pitfalls.

I would encourage you to download a copy of Drew’s example code as you read his blog post to understand the problem he’s describing.

humancode.us

GCD Concurrent Queues

Using GCD Queues For Synchronization

Why GCD?

An Introduction to Grand Central Dispatch

Block APIs are NOT harmful