线程池和多核系统
您认为线程池设计模式是多核未来的出路吗？
例如，线程池库，如果广泛使用，则使/强制应用程序编写者
（1）将问题分解为单独的并行作业，从而促进（强制:)）并行性
（2）从所有低级操作系统调用、同步等中进行抽象等等让程序员的生活更轻松。 （特别是对于 C 程序员:)）
我坚信这是多核未来的最佳方式（或者“最佳”方式之一:)）...
所以，我的问题是，我是这么想的还是我写的我有些错觉:)
问候，
微内核
Do you think threadpooling design pattern is the way to go for the multi-core future?
A threadpooling library for instance, if used extensively, makes/force the application writer
(1) to break the problem into separate parallel jobs hence promoting (enforcing :) ) parallelism
(2) With abstraction from all the low level OS calls, synchronization etc etc makes programmer's life easier. (Especially for C programmers :) )
I have strong belief its the best way (Or One of the "best" ways :) ) for multi-core future...
So, my question is, am I write in thinking so or I am in some delusion :)
Regards,
Microkernel
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
线程池是一种涉及队列和从队列中获取作业并处理它们的多个线程的技术。这与每当新任务到达时就启动新线程的技术形成对比。
好处是最大线程数有限，以避免太多线程，并且任何新任务涉及的开销更少（线程已经在运行并接受任务。没有需要开始威胁）。
这是否是一个好的设计很大程度上取决于您的问题。如果您有许多短期作业以非常快的速度进入您的程序，那么这是一个好主意，因为较低的开销确实是一个好处。如果您有大量并发任务，那么这是一个好主意，可以让您的调度程序不必做太多工作。
在许多领域，线程池没有什么帮助。所以你不能一概而论。有时多线程根本不可能。或者甚至不需要，因为多线程向代码中添加了不可预测的元素（竞争条件），这非常难以调试。
线程池库很难“强迫”您使用它。你仍然需要仔细思考事情，如果你只启动一个线程......不会有帮助。
Thread pooling is a technique that involves a queue and a number of threads taking jobs from the queue and process them. This is in contrast to the technique of just starting new threads whenever a new task arrives.
Benefits are that the maximum number of threads is limited to avoid too much threading and that there is less overhead involved with any new task (Thread is already running and takes task. No threat starting needed).
Whether this is a good design highly depends on your problem. If you have many short jobs that come to your program at a very fast rate, then this is a good idea because the lower overhead is really a benefit. If you have extremely large numbers of concurrent tasks this is a good idea to keep your scheduler from having to do too much work.
There are many areas where thread pooling is just not helpful. So you cannot generalize. Sometimes multi threading at all is not possible. Or not even desired, as multi threading adds an unpredictable element (race conditions) to your code which is extremely hard to debug.
A thread pooling library can hardly "force" you to use it. You still need to think stuff through and if you just start one thread... Won't help.
几乎所有信息学主题的答案都是：视情况而定。
池化系统与 Embarrassingly parallel 配合良好 http://en.wikipedia.org/wiki/Embarrassingly_parallel
对于其他需要线程之间更多同步的任务，这并不是那么好
As almost every informatics topic the answer is: It Depends.
the pooling system is fine with Embarrassingly parallel http://en.wikipedia.org/wiki/Embarrassingly_parallel
For other task where you need more syncornization between threads it's not that good
对于 Windows NT 引擎，线程池的效率通常比 I/O 完成端口低得多。这里的许多问题和答案都广泛涵盖了这些内容。 IOCP 支持事件驱动的处理，因为多个线程可以在 IOCP 上等待，直到由于套接字或句柄上的 IOC（读或写）而发生事件，然后将其排队到 IOCP。 IOCP 依次将等待线程与事件 ID 配对，并释放该线程进行处理。线程处理完事件并启动新的 I/O 后，它返回到 IOCP 等待下一个事件（这可能是也可能不是它刚刚启动的 I/O 的完成）。
IOC 也可能通过非事件的明确发布来人为地发出信号。
使用 IOCP 不是轮询。最佳的 IOCP 实现将有与系统中的内核一样多的等待 IOCP 的线程。如果认为高效的话，线程可以全部执行相同的物理代码。由于线程从 IOC 开始处理直到发出 I/O，因此除了竞争对线程安全区域的访问之外，它不会执行任何强制其等待其他资源的操作。摆脱“每个线程一个句柄”范例是一个自然的选择。因此，IOCP 控制的线程的效率与程序员构建它们的能力一样高。
For the Windows NT engine thread pools are usually much less efficient than I/O Completion Ports. These are covered extensively in numerous questions and answers here. IOCPs enable event-driven processing in that multiple threads can wait on the IOCP until an event occurs due to an IOC (read or write) on a socket or handle which is then queued to the IOCP. The IOCP in turn pairs a waiting thread with the id of the event and releases the thread for processing. After the thread has processed the event and initiated a new I/O it returns to the IOCP to wait for the next event (which may or may not be the completion of the I/O it just initiated).
IOCs may also be artificially signalled by explicit posting from a non-event.
Using IOCPs is not polling. The optimal IOCP implementation will have as many threads waiting on the IOCP as there are cores in the system. The threads may all execute the same physical code if that is deemed efficient. Since a thread processes from an IOC up until it issues an I/O it does nothing which forces it to wait for other resources except perhaps to compete for access to thread-safe areas. It is a natural choice to move away from the "one handle per thread" paradigm. IOCP-controlled threads are therefore as efficient as the programmer is able to construct them.
我非常喜欢@yaankee 的答案，但我认为线程池几乎总是正确的方法。原因是：对于矩阵乘法等问题，线程池可以将自身退化为简单的静态工作分区模型。 OpenMP 指导就是这样的。
I like the answer by @yaankee a lot except I would argue that thread pool is almost always the right way to go. The reason: a thread pool can degenerate itself into a simple static work partitioning model for problems like matrix-matrix multiply. OpenMP guided is kind of along those lines.