6 ms·

I'm very much a novice in concurrent programming so I looked that up: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/

I'm very much a novice in concurrent programming so I looked that up: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... > ...communicating sequential processes (CSP) is a formal language for describing patterns of interaction in concurrent systems. > ... based on message passing via channels. That seems like a mathematical language that could describe goroutines and channels but also seems like it could describe python's multiprocessing and queue constructs. I think of those as very different things given the (vastly different) applications. When I think of "go-style" I think of lightweight threads (I can have 1000s), where as python processes are heavy (100 is pushing it?). So maybe the specifics of the implementation have as much to do with the go-style as the abstract concept? My understanding here is fuzzy for sure and I welcome corrections and more detail.

jlokier 5y ago
There are no queues in CSP, although you can make one by making a queue process. In CSP, the sending side of a message is always logically simultaneous with the receiving side. So it's like Go's default channels where the sender and receiver both block until ready to transfer, and different from Python's multiprocessing and queue constructs, where the sender doesn't block. CSP was used in Occam¹ on Transputers² in the 1980s. In Occam, it was normal to have a large number of tiny processes, some of them maybe only a few instructions (such as an implementation of a queue), and the thread switching and communication primitives were actual CPU instructions. The CPUs were joined with dedicated message communication links into large meshes, providing hardware parallelism with a very different model than today's SMP multi-core. A similar architecture exists today, XMOS³. Go implements a model similar to CSP on today's SMP multi-core systems and OSes, emphasising many efficient, small threads running loops that communicate synchronously. Channels are unbuffered by default, making them like CSP. They can be made buffered, which adds a queue, as if a CSP queue process was added. Go is much less rigid than Occam, because you can also make new channels and spawn new threads efficiently, which are essential features in modern sofware. Python multiprocessing doesn't provide efficient, small threads. You need larger thread units to get good performance out of it. It also emphasises queuing. So it's quite different from CSP. Erlang implements a model like Occam and Go of many, efficient, small threads, but the messaging is always asynchronous. The communication is similar to Go with buffered channels. ¹ https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) ² https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer ³ https://en.wikipedia.org/wiki/XMOS https://en.wikipedia.org/wiki/XMOS
- intrepidhero 5y ago
  Thanks for taking the time to write that! Very helpful.

jlokier 5y ago

There are no queues in CSP, although you can make one by making a queue process. In CSP, the sending side of a message is always logically simultaneous with the receiving side. So it's like Go's default channels where the sender and receiver both block until ready to transfer, and different from Python's multiprocessing and queue constructs, where the sender doesn't block. CSP was used in Occam¹ on Transputers² in the 1980s. In Occam, it was normal to have a large number of tiny processes, some of them maybe only a few instructions (such as an implementation of a queue), and the thread switching and communication primitives were actual CPU instructions. The CPUs were joined with dedicated message communication links into large meshes, providing hardware parallelism with a very different model than today's SMP multi-core. A similar architecture exists today, XMOS³. Go implements a model similar to CSP on today's SMP multi-core systems and OSes, emphasising many efficient, small threads running loops that communicate synchronously. Channels are unbuffered by default, making them like CSP. They can be made buffered, which adds a queue, as if a CSP queue process was added. Go is much less rigid than Occam, because you can also make new channels and spawn new threads efficiently, which are essential features in modern sofware. Python multiprocessing doesn't provide efficient, small threads. You need larger thread units to get good performance out of it. It also emphasises queuing. So it's quite different from CSP. Erlang implements a model like Occam and Go of many, efficient, small threads, but the messaging is always asynchronous. The communication is similar to Go with buffered channels. ¹ https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) ² https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer ³ https://en.wikipedia.org/wiki/XMOS https://en.wikipedia.org/wiki/XMOS

intrepidhero 5y ago
Thanks for taking the time to write that! Very helpful.