C++11 原子：std::memory_order 代码是否可移植？

Question

In functions like std::atomic::compare_exchange , there's runtime parameters like std::memory_order_release , std::memory_order_relaxed . (http://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange )

I'm not sure is these memory order flags are guaranteed to exist in all kinds of CPU/architects, if some CPU don't support a flag, does this flag lead to crash or? Seems some of these flags are designed for intel Itanium, etc, not sure if std::memory_order related code is portable or not.

Would you give some suggestions?

Answer 1

In general, compilers are free to only provide the strongest memory guarantees regardless of what you ask for.

On some platforms, there are relaxed guarantees that are sufficient. Not all platforms support these relaxed guarantees. On those platforms, compilers must provide strictly stronger guarantees.

So they are portable, in that comforming compilers must provide that guarantee or better when you ask for a paticular guarantee.

Note that it isn't just the hardware that is of concern. Certain optimizations and reorderings may be legal or not depending on what memory order guarantee you ask for. I am unaware of any compiler that relies on that, but I am not a compiler expert.

Answer 2

The C++ standard does have the concept of so-called "freestanding" implementations, which can support a subset of the standard library. However, it also defines bare-minimum functionality that even a freestanding implementation must support. Within that list is the entirety of the <atomic> header.

So yes, implementations must support these.

However, that doesn't mean that a particular flag will do exactly and only what that flag describes. The flags represent the minimum memory barrier, the specific things that are guaranteed to be visible. The implementation could issue a full memory barrier even for flags that don't require it, if the hardware implementation doesn't have lower-tier memory barriers.

So you should write code against what the standard says, and let the compiler sort out the details. If it proves to be inefficient on a platform, you can inspect the assembly to see if you might be able to improve matters.

But to answer your main question, yes, atomic-based code is portable (modulo compiler bugs).

Answer 3

In practice, consume semantic is always strengthened to acquire by current compilers because it turned out to be very hard to implement safely without doing that. Either:

• the architecture provides acquire on all loads, and then load consume does the same thing as load acquire which does the same as load relaxed: nothing special (like x86);
• the architecture requires an acquire barrier even on dependent accesses (very very rare, maybe only DEC Alpha): then the compiler will use an acquire barrier on consume;

• The ISA guarantees dependency ordering for loads in asm, but full acquire needs a barrier. (This is what consume is trying to expose to the programmer). The compiler should provide you the benefit of avoiding the barrier with logical (not crazy) uses of consume

  • either the compiler tries to do that, but it's tricky and fails in some corner cases that the compiler back end optimizations break (the front end often does not communicate with its back end enough to avoid these just for consume);
  • or you don't trust the compiler, set optimization to zero, which doesn't even guarantee that no trivial optimization done implicitly by the back end will break consume (and make performance very bad);
  • or the compiler writers did not care about efficiency or knew they couldn't do a reliable job providing consume so they provide acquire instead, which is semantically correct but really less efficient, and not the intent of the standard.

(And C++'s consume semantic is crazy. It's one of the most inconsistent part of C++ which tells you a lot.)