私はerlangを学ぶことを検討してきました。その結果、俳優のモデルについて読んでいました（大丈夫、スキミング）。
私が理解しているところから、アクターモデルは、単純にメッセージの受け渡しによってのみ互いに通信する関数群（erlangの
“プロセス”と呼ばれる軽量スレッド内で実行される）の集合です。
これはC ++やその他の言語で実装するのはかなり簡単です。
class BaseActor {
std::queue 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のインスタンスです。アクターは、メッセージの受け渡しを介してのみ互いに通信します。
（すなわち、押す）。アクターは、他のアクターがそれを見つけることを可能にする初期化時に中央マップを登録し、それらを介して中央機能を実行させる。
さて、私は、私が行方不明、またはむしろ、ここで一つの重要な問題、すなわち：
降格の欠如は、単一の俳優が過度の時間を不公平に消費する可能性があることを意味する。しかし、クロスプラットフォームのコルーチンは、これをC
++で難しくする主なものですか？ （例えば、Windowsにはファイバーがあります。）
私は行方不明の他に何かがありますか、またはモデルは本当に明らかですか？
私は間違いなくここで炎戦を始めようとはしていませんが、これは本質的に同時コードについて幾分理由があるのです。
C
++コードは、Erlangがそのアクターモデルの一部としてもたらすすべてのものである公平性、分離性、障害検出または分布を処理しません。
- 他の俳優を飢えさせる俳優はいない（公正さ）
- 1つのアクタがクラッシュした場合、そのアクタ（アイソレーション）にのみ影響するはずです。
- あるアクタがクラッシュした場合、他のアクタはそのクラッシュを検出して対応する必要があります（障害検出）
- アクターはネットワーク上で同じマシン（ディストリビューション）にいるかのように通信できる必要があります。
また、ビームSMPエミュレータは、アクターのJITスケジューリングを実行し、アクターをコアに移動させます。コアは現在使用率が最も低いコアに移動し、不要になった場合は特定のコアでスレッドを休止します。
さらに、Erlangで書かれたすべての図書館やツールは、これが世界の仕組みであり、それに応じて設計されていると考えることができます。
これらのことはC
++では不可能ではありませんが、Erlangが主なhwとosの設定のほとんどすべてで動作するという事実を追加すると、ますます難しくなります。
編集：ちょうど Ulf Wiger は、erlangスタイルの並行性がどのようなものかを見ています。