c++ - Actor 模型 : Why is Erlang/OTP special? 你能用另一种语言吗？

Question

我一直在研究学习 Erlang/OTP，因此，我一直在阅读(好吧，略读)关于 actor 模型的内容。

据我了解，actor 模型只是一组函数(在 Erlang/OTP 中称为“进程”的轻量级线程中运行)，它们仅通过消息传递相互通信。

用 C++ 或任何其他语言实现这似乎相当简单:

class BaseActor {
    std::queue<BaseMessage*> messages;
    CriticalSection messagecs;
    BaseMessage* Pop();
public:
    void Push(BaseMessage* message)
    {
        auto scopedlock = messagecs.AquireScopedLock();
        messagecs.push(message);
    }
    virtual void ActorFn() = 0;
    virtual ~BaseActor() {} = 0;
}

您的每个进程都是派生 BaseActor 的一个实例。参与者之间仅通过消息传递进行通信。 (即推)。 Actor 在初始化时使用中央 map 注册自己，这允许其他 Actor 找到它们，并允许中央功能通过它们运行。

现在，我知道我遗漏了，或者更确切地说，在这里掩盖了一个重要问题，即:缺乏让步意味着单个 Actor 可能会不公平地消耗过多的时间。但是跨平台协程是在 C++ 中使这变得困难的主要因素吗？ (例如 Windows 有纤维。)

还有什么我遗漏的，或者模型真的这么明显吗？

Answer 1

C++ 代码不处理公平、隔离、故障检测或分发，这些都是 Erlang 作为其参与者模型的一部分带来的。

• 不允许任何 Actor 饿死任何其他 Actor (公平)
• 如果一个 Actor 崩溃，它应该只影响那个 Actor (隔离)
• 如果一个参与者崩溃，其他参与者应该能够检测到该崩溃并使用react(故障检测)
• 参与者应该能够像在同一台机器上一样通过网络进行通信(分布式)

beam SMP 模拟器还带来了参与者的 JIT 调度，将它们移动到目前利用率最低的核心，并且如果不再需要某些核心上的线程，它们也会休眠。

此外，所有用 Erlang 编写的库和工具都可以假定这是世界的运作方式，并相应地进行设计。

这些事情在 C++ 中并非不可能做到，但如果你加上 Erlang 几乎适用于所有主要硬件和操作系统配置的事实，它们就会变得越来越难。

编辑:刚刚找到 Ulf Wiger 的描述关于他认为 erlang 风格的并发是什么。