Is there a specific aspect of it you want to understand?

My recommendation to younger colleagues has been: Learn Go and Erlang. Go implements (basically) communicating sequential processes. If you want to know more from a theory side, you can read C.A.R. Hoare's book on the topic [0]. Erlang uses the actor model and message passing. There are many similarities but enough differences that you can learn a lot by learning both. Other languages offer these same approaches, but these two are the closest mainstream languages I'm aware of that take CSP or actor model as almost their basic design philosophy. This reduces the semantic distance between the language and the theory and makes it easy to learn, IMHO.

Lots of good resources for both, you can google around for.

After getting the hang of things here, I'd continue with studying the concurrency primitives or libraries of your language of choice. You'll hopefully find that you can apply the knowledge you've found from the first two to designing good concurrent software in most other languages.

[0] http://www.usingcsp.com/

You may want to start with "The little book of semaphores" before delving into the concurrency models of a language. I have not found a more approachable text for understanding/solving synchronization problems.

http://greenteapress.com/semaphores/LittleBookOfSemaphores.p...

Yeah learning Go and Erlang has been on my mind. Basically I am interested in learning about the different prevalent models like CSP, STM, actors and how they differ or relate to each other, or how things like event loops or sync and async fit in here. I have a basic idea of the terms but I don't have a clear picture in mind.

You might try "Seven Concurrency Models in Seven Weeks" for a high-level overview of different approaches.

https://pragprog.com/book/pb7con/seven-concurrency-models-in...

Whoa nice, seems like exactly what I wanted

does anyone know what is the trade off between csp and actor?

It varies by implementation but with Actors the processor is addressable (process ID) and with CSP the transport, typically channels, are what is addressable.

To make it more concrete, with CSP you send the message to a channel and you don’t know who is reading from that channel. With Actors you send a message to a specific Actor.

Time for opinions: It’s pretty trivial to get channel semantics with Actors by having an Actor that acts as a reverse proxy. It’s harder, or maybe less conventional, to have Actor semantics with CSP. You would have to assign a channel to each processor (goroutine in Go) and maintain a reference to that.

At the end of the day, they are just abstractions and we are always working with references to memory, IO, and CPU, so the differences are mostly philosophical. Actors resonate better with the model of computation and program structure I have built up in my head over time.