Nothing to do with pthreads. As long as you want to use shared memory to communicate with concurrent processes, you need a memory model with compiler support. Even if you exclusively use mutexes.
> As long as you want to use shared memory to communicate with concurrent processes
That's something pthreads do and CSP doesn't.
> you need a memory model with compiler support. Even if you exclusively use mutexes.
If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."
For better or worse, our current hardware architectures present a shared memory interface for intercore communication. So if you want a non-toy CSP programing language you have to implement with a programming language that support shared memory concurrency (for the OS at the very least).
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
Not sure what CSP is supposed to mean, but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
> but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
If that's your bottleneck then you've either already solved every other class of performance issue with your program or you're working in a fantasy environment-- you're probably not hacking on FFmpeg right now. 90% of performance is I/O bound, whether it be the disk, the network or whatever. You can easily ascertain the correctness of a CSP system, because it's just message passing and inherently synchronous. Not so much with shared memory. It's a tradeoff. Unix pipes are also pretty goddamn fast, like, this is an issue people have spent time squeezing as much performance as possible out of. Google uses Go for all of their important backend shit. The entire internet is a giant message passing system.
> 90% of performance is I/O bound, whether it be the disk, the network or whatever
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
> to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must.
Architecture problem. Do your programs normally saturate a 40 gig network pipe?
> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
You can boot up a Plan 9 kernel and tell me if it works or not. Like, this is not a high bar, but you keep treating it like it is because it's based on the assumption that all compilers are broken with the set of all compilers being GCC.
