What's the difference between synchronous and asynchronous calls in Objective-C, versus multi-threading?
When you invoke something synchronously, it means that the thread that initiated that operation will wait for the task to finish before continuing. Asynchronous means that it will not wait.
Having said that, when people suggest that you perform some slow or expensive process asynchronously, they are implicitly suggesting not only that you should run it asynchronously, but that you should do that on a background thread. The goal is to free the main thread so that it can continue to respond to the user interface (rather than freezing), so you are dispatching tasks to a background thread asynchronously.
So, there are two parts to that. First, using GCD as an example, you grab a background queue (either grab one of the global background queues, or create your own):
// one of the global concurrent background queues
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
// or you could create your own serial background queue:
//
// dispatch_queue_t queue = dispatch_queue_create("com.domain.app.queuename", 0);
Second, you dispatch your tasks to that queue asynchronously:
dispatch_async(queue, ^{
// the slow stuff to be done in the background
});
The pattern for operation queues is very similar. Create an operation queue and add operations to that queue.
In reality, the synchronous vs asynchronous distinction is completely different from the main queue vs background queue distinction. But when people talk about "run some slow process asynchronously", they're really saying "run some slow process asynchronously on a background queue."
"Synchronous" essentially means "in order." Basically, when you do a synchronous operation, everything that comes later has to wait for the operation to finish before they can start.
Conversely, "asynchronous" more or less means "not in order." When you do something asynchronously, the following code can immediately run and the asynchronous operation will be run…sometime. It might be run in parallel with the rest of the code on another thread. It might simply be scheduled for some other time on the same thread.
The concept of synchronicity doesn't have anything to do with particular threads, per se. It's just about whether you have to wait for an operation to finish or not.
Where the main thread comes into this in a big way is in Cocoa (Touch) programs. The AppKit runs the main event loop on the main thread, so if the main thread is waiting for an operation to complete, it can't process any input or update the UI. If you have a piece of code running on a background thread, though, running synchronous code will not block the main event loop, because it isn't the main thread that's waiting for the synchronous operation to complete.
Similarly, a long-running asynchronous operation from a background thread that you place on the main thread can cause problems, because while the background thread isn't going to wait for the operation to complete, it is still taking up time on the main thread where the event loop needs to run.