在查看 Go 和 Erlang 的并发方法时，我注意到它们都依赖于消息传递。
这种方法显然减少了对复杂锁的需求，因为没有共享状态。
但是，考虑到许多客户端希望对内存中的单个大型数据结构（例如后缀数组）进行并行只读访问的情况。
我的问题：
与消息传递相比，使用共享状态是否会更快并使用更少的内存，因为数据是只读的，并且只需要存在于单个位置，因此锁大多是不必要的？
李>如何在消息传递上下文中解决此问题？会不会有一个进程可以访问数据结构，而客户端只需要按顺序从它请求数据吗？或者，如果可能的话，是否将数据分块以创建多个保存块的进程？
【问题讨论】：
标签： memory concurrency erlang parallel-processing go
目前的问题确实是锁定和缓存行一致性可能与复制更简单的数据结构（例如几百字节）一样昂贵。
大多数情况下，一个聪明的编写的新的多线程算法试图消除大部分锁定总是会更快 - 并且使用现代无锁数据结构更快。尤其是当您拥有精心设计的缓存系统（例如 Sun 的 Niagara 芯片级多线程）时。
如果您的系统/问题不容易分解为几个简单的数据访问，那么您就有问题了。并不是所有的问题都可以通过消息传递来解决。这就是为什么仍然有一些基于 Itanium 的超级计算机出售的原因，因为它们具有 TB 的共享 RAM 和多达 128 个 CPU 在同一共享内存上工作。它们比具有相同 CPU 能力的主流 x86 集群贵一个数量级，但您不需要分解数据。
到目前为止没有提到的另一个原因是，当您使用多线程时，程序可以变得更容易编写和维护。消息传递和无共享方法使其更易于维护。
例如，Erlang 的设计初衷不是让事情变得更快，而是使用大量线程来构建复杂的数据和事件流。
我想这是设计的要点之一。在谷歌的网络世界里，你通常不关心性能——只要它可以在云中并行运行。理想情况下，通过消息传递，您可以在不更改源代码的情况下添加更多计算机。
【讨论】：
什么是大型数据结构？
一个人大就是另一个人小。
上周我和两个人谈过——一个人正在制造嵌入式设备，他用了这个词 “大” - 我问他这是什么意思 - 他说超过 256 KB - 在同一周晚些时候 那个人在谈论媒体分发——他用了“大”这个词我问他他是什么 意思是——他想了想说“不适合一台机器”说 20-100 TBytes
在 Erlang 术语中，“大”可能意味着“不适合 RAM”——因此使用 4 GB 的 RAM > 100 MB 的数据结构可能被认为是大的 - 复制 500 MB 的数据结构 可能是个问题。在 Erlang 中复制小型数据结构（比如
必须是非常大的数据结构（即无法在一台机器上安装的数据结构） 在多台机器上复制和“条带化”。
所以我猜你有以下几点：
小数据结构没有问题 - 因为它们是小数据处理时间 快，复制快等等（只是因为它们很小）
大数据结构是个问题——因为它们不能在一台机器上安装——所以复制是必不可少的。
【讨论】：
请注意，您的问题在技术上是无意义的，因为消息传递可以使用共享状态，所以我假设您的意思是通过深度复制来避免共享状态的消息传递（就像 Erlang 目前所做的那样）。
与消息传递相比，使用共享状态会更快并使用更少的内存吗？因为数据是只读的，并且只需要存在于单个位置，因此锁大多是不必要的？
使用共享状态会很多更快。
如何在消息传递上下文中解决这个问题？会不会有一个进程可以访问数据结构，而客户端只需要按顺序从它请求数据吗？或者，如果可能的话，是否将数据分块以创建多个持有块的进程？
任何一种方法都可以使用。
考虑到现代 CPU 和内存的架构，这两种解决方案之间是否存在很大差异——即，共享内存可以由多个内核并行读取——这意味着不存在硬件瓶颈，否则会使两种实现都大致执行一样吗？
复制对缓存不友好，因此会破坏多核的可扩展性，因为它会加剧对共享资源（即主内存）的争用。
归根结底，Erlang 风格的消息传递是为并发编程而设计的，而您关于吞吐量性能的问题实际上是针对并行编程的。这是两个完全不同的主题，在实践中它们之间的重叠很小。具体来说，延迟通常与并发编程上下文中的吞吐量一样重要，而 Erlang 风格的消息传递是实现理想延迟配置文件（即始终如一的低延迟）的好方法。那么共享内存的问题不在于读写器之间的同步，而是低延迟的内存管理。
【讨论】：
是的，在这种情况下，共享状态可能会更快。但前提是您可以放弃锁定，并且只有在绝对只读的情况下才可行。如果它“主要是只读的”，那么您需要一个锁（除非您设法编写无锁结构，否则请注意它们甚至比锁更棘手），然后您将很难让它执行为快速作为一种良好的消息传递架构。
是的，您可以编写一个“服务器进程”来共享它。对于真正轻量级的流程，它并不比编写一个小的 API 来访问数据更繁重。像一个“拥有”数据的对象（在 OOP 意义上）一样思考。将数据拆分成块以增强并行性（在 DB 圈中称为“分片”）有助于处理大型情况（或者数据存储速度较慢）。
即使 NUMA 成为主流，每个 NUMA 单元仍然拥有越来越多的内核。一个很大的区别是，一条消息只能在两个内核之间传递，而一个锁必须从所有内核的缓存中刷新，将其限制为单元间总线延迟（甚至比 RAM 访问慢）。如果有的话，共享状态/锁越来越不可行了。
简而言之....习惯了消息传递和服务器进程，这很流行。
编辑：重新审视这个答案，我想添加关于 Go 文档中的一个短语：
通过通信共享内存，不要通过共享内存进行通信。
这个想法是：当你在线程之间共享一块内存时，避免并发访问的典型方法是使用锁进行仲裁。 Go 风格是通过引用传递消息，线程只有在收到消息时才访问内存。它依赖于某种程度的程序员纪律；但生成的代码看起来非常干净，可以轻松校对，因此相对容易调试。
优点是您不必在每条消息上复制大块数据，也不必像某些锁定实现那样有效地刷新缓存。现在说这种风格是否会带来更高性能的设计还为时过早。 （特别是因为当前的 Go 运行时在线程调度方面有些幼稚）
【讨论】：
另一个并发范式是 STM，即软件事务内存。 Clojure 的 ref 得到了很多关注。 Tim Bray 有一个很好的系列探索 erlang 和 clojure 的并发机制
http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next
http://www.tbray.org/ongoing/When/200x/2009/12/01/Clojure-Theses
【讨论】：
通常消息传递语言（这在 erlang 中特别容易，因为它具有不可变变量）优化进程之间的实际数据复制（当然仅限本地进程：您需要明智地考虑您的网络分布模式），所以这不是什么大问题。
【讨论】：
在 Erlang 中，所有值都是不可变的 - 因此在进程之间发送消息时无需复制消息，因为它无论如何都无法修改。
在 Go 中，消息传递是约定俗成的 - 没有什么可以阻止您通过通道向某人发送指针，然后修改指向的数据，这只是约定，因此再次不需要复制消息。
【讨论】：
这里没有介绍的一个解决方案是主从复制。如果您有一个大型数据结构，您可以将更改复制到所有对其副本执行更新的从站。
如果想要扩展到多台机器，这些机器甚至无法在没有非常人为设置的情况下共享内存（从远程计算机内存读取/写入的块设备的 mmap？），这将特别有趣。
它的一个变体是有一个事务管理器，它很好地要求更新复制的数据结构，它会确保它同时服务一个且仅更新请求。这更像是 mnesia 表数据的主从复制的 mnesia 模型，符合“大数据结构”的条件。
【讨论】：
要意识到的一点是，Erlang 并发模型确实没有真正指定消息中的数据必须在进程之间复制，它指出发送消息是唯一的通信方式，并且存在没有共享状态。由于所有数据都是不可变的，这是基本的，因此实现很可能不会复制数据而只是发送对它的引用。或者可以使用两种方法的组合。与往常一样，没有最佳解决方案，在选择如何做时需要权衡取舍。
BEAM 使用复制，但发送引用的大型二进制文件除外。
【讨论】：
大多数现代处理器使用MESI protocol 的变体。由于共享状态，在不同线程之间传递只读数据非常便宜。但是，修改后的共享数据非常昂贵，因为存储此缓存行的所有其他缓存都必须使其无效。
所以如果你有只读数据，在线程之间共享它而不是用消息复制是非常便宜的。如果您有以读取为主的数据，则在线程之间共享可能会很昂贵，部分原因是需要同步访问，部分原因是写入会破坏共享数据的缓存友好行为。
Immutable data structures 在这里可能会有所帮助。无需更改实际的数据结构，您只需创建一个共享大部分旧数据的新数据结构，但需要更改的内容已更改。共享单个版本的成本很低，因为所有数据都是不可变的，但您仍然可以高效地更新到新版本。
【讨论】：