
Communicating Sequential Processes (1978) [pdf] - tosh
https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf
======
arethuza
CSP provided the basis for the occam programming language designed for the
Transputers:

[https://en.wikipedia.org/wiki/Occam_(programming_language)](https://en.wikipedia.org/wiki/Occam_\(programming_language\))

Edit: The CS course I did in the 1980s had a Concurrent Programming course
that covered CSP and another one of my favourites: Petri Nets

[https://en.wikipedia.org/wiki/Petri_net](https://en.wikipedia.org/wiki/Petri_net)

Edit2: Go also has concurrency features influenced by CSP:

[https://golang.org/doc/faq#csp](https://golang.org/doc/faq#csp)

~~~
wirrbel
I like petri nets so much.

------
lou1306
Whenever CSP comes around on Hacker News, I feel the need to suggest people
look a bit into Milner's CCS as well.

[https://en.wikipedia.org/wiki/Calculus_of_communicating_syst...](https://en.wikipedia.org/wiki/Calculus_of_communicating_systems)

The end goals of both languages are mostly the same, but while CSP aims at
being a "powerful" language, CCS strives for simplicity. You can see how both
approaches have their pros and cons.

~~~
iainmerrick
Yes! CCS feels like “the” concurrent equivalent of the lambda calculus
(although really there’s a huge family of similar simple process calculi that
are all essentially the same). CSP feels very large and untidy in comparison.

------
amboo7
The whole book: [http://www.usingcsp.com/](http://www.usingcsp.com/)

~~~
ejanus
Thanks for sharing

------
djd20
Ha - nice to see this - myself and a few others built a transputer compatible
VM - [http://www.transterpreter.org/](http://www.transterpreter.org/) and used
it to run occam2 and derivatives on various machines, and robots including the
cell processor in the PS3.

------
2sk21
This brings back happy memories for me. In the late 80s, I wrote thousands of
lines of Occam for a Meiko Computing Surface made from Inmos T800 Transputers.
Among the parallel algorithms I implemented was Lamport's algorithm for
finding shortest paths in a graph.

~~~
mpweiher
Sounds really interesting!

Can you write more about the programming experience? Particularly the handling
parallel processes and communication, but also general observations.

------
johnny_douglas
CSP formed the basis for a good chunk of my graduate work.

One concept we explored was using CSP as a 'formal backbone' that handled
communication/parallelism in complex systems while allowing stand-alone
'business logic' to co-exist without the need for the same level of rigour.

If you're reasoning about a concurrency problem, doing a quick CSP spec on the
back of an envelope is a great way to 'check your math.'

Steve Schneider's book is a very approachable text on the subject:
[https://www.amazon.ca/Concurrent-Real-time-Systems-CSP-
Appro...](https://www.amazon.ca/Concurrent-Real-time-Systems-CSP-
Approach/dp/0471623733)

~~~
Jtsummers
[http://www.cs.rhbnc.ac.uk/books/concurrency/](http://www.cs.rhbnc.ac.uk/books/concurrency/)

That book has been made availabel for free as a PDF.

------
fogetti
I find this concept really remarkable and extraordinary. When I first
encountered it I was still programming in Java and to my surprise there is an
implementation of it in Java, see:
[https://en.wikipedia.org/wiki/JCSP](https://en.wikipedia.org/wiki/JCSP)

I really enjoyed playing with this library. Somehow the basic abstractions and
the mental model to use it felt much easier in general than the threading
model. It reminded me of go channels for some extent. It is also a very
powerful concept. It even allows to emulate the actor model. Sadly it is not
actively developed any more.

~~~
jerf
"It reminded me of go channels for some extent."

Go channels explicitly drew from CSP for inspiration, but it is not exactly
the CSP in the paper.

That said, almost everything that draws from CSP for inspiration has at least
a small difference from the paper, if you analyze it closely enough. Often
major differences. The idea seems robust enough to those variations that it's
not a problem, though.

~~~
zzzcpan
How is it robust if Go is pretty much the only widely used CSP implementation
in existence. And Go itself is constantly fighting CSP deficiencies, trying to
abstract it away and move closer to actors. Still not getting there, because
actors cannot be properly implemented on top of CSP and CSP alone cannot be
used for anything real world related.

If anyone wants to learn something from CSP, learn why it doesn't work.

~~~
AnimalMuppet
Could you be a bit more specific? _Why_ do you think it doesn't work? _Why_ do
you think actors are better? And _why_ can't actors be properly implemented on
top of CSP?

~~~
Zalastax
I touched on this in my MSc thesis [1], see section 2.6 and 3.4.1. The
original CSP can only work if you stay on a single machine. You can have
channels in a distributed setting but you need to make the reading capability
of a channel limited to a single consumer. If there are multiple possible
readers at the same time it gets impossible to know where to send each message
and in a distributed setting there's no way of solving that, short of solving
distributed consensus. Cloud Haskell [2] section 4 touches this as well.

[1]:
[http://studentarbeten.chalmers.se/publication/256251-singly-...](http://studentarbeten.chalmers.se/publication/256251-singly-
typed-actors-in-agda-an-approach-to-distributed-programming-with-dependent-
types) [2]: [https://www.microsoft.com/en-us/research/wp-
content/uploads/...](https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/07/remote.pdf)

------
arnon
I took CSP as a basis for learning how distributed and concurrent protocols
work, and then did Erlang to see that into reality. Great thing to learn

