4 ms·
> I'd also learn about atomic operations, atomic cas, and memory barriers, but short of some very specific game libraries with weird macros for this, I couldn't
by exDM69 9y ago
> I'd also learn about atomic operations, atomic cas, and memory barriers, but short of some very specific game libraries with weird macros for this, I couldn't find them anywhere.
How come? These days atomic ops are included in C and C++ standard library. And there are atomic operations for every important compiler out there and if you need portability across compilers (without relying on new C/C++ standards), there are portability libraries (e.g. boost).
These have existed for a long time
E.g. here are GCC's atomics:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins...
> It seemed like we were expected to sprinkle volatile everywhere, remember rules about unaligned access, and write our own platform specific macros for memory barriers.
Unless you're using Java, "volatile" is not useful for concurrent programming. When you see volatile keyword in C code, it's almost always wrong or there for a legacy reason.
Sounds like your computer architecture classes were not up to date or very well taught.
- ohazi 9y ago> Sounds like your computer architecture classes were not up to date or very well taught. Or maybe I went to school before C++11 was around. ¯\_(ツ)_/¯
- exDM69 9y agoThere are many atomics libs and compilers that support atomics that predate C++11. If you went to school in the multi-core era or slightly before that it shouldn't have been a problem. There isn't much need for atomics on single core, single CPU machines so if you went before that, it's understandable.