Question

This is a two part question. Hope someone could reply with a complete answer.

NSOperations are powerful objects. They can be of two different types: non-concurrent or concurrent.

The first type runs synchronously. You can take advantage of a non-concurrent operations by adding them into a NSOperationQueue. The latter creates a thread(s) for you. The result consists in running that operation in a concurrent manner. The only caveat regards the lifecycle of such an operation. When its main method finishes, then it is removed form the queue. This is can be a problem when you deal with async APIs.

Now, what about concurrent operations? From Apple doc

If you want to implement a concurrent operation—that is, one that runs
asynchronously with respect to the calling thread—you must write
additional code to start the operation asynchronously. For example,
you might spawn a separate thread, call an asynchronous system
function, or do anything else to ensure that the start method starts
the task and returns immediately and, in all likelihood, before the
task is finished.

This is quite almost clear to me. They run asynchronously. But you must take the appropriate actions to ensure that they do.

What it is not clear to me is the following. Doc says:

Note: In OS X v10.6, operation queues ignore the value returned by
isConcurrent and always call the start method of your operation from a
separate thread.

What it really means? What happens if I add a concurrent operation in a NSOperationQueue?

Then, in this post Concurrent Operations, concurrent operations are used to download some HTTP content by means of NSURLConnection (in its async form). Operations are concurrent and included in a specific queue.

UrlDownloaderOperation * operation = [UrlDownloaderOperation urlDownloaderWithUrlString:url];
[_queue addOperation:operation];

Since NSURLConnection requires a loop to run, the author shunt the start method in the main thread (so I suppose adding the operation to the queue it has spawn a different one). In this manner, the main run loop can invoke the delegate included in the operation.

- (void)start
{
    if (![NSThread isMainThread])
    {
        [self performSelectorOnMainThread:@selector(start) withObject:nil waitUntilDone:NO];
        return;
    }

    [self willChangeValueForKey:@"isExecuting"];
    _isExecuting = YES;
    [self didChangeValueForKey:@"isExecuting"];

    NSURLRequest * request = [NSURLRequest requestWithURL:_url];
    _connection = [[NSURLConnection alloc] initWithRequest:request
                                                  delegate:self];
    if (_connection == nil)
        [self finish];
}

- (BOOL)isConcurrent
{
    return YES;
}

// delegate method here...

My question is the following. Is this thread safe? The run loop listens for sources but invoked methods are called in a background thread. Am I wrong?

Edit

I’ve completed some tests on my own based on the code provided by Dave Dribin (see 1). I’ve noticed, as you wrote, that callbacks of NSURLConnection are called in the main thread.

Ok, but now I’m still very confusing. I’ll try to explain my doubts.

Why including within a concurrent operation an async pattern where its callback are called in the main thread? Shunting the start method to the main thread it allows to execute callbacks in the main thread, and what about queues and operations? Where do I take advantage of threading mechanisms provided by GCD?

Hope this is clear.

Answer 1

This is kind of a long answer, but the short version is that what you’re doing is totally fine and thread safe since you’ve forced the important part of the operation to run on the main thread.

Your first question was, “What happens if I add a concurrent operation in a NSOperationQueue?” As of iOS 4, NSOperationQueue uses GCD behind the scenes. When your operation reaches the top of the queue, it gets submitted to GCD, which manages a pool of private threads that grows and shrinks dynamically as needed. GCD assigns one of these threads to run the start method of your operation, and guarantees this thread will never be the main thread.

When the start method finishes in a concurrent operation, nothing special happens (which is the point). The queue will allow your operation to run forever until you set isFinished to YES and do the proper KVO willChange/didChange calls, regardless of the calling thread. Typically you’d make a method called finish to do that, which it looks like you have.

All this is fine and well, but there are some caveats involved if you need to observe or manipulate the thread on which your operation is running. The important thing to remember is this: don’t mess with threads managed by GCD. You can’t guarantee they’ll live past the current frame of execution, and you definitely can’t guarantee that subsequent delegate calls (i.e., from NSURLConnection) will occur on the same thread. In fact, they probably won’t.

In your code sample, you’ve shunted start off to the main thread so you don’t need to worry much about background threads (GCD or otherwise). When you create an NSURLConnection it gets scheduled on the current run loop, and all of its delegate methods will get called on that run loop’s thread, meaning that starting the connection on the main thread guarantees its delegate callbacks also happen on the main thread. In this sense it’s “thread safe” because almost nothing is actually happening on a background thread besides the start of the operation itself, which may actually be an advantage because GCD can immediately reclaim the thread and use it for something else.

Let’s imagine what would happen if you didn’t force start to run on the main thread and just used the thread given to you by GCD. A run loop can potentially hang forever if its thread disappears, such as when it gets reclaimed by GCD into its private pool. There’s some techniques floating around for keeping the thread alive (such as adding an empty NSPort), but they don’t apply to threads created by GCD, only to threads you create yourself and can guarantee the lifetime of.

The danger here is that under light load you actually can get away with running a run loop on a GCD thread and think everything is fine. Once you start running many parallel operations, especially if you need to cancel them midflight, you’ll start to see operations that never complete and never deallocate, leaking memory. If you wanted to be completely safe, you’d need to create your own dedicated NSThread and keep the run loop going forever.

In the real world, it’s much easier to do what you’re doing and just run the connection on the main thread. Managing the connection consumes very little CPU and in most cases won’t interfere with your UI, so there’s very little to gain by running the connection completely in the background. The main thread’s run loop is always running and you don’t need to mess with it.

It is possible, however, to run an NSURLConnection connection entirely in the background using the dedicated thread method described above. For an example, check out JXHTTP, in particular the classes JXOperation and JXURLConnectionOperation