Bru*_*ams 8 .net parallel-processing multithreading pfx
我有一个应用程序,它使用多线程同时执行30个独立任务,每个任务通过http检索数据,执行计算并将结果返回给ui线程.
我可以使用TPL执行相同的任务吗？
TPL是否创建了30个新线程并将它们分布在所有可用内核上,还是仅将任务分配到可用内核上并且每个内核使用一个线程？
在这种情况下,使用TPL而不是多线程是否会提升性能？
And*_*ass 10
作为一般规则,没有什么能阻止TPL使用比核心更多(或更少)的线程.
为了使用TPL来控制情况,我的第一种方法是:确保线程池最大线程设置至少为30,然后以最大并发级别 30 并行化任务.在任务中,您可以在使用之前使用信号量启动CPU绑定计算以将并发限制为核心数.如果您没有在IIS或SQL服务器下运行,您可以并且可能希望将最小/最大线程池线程数设置为30,以防止线程池启发式过多地播放线程数.(当然,在您的申请期间,TPL和线程池不会用于其他目的.)
最佳线程数取决于具体情况.考虑例如您的场景:您的任务在检索数据时不受CPU限制 - 它们是网络绑定的.当您开始执行任务时,最好增加并行性,以便同时执行下载.但是,您的计算可能受CPU限制.在这种情况下,减少线程数以便每个核心只运行一个线程可能会产生更好的性能.
TPL现在基于新的CLR线程池.
线程池使用启发式来确定线程数.
有一个关于新线程池的Channel9视频有一些见解.
可以在这里找到旧线程池的启发式和关于新线程的一些内容(最后一段"未来是什么？").
在CLR的不同版本中,算法和数字可能会发生变化.
未来也可能是这种情况.
关于并发级别的帖子很多,我遇到的就是这里.
我相信TPL通常会为每个核心使用一个线程,除非你明确告诉它使用更多.它可能会检测何时不够 - 例如在您的情况下,您的任务将花费大部分时间等待数据.
你有什么理由不能使用异步网页提取吗？我怀疑这里不需要每个任务都有一个线程,甚至不需要每个核心的一个线程.TPL使异步编程的各个方面更容易,例如continuation.
在效率方面,您的应用程序实际上是CPU绑定的吗？听起来你需要在网络端获得最大的适当并行水平 - 这是需要专注的,除非计算真的是重量级.
上面的答案一如既往,但可能会产生误导,因为它在.NET 4.0 CLR中没有一些重要的变化.
正如Andras所说,当前的TPL实现使用线程池,因此将根据需要使用尽可能多的线程(核心数量现在无关紧要):
任务并行库(TPL)是一组新类,专门用于在现代硬件上执行非常细粒度的并行工作负载,使其更容易,更高效.TPL已经作为CTP单独提供了一段时间,并且包含在Visual Studio 2010 CTP中,但在这些版本中,它是基于自己的专用工作调度程序构建的.对于CLR 4.0的Beta 1,TPL的默认 调度程序将是CLR线程池,它允许TPL样式的工作负载与现有的基于QUWI的代码"玩得很好",并允许我们重用大部分底层技术.线程池 - 特别是线程注入算法,我们将在以后的文章中讨论.
从:
http://blogs.msdn.com/b/ericeil/archive/2009/04/23/clr-4-0-threadpool-improvements-part-1.aspx