jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Threads and Why Threads and Multithreading

In programming, almost everything is about threads. The thread that is running right now. The thread that is waiting for something to happen. The thread that is taking care of the user interface. So on and so forth. You could have one thread or a dozen or more.  

Threads, I will admit, can be a complicated topic. Even after building so many apps, I still need to refer or check with experts how something works. However, starting with the essentials will help you get a hang of things. Then, you can keep climbing till you reach the ceiling.  

Consider a bank queue. You are standing in the queue and there are many folks in the queue. Men, women, young girls, old grandpa and grandma. Let's say that in front of you is slow. Like glacier slow. Baby trying to stand up for the first slow. Snail crossing a road on a rainy day slow. The teller (the person from the bank, on the other side of the counter) takes this person's form and finds out that the account number and signature is missing. So, she (bank tellers are almost always exclusively female) will ask the person to fill those items.  

We already told you how this person – who now has to fill those missing items – will take his own time. Remember the snail and baby? Yes you do. While this person fills up the details, the teller is waiting. You are waiting. Everybody behind you is waiting. The world slows to a stop! 

That's how real life works. Now, imagine an alternate scenario. The moment that slow person gets busy with the form, the teller asks for your form. It takes the teller 10 secconds to take of your form. You see, you are smart. You filled out your form properly. By the time you are done, the snail person is done filling in the blanks. Now, the teller can resume that slow persons work and everybody is happy.  

That is how threads work in a program. The computer, any computer is pretty fast. Most of the time, it has the ability to do things, fast. Like really fast. In your program if you multiple threads, you will notice that each thread only needs a fraction of the CPU's processing ability per second. However. Like that old person in the queue, each thread may need a lot of time to complete its work. If the CPU were to wait for the thread to finish all its work, it would be waiting forever. Just like that teller. 

Suppose you have two threads. Thread 1 needs 30 seconds to finish its work, but needs only 1 second of the CPU. Suppose Thread 2 needs 60 seconds to finish its work, but needs only 0.5 second of CPU. Let's say the CPU currently does not know how to handle multiple threads. Like that bank teller who can only handle one customer at a time.  

Here is how it works. Thread 2 begins its work, and occupies the CPU. From the paragraph we know that the thread 2 needs 60 seconds, but only 0.5 of those seconds involve the CPU. After 60 seconds, Thread 2 is done and Thread 1 will start. It needs 30 seconds out of which only one second is CPU involve. When both Thread 1 and Thread 2 are done, 90 seconds have elapsed out of which only 1.5 seconds involves CPU. That means, out of 90 seconds the CPU is idle 88.5 seconds.  

That is almost like buying a popcorn for 90 rupees but only eating 1.5 popcorn and throwing the rest away. You cannot do that. No, you cannot do that at all! Remember how your parents told you that you should never waste anything? This is why they told you. You cannot waste precious CPU cycles.  

Now, let me give you another scenario. This time, unlike that bank teller, our CPU can handle multiple threads. Thread 2 begins its work. However, it informs the CPU that it does not need the CPU right away. Then, the CPU notices that Thread 1 is now waiting for CPU cycles. CPU puts the Thread 2 aside and picks up Thread 1, which is demanding its share of CPU cycle. So CPU gives the 1 second that the Thread 1 wants. After that, Thread 1 will continue with its work, no longer needing the CPU. Now, the CPU just waits for Thread 2 to demand its CPU cycles. While Thread 2 is busy and not demanding CPU cycles, the CPU is idle, ready to serve other threads.  

That means, although the two threads in total need 90 seconds, the CPU itself was busy with threads for 1.5 seconds, and may be another 1 second was lost with all that switching between waiting, idling and being active. That means, the CPU was busy only 3 seconds, and available rest of the time. Comparing to the previous situation, the CPU was busy for 90 seconds and here it was only busy was 3 seconds. The other 87 seconds could be used to serve other threads that are demanding CPU cycles.  

That means, thanks to threads, multithreading and CPU's ability to juggle them, things become awesome. This is precisely what our parents told us did not they. Especially mom. Don't waste resources. Always, make the most of them.

Comments are closed