CSPのモデルに基づいて、実際には、一連の処理を通信チャネルでは、メッセージ通信ROS 、このチャネルテーマとして知られているトピックを
アーランはある俳優、の表現言語GoがあるCSPの表現言語
いくつかの答えがある方法を見て、しかし、ほとんど、これは多くの歴史を語って、より徹底し、便利な、慎重に検討する必要がありませんでした！
http://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model
ACTOR理解とCSPモデル、そこにPythonのソースコード。
https://www.codercto.com/a/9890.html
アクターモデルとオブジェクトモデル
セロンのフレームワークは基づいている俳優の並行プログラミングモデルC ++ ライブラリ。アクターモデルが作るセロンのフレームワークが効果的に直接、並列分散アプリケーションを作成します。セロンのフレームワークは、軽量のポータブル機能のインターフェースをたくさん提供してAPIを、で使用することができますLinuxでは、Windowsの、マック、ARM とMatlabの環境。
私たちは、オブジェクト=データ+振る舞い、すべてを促進するためのオブジェクトモデルを使用してオブジェクト指向プログラミングは、オブジェクトである知っています。俳優のモデルはすべてが俳優、彼らの行動によって維持アクターモデルの内部状態であると考えて、外部のスレッドは、オブジェクトが直接メンバーメソッドオブジェクトモデルを交換する仕組みを渡すメッセージを使用して、つまり、へのメッセージを通じて行動を鼓舞しなければならない行動を呼び出すことはできません呼び出しは、これを保証する俳優の内部データがのみ自分自身を変更することができます。+ + =データメッセージ俳優モデルの挙動。
しかし、C ++はオブジェクト指向言語なので、最終的にこのメカニズムはアクタクラスによってカプセル化され、マルチスレッド、マルチスレッド・メカニズムも共有メモリの設計に依存しているが、これらの事はセロンソースが完了するまでに私たちを助けています、我々は直接それが与えるクラスのインタフェースを使用することができます。サポートのpthread、Windowsのスレッド、ブースト::スレッドとC ++ 11スレッドのマルチスレッドの基礎セロンフレームワークは次の4つの伝統的なタイプを構築します。なぜなら最終的な分析の枠組みセロン内のクラスによって、言うことは口が自然に私たちは、クラスのオブジェクトクラスのメソッドを介してデータを直接呼び出して、C ++でのアクターモデルを達成カプセル化します。しかし、生態系の保全性セロンの枠組みを確保し、真に俳優モデルの優位性を反映するために、我々としてもそうします。
差に基づいて、図のオブジェクトモデルと俳優モデル3に示すように。
（A）
（B）
図俳優のメカニズムに基づいて、3オブジェクト比較機構
図からわかるように、オブジェクトのクラスオブジェクトのメンバーのメンバーは方法の方法は、B :: ::呼ばれるメソッド呼び出しと呼ばれ、実行方法Bの完了を待つ::クラスBコールAを通過するために呼び出し、応答を返し、最終的にA ::最後の呼び出しローカルコールバックは、それの実施を継続します。アクター・モデルでは、俳優の俳優Aは、最初のBにメッセージを送信し、その後、直ちに、次の手順を続行する戻り、俳優Bがウェイクアップメッセージを受信し、俳優に並列実行を続けます。
アクターモデルは、我々は、このようなメッセージスレッド機構が最大の利点は、ノンブロッキングであると呼ばれて見ることができ、これまで、複数の同時スレッドがメソッドの戻りメッセージの実装が完了したことに応じて呼び出されることを待たずに、することができます。もちろん、ここで我々は我々のバックプログラムは、それはすぐにそれを行うにはどのように応答メッセージを返す使用する必要がある場合ということは、おそらく私のような少し混乱の場所を参照してください？実際には、これは、あまりにも、一点の欠陥が俳優の存在で、私たちは最終的にあなたのアプリケーションを考慮する必要があり、それは、このメカニズムに適切である、我々は再び前に、マルチスレッドの設計では、後に詳細に説明します。
---------------------
著者：いいえ靴、子供用の靴
出典：CSDN
オリジナルます。https：//blog.csdn.net/FX677588/article/details/74359823
免責事項：この記事はブロガーのオリジナルの記事、再現され、ボーエンのリンクを添付してください！
異なる点3.2アクターモデルと共有メモリモデル
俳優正反対の別の共有メモリモデルとこの独立した同時モデル。俳優双方向メッセージングによる協力の間に、互いに独立したスレッドの。マルチコアおよび分散システムの時代の到来により、共有メモリモデルは、開発のために本当に適していません。我々は、図中に、例えばホテルの厨房で調理する4 以下。
図4は、比喩俳優モデル共有メモリモデルを示します
①、シングルスレッドに示すように、プログラミング4（A） - ホテルのみシェフスタッフ（のスレッド）であるかのように、プロセスの順序ですべてのアラカルト料理がラインの端部で終了します。
②、などの共有メモリマルチスレッドプログラミング、- 4（b）に比べて、それらの間にホテルのキッチンが実際に野菜等、ナイフ、シェフ、ウェイター、を通じて取り組んでいるかのように（誰もがスレッドである）、エネルギー協力シェフが速く、すべてのプロセスを完了します。私たちは、そのリソースを共有するための皿のと等価である、それが唯一の道料理の数が、その中の一人に対処することができますが、そこにはいつもの間に散在をお待ちしております考慮する必要があります。
③、俳優マルチスレッドプログラミングモデルは、図に示した図4（c） - 以上のホテルのシェフが、存在する場合、マスター四川、山東料理のシェフ、安徽料理のシェフなど、限り、彼らはニーズを注文する客を受け入れるように、全体です人々はそれだけでは、料理の手順を相当にかかわらず、マスターの間で相互にやるべきことなので、マルチスレッドの作業が大幅に効率が向上し、状況が相互にリソースのための待ち時間がなく、後に奉仕するウェイターに自分のメッセージをしますか。
私たちは、直接かつ便利に直接呼び出しなどしていないが、非同期メッセージングのアクターモデルは、並列実行をトリガするために見ることができますが、それは本当の意味での同期で実行メッセージをたくさん作ることができるように。メッセージの実装の成功の後、俳優の間のデカップリングの一方のニュースが出て送信され、どのように多くの時間がかかり、そのため長いバックなしメッセージング、すべてで送信者との任意の接続を持っていないが存在しないとして。これは、順番に、我々が対処するために、マルチスレッド環境要素と同期ロック、ミューテックス、などに共通の基盤を共有しないことを保証します。
---------------------
著者：いいえ靴、子供用の靴
出典：CSDN
オリジナルます。https：//blog.csdn.net/FX677588/article/details/74359823
免責事項：この記事はブロガーのオリジナルの記事、再現され、ボーエンのリンクを添付してください！
この記事では、単純な俳優を実装するためにnetmq使用する方法を説明するだけでなく、俳優モデルの基本的な概念の違いを説明し、共有メモリモデル
https://github.com/zeromq/netmq/blob/master/docs/actor.md
俳優のモデルとCSPのモデル
https://www.jdon.com/concurrent/actor-csp.html
テーマFML、ROSは、CSPモデルCHANNELです！！！
アクターモデルとCSPの差分モデル
アッカ/アーランのアクター・モデルが行くコルーチン言語ゴルーチンチャネルチャネルの代表CSPを（一連の処理を伝える）モデルには、どのような違いを生むのでしょうか？
まず、同時ソリューションモデルですどちらも、我々は2つのシナリオを異なる俳優を見て、チャンネル：
俳優のモデル
俳優のモデルでは、主人公は、俳優の間で労働者の一種に類似俳優は、任意の仲介を経由せずに相互に直接メッセージを送信し、メッセージを非同期に処理が送信されます。
俳優のモデルは、並行プログラミングの公理を避けるために、よくある質問のセットを記述します：
1. すべての俳優の状態俳優ローカル、外部アクセスできない。
2.Actorは、メッセージパッシングによってのみ通信しなければなりません。
3. 俳優の応答メッセージ：新しいの導入俳優、その内部状態を変更し、1人のまたは複数の他の参加者にメッセージを送信します。
4.Actorは自分のを詰まらせることがあり、しかし俳優はそれが実行スレッドをブロックするべきではありません。
もっと目に見える話題の俳優モデル
チャンネルモデル
Channel模型中，worker之间不直接彼此联系，而是通过不同channel进行消息发布和侦听。消息的发送者和接收者之间通过Channel松耦合，发送者不知道自己消息被哪个接收者消费了，接收者也不知道是哪个发送者发送的消息。
Go语言的CSP模型是由协程Goroutine与通道Channel实现：
- Go协程goroutine: 是一种轻量线程，它不是操作系统的线程，而是将一个操作系统线程分段使用，通过调度器实现协作式调度。是一种绿色线程，微线程，它与Coroutine协程也有区别，能够在发现堵塞后启动新的微线程。
- 通道channel: 类似Unix的Pipe，用于协程之间通讯和同步。协程之间虽然解耦，但是它们和Channel有着耦合。
Actor模型和CSP区别
Actor模型和CSP区别图如下：
Actor之间直接通讯，而CSP是通过Channel通讯，在耦合度上两者是有区别的，后者更加松耦合。
同时，它们都是描述独立的流程通过消息传递进行通信。主要的区别在于：在CSP消息交换是同步的(即两个流程的执行"接触点"的，在此他们交换消息)，而Actor模型是完全解耦的，可以在任意的时间将消息发送给任何未经证实的接受者。由于Actor享有更大的相互独立,因为他可以根据自己的状态选择处理哪个传入消息。自主性更大些。
在Go语言中为了不堵塞流程，程序员必须检查不同的传入消息，以便预见确保正确的顺序。CSP好处是Channel不需要缓冲消息，而Actor理论上需要一个无限大小的邮箱作为消息缓冲。
https://www.cnblogs.com/feng9exe/p/10482436.html
源于从Erlang到Go的一些思维碰撞，就像当初从C++到Erlang一样，整理下来记于此。
Actor
Actor模型，又叫参与者模型，其”一切皆参与者(actor)”的理念与面向对象编程的“一切皆是对象”类似，但是面向对象编程中对象的交互通常是顺序执行的(占用的是调用方的时间片，是否并发由调用方决定)，而Actor模型中actor的交互是并行执行的(不占用调用方的时间片，是否并发由自己决定)。
在Actor模型中，actor执行体是第一类对象，每个actor都有自己的ID(类比人的身份证)，可以被传递。actor的交互通过发送消息来完成，每个actor都有一个通信信箱(mailbox，本质上是FIFO消息队列)，用于保存已经收到但尚未被处理的消息。actorA要向actorB发消息，只需持有actorB ID，发送的消息将被立即Push到actorB的消息信箱尾部，然后返回。因此Actor的通信原语是异步的。
从actor自身来说，它的行为模式可简化为:
- 发送消息给其它的actor
- 接收并处理消息，更新自己的状态
- 创建其它的actor
一个好的Actor模型实现的设计目标:
- 调度器: 实现actor的公平调度
- 容错性: 具备良好的容错性和完善错误处理机制
- 扩展性: 屏蔽actor通信细节，统一本地actor和远程actor的通信方式，进而提供分布式支持
- 热更新? (还没弄清楚热更新和Actor模型，函数式范式的关联性)
在Actor模型上，Erlang已经耕耘三十余载，以上提到的各个方面都有非常出色的表现，其OTP整合了在Actor模型上的最佳实践，是Actor模型的标杆。
CSP
顺序通信进程(Communicating sequential processes，CSP)和Actor模型一样，都由独立的，并发的执行实体(process)构成，执行实体间通过消息进行通信。但CSP模型并不关注实体本身，而关注发送消息使用的通道(channel)，在CSP中，channel是第一类对象，process只管向channel写入或读取消息，并不知道也不关心channel的另一端是谁在处理。channel和process是解耦的，可以单独创建和读写，一个process可以读写(订阅)个channel，同样一个channel也可被多个process读写(订阅)。
对每个process来说：
- 从命名channel取出并处理消息
- 向命名channel写入消息
- 创建新的process
Go语言并没有完全实现CSP理论(参见知乎讨论)，只提取了CSP的process和channel的概念为并发提供理论支持。目前Go已经是CSP的代表性语言。
CSP vs Actor
- 相同的宗旨：”不要通过共享内存来通信，而应该通过通信来共享内存”
- 两者都有独立的，并发执行的通信实体
- Actor第一类对象为执行实体(actor)，CSP第一类对象为通信介质(channel)
- Actor中实体和通信介质是紧耦合的，一个Actor持有一个Mailbox，而CSP中process和channel是解耦的，没有从属关系。从这一层来说，CSP更加灵活
- Actor模型中actor是主体，mailbox是匿名的，CSP模型中channel是主体，process是匿名的。从这一层来说，由于Actor不关心通信介质，底层通信对应用层是透明的。因此在分布式和容错方面更有优势
Go vs Erlang
- 以上 CSP vs Actor
- 均实现了语言级的coroutine，在阻塞时能自动让出调度资源，在可执行时重新接受调度
- go的channel是有容量限制的，因此只能一定程度地异步(本质上仍然是同步的)，erlang的mailbox是无限制的(也带来了消息队列膨胀的风险)，并且erlang并不保证消息是否能到达和被正确处理(但保证消息顺序)，是纯粹的异步语义，actor之间做到完全解耦，奠定其在分布式和容错方面的基础
- erlang/otp在actor上扩展了分布式(支持异质节点)，热更和高容错，go在这些方面还有一段路要走(受限于channel，想要在语言级别支持分布式是比较困难的)
- go在消息流控上要做得更好，因为channel的两个特性: 有容量限制并独立于goroutine存在。前者可以控制消息流量并反馈消息处理进度，后者让goroutine本身有更高的处理灵活性。典型的应用场景是扇入扇出，Boss-Worker等。相比go，erlang进程总是被动低处理消息，如果要做流控，需要自己做消息进度反馈和队列控制，灵活性要差很多。另外一个例子就是erlang的receive操作需要遍历消息队列(参考)，而如果用go做同步调用，通过单独的channel来做则更优雅高效
Actor in Go
在用Go写GS框架时，不自觉地会将goroutine封装为actor来使用:
- GS的执行实体(如玩家，公会)的逻辑具备强状态和功能聚合性，不易拆分，因此通常是一个实体一个goroutine
- 实体接收的逻辑消息具备弱优先级，高顺序性的特点，因此通常实体只会暴露一个Channel与其它实体交互(结合go的interface{}很容易统一channel类型)，这个channel称为RPC channel，它就像这个goroutine的ID，几乎所有逻辑goroutine之间通过它进行交互
- 除此之外，实体还有一些特殊的channel，如定时器，外部命令等。实体goroutine对这些channel执行select操作，读出消息进行处理
- 加上goroutine的状态数据之后，此时的goroutine的行为与actor相似：接收消息(多个消息源)，处理消息，更新状态数据，向其它goroutine发送消息(通过RPC channel)
到目前为止，goroutine和channel解耦的优势并未体现出来，我认为主要的原因仍然是GS执行实体的强状态性和对异步交互流程的顺序性导致的。
在研究这个问题的过程中，发现已经有人已经用go实现了Actor模型: https://github.com/AsynkronIT/protoactor-go。 支持分布式，甚至supervisor，整体思想和用法和erlang非常像，真是有种他山逢知音的感觉。:)
参考：
- http://jolestar.com/parallel-programming-model-thread-goroutine-actor/
- https://www.zhihu.com/question/26192499
http://wudaijun.com/2017/05/go-vs-erlang/
// ------------------------------------------------ --------------------------------------------- 木を取り囲む、生Haomoで、ベースの土壌から9つの単位;千マイルは一歩から始まります。土壌成山、風と雨興ヤン、深い水の中に、龍生まれヤン、ドイツなど慈善、満足の神々は、聖心はヤンを準備します。ない小川、jianghaiに、それは短いステップ、千マイルです。スティード飛躍ではなく、10段階; NAG落胆で10ドライブ、電源。枯死木のQieerの家はフォールドしません。忍耐力が石を離れて身に着けています。また、1の意図を、エジプトの土壌の食品には何のポーン、強い骨や筋肉を、ミミズないの下で自分たちの生活を飲みます。六本のGuier 2つのカニの爪、非ヘビウナギの洞窟なし糧、意思もせっかち。