消息传递模型和共享内存模型有什么区别？

Question

问题与here提出的问题的主题重复。

我想就不同的观点要求进一步澄清。

在分布式计算中，内存一致性最终是通过网络通道上的消息传递、分布式锁定等来实现的。消息传递，IIUC，并不总是消除并发性，除非在非常低的级别，因为进程通常仍然会影响彼此的状态。他们以他们认为一致的方式这样做。

例如，可以在消息传递之上实现一个简单的命令解释器，并且可以将命令作为从多个熟悉进程并行执行的多个远程事务的一部分发送。因此，在大多数情况下，高级交互需要设计并发性。也就是说，IMO，进程不太可能没有长期操作的事务语义。

此外，发送具有一致状态值的消息并不能保证正确性。重要的是，这个值是如何产生的，以及在提供输入数据的消息和发布转换结果的消息之间发生了什么。

另一方面，与物理内存的低级交互本质上总是某种通过总线传递的消息。因此，在最低级别，共享内存和消息传递是相同的。

在每条指令级别，对齐加载和存储的原子性通常得到保证。所以，区别对我来说仍然是模糊的。

在散文中，共享内存与消息传递的选择与并发性有何关系？解决并发问题只是选择技术模式，定义和分析并行进程交互的数学模型，还是这些技术也是架构模式，当系统应用时，会从根本上影响系统中的并发问题？

谢谢。

编辑（一些补充说明）：

显然，这两种方法的区别在于正确性和性能。但我对这种区别有以下问题。

我知道消息可以像大型分散虚拟数据的传输一样。但是，“按值”方法不能保证一致性，除非在非单一（或程序生成的）逻辑数据的原子读取之外没有同步。通过一致性，我暗示了诸如因果关系或更改的顺序等。实际上，通过消息传递，每个进程只会改变自己的内存。进程的作用就像其私有内存的控制器。这就像在消息传递之上共享，由拥有数据的进程序列化，但在 MESSAGE-BY-MESSAGE 的基础上（类似于内存逐字或逐个缓存行序列化的方式）基础）。应用程序程序员仍然有责任保证发送消息所涉及的事务的同步。也就是说，从多个熟悉的进程到一个进程的消息必须按照与这些进程正在执行的操作的语义相对应的一致顺序发送。可能是对拥有进程的控制消息，或者通过竞争者之间的直接协调，但对消息的并发性进行一些限制应该是最有必要的。

对于本地进程间通信（忽略争用），共享内存确实可以更快，但是为什么跨机器通信会出现这种情况呢？分布式计算的共享内存是在网络通信之上实现的。因此，共享内存除了缓存优势之外，还不能更快。

技术显然不同。我似乎无法理解的是，当对两者都没有本质上的好处时，如何将它们进行广泛的比较。必须假设平台提供什么，以及软件试图完成什么，而这样的假设不能普遍正确。

Answer 1

如果您正在构建分布式和/或多线程应用程序，您会希望确保其性能优于单进程单线程应用程序。

对于分布式应用程序，即潜在的多个系统上的多个进程，通信节点之间的延迟是主要问题。随着微服务器的出现，延迟和功耗显着下降，软件开发人员应该开始考虑如何设计、开发、调试、部署等多核/微服务器应用程序。

在开发多进程应用程序时，通常归结为在最底层使用两组 OS 调用来实现进程间通信：共享内存，例如通过使用 shmget、shmat、shmctl 等，以及消息传递，例如通过使用 socket、accept、send、recv 等。

使用共享内存，延迟可以忽略不计。一旦获得对共享内存缓冲区的引用，应用程序就可以访问共享内存的任何部分并对其进行修改。当然，进程必须使用锁、互斥锁等进行合作，以确保维护数据结构的完整性并确保应用程序正常工作。这个解决方案的问题是，当无法控制何时可能发生上下文切换时，如何测试所有保持完整性的情况？

通过消息传递，不会共享任何数据。所有通信都是通过交换缓冲区来实现的。这样就不必担心锁、互斥锁等问题，但现在必须确保应用程序能够处理网络超时、带宽、延迟等问题。

为了开发可以超越单个系统的应用程序，最常用的方法是使用消息传递。如果通信进程碰巧在同一台主机上，它仍然可以工作。

不管是共享内存还是消息传递，并发本质上是在共享内存的情况下，通过锁/互斥锁确保数据结构的完整性，在消息传递的情况下，序列化请求/响应。