Hacker News Reader

Comment by Joker_vD | Hacker News Reader

groans See, and that's why I'm personally fine with [[indeterminate]], etc: all of this is already a finely-splitted hairy mess and I'd rather not see even more keywords introduced if we can just use attributes instead.

And yeah, it would probably be nice to also have some sane intrinsics to provide memory_order_consume semantics... but what can you do.

View on HN

Const, constexpr etc. Are mandatory to understand at this point. That situation doesn’t justify adding more things imo

Consume is dead. Long live acquire!

But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.

If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like

    ldr     x8, [x8]    # load a pointer from memory
    ldr     x1, 16[x8]  # load a field through that pointer

or turning the second load into "ldar" — there is quite a visible data dependency between two registers. But compilers usually puts a barrier there anyway.

I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.

As I understand it, it's the other way around: for x86 (which is TSO) the fence doesn't really matter because the "normal" load is already slowed down, but for ARM it does matter quite a bit, see e.g. [0] (admittedly old blog post) slightly lower on the page. But perhaps we did get to the point where even ARM CPUs and surrounding memory is already performant enough so that spurious fences aren't as noticeable.

[0] https://preshing.com/20140709/the-purpose-of-memory_order_co...

arm64 added a load acquire instruction which I think it is fast enough on actual hardware that might not be worth bothering with consume. If it isn't, then load-relaxed plus atomic_signal_fence might be your best bet. Good luck!

Reply on news.ycombinator.com