与Task Parallel并行相比，并行管道的优势是什么？
我经常将管道模式作为开发并发性的常见和有用的模式来阅读。 但我不知道是否有与任务并行模式相比，并行流水线模式的任何优势。
假设我们有一个流水线中有三个阶段：A，B，C。当数据需要处理时，A处理它，处理它并将它交给B.当下一个数据块进入时，同样发生，A和B正在同时工作。
因此，流水线中的不同阶段可以并行执行，但是当我们使用三条并行工作的流水线时（如任务并行模式），我们可以得到完全相同的图像。 当两个数据块一个接一个进入时，第一个块由Pipeline 1占用，下一个块由Pipeline 2占用，两个块同时处理。
此外，我可以很容易地想象出并行中的许多问题。流水线：各个阶段之间的缓冲区可能会阻塞（或溢出），一个阶段在处理速度方面占主导地位，所以在最慢阶段之前的所有阶段都必须等待。
任务并行模式中不存在这些问题。 此外，这种模式在块快速到达时比管道的第一阶段可以处理它们更快（或者它们可以同时获取）。
那么为什么我应该使用并行流水线模式呢？
提前感谢您的任何想法！
如果你有一个管道A => B => C并且没有进一步的限制，那确实没用。 你可能刚刚使用了一个函数C(B(A(input))) 。
如果在流水线阶段允许不同程度的并行性，这个概念变得更有用。 也许步骤B访问SSD并且最多需要4个并发访问。 信号量可以达到同样的效果。
如果A，B和C限于1的并行度，那么管道也有价值：在管道模型中，所有3个节点都可以同时执行。 由于假定的并行性限制（或者您需要3个锁，这相当于管道解决方案），因此使用“三条管线”是不可能的。
有时候，你想在节点之间缓冲。 也许，A很少会发出B会随着时间的推移处理的高爆发。 缓冲有助于保持A正常工作而不会停滞。
有时候，这不是一个管道，而是一个分支进出的数据流网络（可能是连接）。
总而言之，我很少发现数据流网络的用例。 通常，仅使用数据并行性并使用适当的锁和信号灯会更简单。 但这可能是因为我通常工作的领域。YMMV。
管道和任务并行性绝对是两个不同的概念。
管道 ：
实现生产者 - 消费者模式 。 ProcessA获取一些数据进程并传递给下一个进程（ ProcessB ）。 在A处理之前B不能做任何事情。 与B和C等相同。进程之间存在依赖关系。
例如：参考这个
简单地说，没有依赖关系。
例如：loop-parallels
所以，您不能将任务并行用于依赖任务。
链接地址: http://www.djcxy.com/p/50171.html上一篇: What is the advantage of a parallel pipeline compared with Task Parallelism?