93: Multithreading. When Should You Use It?

Take Up Code - Un pódcast de Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categorías:

Do you know when to use multithreading? What are the advantages and disadvantages? This episode continues what will likely be several more episodes devoted to multithreading. Listen to this episode, or read the full transcript below, to learn about the following four reasons to use multithreading: When you’re about to call some method that could take a long time to complete and you don’t want to wait around. When you want to setup some completely independent part of your application. When you have a problem that lends itself to being divided up into smaller problems that can be recombined later to form the final answer. When you want to perform the same task multiple times in slightly different ways. Transcript When your application starts, it’s running as a process so that the operating system can isolate everything that happens in your process from all the other processes that are running. A process doesn’t really run though, at least not on modern operating systems. Older versions of Unix used processes exclusively and had no concept of threads. The idea of threads was to allow for mini-processes. You see, it’s expensive to start a process because of all the isolation and security that the operating system needs to setup and maintain. So whenever you want to do multiple things, instead of starting a new instance of your entire process, you just create a thread that runs inside your process. I use the words process and application a lot to mean the same thing. the only real difference is that users normally think of applications as the programs that they run. And now that I say it, I also use program too. All these really mean about the same thing. However, an operating system usually has many processes running that the user is normally unaware of. An application is just a process that the user knows about and usually has a main window. And a program is the same as an application. I can’t think of any meaningful difference between an application and a program. For thread aware operating systems, which should include almost all of them these days, when your application starts, the operating system will create your first thread for you. This is sometimes called the main thread. If your application doesn’t use multithreading, then you may not even be aware that the whole system enabling your code to run is based on a thread provided for you. Your main thread and any other threads you create all run inside your process. They share the same memory space and default user identity and security. Other than your main thread, if you want another thread, you need to create it yourself. You do this by calling a method usually provided by your operating system or maybe the library that comes with your language also has this ability. If your library allows you to create additional threads, it’ll eventually need to call an operating system method anyway. the nice thing about using a library method is that it makes your code more portable to other platforms. Alright, so when should you create a new thread? There are many reasons. Here are probably the four most common that I can think of: ◦ #1 When you’re about to call some method that could take a long time to complete and you don’t want to wait around. ◦ #2 When you want to setup some completely independent part of your application. ◦ #3 When you have a problem that lends itself to being divided up into smaller problems that can be recombined later to form the final answer. ◦ #4 When you want to perform the same task multiple times in slightly different ways. I’ll explain more details about each of these four reasons right after this message from our sponsor. (Message from Sponsor ) The first reason is by far the most common reason that I’ve had for multithreading. Let’s say you have a graphical application. I don’t mean an application to create graphic images. I mean an application that has windows tha

Visit the podcast's native language site