Reply to post: Re: Yes, its you.

Re: Yes, its you.

@boltar,

Is using pthreads REALLY so hard? There seems to be a lot of noise about the latest flavour of the month concurrent languages but in reality all they do is prettify (and arguably simplify) threading syntax and control then make the same underlying calls to the OS threading system. They don't actually give you any more power.

PThreads are harder to get right (from the point of view of being sure there's no potential for deadlock, lock failures, etc). Shared memory, semaphores, etc can be fearsomely difficult to debug, etc.

CSP in particular makes it easier to get it right, or at least if you don't you're guaranteed to find out as soon as you run your system. If you've written it such that it can deadlock, it will deadlock.

Also you can do some process calculi maths and prove the correctness of a CSP design theoretically. That's not something you can do with pthreads, shared memory and semaphores in anything but the most trivial of cases.

As for more power, one has to be a bit careful. Pthreads, shared memory, semaphores all assume that it's running on top of an SMP computer architecture. Whereas CSP is quite content to exist on NUMA architectures. What Intel actually give us is, effectively, a NUMA machine with SMP emulated on top. Thus software that's more NUMAry in operation can be kinder to the Quickpath interconnect between CPUS and the shared L3 caches.

And because CSP is NUMA friendly, it's quite straight forward to scatter CSP proecesses around a network and scale up (though Go and Rust don't AFAIK do this for you). That's a complete no-no with shared memory, semaphores and pthreads.