blocks|key|1523069|text|当你有比可用线程更多的任务要处理时，线程池是很好的选择。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523070|您可以将所有任务添加到线程池中，并指定在特定时间可以运行的最大线程数。|1523071|查看MSDN上的this页面：http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx|offset|length|1523072|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx|1^0|0|0|8|4|0|F|1O|1|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@$F|T|G|U|1|V]|$F|W|G|X|1|Y]]|A|$]]|$1|H|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|O]]]]

Thread pools are great when you have more tasks to process than available threads.

You can add all the tasks to a thread pool and specify the maximum number of threads that can run at a certain time.

Check out <a href="http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx" rel="nofollow noreferrer">this</a> page on MSDN:
<a href="http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx</a>

blocks|key|1523090|text|如果可以，请始终使用线程池，在尽可能高的抽象级别上工作。线程池隐藏了为你创建和销毁线程，这通常是一件好事！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523091|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Always use a thread pool if you can, work at the highest level of abstraction possible. Thread pools hide creating and destroying threads for you, this is usually a good thing!

blocks|key|1738133|text|如果您有许多需要持续处理的逻辑任务，并且希望以并行方式完成这些任务，请使用pool%2Bscheduler。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1738134|如果您需要并发执行与IO相关的任务，例如从远程服务器下载内容或访问磁盘，但需要这样做，例如每隔几分钟执行一次，那么可以创建自己的线程，并在完成后杀死它们。|1738135|编辑:关于一些考虑因素，我将线程池用于数据库访问、物理/模拟、AI(游戏)，以及在处理大量用户定义任务的虚拟机上运行的脚本任务。|1738136|通常一个池由每个处理器2个线程组成(所以现在可能是4个)，但是如果你知道你需要多少线程，你可以设置你想要的线程数量。|1738137|编辑:创建自己的线程的原因是因为上下文发生了变化(即线程需要在进程内和进程外交换，以及它们的内存)。有了无用的上下文更改，比如当你不使用你的线程时，就像一个人可能会说的那样，让它们坐着不动，可以很容易地让你的程序的性能减半(比如你有3个休眠线程和2个活动线程)。因此，如果这些下载线程只是在等待，那么它们将消耗大量的CPU并为您的实际应用程序冷却缓存|1738138|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If you have lots of logical tasks that require constant processing and you want that to be done in parallel use the pool+scheduler.

If you need to make your IO related tasks concurrently such as downloading stuff from remote servers or disk access, but need to do this say once every few minutes, then make your own threads and kill them once you're finished.

Edit: About some considerations, I use thread pools for database access, physics/simulation, AI(games), and for scripted tasks ran on virtual machines that process lots of user defined tasks.

Normally a pool consists of 2 threads per processor (so likely 4 nowadays), however you can set up the amount of threads you want, if you know how many you need.

Edit: The reason to make your own threads is because of context changes, (thats when threads need to swap in and out of the process, along with their memory). Having useless context changes, say when you aren't using your threads, just leaving them sit around as one might say, can easily half the performance of your program (say you have 3 sleeping threads and 2 active threads). Thus if those downloading threads are just waiting they're eating up tons of CPU and cooling down the cache for your real application

blocks|key|1738180|text|我建议您在C#中使用线程池，原因与其他语言相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1738181|当您想要限制正在运行的线程的数量，或者不想要创建和销毁它们的开销时，可以使用线程池。|1738182|对于小任务，你读的书是指生命周期很短的任务。如果创建一个只运行一秒的线程需要10秒，那么您应该使用池(忽略我的实际数字，它才是最重要的)。|1738183|否则，您会将大部分时间花在创建和销毁线程上，而不是简单地完成它们想要做的工作。|1738184|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I would suggest you use a thread pool in C# for the same reasons as any other language.

When you want to limit the number of threads running or don't want the overhead of creating and destroying them, use a thread pool.

By small tasks, the book you read means tasks with a short lifetime. If it takes ten seconds to create a thread which only runs for one second, that's one place where you should be using pools (ignore my actual figures, it's the ratio that counts).

Otherwise you spend the bulk of your time creating and destroying threads rather than simply doing the work they're intended to do.

blocks|key|1523232|text|下面是对.Net中线程池的一个很好的总结：http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1523233|这篇文章也有一些要点，告诉你什么时候不应该使用线程池，而是启动自己的线程。|1523234|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx^0|L|2K|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Here's a nice summary of the thread pool in .Net: <a href="http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx" rel="noreferrer">http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx</a>

The post also has some points on when you should not use the thread pool and start your own thread instead.

blocks|key|1523293|text|线程池旨在减少线程之间的上下文切换。考虑一个有多个组件正在运行的进程。这些组件中的每一个都可以创建工作线程。进程中的线程越多，在上下文切换上浪费的时间就越多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523294|现在，如果这些组件中的每个组件都将项目排队到线程池中，那么您将有更少的上下文切换开销。|1523295|线程池旨在最大化跨CPU+(或CPU核心)执行的工作。这就是为什么在默认情况下，线程池会在每个处理器上运行多个线程。|1523296|在某些情况下，您不希望使用线程池。如果你正在等待I/O，或者等待一个事件，等等，那么你占用了线程池线程，其他任何人都不能使用它。同样的想法也适用于长时间运行的任务，尽管长时间运行任务的构成是主观的。|1523297|Pax+Diablo也提出了很好的观点。旋转线程并不是免费的。这需要时间，而且它们会为堆栈空间消耗额外的内存。线程池将重用线程来摊销此成本。|1523298|注意:您询问了使用线程池线程来下载数据或执行磁盘I/O。您不应该为此使用线程池线程(出于我上面概述的原因)。相反，请使用异步I/O+(也称为BeginXX和EndXX方法)。对于BeginRead和EndRead的FileStream。对于HttpWebRequest，应该是BeginGetResponse和EndGetResponse。它们使用起来比较复杂，但它们是执行多线程I/O的合适方法。|offset|length|style|CODE|1523299|entityMap^0|0|0|0|0|0|2H|9|2R|7|2Z|A|3C|E|3U|G|4B|E|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$L|X|M|Y|N|O]|$L|Z|M|10|N|O]|$L|11|M|12|N|O]|$L|13|M|14|N|O]|$L|15|M|16|N|O]|$L|17|M|18|N|O]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|Q|$]]

The thread pool is designed to reduce context switching among your threads. Consider a process that has several components running. Each of those components could be creating worker threads. The more threads in your process, the more time is wasted on context switching.

Now, if each of those components were queuing items to the thread pool, you would have a lot less context switching overhead.

The thread pool is designed to maximize the work being done across your CPUs (or CPU cores). That is why, by default, the thread pool spins up multiple threads per processor. 

There are some situations where you would not want to use the thread pool. If you are waiting on I/O, or waiting on an event, etc then you tie up that thread pool thread and it can't be used by anyone else. Same idea applies to long running tasks, though what constitutes a long running task is subjective.

Pax Diablo makes a good point as well. Spinning up threads is not free. It takes time and they consume additional memory for their stack space. The thread pool will re-use threads to amortize this cost.

Note: you asked about using a thread pool thread to download data or perform disk I/O. You should not use a thread pool thread for this (for the reasons I outlined above). Instead use asynchronous I/O (aka the BeginXX and EndXX methods). For a <code>FileStream</code> that would be <code>BeginRead</code> and <code>EndRead</code>. For an <code>HttpWebRequest</code> that would be <code>BeginGetResponse</code> and <code>EndGetResponse</code>. They are more complicated to use, but they are the proper way to perform multi-threaded I/O.

blocks|key|1523345|text|大多数情况下，您可以使用池，因为您可以避免创建线程的昂贵过程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523346|但是，在某些情况下，您可能希望创建一个线程。例如，如果您不是唯一使用线程池的人，并且您创建的线程是长期的(为了避免消耗共享资源)，或者如果您想要控制线程的堆栈大小。|1523347|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most of the time you can use the pool as you avoid the expensive process of creating the thread.

However in some scenarios you may want to create a thread. For example if you are not the only one using the thread pool and the thread you create is long-lived (to avoid consuming shared resources) or for example if you want to control the stacksize of the thread.

blocks|key|1738386|text|仅将线程池用于小任务的一个原因是线程池线程的数量有限。如果一个线程被使用了很长时间，那么它就会阻止其他代码使用该线程。如果这种情况发生了很多次，那么线程池就会耗尽。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1738387|耗尽线程池可能会产生一些微妙的影响-例如，一些.NET计时器使用线程池线程，因此不会触发。|1738388|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One reason to use the thread pool for small tasks only is that there are a limited number of thread pool threads. If one is used for a long time then it stops that thread from being used by other code. If this happens many times then the thread pool can become used up. 

Using up the thread pool can have subtle effects - some .NET timers use thread pool threads and will not fire, for example.

blocks|key|1738433|text|如果你有一个很长时间的后台任务，比如你的应用程序的整个生命周期，那么创建你自己的线程是合理的。如果您有需要在线程中完成的短作业，则使用线程池。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1738434|在创建多个线程的应用程序中，创建线程的开销变得很大。使用线程池创建线程一次并重用它们，从而避免线程创建开销。|1738435|在我工作的一个应用程序中，从创建线程改为使用线程池来处理短暂的线程，这确实有助于提高应用程序的吞吐量。|1738436|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you have a background task that will live for a long time, like for the entire lifetime of your application, then creating your own thread is a reasonable thing. If you have short jobs that need to be done in a thread, then use thread pooling.

In an application where you are creating many threads, the overhead of creating the threads becomes substantial. Using the thread pool creates the threads once and reuses them, thus avoiding the thread creation overhead.

In an application that I worked on, changing from creating threads to using the thread pool for the short lived threads really helpped the through put of the application.

blocks|key|1523475|text|当心.NET线程池中可能阻塞任何重要的、可变的或未知的处理部分的操作，因为它容易导致线程匮乏。考虑使用.NET并行扩展，它为线程操作提供了大量的逻辑抽象。它们还包括一个新的调度器，这应该是对ThreadPool的改进。请参阅here|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1523476|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/pfxteam/archive/2008/06/02/8567093.aspx^0|34|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Beware of the .NET thread pool for operations that may block for any significant, variable or unknown part of their processing, as it is prone to thread starvation. Consider using the .NET parallel extensions, which provide a good number of logical abstractions over threaded operations. They also include a new scheduler, which should be an improvement on ThreadPool. See <a href="http://blogs.msdn.com/pfxteam/archive/2008/06/02/8567093.aspx" rel="nofollow noreferrer">here</a>

blocks|key|1738544|text|当我只需要在另一个线程上做一些事情时，我通常会使用线程池，而不是真正关心它何时运行或结束。像日志记录或者甚至后台下载文件这样的事情(尽管有更好的方法来实现异步方式)。当我需要更多的控制时，我会使用自己的线程。我还发现，当我需要在一个以上的线程中处理多个命令时，使用Threadsafe队列(你自己的)来存储“命令对象”是很好的。因此，您可以拆分一个Xml文件，并将每个元素放入一个队列中，然后让多个线程对这些元素进行一些处理。早在uni中我就写了这样一个队列(VB.net!)我已经转换成C#了。我没有特别的原因将它包含在下面(这段代码可能包含一些错误)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1738545|using+System.Collections.Generic;
using+System.Threading;

namespace+ThreadSafeQueue+{
++++public+class+ThreadSafeQueue<T>+{
++++++++private+Queue<T>+_queue;

++++++++public+ThreadSafeQueue()+{
++++++++++++_queue+=+new+Queue<T>();
++++++++}

++++++++public+void+EnqueueSafe(T+item)+{
++++++++++++lock+(+this+)+{
++++++++++++++++_queue.Enqueue(item);
++++++++++++++++if+(+_queue.Count+>=+1+)
++++++++++++++++++++Monitor.Pulse(this);
++++++++++++}
++++++++}

++++++++public+T+DequeueSafe()+{
++++++++++++lock+(+this+)+{
++++++++++++++++while+(+_queue.Count+<=+0+)
++++++++++++++++++++Monitor.Wait(this);

++++++++++++++++return+this.DeEnqueueUnblock();

++++++++++++}
++++++++}

++++++++private+T+DeEnqueueUnblock()+{
++++++++++++return+_queue.Dequeue();
++++++++}
++++}
}|code-block|syntax|javascript|1738546|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I usually use the Threadpool whenever I need to just do something on another thread and don't really care when it runs or ends. Something like logging or maybe even background downloading a file (though there are better ways to do that async-style). I use my own thread when I need more control. Also what I've found is using a Threadsafe queue (hack your own) to store "command objects" is nice when I have multiple commands that I need to work on in >1 thread. So you'd may split up an Xml file and put each element in a queue and then have multiple threads working on doing some processing on these elements. I wrote such a queue way back in uni (VB.net!) that I've converted to C#. I've included it below for no particular reason (this code might contain some errors).

<pre><code>using System.Collections.Generic;
using System.Threading;

namespace ThreadSafeQueue {
 public class ThreadSafeQueue&lt;T&gt; {
 private Queue&lt;T&gt; _queue;

 public ThreadSafeQueue() {
 _queue = new Queue&lt;T&gt;();
 }

 public void EnqueueSafe(T item) {
 lock ( this ) {
 _queue.Enqueue(item);
 if ( _queue.Count &gt;= 1 )
 Monitor.Pulse(this);
 }
 }

 public T DequeueSafe() {
 lock ( this ) {
 while ( _queue.Count &lt;= 0 )
 Monitor.Wait(this);

 return this.DeEnqueueUnblock();

 }
 }

 private T DeEnqueueUnblock() {
 return _queue.Dequeue();
 }
 }
}
</code></pre>

blocks|key|1523566|text|别忘了调查后台工作者。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523567|我发现在很多情况下，它只给了我想要的东西，而不是繁重的负担。|1523568|干杯。|1523569|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Don't forget to investigate the Background worker.

I find for a lot of situations, it gives me just what i want without the heavy lifting.

Cheers.

blocks|key|1738658|text|我想要一个线程池，以尽可能少的延迟跨内核分配工作，而且不必与其他应用程序很好地配合。我发现.NET线程池的性能并不像它应该达到的那样好。我知道我需要每个内核一个线程，所以我编写了自己的线程池替代类。代码作为对另一个StackOverflow问题over+here的答案提供。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1738659|至于最初的问题，线程池对于将重复计算分解成可以并行执行的部分很有用(假设它们可以并行执行，而不会改变结果)。手动线程管理对于UI和IO之类的任务非常有用。|1738660|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/2215911/how-can-i-most-effectively-take-advantage-of-multiple-cores-for-short-computation/2218329#2218329^0|3E|9|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I wanted a thread pool to distribute work across cores with as little latency as possible, and that didn't have to play well with other applications. I found that the .NET thread pool performance wasn't as good as it could be. I knew I wanted one thread per core, so I wrote my own thread pool substitute class. The code is provided as an answer to another StackOverflow question <a href="https://stackoverflow.com/questions/2215911/how-can-i-most-effectively-take-advantage-of-multiple-cores-for-short-computation/2218329#2218329">over here</a>.

As to the original question, the thread pool is useful for breaking repetitive computations up into parts that can be executed in parallel (assuming they can be executed in parallel without changing the outcome). Manual thread management is useful for tasks like UI and IO.

blocks|key|1523681|text|为了获得并发执行单元的最高性能，请编写自己的线程池，其中线程对象池在启动时创建，然后进入阻塞状态(以前被挂起)，等待上下文运行(具有由您的代码实现的标准接口的对象)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523682|太多关于任务、线程和.NET+ThreadPool的文章并没有真正给出你所需要的关于性能的决定。但当你比较它们时，线程胜出，尤其是线程池。它们在CPU上的分布最好，而且启动速度更快。|1523683|应该讨论的是，Windows+(包括Windows+10)的主要执行单元是线程，OS上下文切换开销通常可以忽略不计。简而言之，我还没有找到这些文章中许多令人信服的证据，无论这篇文章声称通过节省上下文切换或更好的CPU使用率来提高性能。|1523684|现在让我们来了解一下现实情况：|1523685|我们中的大多数人不需要我们的应用程序是确定性的，并且我们中的大多数人都没有线程方面的背景知识，例如，这通常伴随着开发操作系统而来。我上面写的内容不适合初学者。|1523686|因此，最重要的可能是讨论什么是容易编程的。|1523687|如果您创建了自己的线程池，您将需要编写一些代码，因为您需要关注跟踪执行状态、如何模拟挂起和恢复以及如何取消执行-包括在应用程序范围内关闭时。您可能还需要考虑是否要动态增加池，以及池的容量限制。我可以在一个小时内写出这样一个框架，但那是因为我已经做过很多次了。|1523688|也许编写执行单元最简单的方法就是使用Task。任务的美妙之处在于，您可以创建一个任务，并在代码中以内联方式启动它(尽管可能需要谨慎)。当您想要取消任务时，您可以传递一个取消令牌来处理。此外，它使用promise方法来链接事件，您可以让它返回特定类型的值。此外，使用async和await，有了更多的选项，您的代码将更具可移植性。|1523689|本质上，理解Tasks、Thread和.NET+ThreadPool的优缺点是很重要的。如果我需要高性能，我将使用线程，并且我更喜欢使用我自己的池。|1523690|比较的简单方法是启动512个线程、512个任务和512个ThreadPool线程。你会发现线程在开始时有延迟(因此，为什么要写线程池)，但是所有512个线程都将在几秒钟内运行，而任务和.NET+ThreadPool线程需要几分钟才能全部启动。|1523691|下面是这样一个测试的结果(i5四核，16+GB内存)，给每个测试30秒的运行时间。执行的代码在SSD驱动器上执行简单的文件I/O。|1523692|Test+Results|offset|length|1523693|entityMap|0|LINK|mutability|MUTABLE|url|https://i.stack.imgur.com/ElG9s.png^0|0|0|0|0|0|0|0|0|0|0|0|0|C|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1F|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1G|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1H|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1I|8|@]|9|@$X|1J|Y|1K|1|1L]]|A|$]]|$1|Z|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]]]

For the highest performance with concurrently executing units, write your own thread pool, where a pool of Thread objects are created at start up and go to blocking (formerly suspended), waiting on a context to run (an object with a standard interface implemented by your code).

So many articles about Tasks vs. Threads vs. the .NET ThreadPool fail to really give you what you need to make a decision for performance. But when you compare them, Threads win out and especially a pool of Threads. They are distributed the best across CPUs and they start up faster. 

What should be discussed is the fact that the main execution unit of Windows (including Windows 10) is a thread, and OS context switching overhead is usually negligible. Simply put, I have not been able to find convincing evidence of many of these articles, whether the article claims higher performance by saving context switching or better CPU usage.

Now for a bit of realism:

Most of us won’t need our application to be deterministic, and most of us do not have a hard-knocks background with threads, which for instance often comes with developing an operating system. What I wrote above is not for a beginner.

So what may be most important is to discuss is what is easy to program. 

If you create your own thread pool, you’ll have a bit of writing to do as you’ll need to be concerned with tracking execution status, how to simulate suspend and resume, and how to cancel execution – including in an application-wide shut down. You might also have to be concerned with whether you want to dynamically grow your pool and also what capacity limitation your pool will have. I can write such a framework in an hour but that is because I’ve done it so many times.

Perhaps the easiest way to write an execution unit is to use a Task. The beauty of a Task is that you can create one and kick it off in-line in your code (though caution may be warranted). You can pass a cancellation token to handle when you want to cancel the Task. Also, it uses the promise approach to chaining events, and you can have it return a specific type of value. Moreover, with async and await, more options exist and your code will be more portable.

In essence, it is important to understand the pros and cons with Tasks vs. Threads vs. the .NET ThreadPool. If I need high performance, I am going to use threads, and I prefer using my own pool. 

An easy way to compare is start up 512 Threads, 512 Tasks, and 512 ThreadPool threads. You’ll find a delay in the beginning with Threads (hence, why write a thread pool), but all 512 Threads will be running in a few seconds while Tasks and .NET ThreadPool threads take up to a few minutes to all start.

Below are the results of such a test (i5 quad core with 16 GB of RAM), giving each 30 seconds to run. The code executed performs simple file I/O on an SSD drive.

<a href="https://i.stack.imgur.com/ElG9s.png" rel="nofollow noreferrer">Test Results</a>

I have been trying to learn multi-threaded programming in C# and I am confused about when it is best to use a thread pool vs. create my own threads. One book recommends using a thread pool for small tasks only (whatever that means), but I can't seem to find any real guidelines.
What are some pros and cons of thread pools vs creating my own threads? And what are some example use cases for each?

When to use thread pool in C#?

数据库

服务器

虚拟机

Windows

我一直在努力学习C#中的多线程编程，我很困惑什么时候使用线程池最好，而不是创建我自己的线程。有一本书建议只对小任务使用线程池(不管这意味着什么)，但我似乎找不到任何真正的指导原则。与创建自己的线程相比，线程池有什么优点和缺点？每种情况下都有哪些示例用例？

问什么时候在C#中使用线程池？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候在C#中使用线程池？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候在C#中使用线程池？
EN