<p>CSP is roughly like processes communicating via TCP connections (sender blocks until the receiver ACKed), the actor model is roughly like processes communicating via UDP (you send packets and hope for the best).</p>
<p>If the platform has guarenteed delivery (unlike network protocols, but like Kafka or messages via the file system), the actor model becomes quite a bit more powerful and allows for temporal decoupling. So a pipeline of actors does not strictly require the actors themselves to even exist at the same time as long as their mailboxes exist, you could run them sequentially one after another.</p>
<p>CSP by contrast would require an explicit adapter that can serialize/deserialize messages if you want temporal decoupling (and serialization would be outside of CSP proper), though with one-way channels that is easy to do. Alternatively, you can extend CSP with buffered channels (only block and wait for an ACK after &gt;=N unacknowledged messages) which also allows some temporal decoupling.</p>

CC BY-SA 4.0
2024-02-09T08:53:36.040Z
2024-02-09T08:53:36.040Z
saolof
<p>I believe one core difference is that in CSP, processes synchronize when messages are received (i.e. a message cannot be sent from one process unless another process is in a receiving mode), while the Actor model is inherently asynchronous (i.e. messages are immediately sent to other processes' address, irrespective of whether they're actively waiting on a message or not).</p>

<p>There should be another answer that is more well-developed, however.</p>

CC BY-SA 3.0
2015-08-17T02:39:14.380Z
I'm not sure if this the core difference, since CSP can have buffered channels allowing asynchronous message sending. Perhaps it's more about the process id, in CSP processes are anonymous, while actors are named.
CMCDragonkai
CC BY-SA 4.0
2022-05-13T21:18:09.940Z
@CMCDragonkai It seems that in the original CSP paper, https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf, explicitly addresses these two points:
xji
CC BY-SA 4.0
2022-05-13T21:18:35.657Z
"As an alternative to synchronization of input and
output, it is often proposed that an outputting process
should be allowed to proceed even when the inputting
process is not yet ready to accept the output. An implementation
would be expected automatically to interpose
a chain of buffers to hold output messages that have not
yet been input. 
I have deliberately rejected this alternative, for two
reasons ..."
xji
CC BY-SA 4.0
2022-05-13T21:21:49.647Z
"My design insists that every input or output command must name its source or destination explicitly."
xji
CC BY-SA 4.0
2022-05-13T21:22:24.753Z
So yeah, if the subject of the discussion is the original CSP paper, then this answer by Daniel seems accurate. It actually doesn't seem to be exactly the same thing as we see in Golang or Clojure's core.async, which have explicit channels.
xji
CC BY-SA 4.0
2022-05-13T22:10:13.163Z
Though the WP article https://en.wikipedia.org/wiki/Communicating_sequential_processes and a summary https://www.springer.com/computer/theoretical+computer+science/foundations+of+computations/book/978-3-540-25813-1 does mention that it has evolved substantially since Hoare originally proposed it in 1978, so probably now it indeed always refers to implementations using channels.
xji
CC BY-SA 4.0
2022-05-14T07:39:26.133Z
So original CSP was meant to be synchronous, but implementations nowadays allow asynchronous buffers. As for anonymous processes, it does appear CSP allows anonymous, while actors must always be named.
CMCDragonkai
CC BY-SA 2.5
2010-09-03T22:29:59.077Z
So, basically, it's all about the mailbox?
Jörg W Mittag
CC BY-SA 2.5
2010-09-09T03:24:21.500Z
What about the differences listed here:
http://en.wikipedia.org/wiki/Actor_model_and_process_calculi_history#Early_work and
http://en.wikipedia.org/wiki/Actor_model#Contrast_with_other_models_of_message-passing_concurrency ? Another important difference, for earlier versions of CSP, is unbounded nondeterminism (see those links).
Blaisorblade
CC BY-SA 2.5
2010-08-17T18:30:54.127Z
That's pretty much the answer I would have written. In the original actor model (Hewitt, Agha), the receiving process did not even automatically provide access to the name of the sender, though more modern realisations (such as Scala's actors) do.

The other difference is that actors enable the sending of actor ids in the messages, as hinted in the question, whereas this is not possible in CSP. (Also possible in the pi-calculus, but not in CCS.)
Dave Clarke
CC BY-SA 2.5
2010-08-17T18:13:34.927Z
2010-08-17T18:13:34.927Z
Daniel Apon
<p>I'm trying to wrap my head around what the real differences between the Actor Model of concurrency and Communicating Sequential Processes (CSP) model of concurrency.  </p>

<p>So far the best that I have been able to come up with is that the Actor Model allows the number and layout of nodes to change while CSP has a fixed structure of nodes.</p>

CC BY-SA 3.0
2015-07-12T17:02:00.313Z
See also [The Actor Model at ~14:45](https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask) on Channel 9, where Carl Hewitt discusses the Actor Model in some depth. He notes a difference between actors and CSP is the use of channels for communication in CSP versus direct communication in the Actor Model.
Whymarrh
CC BY-SA 4.0
2022-05-13T21:27:24.503Z
@Whymarrh Interestingly, the original CSP paper https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf doesn't seem to make channels an integral part of the proposal. Processes are supposed to directly talk to each other by their names (though in a synchronous fashion). So I guess if the comparison is between current iterations of the idea, e.g. as seen in Golang or Clojure's core.async, then this is true, but Daniel's answer about the synchronous nature of the communication seems more accurate regarding the original CSP idea.
xji
CC BY-SA 4.0
2022-05-13T22:10:09.710Z
Though the WP article https://en.wikipedia.org/wiki/Communicating_sequential_processes and a summary https://www.springer.com/computer/theoretical+computer+science/foundations+of+computations/book/978-3-540-25813-1 does mention that it has evolved substantially since Hoare originally proposed it in 1978, so probably now it indeed always refers to implementations using channels.
xji
<concurrency>
What's the difference between the Actor Model of Concurrency and Communicating Sequential Processes
twhitlock
# What's the difference between the Actor Model of Concurrency and Communicating Sequential Processes

(Asked by: username_0 on 2010-08-17)

I'm trying to wrap my head around what the real differences between the Actor Model of concurrency and Communicating Sequential Processes (CSP) model of concurrency.

So far the best that I have been able to come up with is that the Actor Model allows the number and layout of nodes to change while CSP has a fixed structure of nodes.

**Tags:** concurrency
> **Comments:**
> **username_1**: See also [The Actor Model at ~14:45](https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask) on Channel 9, where Carl Hewitt discusses the Actor Model in some depth. He notes a difference between actors and CSP is the use of channels for communication in CSP versus direct communication in the Actor Model.  
> **username_2**: @Whymarrh Interestingly, the original CSP paper https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf doesn't seem to make channels an integral part of the proposal. Processes are supposed to directly talk to each other by their names (though in a synchronous fashion). So I guess if the comparison is between current iterations of the idea, e.g. as seen in Golang or Clojure's core.async, then this is true, but Daniel's answer about the synchronous nature of the communication seems more accurate regarding the original CSP idea.  
> **username_2**: Though the WP article https://en.wikipedia.org/wiki/Communicating_sequential_processes and a summary https://www.springer.com/computer/theoretical+computer+science/foundations+of+computations/book/978-3-540-25813-1 does mention that it has evolved substantially since Hoare originally proposed it in 1978, so probably now it indeed always refers to implementations using channels.  

---

## 2 answers

### Answer by username_4 on 2010-08-17. Score: 22 | Accepted answer

I believe one core difference is that in CSP, processes synchronize when messages are received (i.e. a message cannot be sent from one process unless another process is in a receiving mode), while the Actor model is inherently asynchronous (i.e. messages are immediately sent to other processes' address, irrespective of whether they're actively waiting on a message or not).

There should be another answer that is more well-developed, however.

> **Comments:**
> **username_8**: That's pretty much the answer I would have written. In the original actor model (Hewitt, Agha), the receiving process did not even automatically provide access to the name of the sender, though more modern realisations (such as Scala's actors) do.  The other difference is that actors enable the sending of actor ids in the messages, as hinted in the question, whereas this is not possible in CSP. (Also possible in the pi-calculus, but not in CCS.)  
> **username_6**: So, basically, it's all about the mailbox?  
> **username_7**: What about the differences listed here: http://en.wikipedia.org/wiki/Actor_model_and_process_calculi_history#Early_work and http://en.wikipedia.org/wiki/Actor_model#Contrast_with_other_models_of_message-passing_concurrency ? Another important difference, for earlier versions of CSP, is unbounded nondeterminism (see those links).  
> **username_5**: I'm not sure if this the core difference, since CSP can have buffered channels allowing asynchronous message sending. Perhaps it's more about the process id, in CSP processes are anonymous, while actors are named.  
> **username_2**: @CMCDragonkai It seems that in the original CSP paper, https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf, explicitly addresses these two points:  
> **username_2**: "As an alternative to synchronization of input and output, it is often proposed that an outputting process should be allowed to proceed even when the inputting process is not yet ready to accept the output. An implementation would be expected automatically to interpose a chain of buffers to hold output messages that have not yet been input.  I have deliberately rejected this alternative, for two reasons ..."  
> **username_2**: "My design insists that every input or output command must name its source or destination explicitly."  
> **username_2**: So yeah, if the subject of the discussion is the original CSP paper, then this answer by Daniel seems accurate. It actually doesn't seem to be exactly the same thing as we see in Golang or Clojure's core.async, which have explicit channels.  
> **username_2**: Though the WP article https://en.wikipedia.org/wiki/Communicating_sequential_processes and a summary https://www.springer.com/computer/theoretical+computer+science/foundations+of+computations/book/978-3-540-25813-1 does mention that it has evolved substantially since Hoare originally proposed it in 1978, so probably now it indeed always refers to implementations using channels.  
> **username_5**: So original CSP was meant to be synchronous, but implementations nowadays allow asynchronous buffers. As for anonymous processes, it does appear CSP allows anonymous, while actors must always be named.  

---

### Answer by username_3 on 2024-02-09. Score: 1

CSP is roughly like processes communicating via TCP connections (sender blocks until the receiver ACKed), the actor model is roughly like processes communicating via UDP (you send packets and hope for the best).

If the platform has guarenteed delivery (unlike network protocols, but like Kafka or messages via the file system), the actor model becomes quite a bit more powerful and allows for temporal decoupling. So a pipeline of actors does not strictly require the actors themselves to even exist at the same time as long as their mailboxes exist, you could run them sequentially one after another.

CSP by contrast would require an explicit adapter that can serialize/deserialize messages if you want temporal decoupling (and serialization would be outside of CSP proper), though with one-way channels that is easy to do. Alternatively, you can extend CSP with buffered channels (only block and wait for an ACK after >=N unacknowledged messages) which also allows some temporal decoupling.


---

