线程池和多核系统

时间:2011-02-07 17:56:38

标签: multithreading design-patterns threadpool multicore

您认为线程设计模式是多核未来的发展方向吗?

例如,如果广泛使用线程池,则会强制执行应用程序编写器

(1)将问题分解为单独的并行作业,从而促进(强制执行:)并行性

(2)从所有低级OS调用的抽象,同步等等使程序员的生活更轻松。 (特别是对于C程序员:))

我坚信它是多核心未来的最佳方式(或“最佳方式之一:)”...

所以,我的问题是,我是在写这么想,还是我有些妄想:)

此致

微内核

4 个答案:

答案 0 :(得分:6)

线程池是一种涉及队列和许多线程从队列中获取作业并处理它们的技术。这与每当新任务到来时刚启动新线程的技术形成对比。

好处是最大线程数限制以避免太多线程并且任何新任务涉及的开销更少(Thread已经运行并且需要任务。不需要威胁启动。)

这是否是一个好的设计高度取决于你的问题。如果你有很多短期工作以非常快的速度进入你的程序,那么这是一个好主意,因为较低的开销实际上是一个好处。如果你有大量的并发任务,那么最好不要让你的调度程序做太多工作。

在许多方面,线程池只是没用。所以你不能概括。有时多线程是不可能的。或者甚至不需要,因为多线程会给你的代码添加一个不可预测的元素(竞争条件),这非常难以调试。

线程池库很难“强迫”您使用它。你仍然需要考虑一下,如果你只是开始一个线程......无济于事。

答案 1 :(得分:1)

几乎每个信息学主题的答案都是:它取决于。

汇集系统很好,令人尴尬的是并行http://en.wikipedia.org/wiki/Embarrassingly_parallel

对于需要在线程之间进行更多同步化的其他任务,它不是那么好

答案 2 :(得分:1)

对于Windows NT引擎,线程池的效率通常远低于I / O完成端口。这些内容在很多问题和答案中都有广泛的内容。 IOCP启用事件驱动的处理,因为多个线程可以在IOCP上等待,直到由于套接字或句柄上的IOC(读取或写入)而发生事件,然后将其排队到IOCP。 IOCP反过来将一个等待线程与事件的id配对,并释放线程进行处理。在线程处理完事件并启动新的I / O后,它返回IOCP以等待下一个事件(可能是也可能不是它刚刚启动的I / O完成)。

IOC也可以通过非事件的明确发布来人为地发出信号。

使用IOCP不是轮询。最佳IOCP实现将在IOCP上等待与系统中的核心一样多的线程。如果认为有效,则线程可以全部执行相同的物理代码。由于线程从IOC处理直到它发出I / O,它什么都不会迫使它等待其他资源,除非可能竞争对线程安全区域的访问。离开“每个线程一个句柄”范例是一种自然的选择。因此,IOCP控制的线程与程序员能够构建它们一样高效。

答案 3 :(得分:0)

我非常喜欢@yaankee的答案,除非我认为线程池几乎总是正确的方法。原因是:线程池可以将自身退化为一个简单的静态工作分区模型,用于矩阵 - 矩阵乘法等问题。 OpenMP指导就是这样的。