Actor模型取代线程模型？答案

【问题标题】：Actor model to replace the threading model?Actor模型取代线程模型？
【发布时间】：2010-03-26 15:40:10
【问题描述】：

我读了一本书（Bruce A. Tate 的七周内的七种语言）中关于 Matz（Ruby 的发明者）的一章，说“我将删除线程并添加演员，或其他一些更高级的并发功能”。

【问题讨论】：

【解决方案1】：

与其说是actor模型会取代线程；在 CPU 级别，进程仍将有多个线程，这些线程在处理器内核上调度和运行。 Actor 的想法是用一种模型替换这种潜在的复杂性，其支持者认为，这种模型使程序员更容易编写可靠的代码。

actor 的想法是拥有单独的控制线程（Erlang 术语中的进程），它们专门通过消息传递进行通信。更传统的编程模型是共享内存，并使用互斥锁协调线程之间的通信。这仍然发生在 Actor 模型的表面之下，但细节被抽象掉了，并且基于消息传递给程序员提供了可靠的原语。

重要的一点是参与者不一定将 1-1 映射到线程——在 Erlang 的情况下，他们肯定不会——每个内核线程通常会有很多 Erlang 进程。所以必须有一个调度器将actor分配给线程，并且这个细节也从应用程序程序员中抽象出来。

如果您对 Actor 模型感兴趣，您可能想看看它在 Erlang 或 Scala 中的工作方式。

如果您对其他类型的新并发热点感兴趣，您可能需要查看software transactional memory，这是一种可以在 clojure 和 haskell 中找到的不同方法。

值得一提的是，创建高级并发模型的许多更积极的尝试似乎都发生在函数式语言中。可能是因为相信（我自己喝了一些这种kool-aid）不变性使并发更容易。

【讨论】：

我会进一步说，不变性增加了系统的稳健性。并发性是软件复杂性的一个维度，其中健壮性的差异非常明显。即使不需要满足并发问题，非常复杂的系统也可以从使用不变性中受益。
另外，请记住，actor模型也可以应用在网络中，以开发请求处理的异步模型。事实上，考虑到多核将成为规则，这种抽象在 os api 级别甚至可能很有趣（至少对我来说是这样）。

【解决方案2】：

我最喜欢这个问题，正在等待答案，但既然还没有，这里是我的..

演员模型为何以及如何成为高级并发模型替换线程？

Actor 可以摆脱可变的共享状态，这很难正确编码。（我的理解是）actors 基本上可以认为是具有自己线程的对象。您在 Actor 之间发送消息，这些消息将被 Actor 内的线程排队并使用。因此，actor 中的任何状态都被封装，并且不会被共享。所以很容易正确编码。

“高级”还有哪些其他型号并发模型？

【讨论】：

【解决方案3】：

请参阅数据流编程。这是一种方法，是通常的 OOP 设计之上的一层。一句话：

编程正在进行 3 层：

维基百科文章是了解业务的良好起点：http://en.wikipedia.org/wiki/Flow-based_programming 另见“演员模型”、“数据流编程”等。

【讨论】：

我不确定我是否会称 Dataflow 为 OOP 之上的一个层，它更像是 OOP 的一种替代方案，具有一些概念上的交叉。根据 Smalltalk，您可以说 OOP 是一种面向消息的语言，这就是 Dataflow 的意义所在。
数据流系统的实现需要 OOP（或者至少，这是推荐的自然方式），具体取决于 DF 架构。我编写了一个 DF 系统，其中调度程序和组件是用 C++ 编写的，连接和参数是使用专有脚本语言定义的，该语言被编译为 C++ 代码，最终结果是一个 a.out/ELF 可执行文件。所以，底层架构是OOP，DF系统就是建立在它上面的。（类：消息、端口、消费者、生产者、组件（抽象）等，当然还有很多组件类）。

【解决方案4】：

请看下面的论文

【讨论】：

【解决方案5】：

也请看

【讨论】：