by: Milind Shroff
There are several very useful benefits to threading; we can have several processes running at once, and several threads running within those processes. So, with all these benefits, why don’t we just use new threads for all of our methods? Wouldn’t that just make everything run fast? Not really. As a matter of fact, we will see in this section that quite the opposite can happen if we overuse threading.
Multithreaded applications require resources. Threads require memory to store the thread-local storage container. As you can imagine, the number of threads used is limited by the amount of memory available. Memory is fairly inexpensive these days so many computers have large amounts of memory. However, you should not assume that this is the case. If you are running your application on an unknown hardware configuration, you cannot assume that your application will have enough memory. Additionally, you cannot assume that your process will be the only one spawning threads and consuming system resources. Just because a machine has a lot of memory, doesn’t mean it’s all for your application.
You will also discover that each thread also incurs additional processor overhead. Creating too many threads in your applications will limit the amount of time that your thread has to execute. Therefore, your processor could potentially spend more time switching between threads as opposed to actually executing the instructions that the threads contain. If your application is creating more threads, your application will gain more execution time than all the other processes with fewer threads.
To make this concept easier to understand, take the parallel example you’ll find down at your local grocery store. Two cashiers are scanning groceries for their customers. However, there is only one bagger, who takes turns switching between the two cashiers. The bagger is rather efficient at jumping back and forth between the two registers and bagging the groceries because they don’t pile up any faster than the bagger can bag the groceries. However, if two more cashiers open up lanes, it will become apparent that the bagger will spend more time jumping back and forth between the registers than they spend actually bagging groceries. Eventually, the store will need to get another bagger. In the case of threading, think of the cashiers as applications - or threads, and the bagger as a processor. The processor has to switch between threads. As the “threads” increase, the grocery store has to add another “processor” to be sure that the customers get the attention they need.
The phrase “too many threads” is a rather generic term - and rightly so. What constitutes “too many” on one system could be fine on another. Since hardware configurations largely dictate the number of threads available on a system, “too many” is an unquantifiable variable without specific configuration details and lots of testing.
It is for these reasons that Microsoft recommends that you use as few threads as possible in your applications. This limits the amount of resources required by the operating system.
There are several very useful benefits to threading; we can have several processes running at once, and several threads running within those processes. So, with all these benefits, why don’t we just use new threads for all of our methods? Wouldn’t that just make everything run fast? Not really. As a matter of fact, we will see in this section that quite the opposite can happen if we overuse threading.
Multithreaded applications require resources. Threads require memory to store the thread-local storage container. As you can imagine, the number of threads used is limited by the amount of memory available. Memory is fairly inexpensive these days so many computers have large amounts of memory. However, you should not assume that this is the case. If you are running your application on an unknown hardware configuration, you cannot assume that your application will have enough memory. Additionally, you cannot assume that your process will be the only one spawning threads and consuming system resources. Just because a machine has a lot of memory, doesn’t mean it’s all for your application.
You will also discover that each thread also incurs additional processor overhead. Creating too many threads in your applications will limit the amount of time that your thread has to execute. Therefore, your processor could potentially spend more time switching between threads as opposed to actually executing the instructions that the threads contain. If your application is creating more threads, your application will gain more execution time than all the other processes with fewer threads.
To make this concept easier to understand, take the parallel example you’ll find down at your local grocery store. Two cashiers are scanning groceries for their customers. However, there is only one bagger, who takes turns switching between the two cashiers. The bagger is rather efficient at jumping back and forth between the two registers and bagging the groceries because they don’t pile up any faster than the bagger can bag the groceries. However, if two more cashiers open up lanes, it will become apparent that the bagger will spend more time jumping back and forth between the registers than they spend actually bagging groceries. Eventually, the store will need to get another bagger. In the case of threading, think of the cashiers as applications - or threads, and the bagger as a processor. The processor has to switch between threads. As the “threads” increase, the grocery store has to add another “processor” to be sure that the customers get the attention they need.
The phrase “too many threads” is a rather generic term - and rightly so. What constitutes “too many” on one system could be fine on another. Since hardware configurations largely dictate the number of threads available on a system, “too many” is an unquantifiable variable without specific configuration details and lots of testing.
It is for these reasons that Microsoft recommends that you use as few threads as possible in your applications. This limits the amount of resources required by the operating system.
No comments:
Post a Comment