Thread Pool (I): The role of thread pool and CLR Thread Pool

Thread Pool is an important concept. However, I found that there seems to be something missing from the discussion on this topic. Supplement the information and futureArticleThe reference I need here is a complete and simple introduction to the thread pool and the basis of various thread pools in. net. More details will not be discussed. We will have the opportunity to discuss the details in detail. This time, it is still an "summary" Nature, hoping to understand some concepts of this issue.

Role of Thread Pool

In fact, the "Thread Pool" is the object pool used to store the "Thread.

InProgramIf the cost of creating an object is too high and this object can be used repeatedly, we will usually prepare a container to save a batch of such objects. Therefore, if we want to use such an object, we don't need to create one each time, but simply retrieve a ready-made object from the container. Because it saves the cost of creating objects, the program performance naturally increases. 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 is used up, so that the object can be put back into the pool, you can use it again when you need it next time.

For example, we are using ADO.. net connection to SQL Server ,. net Framework will automatically help us maintain a connection pool. This is because the cost of re-creating a connection is relatively high, and "reuse" is relatively easy. However, some may say that we create a sqlconnection object every time. Where can we reuse it? This is because the. NET Framework makes the "connection pool" transparent and completely hides this concept from programmers. Each time we create a new sqlconnection object, the "database connection" occupied by this object will still be reused. Why does it always mean to "close" (dispose or close) in time after the sqlconnection object is used up? In fact, the database connection is not closed, but the connection is put back into the connection pool. When a new sqlconnection object is created, the connection can be used again.

Since we get objects from the pool every time, who will create these objects and when will they be created? This is implemented by the object pool from rows according to different situations. For example, you can specify the number of objects in the pool when creating an object pool, and all objects are created at once. Of course, you can also create an object if no objects exist in the pool when you get the request. You can also "prepare a part in advance" and "in progress" as needed. It can also be "intelligent", for example, adding or deleting objects based on actual conditions, or even making "predictions" on the Demand "trend ", when you are idle, you can create more objects for "temporary needs ". The changes are hard to explain.

Of course, their principles and purposes are similar. I believe the above text has also clarified the role of the "Thread Pool": because it is costly to create a thread, we use the thread pool to reuse the thread. That's simple.

CLR Thread Pool

In. net, the CLR thread corresponds to the operating system thread, you can simply think. the thread object in. Net encapsulates an operating system thread with the required data (such as GC handle) 1 in a hosted environment. The CLR thread pool is the object pool that stores these CLR threads.

When writing a program, we can use 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, the former collects the executioncontext of the caller, that is, the execution information of the current thread (such as authentication or language culture) retained ), so that the task will eventually be executed in the environment at the time of "creation"-the latter will not. Therefore, if we compare the absolute performance of the two methods, the unsafe method will be slightly better. However, we recommend that you use the queueuserworkitem method at ordinary times, because retaining the execution context will avoid a lot of troubles, And this performance loss is actually nothing.

The CLR thread pool plays a major role in the. NET Framework. In addition to being used by programmers, other functions also depend on the CLR thread pool. Such as threadpool. registerwaitforsingleobject method, or system. threading. timer component -- more important and possibly hidden: Asp. net will also submit the tasks processed by this request to the CLR thread pool for execution after a request is obtained. Note that they are only adding tasks at most and do not indicate that the task will be executed immediately. All tasks added to the CLR thread pool will be executed at the right time-either immediately or for a moment or even longer.

When a task is added to the CLR thread pool, the task is temporarily put into a queue and executed as appropriate. So how can this be a "suitable time "? Simply put, it is the time when there are Idle threads in the thread pool, or the number of threads managed by the thread pool has not reached the upper limit. If there is an idle thread, the thread pool immediately receives a task for execution. In the second case, the thread pool creates a new thread object. Since operating system management is too multi-threaded, performance may decrease. Therefore, the CLR thread pool has an upper limit. Different hosting environments have different limits. For example, after. NET 2.0 SP1, a common Windows application (such as the console or winform/WPF) will set it to "processor count * 250 ". That is to say, if your machine has two 2-core CPUs, the maximum capacity of the CLR thread pool is 1000 by default. That is to say, it can manage up to 1000 threads at the same time-in many cases this is already a terrible number, if you think this is not enough, then you should consider whether your implementation method can be improved.

For ASP. NET applications, the CLR thread pool capacity represents the maximum number of requests that an application can execute at the same time. For the ASP. NET execution environment hosted on IIS, this value is determined by the global configuration. This configuration is in the system. Web/processmodel node in the machine. config file, which is the maxworkerthreads attribute and determines the number of threads allocated to a single processor. If the value is 40 and the machine has 4 Processors (2*2 CPU), the current configuration of this machine indicates that ASP. NET can process 160 requests at the same time. For some references, we recommend that you change it to 80-threads per processor. You only need to modify the attribute value.

Since there is a maximum value, there is a corresponding minimum value, it represents the minimum number of threads in the CLR thread pool that "will always be retained. Because the thread occupies resources, for example, by default, each thread will get 3 of the stack space of 1 MB. Therefore, it is a waste of resources to keep too many Idle threads in the system. Therefore, after a large number of threads are used to process a large number of tasks, the CLR thread pool will gradually release the threads until the minimum value is reached. The minimum number of threads in the CLR thread pool ensures that new tasks can be executed immediately when the number of tasks is small, thus saving the time for creating new threads. In a common application, this value is "Number of processors * 1", while in ASP. NET application. system. 4 In the minworkerthreads attribute of the Web/processmodel node.

In some cases, a large number of tasks suddenly occur in an instant. The execution time of each task is short, short, or short, however, the thread pool can quickly allocate hundreds of threads. If the peak value is calm, it will inevitably lead to a large number of Idle threads. This overhead is also very obvious to the performance consumption. Therefore, the CLR thread pool limits the thread creation speed to no more than 2 per second. In this way, the CLR thread pool can use a relatively small number of threads to complete all work even if a large number of tasks are obtained in a certain instant.

However, there is another situation worth considering. For example, for a busy web application, a large number of connections will flood into when it is opened. The thread creation speed is limited, so the number of requests that can be executed can only increase slowly. In this situation, you expect to produce a large number of threads, and the busy condition will last for a period of time. Limiting the thread creation speed will lead to damage efficiency. In this case, you can manually set the minimum number of threads in the CLR thread pool. If the number of threads in the CLR thread pool is small at this time, the system will immediately create a certain number of threads to reach this minimum value. The interface for setting and obtaining the minimum number of threads in the CLR thread pool is:

Public static classThreadpool{Public static voidGetminthreads (Out intWorkerthreads,Out intCompletionportthreads );Public static boolSetminthreads (IntWorkerthreads,IntCompletionportthreads );}
 

The functions and usage of these two interfaces should be obvious enough (you can refer to msdn if you don't understand it). The workerthreads parameter is the minimum number of threads in the CLR thread pool, the completionportthreads involves the I/O thread pool we will discuss next time, so we will not proceed here. In addition to setting and reading the minimum number of CLR threads, threadpool also includes these interfaces:

Public static classThreadpool{Public static voidGetmaxthreads (Out intWorkerthreads,Out intCompletionportthreads );Public static boolSetmaxthreads (IntWorkerthreads,IntCompletionportthreads );Public static voidGetavailablethreads (Out intWorkerthreads,Out intCompletionportthreads );}
 

It is worth noting that both the Set and the obtained values have nothing to do with the number of processors. That is to say, when running a common. NET application on a 2*2 CPU machine:

• Call the getmaxthreads method to obtain 1000, indicating that the maximum capacity of the CLR thread pool is 1000 (250*4), instead of 250.
• Call setminthreads and input 100, indicating that the minimum number of threads in the CLR thread pool is 100, instead of 400 (100*4 ).

A brief description of the CLR thread pool is provided here. If you have any questions, I will add them.

 

Original article: http://www.cnblogs.com/jeffreyzhao/archive/2009/07/22/thread-pool-1-the-goal-and-the-clr-thread-pool.html