C＃ - ThreadPool vs任务

Question

正如在.NET 4.0中看到的一样，他们已经添加了一个新的名称空间System.Threading.Tasks，它基本上就是什么意思，一个任务。我只用了几天，从使用ThreadPool。

哪一个更高效，更少资源消耗？ （或只是更好的整体？）

Answer 1

Tasks命名空间的目标是提供一个可插拔的体系结构，使多任务应用程序易于编写和更灵活。

该实现使用一个TaskScheduler对象来控制任务的处理。这有虚拟方法，您可以重写以创建自己的任务处理。方法包括例如

protected virtual void QueueTask(Task task) 
public virtual int MaximumConcurrencyLevel 

会有一个小的开销，使用缺省实现有围绕.NET线程实现的包装，但我不希望它是巨大的。

有一个自定义TaskScheduler的实现（草稿）实现多个任务在单个线程here。

Answer 2

哪一个更有效率更低 资源消耗？

不相干的，会有很小的差别。

（或只是更好的整体）

Task类将是更容易使用的，因为它提供了一个非常干净的界面，用于启动和连接螺纹，并传送例外。它还支持（有限）形式的负载平衡。

Answer 3

另一个值得考虑的关于任务的好处是，当你使用ThreadPool时，你没有任何方法来中止或等待正在运行的线程（除非你在线程的方法中手动执行），但使用这是可能的。如果我错了，请纠正我的错误

Answer 4

调度是并行任务的一个重要方面。

与线程不同，新任务不一定立即开始执行。相反，他们被放置在工作队列中。任务在其关联的任务调度程序将其从队列中移除时运行，通常在核心可用时运行。任务调度程序通过控制系统的并发程度来尝试优化整体吞吐量。只要有足够的任务并且任务足够不依赖序列化，程序的性能就会随着可用内核的数量而变化。通过这种方式，任务体现潜在的并行

的概念，我在MSDN上http://msdn.microsoft.com/en-us/library/ff963549.aspx

Answer 5

看到“从.NET Framework 4开始，太平人寿编写多线程和并行代码的首选方式。“

http://msdn.microsoft.com/en-us/library/dd460717.aspx

Answer 6

主题

裸机的事情，你可能并不需要使用它，你大概可以使用LongRunning任务，并受益于它的设施。

任务

线程上方的抽象使用线程池（除非您将任务指定为LongRunning操作，如果是这样，则新的线程在你的引擎盖下创建）。

线程池

，顾名思义：线程池。 .NET框架是否为您处理有限数量的线程。为什么？因为在只有8个内核的CPU上打开100个线程来执行昂贵的CPU操作绝对不是一个好主意。该框架将为您维护该池，重用线程（不在每个操作中创建/杀死它们），并且以CPU不会刻录的方式并行执行它们中的一部分。

好的，但何时使用每一个？

恢复中：始终使用任务。

任务是一个抽象，所以它使用起来更容易。我建议你总是尝试使用任务，如果你面临一些问题，使得你需要自己处理一个线程（可能是1％的时间），然后使用线程。

但是要注意：

• I/O密集型：对于I/O密集型操作（数据库调用，读/写文件，API的调用等）从不使用正常任务，使用如果需要，可以使用任务或线程，但不是正常的任务。因为这会导致你有一些线程繁忙的线程池，还有很多其他任务正在等待轮到池。
• CPU绑定：对于CPU绑定操作只需使用正常的任务，并很高兴。