39 ms·

I don't remember who said it. But some C++ Guru on some online talk (Herb Sutter, Pikus, etc etc.) was saying that 'consume' was pushed by ARM and PowerPC chipm

I don't remember who said it. But some C++ Guru on some online talk (Herb Sutter, Pikus, etc etc.) was saying that 'consume' was pushed by ARM and PowerPC chipmakers as sufficient for C++11. And these chipmakers were somewhat biased by how POWER7 and ARMv7 worked. Alas, it seems like consume was too complicated for compiler writers to take full advantage of. So in practice, acquire is used instead. And then in ARMv8 and POWER9, acquire was added to those instruction sets. Acquire isn't the default, but we do have accelerated assembly language support for the acquire model. So moving forward, acquire seems to be the sweetspot model. I guess consume exists for a hypothetical future C++ compiler that tries to optimize multithreaded ARMv7 or something, a relatively small niche in practice as current C++ compilers don't support consume and future processors have moved on to the acquire model.

gpderetta 3y ago
Yes, I believe that consume will be consigned to the annals of history. Acq/rel is such a sweet spot that in retrospect it should have been the default (for load and stores respectively) instead of seq_cst.
- tialaramex 3y ago
  All the (C++) defaults are wrong, of course. But in this case I believe the choice to have a default was itself the error. I have been persuaded that either you know which Ordering you need, and thus you should specify what you meant - or else you should not be using these APIs at all. If you aren't confident of the correct Ordering, you are not in fact confident your algorithm is correct, so don't do it.
  - gpderetta 3y ago
    You are not wrong; still an std::atomic variant that defaulted to mo_release on assignment, mo_acquire on load and mo_aq_rel on RMW would have covered 99% of my use cases. Then again, I usually target x86 where these defaults are optimal, in other architectures relaxing RMWs further has benefits.
- dragontamer 3y ago
  Seq_cst is still how programmers think how computers work before they study memory reorderings. Because that's how typical programmers think, it is the default. Relaxed, consume, and acquire are invented for the people who are trying to save those precious nanoseconds by cutting out a potential memory barrier from the resulting code. In the pre-C++11 days, I would just shove full barriers everywhere in my code defensively, cause I didn't really understand memory models. Seq_cst is basically that behavior (a full memory barrier between important operations) which is always correct but maybe a bit slow.
  - kccqzy 3y ago
    Using seq_cst everywhere is probably so slow that you'd be better off not using atomics at all; just use a mutex library that internally uses acquire/release to protect regular non-atomic variables.
    - dragontamer 3y ago
      Its a bad idea to use a mutex inside of interrupt code. seq_cst / atomics / barriers are for writing lock-free code, which is fully compatible with interrupts and other system-call level details. Its about correctness, not about speed. -------- I had a discussion elsewhere where people seem to think that these constructs are for speed. They... really aren't. Atomics are about lock-free code, and lock-free code might be slower than locked-code/mutex code. Lock-free code is about forward progress in all conditions. Sometimes its faster, but its an independent axis as far as software design is concerned. I guess acquire is faster than seq_cst, and consume/relaxed would be even faster than acquire. But correctness comes first, and proving correctness in consume-style code is seemingly too difficult in practice. So acquire is where the sweet spot seems to be... at least with today's tech and understanding of multithreaded issues.
      - gpderetta 3y ago
        The thing is, seq-cst does not guarantee correctness, far from it. And you write down a proof, using the happen-before rules, the acquire/release edges are fairly obvious. So I don't think seq-cst buys you a significant amount of safety.

gpderetta 3y ago

Yes, I believe that consume will be consigned to the annals of history. Acq/rel is such a sweet spot that in retrospect it should have been the default (for load and stores respectively) instead of seq_cst.

tialaramex 3y ago
All the (C++) defaults are wrong, of course. But in this case I believe the choice to have a default was itself the error. I have been persuaded that either you know which Ordering you need, and thus you should specify what you meant - or else you should not be using these APIs at all. If you aren't confident of the correct Ordering, you are not in fact confident your algorithm is correct, so don't do it.
- gpderetta 3y ago
  You are not wrong; still an std::atomic variant that defaulted to mo_release on assignment, mo_acquire on load and mo_aq_rel on RMW would have covered 99% of my use cases. Then again, I usually target x86 where these defaults are optimal, in other architectures relaxing RMWs further has benefits.
dragontamer 3y ago
Seq_cst is still how programmers think how computers work before they study memory reorderings. Because that's how typical programmers think, it is the default. Relaxed, consume, and acquire are invented for the people who are trying to save those precious nanoseconds by cutting out a potential memory barrier from the resulting code. In the pre-C++11 days, I would just shove full barriers everywhere in my code defensively, cause I didn't really understand memory models. Seq_cst is basically that behavior (a full memory barrier between important operations) which is always correct but maybe a bit slow.
- kccqzy 3y ago
  Using seq_cst everywhere is probably so slow that you'd be better off not using atomics at all; just use a mutex library that internally uses acquire/release to protect regular non-atomic variables.
  - dragontamer 3y ago
    Its a bad idea to use a mutex inside of interrupt code. seq_cst / atomics / barriers are for writing lock-free code, which is fully compatible with interrupts and other system-call level details. Its about correctness, not about speed. -------- I had a discussion elsewhere where people seem to think that these constructs are for speed. They... really aren't. Atomics are about lock-free code, and lock-free code might be slower than locked-code/mutex code. Lock-free code is about forward progress in all conditions. Sometimes its faster, but its an independent axis as far as software design is concerned. I guess acquire is faster than seq_cst, and consume/relaxed would be even faster than acquire. But correctness comes first, and proving correctness in consume-style code is seemingly too difficult in practice. So acquire is where the sweet spot seems to be... at least with today's tech and understanding of multithreaded issues.
    - gpderetta 3y ago
      The thing is, seq-cst does not guarantee correctness, far from it. And you write down a proof, using the happen-before rules, the acquire/release edges are fairly obvious. So I don't think seq-cst buys you a significant amount of safety.