4 ms·
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
by Joker_vD 7mo ago
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.
- jcalvinowens 7mo agoI'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.
- Joker_vD 7mo agoAs 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_consume-in-cpp11/#the-value-of-consume-semantics https://preshing.com/20140709/the-purpose-of-memory_order_co...
- gpderetta 7mo agoarm64 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!