4 ms·
> Ten years on, was the C++11 memory model (which I've used) a success? Concurrent/parallel programming in C and C++ before the memory model was an absolute sh
by adwn 5y ago
> Ten years on, was the C++11 memory model (which I've used) a success?
Concurrent/parallel programming in C and C++ before the memory model was an absolute shitshow. You could either
a) scream "YOLO lol" and resort to abusing volatile (and secretly hoping that no one will ever actually execute your code on a CPU with more than one core [1]), or
b) carefully construct synchronization routines in assembly and try to make sure that the single compiler you support doesn't screw you over in its effort to make your program run super-fast (and slightly wrong) [2], or
c) use a library which handles b) for you.
[1] FreeRTOS does this, and it only supports a single core.
[2] Linux did (does?) this.
- nyanpasu64 5y agoYikes, that is scary. Perhaps Go was more of a clear improvement than dealing with this "shitshow", and C++ has become more usable for concurrent/parallel code in the years since. I still find data races (sometimes crashes) in the wild on a regular basis. For example, RSS Guard accesses shared data unsynchronized when syncing settings from a server, so performing two types of syncs at once on 2 different threads will crash when they reallocate the same vector. Qt Creator intermittently crashes (or at least used to) in some tricky CMake handling code with multithreaded copy-on-write string lists. And I see apps now and then that perform unsynchronized writes to memory concurrently read in another thread, and it usually doesn't misbehave.