.Net 4.0 Tasks是否应该是多线程应用程序的首选方法？

Question

我正在阅读任务并行库,文章说:

在.NET Framework 4中,任务是编写多线程,异步和并行代码的首选API

但它也表示他们在幕后使用ThreadPool.我难以弄清楚的是,如果只在你使用ThreadPool时使用Tasks(因此"Thread vs. Task"等同于"Thread与ThreadPool"相同),或者Microsoft是否打算使用Tasks需要多个线程的任何地方,没有"Thread与ThreadPool"困境所固有的考虑因素.

那么,应该在需要多个线程的任何地方使用任务吗？

Answer 1

使用任务的设计优势在于，您可以将线程的本质交给运行时，这可能可以使用错误更少、更优化的解决方案来完成线程任务。我知道某些基于任务的范例，例如 PLINQ，允许您暗示运行时应采用哪种策略，以便可以直接处理“是否使用线程池”的问题。

切换到此模型类似于切换到托管 GC 语言与需要清理自己内存的语言。总会有支持后者的争论，但垃圾收集现在已经变得如此优化，以至于它实际上不再是问题。理想情况下，任务的运行时切换机制将会不断发展并变得更好。因此从理论上讲，为 .NET 4 编写和编译的应用程序可以通过更好的运行时实现来变得更快，而无需进一步重新编译。此外，众所周知，线程代码很难正确执行，因此任何隐藏这些细节的机制对程序员来说都是有好处的。

这些好处是否超过潜在的危害，例如运行时不能很好处理的边缘情况，应该具体情况具体考虑。不过，我当然会尽量不要过早优化。