I would agree, but I'd add that it has been made a little bit easier to handle with the addition of `atomic` in C11 and C++11, since it means you can write atomic code without having to drop to inline assembly to ensure you use the right instructions to make it lock-free. That said, that's only one piece of the puzzle, and you really have to know what you're doing to ensure you write it correctly.
That said, after looking at this code the author appears to know what they're doing. I'd have to read it a lot closer to really make sure though.
True. In that event though, there's little other options. Locking those variables individually like that is probably worse then other locking options though, so it is worth keeping in mind. but while it would be slower, it would still be just as 'correct' as using actual atomic variables.
As far as atomic 'types' are concerned, they rely on CPU hardware for atomicity. I wouldn't be surprised if generated code for non-supported width is done using lock. http://en.cppreference.com/w/cpp/atomic/atomic
Don't get me wrong, I understand that atomic operations require CPU support. My point was that `atomic` allows you to get access to these operations in a more standard way for different platforms (And of course, it will fall back to generic locking in the event you use an unsupported width or operation - but that's arguably better then simply not working at all).
I've been to a C++11 presentation on multithreading recently, and x86 CPUs guarantee that all reads/writes on from std::atomic are indeed, atomic and they always happen in order they were called in. Code generated on ARM guarantees that even multi-byte reads/writes happen in one instruction, but there's no guarantee on the order.
> x86 CPUs guarantee that all reads/writes on from std::atomic are indeed, atomic
... for sizeof(T) <= 64 bits on amd64.
128 bit is technically supported (thanks to the availability DCAS) but stores and especially loads are significantly more expensive (as there are no native atomic 128 bit load and store), even in relaxed modes. Also, as even loads perform write cycles, they can't be used on read-only memory.
Anything larger uses, IIRC, a spinlock pool and is not lock-free.
That said, after looking at this code the author appears to know what they're doing. I'd have to read it a lot closer to really make sure though.