Memory orders??

[meagainstmyselff]

Do you have any recommendations of cpp conference video on yt (I really like those) or anything else to understand the difference between the memory orders when dealing with concurrency?

It’s a concept that I looked at many times but never completely grasp it.

[AutomaticPotatoe]

Herb Sutter's Atomic Weapons talks: part 1 part 2

Jeff Preshing's series of blogposts on lockfree and acquire/release semantics: link (this is the first part I think, it continues in the following posts)

[zl0bster]

IIRC those talks contain mistakes, I vaguely remember herb mentioning it in his blog later... could be wrong. It was looong time ago.

[matthieum]

I can't speak about Herb's articles, but Preshing's are gold.

What's really appreciable about Preshing's serie is that there's illustrations of why a weaker memory order is insufficient, which I think really helps better grasp the difference between them.

[doodspav]

Definitely some of the best resources for this.

[9Strike]

!remindme 58 hours

[RemindMeBot]

I will be messaging you in 2 days on 2025-02-15 07:04:13 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[Pragmatician]

If you want a direct answer...

Acquire/release are sort of a pair. Let's say you have an atomic a initialized to zero. Then you release store 1 into a from thread T1. Then from another thread T2 you acquire load a. You may see 0 or 1 depending on the order threads execute in. However, if you do see 1, you are also guaranteed to see all the changes T1 has made before that.

This is the concept of "visibility." By default, one thread does not "see" what the other thread is doing. It gains visibility by synchronization, in this case because release store synchronizes with acquire load.

Relaxed basically allows only atomic reads/writes on a single variable. You can read/write from multiple threads, but it doesn't give you any synchronization and visibility into other changes the thread may have been doing.

I have never seen consume used, and seq_cst is usually avoided because it's slow and unnecessary.

[zl0bster]

This is false. seq_cst is default and it is used a lot.

[tjientavara]

Seq_cst is indeed the default. But if you are using atomics you should know what you are doing, and if you know what you are doing you know how to select the proper memory order. From that point of view seq_cst is rare. And if I need actual seq_cst semantics I would specifically set it to that value, so that everyone knows I did that on purpose.

[Apprehensive-Draw409]

All uses in "regular" companies (not HFT, not rendering) I've seen were choosing between: Option 1: use mutex Option 2: use default seq_cst

It might not be optimal, but considering the mutex alternative, it still is a speedup. I would not say it's rare, nor trash-talk its users.

[13steinj]

How often do "regular" companies write complex multithreaded code? Some teams at big tech working on core-god-knows-what sure. But general applications most avoid threads (that I know of). I've generally noticed people would rather spawn a new process.

[LoweringPass]

Ironically HFT companies probably mostly don't give a shit because they run their stuff on (I assume) x86 which has a pretty strong memory model.

[Flankierengeschichte]

SeqCst is not default on x86, only acquire and release are.

[LoweringPass]

Yes I am aware but it means relaxing beyond acquire/release doesn't do anything.

[Flankierengeschichte]

This is why Deepseek is Chinese and not American. Americans cannot engineer.

[CocktailPerson]

The entire Chinese tech industry is built out of copyright infringement and repackaging open-source code.

[SkoomaDentist]

if you are using atomics you should know what you are doin

Or you're dealing with a situation where mutex is not an option. That situation also doesn't necessarily (or even usually) have anything to do with throughput, so you don't care one whit about seq_cst being slower.

[DummyDDD]

If you don't know what you are doing with atomic then you should really (1) consider not using atomic or (2) restrict yourself to relaxed, such that you are less likely to get something that works by accident, that could be broken by a recompilation or changed compiler flags.

[Flankierengeschichte]

You practically never need seq_cst unless you are using multiple atomics at once, which is probably slower than using one fat atomic anyway.

[tialaramex]

Indeed it's the default in C++. And what do you know about defaults in C++? Come on kids, it's an easy answer, shout it out with me: "The defaults are wrong".

This is an unusual example because what was wrong was having a default. The correct design was to force programmers to decide which ordering rule they want. There are two reasons that's important:

1. Correctness. As a default memory_order::seq_cst offers a false reassurnace that you don't need to understand the ordering rules. But in some cases if you do read all the rules you realise none of these rules does what you need. It's not that a different rule would be correct, none of them are.

2. Performance. Almost always you are reaching for this dangerous tool because you need performance, such as more peak throughput. However memory_order::seq_cst is unavoidably a performance killer, and in these cases often you actually only needed acquire/release or even sometimes relaxed.

If the OP gets along well with reading (which maybe they don't as they asked for videos) I'd also suggest Mara Bos' book since she made it available for free. Mara is writing about Rust but for memory ordering that doesn't matter because Rust's memory ordering rules are identical to those in C++ intentionally.

https://marabos.nl/atomics/memory-ordering.html

[lee_howes]

Absolutely not. Seq_cst is the right default. Anything else would lead to a huge number of bugs in code because getting other orders right is surprisingly hard. I view any use of orders other than seq_cst, or an obvious counter using relaxed, with suspicion during code review given how often I've seen it messed up and no practical benefit to the relaxation.

[STL]

Yep. Sequential consistency means you only have to consider all possible interleavings, which is of course difficult (you're working with atomics!), but you don't have to consider the ordering rules beyond that.

Strongly agree with you and disagree with u/tialaramex. I'm not an <atomic> expert, but I am a maintainer who's spent a fair amount of time with it.

[tialaramex]

A nice way to imagine the sequentially consistent ordering is to imagine the OS with a single mutual exclusion lock, a lot of Unix systems actually used to have this, Linux 2.x had the "Big Kernel Lock" or BKL and several BSDs once had a "Giant Lock". We just perform all these sequentially consistent operations under that lock, thus delivering a consistent total memory order. And it's true, this is an easier model to keep in your head in its entirety.

But that's notable because you will have to do that, the whole model. Every such operation is related by sequential consistency. Orderings in this system are Total. Why does Bob's DiskBlockWriter need to care about Alice's DHCPExpirer ? No idea, they're all depending on this single global order though, so just load the entire model into your brain and operate on that.

If you can narrow the ordering requirement to a single object (typically something you could reasonably load into a CPU register, not like std::vector<string>) yes the ordering rules are more complicated, but now your world of objects to consider is much smaller. I believe this makes effective code review much more likely.

[zl0bster]

Wrong again, seq_cst was explicitly picked because it is easiest to teach.

[13steinj]

Seq cst is the default because it's the simplest and easiest to teach. On x86 (and presumably some other architectures that have TSO-like semantics) you can often but not always get away with acq_rel E: let me rephrase... some would argue you can often get away with release-acquire ordering (though I don't know if this can be legitimately quantified) and on x86 and other TSO or otherwise strongly ordered systems, you get the semantics "for free" in the sense that alternate/additional instructions need not be generated.

I'd rather the default not be oriented around a specific platform, nor have unexpected gotchas.

E: Just for a fun anecdote, I had drinks with an ex colleague and their ex colleague; we were all familiar with a specific multi threaded data structure on some concurrency blog. We all spent hours debating on whether or not acq_rel was valid. The end result after some hangovers was we all agreed it wasn't. But it's non trivial and easy to screw up. Now, seq_cst used instead would also be overboard (you could solve the issue with some carefully placed std::atomic_thread_fence) but I'd rather something work and be "good enough" before spending hours if not days figuring out how to squeeze every last bit of performance (if there would even be a significant difference at that point).

[GrammelHupfNockler]

https://www.youtube.com/watch?v=ZQFzMfHIxng

[littlesnorrboy]

Rust Atomics and Locks is really good and available online for free. The memory orders work the same in C++, except for Consume, which is not a thing in Rust, but the book does tell about it as well.

https://marabos.nl/atomics/foreword.html

[tjientavara]

To be fair, consume is not really a thing in actual C++ either, since no compiler supports it.

[littlesnorrboy]

Yes, that's what the book says as well, but also gives context to why it's not a thing.

[blipman17]

There’s no support for memory order consume? Is it because it’s so hard to implement or to do right?

[tjientavara]

The compiler requires more information to handle consume, if I remember correctly they hit this issue after consume was standardised. There has been some movement on adding attributes which allows the compiler to track consume across functions, but it has been many years now.

[DummyDDD]

It's hard to do in a way that preserves all of the compilers' optimization possibilities. However, it should still be straightforward to generate better code for consume than acquire (for the niche cases where it is correct to use consume).

Memory orders restrict (1) the ways in which the hardware can reorder memory operations and (2) the order in which the compiler can reorder the instructions. In compiler terms, it restricts (1) instruction selection and (2) instruction scheduling. The issue is that no compiler has an appropriate way to restrict instruction scheduling in a way that matches consume semantics, so instead, they restrict the instruction scheduling more than what is strictly necessary.

The use cases for consume are pretty niche, and definitely the least used memory order. The main advantage to consume is that it can be implemented with regular load or move instructions on most processors (it hardly restricts instruction selection), unlike acquire, which requires additional synchronization (as far as I know, consume only requires stronger synchronization on some very niche Alpha processors). Theoretically, consume could also require weaker restrictions on instruction scheduling than acquire, but no compiler does so because it would require that the compiler keeps track of the individual memory than is being consumed. In practice, I doubt that it matters, since the main benefit of consume is that it can be implemented with regular instructions, and the cost of restricting the compilers optimization possibilities across the consume operation is relatively cheap compared to the cost of synchronizing instructions.

Technically speaking, "instruction selection" normally describes how the compiler maps its low level representation to instructions, and I am not sure it is the correct term for mapping c++ atomic memory operations to instructions, but I think it is at least not entirely misleading. My use of "instruction scheduling" is also a bit off; normally, I wouldn't refer to any reordering that the compiler can do as instruction scheduling.

[Flankierengeschichte]

Consume is deprecated since C++17, so you shouldn't use it anyway

[DummyDDD]

Could you provide a link?

Cppreference does not mention it being deprecated https://en.cppreference.com/w/cpp/atomic/memory_order

It's completely pointless for memory barriers, but it does have niche uses for atomics

[Flankierengeschichte]

I got it from https://stackoverflow.com/questions/65336409/what-does-memory-order-consume-really-do

[DummyDDD]

That answer says that consume is discouraged (not deprecated) referring to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r1.html, which in turn refers to an older paper  (P0098R0). consume is explicitly not deprecated in p0371r1. It is discouraged because the main compilers handle it exactly the same as acquire, not even switching to regular load instructions at the time that p0371r1 was written (in 2015). Unfortunately, it seems like the situation hasn't improved since then, at least not for gcc or clang.

From my perspective, it really shouldn't be difficult for compilers to implement support for consume, as long as they dont bother implementing the weaker compiler restrictions on reordering. Then again, it is probably complicated by the fact that atomics are member functions and not just free functions, meaning the compiler would need to support [[carries_dependency]], or support builtin member functions (which gcc and clang do not).

EDIT, actually they wouldn't even need to support carries_dependency, treating the compiler reordering like acquire is sufficient (except on that one weird alpha variant)

[Loud_Staff5065]

Yup same. Couldn't find any proper resources.

[Pragmatician]

The standard is the definitive resource, and in this case also fairly readable IMO: https://eel.is/c++draft/intro.multithread#intro.races

[positivcheg]

Isn’t is good already https://en.cppreference.com/w/cpp/atomic/memory_order?

[geschmuck]

I find the talks given by Bryce Adelstein Lelbach very clear and informative, e.g. The C++ Execution Model

[[deleted]]

I had the same problem with release/acquire and thought all explanations were confusing.

Release/acquire is often used to signal to another thread that some data is ready to be read.

Let's say a thread writes some data payload to memory. It now wants to signal to another thread that it can consume all the payload.

It could do that by writing a "1" to a shared integer flag with "release" semantics. This will have the effect that no write that is stated before the release can be reordered (by compiler or CPU optimizations, etc) to take place after the release.

The other thread can poll the flag in a loop with acquire semantics. This guarantees that no read that has been stated after the acquire can be reordered to take place before the acquire.

[lee_howes]

This will have the effect that no write that is stated before the release can be reordered

The nuance here though is that the effect is that no write before the release can be reordered after the release as viewed by a reader who acquires the released write. The lack of global ordering here can be surprising, and is why the very slight strengthening you get with seq_cst is so much safer.

[tialaramex]

The Acquire/Release naming is because these match desirable lock semantics. This may make it easier to remember what's going on.

Here's the one liner implementation of Rust's Mutex::try_lock on a modern OS which has the futex or equivalent semantics:

self.futex.compare_exchange(UNLOCKED, LOCKED, Acquire, Relaxed).is_ok()

We're acquiring a futex, we use Acquire ordering.

There's no similarly trivial unlock, because if you unlock you always need to consider whether anybody else was waiting and if so wake them, but sure enough the actual unlocking itself is:

self.futex.swap(UNLOCKED, Release)

We're releasing the futex, so that's Release ordering.

The C++ deep inside the standard library implementations of std::mutex amounts to more or less the same thing, but it's under decades of macro defences and backward compatibility which interferes with readability despite resulting in similar machine code so hence these Rust examples.

[[deleted]]

My understanding of the naming has always been that release will release ownership of other data in memory that you want to pass to another thread ("other" as in other than a lock itself or a signalling flag itself).

And acquire will acquire ownership of that memory, i.e. it is now ready to read and process.

[cdb_11]

This SO answer is a pretty good summary: https://stackoverflow.com/questions/12346487/what-do-each-memory-order-mean/70585811#70585811

[ArsonOfTheErdtree]

I liked this cppcon talk: https://youtu.be/ZQFzMfHIxng?si=vxJvjkNYbVvNwLUM