并行编程和并行编程的区别是什么?我问了谷歌,但没有找到任何帮助我理解这种区别的东西。你能给我举个例子吗?

现在我找到了这个解释:http://www.linux-mag.com/id/7411 -但是“并发性是程序的属性”vs“并行执行是机器的属性”对我来说还不够-我仍然不能说什么是什么。


当前回答

虽然没有完整 对并行和并发这两个术语的区别达成一致, 许多作者做了以下区分:

在并发计算中,一个程序可以在任意时刻执行多个任务。 在并行计算中,一个程序是多个任务紧密合作的程序 解决一个问题。

所以并行程序是并发的,但是像多任务操作系统这样的程序也是并发的,即使它运行在一台带有 只有一个核心,因为多个任务可以在任何时刻进行。

来源:Peter Pacheco的《并行编程介绍》

其他回答

将原始问题解释为并行/并发计算,而不是编程。

在并发计算中,两个计算都是彼此独立前进的。第二个计算不需要等到第一个计算完成后才能继续进行。但是,它并没有说明这是如何实现的机制。在单核设置中,线程之间需要挂起和交替(也称为抢占式多线程)。

在并行计算中,两个计算同时进行——字面上是同时进行。这对于单CPU来说是不可能的,而是需要多核设置。

图片来自文章:“Node.js中的并行vs并发”

只是分享一个有助于突出区别的例子:

并行编程:假设您想实现归并排序算法。每次将问题划分为两个子问题时,可以有两个线程来解决它们。然而,为了进行合并步骤,您必须等待这两个线程完成,因为合并需要两个子解决方案。这种“强制等待”使其成为并行程序。

并发程序:假设你想压缩n个文本文件,并为每个文件生成一个压缩文件。您可以有2个(最多n个)线程,每个线程处理压缩文件的一个子集。当每个线程完成时,它就完成了,它不需要等待或做任何其他事情。因此,由于不同的任务以“任意顺序”交错的方式执行,所以程序是并发的,而不是并行的。

正如其他人提到的,每个并行程序都是并发的(事实上必须是),而不是相反。

并发编程是一个通用概念,即一个程序可以以未定义的完成顺序执行多个任务,并且这些任务可以同时执行,也可以不同时执行。

并行编程只是一种并发编程,其中这些任务运行在同时执行的线程上。

我真的不理解这里许多过于冗长的回答,这些回答似乎暗示并行编程和并行编程是不同的编程方法,它们并不重叠。

如果你在写一个并行程序,根据定义,你是在写一个并发程序的特殊情况。这些年来,术语似乎被不必要地混淆和复杂化了。

关于并发编程最好、最详细的报道之一是Joe Duffy所著的《Windows上的并发编程》一书。这本书定义了并发,然后继续解释各种操作系统资源,库等可用来编写“并行”程序,如。net中的任务并行库。

第5页:

并行性是使用并发性将操作分解为 粒度更细的组成部分,以便独立的部分可以运行 机器上的独立处理器"

同样,并行编程只是一种特殊类型的并发编程,其中多个线程/任务将同时运行。

PS 我一直不喜欢在编程中,并发和并行这两个词有如此多的含义。例:在编程之外的广阔世界里,“篮球比赛将并行进行”和“篮球比赛将并行进行”是完全相同的。

想象一下,在开发者大会上,他们在第一天宣传会议将“并行”运行,但第二天他们将“并发”运行,这是多么可笑的困惑。那会很搞笑的!

并发性和并行性源

在单个处理器上的多线程进程中,处理器可以在线程之间切换执行资源,从而实现并发执行。

在共享内存多处理器环境中的同一个多线程进程中,进程中的每个线程可以同时在单独的处理器上运行,从而导致并行执行。

当进程的线程数量与处理器数量相同或较少时,线程支持系统结合操作环境确保每个线程运行在不同的处理器上。

例如,在具有相同数量的线程和处理器的矩阵乘法中,每个线程(和每个处理器)计算结果的一行。

并行编程发生在代码同时被执行并且每次执行都是相互独立的时候。因此,通常不会有关于共享变量之类的关注,因为那不太可能发生。

However, concurrent programming consists on code being executed by different processes/threads that share variables and such, therefore on concurrent programming we must establish some sort of rule to decide which process/thread executes first, we want this so that we can be sure there will be consistency and that we can know with certainty what will happen. If there is no control and all threads compute at the same time and store things on the same variables, how would we know what to expect in the end? Maybe a thread is faster than the other, maybe one of the threads even stopped in the middle of its execution and another continued a different computation with a corrupted (not yet fully computed) variable, the possibilities are endless. It's in these situations that we usually use concurrent programming instead of parallel.