Understanding Concurrency and Grand Central Dispatch
Tags: Devslopes, Software Engineering, Application Development, Grand Central Dispatch, iOS App Development

When anything is being referred to as being “concurrent,” it is being compared with something else that is being done at the same time. When a task has been coded to execute, it can be programmed to happen at the same time as another task. This is concurrency or concurrent programming.

What physically allows us to do this is multicore processors. Specifically in iOS Development, with today's technology at the time of writing this, we are currently at a six-core CPU with the latest iPhone 11 and 12 Pros. The more cores there are, the more tasks we can perform. Within these cores, these tasks are done on what are called threads.

Certain threads perform different tasks, and in iOS Development, we want to keep certain threads clear and not as busy as others. For the example I learned this week in the Academy, we want the UI part of the app to be on a different thread than the network requests. We want the UI thread(which is the main thread) to have less traffic so that it can be responsive and quick. While the other threads(background threads), handles the heavy lifting of making HTTP requests and handling data or errors. Doing this on the main thread could cause the users to think the app is slow while the UI is waiting for the network request.

Grand Central Station Clock

Thankfully, Apple has given us tools to manage these threads, this is what is known as Grand Central Dispatch(GCD). We as developers just make the queues for Dispatch and it handles the management of those queues. But what is a queue?

The first thing that pops into my mind was how they’re used in Netflix. When there is something you want to watch but not right now, you would add it to your queue. This is a list of movies or shows waiting to be watched in the order they were added. Once one is done, then the next in queue is up. So, much like how Grand Central Station in Manhattan manages all the traffic on different tracks, the GCD manages all the different queues on different threads. Some on the main thread, some on others.

The first task in a queue is executed first, then the second, then so on, and so forth. This order is called FIFO or First In First Out. Much like a Netflix queue. Now there are two types of queues we can program in our code, Serial(Sequential) and Concurrent.

Image captured from video ( bit.ly/36SZde7 )

In serial queues, task 2 doesn't start until task 1 is complete. Just like a movie in a Netflix queue.

Image captured from video ( bit.ly/36SZde7 )

In concurrent queues, each task is started in order but they don't wait for the task before it to be completed, they are all concurrent performing tasks at the same time. And with some tasks being easier than others, some tasks might be done before others that started before it, as you see in the image above.

So with concurrent queues, you can imagine that all the tasks would be done sooner, but the outcome may vary as to which task gets done first depending upon how easy it is to perform.

The most common implementation of GCD that I have used in App Development is moving things from the background queue to the main queue. Especially when making HTTP requests with URLSession and having a completion handler that is run once the request is finished. Somewhere in the code, I would update the UI on the main thread.

Since the collection view is part of the UI on the main thread, I would dispatch the background queue, put it on the main thread, and reload the collection view like the image above. You could move queues from the main to the background thread, but I haven't needed to yet.

This was what I learned in this last week of iOS Development, asynchronous code, Grand Central Dispatch, and Threading.

Rick Martinez