iOS Concurrency and Threading - iOS Interview Question - Swift

what's up everybody we're back with another video in my iOS interview question series and today we're gonna be talking about concurrency and threading now this is a huge topic that I could do hours and hours of videos on however we're gonna keep this video at a high level because the entire point of this video it's for you to be able to answer an interview question now during an interview if they're asking you a lot of questions so they're not gonna expect you to be an expert in deep dive into this topic they're just gonna want to know that you have very basic general understanding of what's actually going on with concurrency and threading and with that being said we're gonna talk about the different thread types the main thread the background thread we're going to talk about cues a little bit serial cues concurrent cues and then we're also gonna talk about how Grand Central Dispatch kind of ties that all together and you can move things around from different threads and queues alright let's dive in so let's start with the big picture and what is concurrency basically concurrency is doing multiple tasks at the same time now what allows us to do this is Apple's multi-core processors here I have picture just an example of latest a10 processor which is a quad core processor in the iPhone 7 so the more cores you have the more tasks you can do at the same time now all these tasks are being executed on what are called threads imagine threads is kind of like this major highway each Lane in the highway is a thread in each car in that Lane is a task being executed on that thread now you notice here pictured I have a lane here on the left the express lane that's real clean and speedy in that is called our main thread and the reason we want to keep our main thread you know speedy and clean is because that is what our UI is done on so for example if you clog up this main thread with a very you know time intensive task your UI is gonna freeze inner user is gonna think your app is locked up so that's why we do all those time heavy tasks on the background threads keep the main thread clear so the UI is still responsive now all this management of the main thread and all the background threads you can have because you can have you know a lot of background threads can get really hard and tricky however luckily Apple has built something for us called Grand Central Dispatch and NS operation queues which is basically just an API built on top of this threading to make our lives as developers easier and essentially it just handles all the heavy lifting of creating and managing threads for us as developers we just work with a queue of tasks give that to Grand Central Dispatch and it just handles all the thread management stuff for us it's pretty nice so by now you probably has what's a queue imagine a queue like people lining up for Star Wars and I don't know what kind of crazy people do this certainly not me definitely definitely not me I lined up for Star Wars and I loved every second of it but anyway it's a line so the first person in the line is the first person to go into the movie theater it's called first-in first-out and that's really all the queue is you just line up tasks and then the pass the win in first is the first one they get executed the second one is the second one it get executed let's take a look so here you see all our tasks come in task one is the first one to go it gets executed first then tax two will get executed then three and so on and so on there's your basic queue now there's two types of cues we have a serial cue in a concurrent queue we're going to talk about the differences there we kind of just saw the serial cue so we'll run through it again real quick but the serial cue the tasks come in in order and then task two doesn't start until task one is a hundred percent complete task three doesn't start until test two is 100% complete so everything happens one at a time in order now let's take a look at a concurrent queue so in a concurrent queue everything still starts in the same order so the tasks are gonna start one two three four however task two does not have to wait for task 1 to complete to start so therefore things will happen quicker but as you can see it's gonna be unpredictable on how things finish so you can see things start in order one two three four however certain tasks are quicker than other tasks let's take a look at that one more time now imagine tasks to being something like downloading a high-res image whereas task 4 is you know just downloading some text so test 2 certainly starts first however taps 4 happens much quicker so yes concurrent stuff you're doing stuff at the same time so it ends quicker however the order of completion is very unpredictable so this leads us into the pros and cons of each when should you use a serial queue when should use a concurrent queue let's talk about the serial queue first so in a serial queue it's a predictable execution order so everything happens in order one two three four two doesn't even start until one is done so this prevents race conditions which we'll talk about in a second it's very predictable let's take a look so again the tasks come in caps one gets completed test to be completed test 3 test for cetera everything's in order one at a time pretty clean however as you can imagine this is slower because everything is happening one at a time Cass too doesn't even start until task one is complete so concurrent queues are faster because yes they still start an order but everything is kind of happening concurrently or at the same time however this results in an unpredictable order and what I mentioned earlier in race conditions so we're gonna look at our example again here in a second but I want you to imagine something first imagine test three and task four are related in your code has some conditional logic that is relying on task 3 to be complete before task 4 however you put it on a concurrent queue so you can't guarantee the order of completion now sometimes task 3 will be done before task forward you can't really predict that it all depends on how the system is managing the threads and the resources and again that's why it's called a race condition because you can never be certain which task is gonna finish before the other task and again that's why it has an unpredictable order again remember the concurrent queue is a much faster way to execute a group of tasks however you just have to not care about the order they get executed in so for example let's say you're saving a bunch of user preferences you don't care what order they get saved and you just want to be saved as quick as possible so that's when you would use a concurrent queue in vice-versa when the order of execution is absolutely imperative then you would want to use a serial queue now by default every app gets one serial queue which is the main queue and then for concurrent queues which are your background queues of various priorities now you can create your own custom queues but for the most part this main queue that you get and the for concurrent queues in the background that's usually more than enough for what you need if you want to create our own custom ones that's probably more a little more advanced but just know that you can do that so how do we switch back and forth between these queues now you've probably seen this little bit of code before this ditch batch queue main async and then you do some code in there a very common case when you would use this is not what I have shown now let's say you downloaded some JSON data from the internet you're populating a table view once all that stuff is done downloading you want to reload your table view to show your data well all that downloading stuff is happening on a background thread now you want to shift to a main thread to update your UI remember the main thread is kind of like the UI thread so here what this code is doing it is dispatching off the background thread to the main thread and then here we are reloading our table view data this is a very common little chunk of code and a the new UI on the main thread is something you'll do all the time as a developer so you'll see this a lot now you can't move stuff to a background cue manually here using dispatch cube global and the QoS stands for quality of service and in this case we want it to be on the background and then you just run whatever code you run run in this block now to be honest with you I have almost never used this code to manually send something to a background cue I'm not saying you're never going to use it but the previous example of moving something to the main cue and the main thread is much more common than manually sending something to the background thread but I did just want to show you this so you know it is possible but again far and away the most common way you're going to use Grand Central Dispatch is moving stuff from a background cue to the main queue using this dispatch cue async and then doing something like reloading your table view again you're gonna use this all the time alright so there you have it hopefully have a pretty good understanding about what concurrency and threading is and what's going on and then now you can crush that interview question if you don't leave a comment leave a question I'll jump in there and help out all right you found this little useful going to subscribe I put out new videos all the time

Channel: Sean Allen

Views: 82,027

Keywords: concurrency, concurrency and threading, ios concurrency, ios multithreading, ios multithread, ios threading, ios interview question, ios interview questions and answers, swift interview questions, swift interview questions and answers, ios thread example, ios multithreading tutorial, ios concurrency tutorial, ios race condition, race condition explained, ios interview question in swift, ios interview, ios interview questions in Swift, ios interview questions 2017

Id: iTcq6L-PaDQ

Length: 7min 50sec (470 seconds)

Published: Thu Aug 10 2017