Clarification on Threads and Run Loops In Cocoa

Question

I'm trying to learn about threading and I'm thoroughly confused. I'm sure all the answers are there in the apple docs but I just found it really hard to breakdown and digest. Maybe somebody could clear a thing or 2 up for me.

1)performSelectorOnMainThread

Does the above simply register an event in the main run loop or is it somehow a new thread even though the method says "mainThread"? If the purpose of threads is to relieve processing on the main thread how does this help?

2) RunLoops

Is it true that if I want to create a completely seperate thread I use "detachNewThreadSelector"? Does calling start on this initiate a default run loop for the thread that has been created? If so where do run loops come into it?

3) And Finally , I've seen examples using NSOperationQueue. Is it true to say that If you use performSelectorOnMainThread the threads are in a queue anyway so NSOperation is not needed?

4) Should I forget about all of this and just use the Grand Central Dispatch instead?

Answer 1

Run Loops

You can think of a Run Loop to be an event processing for-loop associated to a thread. This is provided by the system for every thread, but it's only run automatically for the main thread.

Note that running run loops and executing a thread are two distinct concepts. You can execute a thread without running a run loop, when you're just performing long calculations and you don't have to respond to various events. If you want to respond to various events from a secondary thread, you retrieve the run loop associated to the thread by

[NSRunLoop currentRunLoop]

and run it. The events run loops can handle is called input sources. You can add input sources to a run-loop.

PerformSelector

performSelectorOnMainThread: adds the target and the selector to a special input source called performSelector input source. The run loop of the main thread dequeues that input source and handles the method call one by one, as part of its event processing loop.

NSOperation/NSOperationQueue

I think of NSOperation as a way to explicitly declare various tasks inside an app which takes some time but can be run mostly independently. It's easier to use than to detach the new thread yourself and maintain various things yourself, too. The main NSOperationQueue automatically maintains a set of background threads which it reuses, and run NSOperations in parallel. So yes, if you just need to queue up operations in the main thread, you can do away with NSOperationQueue and just use performSelectorOnMainThread:, but that's not the main point of NSOperation.

GCD

GCD is a new infrastructure introduced in Snow Leopard. NSOperationQueue is now implemented on top of it. It works at the level of functions / blocks. Feeding blocks to dispatch_async is extremely handy, but for a larger chunk of operations I prefer to use NSOperation, especially when that chunk is used from various places in an app.

Summary

You need to read Official Apple Doc! There are many informative blog posts on this point, too.

Answer 2

1)performSelectorOnMainThread

Does the above simply register an event in the main run loop …

You're asking about implementation details. Don't worry about how it works.

What it does is perform that selector on the main thread.

… or is it somehow a new thread even though the method says "mainThread"?

No.

If the purpose of threads is to relieve processing on the main thread how does this help?

It helps you when you need to do something on the main thread. A common example is updating your UI, which you should always do on the main thread.

There are other methods for doing things on new secondary threads, although NSOperationQueue and GCD are generally easier ways to do it.

2) RunLoops

Is it true that if I want to create a completely seperate thread I use "detachNewThreadSelector"?

That has nothing to do with run loops.

Yes, that is one way to start a new thread.

Does calling start on this initiate a default run loop for the thread that has been created?

No.

I don't know what you're “calling start on” here, anyway. detachNewThreadSelector: doesn't return anything, and it starts the thread immediately. I think you mixed this up with NSOperations (which you also don't start yourself—that's the queue's job).

If so where do run loops come into it?

Run loops just exist, one per thread. On the implementation side, they're probably lazily created upon demand.

3) And Finally , I've seen examples using NSOperationQueue. Is it true to say that If you use performSelectorOnMainThread the threads are in a queue anyway so NSOperation is not needed?

These two things are unrelated.

performSelectorOnMainThread: does exactly that: Performs the selector on the main thread.

NSOperations run on secondary threads, one per operation.

An operation queue determines the order in which the operations (and their threads) are started.

Threads themselves are not queued (except maybe by the scheduler, but that's part of the kernel, not your application). The operations are queued, and they are started in that order. Once started, their threads run in parallel.

4) Should I forget about all of this and just use the Grand Central Dispatch instead?

GCD is more or less the same set of concepts as operation queues. You won't understand one as long as you don't understand the other.

---

So what are all these things good for?

Run loops

Within a thread, a way to schedule things to happen. Some may be scheduled at a specific date (timers), others simply “whenever you get around to it” (sources). Most of these are zero-cost when idle, only consuming any CPU time when the thing happens (timer fires or source is signaled), which makes run loops a very efficient way to have several things going on at once without any threads.

You generally don't handle a run loop yourself when you create a scheduled timer; the timer adds itself to the run loop for you.

Threads

Threads enable multiple things to happen at the exact same time on different processors. Thing 1 can happen on thread A (on processor 1) while thing 2 happens on thread B (on processor 0).

This can be a problem. Multithreaded programming is a dance, and when two threads try to step in the same place, pain ensues. This is called contention, and most discussion of threaded programming is on the topic of how to avoid it.

NSOperationQueue and GCD

You have a thing you need done. That's an operation. You can't have it done on the main thread, or you'd simply send a message like normal; you need to run it in the background, on a secondary thread.

To achieve this, express it as either an NSOperation object (you create a subclass of NSOperation and instantiate it) or a block (or both), then add it to either an NSOperationQueue (NSOperations, including NSBlockOperation) or a dispatch queue (bare block).

GCD can be used to make things happen on the main thread, as well; you can create serial queues and add blocks to them. A serial queue, as its name suggests, will run exactly one block at a time, rather than running a bunch of them in parallel.

So what should I do?

I would not recommend creating threads directly. Use NSOperationQueue or GCD instead; they force you into better thinking habits that will reduce the risk of your threaded code inducing headaches.

For things that run periodically, not fitting into the “thing I need done” model of NSOperations and GCD blocks, consider just using the run loop on the main thread. Chances are, you don't need to put it on a thread after all. A rendering loop in a 3D game, for example, can be a simple timer.