我经常阅读有关管道模式作为利用并发性的常见且有用的模式。但我想知道并行管道模式与任务并行模式相比是否有任何优势。
假设我们在管道中有三个阶段：A，B，C。当需要处理数据时A接受它，处理它并将其移交给B.当下一个数据块进入时，同样的情况发生并且A和B同时工作。
因此管道中的不同阶段可以并行执行，但是当我们使用三个管道并行工作时（如在任务并行模式中），我们得到完全相同的图片。当两个数据块一个接一个地进入时，第一个块由管道1获取，下一个块由管道2获取，并且两个块同时处理。
此外，我很容易想象并行管道中的许多问题：阶段之间的缓冲区可能会阻塞（或溢出），一个阶段在处理速度方面占主导地位，因此在最慢阶段之前的所有阶段都必须等待等等。
任务并行模式中不存在这些问题。此外，当块的进入速度快于管道的第一阶段可以处理它们时（或者它们可以同时获取），这种模式更灵活。
那我为什么要使用并行管道模式？
提前感谢任何想法！
答案 0 :(得分：3)
如果你有一个管道A =＆gt; B =＆gt; C并且对它没有进一步的限制，这确实是无用的。您可以使用函数C(B(A(input)))。
如果在管道阶段允许不同程度的并行性，则该概念会变得更有用。也许步骤B访问SSD，您最多需要4次并发访问。你可以用信号量实现同样的目的。
如果A，B和C限制为1的并行度，则管道也具有值：在管道模型中，所有3个节点可以同时执行。使用“三个管道”是不可能的，因为假设的并行性限制（或者您需要3个锁，这相当于管道解决方案）。
有时，您希望在节点之间进行缓冲。也许，A很少发出B将随着时间推移处理的高爆发。缓冲有助于保持A工作而不会停滞。
有时，它不是管道而是分支进出（可能是连接）的数据流网络。
总而言之，我很少找到数据流网络的用例。通常，使用数据并行性并使用适当的锁和信号量更简单。但这可能是因为我通常使用的域名.YMMV。
答案 1 :(得分：0)
管道和任务并行绝对是两个不同的概念。
<强>管道：
实施生产者 - 消费者模式。 ProcessA 获取一些数据流程并传递给下一个（ ProcessB ）。 B在A处理之前无法做任何事情。与B和C等相同。进程之间存在依赖关系。
例如：参考this
简直就是没有依赖。
因此，您不能将任务并行用于依赖任务。