Analysis of the function and principle of CLR thread pool

The thread pool is an important concept. But I find that there seems to be a lack of discussion on this topic. As a supplement to the information and references needed for future articles, I am here to talk about the thread pool in a complete and simple way, and. NET in the basis of various thread pools. More details will not be launched, and we have the opportunity to discuss the details in detail. This time, it is an "overview" of the nature, I hope to be able to understand some of the concepts of this problem.

The role of the thread pool

In fact, the "thread pool" is the object pool used to hold threads.

In a program, if the cost of creating an object is too high, and the object can be reused again and again, we tend to prepare a container to hold a batch of such objects. So, when we want to use this object, we don't need to create one at a time, and just take a ready-made object out of the container. Due to the savings in the cost of creating objects, program performance naturally goes up. This container is the "pool". It is easy to understand that because of the object pool, there must be a "return" action after the object has been used, so that the object can be put back in the pool and used again the next time it is needed.

For example, when we are using ado.net to connect to SQL Server. NET Framework automatically helps us maintain a connection pool because the cost of recreating a connection is relatively high, and "reusing" is more cost-effective. However, some friends may say, we obviously create a SqlConnection object every time, where there is "reuse" Ah? This is because. NET Framework to make the "connection pool" clear, for programmers completely hide the concept. Each time we create a new SqlConnection object, the "database connection" used internally by this object is reused. Why do you always have to "turn off" (Dispose or close) when you finish using SqlConnection objects? In fact, there is no disconnect from the database, just put the connection back to the connection pool. Wait until the next time you create a new SqlConnection object, the connection can be used again.

Since we are getting objects from the pool each time, who is creating the objects and when are they created? This will be based on different situations by the object pool from the row implementation. For example, you can specify the number of objects in the pool when you create the object pool, and you can create them all at once, but you may also create a request if you find that there are no remaining objects in the pool. You can also "beforehand" prepare a part, "in the matter" to continue to supplement as needed. You can also do some of the "smart", for example, to add or delete objects according to the actual situation, even to the demand "trend" to "predict", in the idle will create more objects for "rainy time." All the changes are difficult to say.

Of course, they are similar in principle and purpose. I believe that the above text has also made clear the role of the "thread pool": Because the cost of creating a thread is high, we use the thread pool to try to reuse the thread. It's so simple.

The role of the CLR thread pool

In. NET, the CLR thread and the operating system thread correspond, as you can simply assume. NET encapsulates an operating system thread and comes with data (such as GC Handle) 1 that is required in a managed environment. The CLR thread pool is the object pool where these CLR threads are stored.

When we write a program, we can use the two static methods of the ThreadPool class: QueueUserWorkItem and Unsafeuserqueueworkitem to add a task (a Workcallback delegate object) to the CLR thread pool. The difference between the two methods is that the former collects the executioncontext of the caller, that is, the execution information (such as authentication or language culture) of the current thread that is retained, so that the task will eventually execute in the context of the "create" time 2--the latter will not. Therefore, if you compare the absolute performance of two methods, the unsafe method will slightly. However, it is usually recommended that you use the QueueUserWorkItem method, because preserving the execution context avoids a lot of trouble, and this loss of performance is actually nothing.

The CLR thread pool plays a large role in the. NET Framework, and other features rely on the CLR thread pool in addition to being used by programmers. such as ThreadPool.RegisterWaitForSingleObject method, or System.Threading.Timer component-- More important and potentially more hidden: asp.net the request will be processed by the CLR thread pool when it gets a request--note that they are at most just adding a task and do not mean that the task will be executed immediately. All tasks added to the CLR thread pool will be executed at the right time--perhaps immediately, or perhaps even longer.

When you add a task to the CLR thread pool, the task is temporarily placed in a queue and executed at the appropriate time. So what's the "Right time"? The simple generalization is that there are idle threads in the thread pool, or the number of threads managed by thread pools is not up to the upper limit. If there is an idle thread, the thread pool will immediately let it pick up a task execution. In the second case, the thread pool creates a new thread object. The CLR thread pool has an upper limit because of the performance degradation caused by allowing the operating system to manage too many threads. Different managed environments have different caps set. After a. NET 2.0 SP1, a normal Windows application, such as a console or WINFORM/WPF, is set to processor number * 250. That is, if your machine is 2 2 cores, the default upper limit for the CLR thread pool is 1000, that is, it can manage up to 1000 threads at the same time--in many cases it's already a scary number, if you don't think it's enough, Then you should consider whether your implementation can be improved.