22

In the C++11 standard, section 1.10/5 mentions, but does not formally define the terms acquire operation, release operation, and consume operation. It then goes on in Section 29 to use these terms to describe the actions of certain memory orderings, atomic operations, and memory fences. For instance, 29.3/1 on "Order and Consistency" states:

memory_order_release, memory_order_acq_rel, and memory_order_seq_cst: a store operation performs a release operation [emphasis added] on the affected memory location.

This type of language is repeated throughout section 29, but it bothers me a bit that all meanings for the memory_order enumerations are based on operation types that themselves do not seem to be formalized by the standard, yet must have some commonly agreed-to meaning for them to be effective as definitions.

Put a different way, if I said "A bar is a flipped foo", the concrete meaning of bar and foo are ambiguous since neither term is formally defined. Only their relative natures are defined.

Does the C++11 standard, or some other C++11 standards committee document formally define what exactly an acquire operation, release operation, etc. is, or are these simply commonly understood terms? If the latter, is there a good reference that is considered an industry standard for the meaning of these operations? I specifically ask because hardware memory consistency models are not created equal, and therefore I'm figuring there must be some commonly agreed-to reference that allows those implementing compilers, etc. to properly translate the semantics of these operations into native assembly commands.

BeeOnRope
  • 60,350
  • 16
  • 207
  • 386
Jason
  • 31,834
  • 7
  • 59
  • 78
  • 1
    I agree with the OP. Whether the standard is logically decipherable is one question, but at any rate the standard is unusually confusing on this particular point. – thb Dec 28 '12 at 02:17
  • [Jeff Preshing's blog post about release/acquire](http://preshing.com/20120913/acquire-and-release-semantics/) defines them in terms of required ordering with respect to earlier/later loads/stores, in a way that's compatible with the C++11 semantics. I hadn't realized that C++11 didn't formally define them in terms like this. – Peter Cordes Feb 24 '16 at 01:36

4 Answers4

6

There's an informal summarized definition given in one of the notes:

performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A.

Besides that, the behavior of acquire and release operations is fully defined in 1.10, specifically in how they contribute to happens-before relationships. Any definition apart from behavior is useless.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • I guess it's the "informal summaries" that sort of bother me. For instance, if you attempt to map a release operation to hardware instructions for a given platform, you have to know what is and isn't permissible semantically, since the hardware may not provide some specific "release" operation. Since there isn't a one-to-one correspondence, a more formal meaning can help with accurate translations. That being said, I'll re-read section 1.10 and see if I can't make further sense of the bridge between the behavior you're describing, and the actual use of the operation terms themselves. – Jason May 10 '12 at 02:55
  • 1
    @Jason: The standard focuses on behavior. It doesn't try to define terms in isolation. – Ben Voigt May 10 '12 at 03:05
  • @Jason, It should be noted that even in Intel technical docs the memory order guarantees are also described somewhat as behavioural ordering guarantees. That is, memory ordering is a behaviour controlled by a series of instructions. How the C++ guaranteed orderings are achieved could be different from compiler to compiler for the same platform, and certainly will be for different hardware. – edA-qa mort-ora-y May 10 '12 at 08:30
  • It's not useless if you're trying to write something that uses a platform-specific feature (like [x86 cache-evicting/bypassing stores that are also weakly-ordered](http://stackoverflow.com/q/35516878/224132)), and interoperate with C++11 release/acquire semantics. i.e. you're rolling your own release-store, which needs to interoperate with the standard load-acquire for that platform. If different compilers (or different ABIs) for the same platform could potentially have different semantic requirements for a release-store, you need to handle that. – Peter Cordes Feb 24 '16 at 02:11
  • @PeterCordes: Writing something that uses a platform-specific feature is non-portable, by definition. The C++ Standard is platform agnostic -- it's never going to specify how these features interact with platform-local features. The toolchain documentation can specify that -- but that doesn't help give you compatibility between toolchains. If the platform is controlled by a single vendor (x86 isn't), they can specify it, but then you probably wouldn't be talking about multiple ABIs, because the platform vendor would specify that too. – Ben Voigt Feb 24 '16 at 02:31
  • 1
    @BenVoigt: **It's not useless or meaningless to talk about portability for code that uses *some* platform-specific features**. e.g. SSE/AVX intrinsics can give big speedups, and are portable across different compilers for Windows / Linux / Mac, unlike inline asm. If C++11 said something specific but generic, like that release-stores must not reorder with preceding loads/stores, then it would be easier to write something that was guaranteed to work on all x86. Instead, in theory you need to go and double check all the existing implementations, and even then your code isn't future-proof. – Peter Cordes Feb 24 '16 at 02:43
  • Now, in practice, I think it's safe to assume that every C++ implementation on x86 will use those semantics for release-stores, because x86 does that for free (every store is a release-store, except weakly-ordered MOVNT stores). It would just be nice if it was really guaranteed, rather than just guaranteed-for-Linux, guaranteed-for-Windows, and guaranteed-for-OSX. I see the advantage of having the standard leave it more open: e.g. a new type of HW that can support a conforming C++11 implementation. Or even whole-program optimization using weaker but sufficient hardware ordering. – Peter Cordes Feb 24 '16 at 02:54
  • @Peter: I wish x86 intrinsics were the same across compilers, but no, gcc calls it `__builtin_ctz` while Microsoft has `_BitScanForward`. Anyway, where the processor architecture is controlled by a single vendor (example: ARM), and chooses to document C and C++ bindings for the architecture, then you have a decent chance of code working across compilers. For x86, there's no single entity in control, both Intel and AMD routinely add instructions. And I don't think I've seen C or C++ bindings specified by either. – Ben Voigt Feb 24 '16 at 03:41
  • @BenVoigt: I only meant the intrinsics that Intel specifies for SSE/AVX instructions, which are pretty much portable. You're right that there aren't portable intrinsics for other essential functions like `bsf`. Intel's intrinsics guide [*does* list intrinsics for `bsf`](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=bsf), but none of those are supported by gcc, even with `#include ` :/ POSIX `ffs` [tends to compile to bsf/test/cmov, or tzcnt/cmov](http://goo.gl/xekYaC) :/ Anyway, this doesn't means we should give up on portability, IMO. – Peter Cordes Feb 24 '16 at 04:46
3

I don't see any formal definition of acquire/release semantics after a quick look through the standard, so my guess is that they are assumed to be commonly understood terms.

They can't define everything, after all.

It's not a definitive reference, but Raymond Chen has blogged about acquire/release semantics. His post includes a link to Microsoft's definition of acquire and release semantics, which you might also find useful.

Nate Kohl
  • 35,264
  • 10
  • 43
  • 55
3

actually these operations are defined in section 1.10/5-12.

release/acquire pair corresponds to the happen before relationship; while release/consume pair to the dependency-ordered before relationship.

user2k5
  • 827
  • 1
  • 7
  • 9
0

I also take acquire/release semantics to be fairly definitive on it's own; although they're more hardware specific terms historically rather than programming terms.

But, I think section 1.10 para 5 and 6 seem to match all acquire/release semantics definitions I've read in other language standards as well as CPU definitions.

Regardless, one of the major points of C++11 was to define a modern memory model to support concurrent and multi-threaded code. I find it hard to believe they didn't get it right :)

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98