105: Multithreading. Sync vs. Async.

What are synchronous and asynchronous methods and how do you use them? Sometimes we expect an answer or a result right away. And sometimes, it might take a while. And sometimes, what we thought would be quick turns out to take longer. If I ask you what’s the current time, then I expect some kind of answer even if that answer is “I don’t know.” And if I ask you for a favor, then I usually expect that you’ll start soon but probably not right away. What if you’re in the middle of an important phone call and I ask you for the time? It might take a little longer, right? Or if the favor is small and you’re not doing anything at the moment, then you might be glad to help immediately. The point is, we can’t be sure how long something will take in the real world and the same thing is true in programming. A method that runs right away is called synchronous. And a method that runs later is called asynchronous. The asynchronous method doesn’t exactly run later. It’s actually composed of two parts. The first part is a normal synchronous method that you can call and expect an immediate answer. The difference is that the method will start a new thread to perform the requested action. What you get back right away isn’t the result you want but instead information that will let you get your desired outcome later. This frees the calling code to be able to do other tasks and periodically wait for the asynchronous task to complete. Listen to the full episode about these methods or you can read the full transcript below. Transcript Sometimes we expect an answer or a result right away. And sometimes, it might take a while. And sometimes, what we thought would be quick turns out to take longer. If I ask you what’s the current time, then I expect some kind of answer even if that answer is “I don’t know.” And if I ask you for a favor, then I usually expect that you’ll start soon but probably not right away. What if you’re in the middle of an important phone call and I ask you for the time? It might take a little longer, right? Or if the favor is small and you’re not doing anything at the moment, then you might be glad to help immediately. The point is, we can’t be sure how long something will take in the real world and the same thing is true in programming. A method that runs right away is called synchronous. And a method that runs later is called asynchronous. We normally have an idea if something can be done right away or not. And it helps to plan one way or another. Calling a method is the same. Or at least it should be. Here’s what I mean. Most methods that you call will be very clear if they run right away or not. This is because when a method can run later, then there needs to be some way for the asynchronous method to communicate back to you when it’s done. Sure, it’s possible to design a system where method calls all look synchronous and there’s some roundabout way to find out when they complete and get the results but I wouldn’t want to use a system like that. It’s just too confusing. Let’s take a simple method called removeCakeFromOven that returns void and takes no parameters. If I had code that called such a method, then I’d expect the method to begin running right away and complete fairly soon in a synchronous manner. In fact, the normal method calling protocol causes my code to stop running and the processor goes right into the removeCakeFromOven code. When the removeCakeFromOven code eventually hits a return statement, then it’s done and the processor switches back to the next line in my code right after I called the removeCakeFromOven method. In other words, my code continues running right where it left off. There’s a builtin ability to synchronize the call of this type of method with it’s return. That’s why normal methods like this are call synchronous