News for hackers. Stuff that matters.
Re:Revisiting Actor Programming in C++ (2015) by srean on Monday November 19, 2018 @04:16AM (#18485065)
A question for those who are more knowledgeable than me -- Is Actor model the same as the CSP model ? They feel the same but I am not sure.
Re:Revisiting Actor Programming in C++ (2015) by RossBencina on Monday November 19, 2018 @10:38AM (#18487122)
Their definitions are distinct -- and at least at a surface level, quite different.[1] They have different abstract interfaces. From a practical point of view, if you're going to use them for programming, it's safe to say that they're not "the same." However, you do see some overlap in practical implementations: for example some actor systems have first-class channel or mailbox abstractions, whereas the pure Actor model has no such entities. People talk about implementing actors in Go, but Go is a CSP-based system.

You can ask whether the models are somehow equivalent (isomorphic?), or to what degree can you express one model in the other. Last time I checked, that is a fairly deep rabbit hole -- you'd need a solid grasp of the theory of equivalence of concurrent programs (e.g. pi-calculus) to answer the question properly.

Also don't forget that the Erlang team claim to have never heard of Hewitt's actor model, so Erlang-inspired actor systems are potentially distinct from (Hewitt, Agha et. al.) Actor Model systems.

[1] https://arild.github.io/csp-presentation/#1

Re:Revisiting Actor Programming in C++ (2015) by keithnz on Monday November 19, 2018 @04:22AM (#18485090)
Re:Revisiting Actor Programming in C++ (2015) by srean on Monday November 19, 2018 @04:35AM (#18485134)
Ah! Thank you very much.
Re:Revisiting Actor Programming in C++ (2015) by eao197 on Monday November 19, 2018 @05:21AM (#18485357)
This point:

"CSP message-passing fundamentally involves a rendezvous between the processes involved in sending and receiving the message, i.e. the sender cannot transmit a message until the receiver is ready to accept it."

it not that strict in a practice. In dependency of implementation of CSP there can be CSP-channels with limited and unlimited capacity. If channels with limited capacity are used then some kind of rendezvous is necessary only on attempt to write a new message to a full channel. In that case process-writer will be blocked until process-reader read some messages from the channel.

If size-unlimited channels are used then interaction of CSP-processes will be asynchronous (just like in Actor Model).

There is another important difference (but it also depends on implementation details): CSP-processes are always proactive. They can do something even if there is no messages to read and process.

Otherwise actors are reactive (usually). They react only to incoming messages and do nothing if there is no new message in they inboxes.

This especially true for cases when actors are implemented as objects with callbacks (for example it is true for Akka, CAF, SObjectizer, QP/C++, Orleans and so on).

But there can be implementations of Actor Model where an actor has to call some kind `receive` primitive to get an incoming message. For example it is Erlang programming language and Just::Thread Pro Actor Edition library for C++.