Recently I’ve been doing a lot of asynchronous and concurrency-related stuff and I thought: ‘What the heck is concurrency? Isn’t it the same as asynchronous?’ So I decided to look into it a bit more.
The Main Thread and Background Threads
In iOS development there are essentially two types of thread that run: the Main thread and a Background thread(s). All of your user interaction, touches and feedback happen on the main thread so you never, ever want to do things on there that might block it or impede it’s performance; just imagine everyone standing in one queue for train tickets in the morning. So it’s best to put operations like URL calls, downloads etc on a background thread and immediately return control back to the main thread to keep things nice and smooth for the user; because if you don’t they gonna quit your app so faaaaast.
Asynchronous means several things at the same time and concurrent also has a very similar meaning. So what’s the difference?
Gandalf is the main man. He’s always in the main limelight and he’s got the main role. Radagast the Brown is in the background, but actually does a lot of cool stuff like investigate creepy castles and can talk to all animal life. (this is relevant, sort of)
If you’ve used Grand Centra Dispatch (GCD) on iOS you’ll often use async. Dispatch.Async means:
‘Send this operation off and immediately return to the main thread’ #Good
Approximate translation: ‘Send Radagast off to do scary, actual work and give me back the limelight to entertain people with my smooth voice and well-trimmed beard.’
In contrast Dispatch.Sync means:
‘Send this operation off and wait for it to finish before returning control back to the main thread’ #BadInMostCases
Translation: ‘I will literally stand here by this fire, on this spot and not even breathe until you return after the task’. Not only is this bad, Gandalf may even not survive…
So far so good right? Most of the time you want to return things back to the main thread and fire off other stuff in the background, like Gandalf running the show in the lime light while under-appreciated Radagast the Brown really does all of the investigation in the dangerous, spider-ridden places.
The real question here is do we want the task faithful Radagast is going to be completely inhibited? Do we want to send him on a path that we know is totally clear, with no one else on, or do we mind if he meets a fellow on the same path along the way? I mean he could meet a cool elf, or hobbit or something right?
Concurrency vs Serial
Whether we send the task off async or sync, we need to decide if we need that background thread to have nothing else on it. If we specify the thread is serial, then we can guarantee that no other task is on that thread. If we specify that it is concurrent, then it may or may not meet another task along the way in the thread.
This really has nothing to do with whether Gandalf can continue his work or not, more whether we can trust Radagast or not!
Read The Hobbit right now.
Async + Concurrent task => Send task into the background, return control right away to the main thread, and on the task’s noble journey it may share a queue with another fellow task
Async + Serial => Away task on a lonely journey and return control to the main thread knowing it will be solo all the way to the very end
Sync + Concurrent => Main thread will wait for the background task to complete and the task isn’t guaranteed to be the only task on that thread
Sync + Serial => Main thread will wait for completion and the task is guaranteed free reign of the that background thread until it’s completion.