3 ms·

I have always found that the biggest hurdle in understanding concurrency amongst my peers is learning how memory barriers work.

gpderetta 9y ago
Although I did understand memory barriers early while playing with lock free concurrency, I didn't really grok them until much later. I had initially a very hard time, while thinking in term of reordering, in figuring out which barrier goes where. But the C++ memory model (and the acquire/release consistency model in general), which does away with explicit barriers but attach synchronization behaviour to store->load edges [1], instead clicked almost immediately and in retrospect made it easier for me to describe an algorithm in the more informal reordering based model. [1] barriers are available, but are discouraged and are still defined in term of acquire/release and sequential consistency.
ohazi 9y ago
One reason for this is that for the longest time they weren't really available in a cross platform way. I'd learn about e.g. mutexes in a computer architecture class, and then I could immediately go use them with boost or pthread or whatever. 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. 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. If you're primarily testing your code on an x86 laptop, it's very difficult to be confident that you're doing it correctly.
- 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 ago
      There 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.

gpderetta 9y ago

Although I did understand memory barriers early while playing with lock free concurrency, I didn't really grok them until much later. I had initially a very hard time, while thinking in term of reordering, in figuring out which barrier goes where. But the C++ memory model (and the acquire/release consistency model in general), which does away with explicit barriers but attach synchronization behaviour to store->load edges [1], instead clicked almost immediately and in retrospect made it easier for me to describe an algorithm in the more informal reordering based model. [1] barriers are available, but are discouraged and are still defined in term of acquire/release and sequential consistency.

ohazi 9y ago

One reason for this is that for the longest time they weren't really available in a cross platform way. I'd learn about e.g. mutexes in a computer architecture class, and then I could immediately go use them with boost or pthread or whatever. 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. 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. If you're primarily testing your code on an x86 laptop, it's very difficult to be confident that you're doing it correctly.

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 ago
    There 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.