C11中的内存顺序消耗用法

脚注2 :x86对所有加载进行排序，无论它们是否对指针携带数据依赖项，因此它都不需要保留"false"依赖项，并且具有可变长度的指令集实际上将代码大小保存为xor eax,eax(2个字节)，而不是mov eax,0(5个字节).因此xor reg,reg自8086年初开始成为标准的习惯用法，现在它像mov一样被识别和处理，而不再依赖于旧值或RAX. (实际上，除代码大小之外，比mov reg,0更有效: x86组件中的寄存器设置为零的最佳方法是:xor，mov或and? a>)但是对于ARM或大多数其他顺序较弱的ISA来说，这是不可能的，就像我说过的那样，实际上是不允许他们这样做的. ldr r3, [something] ; load r3 = memeor r0, r3,r3 ; r0 = r3^r3 = 0ldr r4, [r1, r0] ; load r4 = mem[r1+r0]. Ordered after the other load即使加载地址r1+r0始终只是r1，因为r3^r3 = 0，但仍需要注入对r0的依赖关系并在r3加载之后对r4的加载进行排序. 但仅加载 ，而不加载其他所有后续加载；它不是获取障碍或获取负载. I read about the carries a dependency relation and dependency-ordered before that uses one in its definition 5.1.2.4(p16):So I tried to craft an example where it might be useful. Here is it:static _Atomic int i;void *produce(void *ptr){ int int_value = *((int *) ptr); atomic_store_explicit(&i, int_value, memory_order_release); return NULL;}void *consume(void *ignored){ int int_value = atomic_load_explicit(&i, memory_order_consume); int new_int_value = int_value + 42; printf("Consumed = %d\n", new_int_value);}int main(int args, const char *argv[]){ int int_value = 123123; pthread_t t2; pthread_create(&t2, NULL, &produce, &int_value); pthread_t t1; pthread_create(&t1, NULL, &consume, NULL); sleep(1000);}In the function void *consume(void*) the int_value carries a dependency for new_int_value so if atomic_load_explicit(&i, memory_order_consume); reads a value written by some atomic_store_explicit(&i, int_value, memory_order_release); then new_int_value computation dependency-ordered-before the atomic_store_explicit(&i, int_value, memory_order_release);.But what useful things can the dependency-ordered-before give us?I currently think that the memory_order_consume may well be replaced with memory_order_acquire without causing any data race... 解决方案 consume is cheaper than acquire. All CPUs (except DEC Alpha AXP's famously weak memory model) do it for free, unlike acquire. (Except on x86 and SPARC-TSO, where the hardware has acq/rel memory ordering without extra barriers or special instructions.)On ARM/AArch64/PowerPC/MIPS/etc weakly-ordered ISAs, consume and relaxed are the only orderings that don't require any extra barriers, just ordinary cheap load instructions. i.e. all asm load instructions are (at least) consume loads, except on Alpha. acquire requires LoadStore and LoadLoad ordering, which is a cheaper barrier instruction than a full-barrier for seq_cst, but still more expensive than nothing.mo_consume is like acquire only for loads with a data dependency on the consume load. e.g. float *array = atomic_ld(&shared, mo_consume);, then access to any array[i] is safe if the producer stored the buffer and then used a mo_release store to write the pointer to the shared variable. But independent loads/stores don't have to wait for the consume load to complete, and can happen before it even if they appear later in program order. So consume only orders the bare minimum, not affecting other loads or stores.(It's basically free to implement support for consume semantics in hardware for most CPU designs, because OoO exec can't break true dependencies, and a load has a data dependency on the pointer, so loading a pointer and then dereferencing it inherently orders those 2 loads just by the nature of causality. Unless CPUs do value-prediction or something crazy. Value prediction is like branch prediction, but guess what value is going to be loaded instead of which way a branch is going to go.Alpha had to do some crazy stuff to make CPUs that could actually load data from before the pointer value was truly loaded, when the stores were done in order with sufficient barriers.Unlike for stores, where the store buffer can introduce reordering between store execution and commit to L1d cache, loads become "visible" by taking data from L1d cache when they execute, not when the retire + eventually commit. So ordering 2 loads wrt. each other really does just mean executing those 2 loads in order. With a data dependency of one on the other, causality requires that on CPUs without value prediction, and on most architectures the ISA rules do specifically require that. So you don't have to use a barrier between loading + using a pointer in asm, e.g. for traversing a linked list.)See also Dependent loads reordering in CPUBut current compilers just give up and strengthen consume to acquire... instead of trying to map C dependencies to asm data dependencies (without accidentally breaking having only a control dependency that branch prediction + speculative execution could bypass). Apparently it's a hard problem for compilers to keep track of it and make it safe.It's non-trivial to map C to asm, because if the dependency is only in the form of a conditional branch, the asm rules don't apply. So it's hard to define C rules for mo_consume propagating dependencies only in ways that line up with what does "carry a dependency" in terms of asm ISA rules.So yes, you're correct that consume can be safely replaced with acquire, but you're totally missing the point.ISAs with weak memory-ordering rules do have rules about which instructions carry a dependency. So even an instruction like ARM eor r0,r0 which unconditionally zeroes r0 is architecturally required to still carry a data dependency on the old value, unlike x86 where the xor eax,eax idiom is specially recognized as dependency-breaking.See also http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/I also mentioned mo_consume in an answer on Atomic operations, std::atomic<> and ordering of writes.Footnote 1: The few Alpha models that actually could in theory "violate causality" didn't do value-prediction, there was a different mechanism with their banked cache. I think I've seen a more detailed explanation of how it was possible, but Linus's comments about how rare it actually was are interesting.Linus Torvalds (Linux lead developer), in a RealWorldTech forum threadI never saw it myself, and I don't think any of the models I ever had access to actually did it. Which actually made the (slow) RMB instruction extra annoying, because it was just pure downside. Even on CPU's that actually could re-order the loads, it was apparently basically impossible to hit in practice. Which is actually pretty nasty. It result in "oops, I forgot a barrier, but everything worked fine for a decade, with three odd reports of 'that can't happen' bugs from the field" kinds of things. Figuring out what's going on is just painful as hell.I think it was the 21264, and I have this dim memory of it being due to a partitioned cache: even if the originating CPU did two writes in order (with a wmb in between), the reading CPU might end up having the first write delayed (because the cache partition that it went into was busy with other updates), and would read the second write first. If that second write was the address to the first one, it could then follow that pointer, and without a read barrier to synchronize the cache partitions, it could see the old stale value. But note the "dim memory". I may have confused it with something else. I haven't actually used an alpha in closer to two decades by now. You can get very similar effects from value prediction, but I don't think any alpha microarchitecture ever did that. Anyway, there definitely were versions of the alpha that could do this, and it wasn't just purely theoretical.(RMB = Read Memory Barrier asm instruction, and/or the name of Linux kernel function rmb() that wraps whatever inline asm is necessary to make that happen. e.g. on x86, just a barrier to compile-time reordering, asm("":::"memory"). I think modern Linux manages to avoid an acquire barrier when only a data dependency is needed, unlike C11/C++11, but I forget. Linux is only portable to a few compilers, and those compilers do take care to support what Linux depends on, so they have an easier time than the ISO C11 standard in cooking up something that works in practice on real ISAs.)See also https://lkml.org/lkml/2012/2/1/521 re: Linux's smp_read_barrier_depends() which is necessary in Linux only because of Alpha. (But a reply from Hans Boehm points out that "compilers can, and sometimes do, remove dependencies", which is why C11 memory_order_consume support needs to be so elaborate to avoid risk of breakage. Thus smp_read_barrier_depends is potentially brittle.)Footnote 2: x86 orders all loads whether they carry a data dependency on the pointer or not, so it doesn't need to preserve "false" dependencies, and with a variable-length instruction set it actually saves code size to xor eax,eax (2 bytes) instead mov eax,0 (5 bytes).So xor reg,reg became the standard idiom since early 8086 days, and now it's recognized and actually handled like mov, with no dependency on the old value or RAX. (And in fact more efficiently than mov reg,0 beyond just code-size: What is the best way to set a register to zero in x86 assembly: xor, mov or and?)But this is impossible for ARM or most other weakly ordered ISAs, like I said they're literally not allowed to do this. ldr r3, [something] ; load r3 = memeor r0, r3,r3 ; r0 = r3^r3 = 0ldr r4, [r1, r0] ; load r4 = mem[r1+r0]. Ordered after the other loadis required to inject a dependency on r0 and order the load of r4 after the load of r3, even though the load address r1+r0 is always just r1 because r3^r3 = 0. But only that load, not all other later loads; it's not an acquire barrier or an acquire load. 这篇关于C11中的内存顺序消耗用法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！