gpt4 book ai didi

c - C11中的内存顺序消耗用法

转载 作者:行者123 更新时间:2023-12-03 12:44:26 25 4
gpt4 key购买 nike

我读过关于载具的依赖关系,并且在其定义5.1.2.4(p16)中使用一个依赖关系之前对其进行了依赖排序:

An evaluation A is dependency-ordered before an evaluation B if:

A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or

— for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.



因此,我尝试制作一个可能有用的示例。就这个:
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);
}

void *consume(void*)函数中, int_value带有 new_int_value的依赖项,因此,如果 atomic_load_explicit(&i, memory_order_consume);读取某个 atomic_store_explicit(&i, int_value, memory_order_release);写入的值,则 new_int_value的计算依赖项应在 atomic_store_explicit(&i, int_value, memory_order_release);之前进行排序。

但是,依赖顺序之前可以给我们带来什么有用的东西呢?

我目前认为 memory_order_consume很可能会被 memory_order_acquire取代而不会引起任何数据争用...

最佳答案

consumeacquire便宜。与acquire不同,所有CPU(DEC Alpha AXP著名的弱内存模型1除外)都是免费的。 (x86和SPARC-TSO除外,这些硬件具有acq/rel存储器顺序,没有额外的障碍或特殊说明。)

在ARM/AArch64/PowerPC/MIPS/等弱排序的ISA上,consumerelaxed是唯一不需要任何额外障碍的命令,仅需普通的廉价加载指令即可。也就是说,除了在Alpha上,所有的asm加载指令(至少)都是consume加载。 acquire需要LoadStore和LoadLoad排序,这是比seq_cst的全屏障便宜的屏障指令,但总比没有便宜。

mo_consume类似于acquire,仅适用于数据与消耗负载相关的负载。例如float *array = atomic_ld(&shared, mo_consume);,如果生产者存储了缓冲区然后使用array[i]存储将指针写入共享变量,则访问任何mo_release是安全的。但是,独立的加载/存储不必等待consume加载完成,并且即使它们在程序顺序中稍后出现,也可以在加载之前发生。因此,consume仅排序最低要求,而不影响其他负载或存储。

(对于大多数CPU设计,基本上都可以在硬件中免费实现对consume语义的支持,因为OoO exec不能破坏真正的依赖项,并且加载对指针具有数据依赖关系,因此加载指针然后再对其固有地取消引用这2个负载只是因果关系的性质,除非CPU做值预测或疯狂的事情。
值预测类似于分支预测,但是猜测将要加载什么值,而不是分支将采用哪种方式。

Alpha必须做一些疯狂的事情,使CPU可以真正地从指针值真正加载之前的时间开始加载数据,而此时存储是在有足够的障碍的情况下完成的。

与商店不同,商店缓冲区可以在商店执行和提交到L1d缓存loads become "visible" by taking data from L1d cache when they execute之间引入重新排序,而不是在退休+最终提交时引入。因此订购2个负载wrt。彼此之间的确只意味着按顺序执行这两个加载。由于数据相互依赖,因果关系要求在没有值预测的CPU上进行,而在大多数体系结构上,ISA规则确实要求这样做。 因此,您不必在加载和使用asm中的指针之间使用障碍,例如用于遍历链接列表。 )

另请参见Dependent loads reordering in CPU

,但是当前的编译器只是放弃并将consume增强为acquire

...而不是尝试将C依赖关系映射到asm数据依赖关系(不会意外中断,只有分支预测+投机执行可以绕过的控制依赖关系)。显然,对于编译器而言,跟踪它并使之安全是一个难题。

将C映射到asm并非易事,因为如果依赖性仅是条件分支的形式,则asm规则将不适用。因此,仅通过与符合asm ISA规则的“携带依赖项”相一致的方式,很难为mo_consume传播依赖项定义C规则。

因此,是的,您正确地认为consume可以安全地替换为acquire,但是您完全没有注意这一点。

内存排序规则较弱的ISA确实有关于哪些指令带有依赖性的规则。因此,即使在架构上也需要像ARM eor r0,r0这样无条件置零r0的指令来仍然携带对旧值的数据依赖性,这与x86不同,在x86中xor eax,eax惯用法被专门识别为dependency-breaking2。

另请参阅http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/

我在Atomic operations, std::atomic<> and ordering of writes的答案中也提到了mo_consume

脚注1 :少数在理论上实际上可以“违反因果关系”的Alpha模型没有进行值(value)预测,它们的存储缓存机制不同。我想我已经看到了关于如何实现的更详细的解释,但是Linus关于它实际上是多么稀有的评论很有趣。

Linus Torvalds (Linux lead developer), in a RealWorldTech forum thread

I wonder, did you see non-causality on Alpha by yourself or just in the manual?



我自己从未见过,而且我认为我从未有过任何模型
访问实际上做到了。实际赚了(慢)人民币
指令特别烦人,因为这只是纯粹的缺点。

即使在实际上可以重新排序负载的CPU上,
显然在实践中根本无法实现。实际上是哪个
真讨厌结果是“糟糕,我忘记了障碍,但是一切
工作十年很好,有三个奇怪的报告说“不能
发生“来自现场的错误”之类的事情。弄清楚是什么
继续下去真是痛苦不堪。

Which models actually had it? And how exactly they got here?



我认为那是21264,我对它的内存有些暗淡
到分区缓存:即使原始CPU进行了两次写入
顺序(中间有wmb),则读取CPU可能最终会
第一次写入延迟(因为它进入的缓存分区是
忙于其他更新),并且会先读取第二个写入内容。如果
第二个写是第一个写的地址,然后它可以
跟随该指针,并且没有读取障碍来同步
缓存分区,它可能会看到旧的过时的值。

但是请注意“暗淡的内存”。我可能已经将它与其他东西混淆了。
到目前为止,我已经有近二十年没有实际使用过alpha了。你
可以从值(value)预测中获得非常相似的效果,但是我不认为
任何alpha微架构都可以做到这一点。

无论如何,肯定有可以做的Alpha版本
这,而不仅仅是纯粹的理论上。

(RMB =读取内存屏障asm指令,和/或Linux内核函数 rmb()的名称,该名称包装了实现该功能所需的任何内联asm。例如,在x86上,这只是编译时重新排序的障碍 asm("":::"memory")。我认为现代Linux与C11/C++ 11不同,设法在仅需要数据依赖项时避免了获取障碍,但我忘了,Linux仅可移植到少数几个编译器中,并且那些编译器确实会支持Linux所依赖的内容,因此它们比ISO C11标准更轻松地整理出可以在实际ISA上实际使用的内容。)

另请参见 https://lkml.org/lkml/2012/2/1/521:Linux的 smp_read_barrier_depends(),仅在Alpha中才需要在Linux中使用。 (但是 Hans Boehm的答复指出,“编译器可以并且有时确实可以删除依赖项”,这就是为什么C11 memory_order_consume支持必须如此精心设计以避免损坏的风险。因此 smp_read_barrier_depends可能很脆弱。)

脚注2 :x86命令所有加载,无论它们是否对指针进行数据依赖,因此它不需要保留“false”依赖,并且通过设置变长指令,它实际上将代码大小保存为 xor eax,eax( 2个字节)而不是 mov eax,0(5个字节)。

因此 xor reg,reg自8086年初开始成为标准的惯用语,现在它像 mov一样被识别和处理,不再依赖于旧值或RAX。 (实际上,除了 What is the best way to set a register to zero in x86 assembly: xor, mov or and?之外,它比 mov reg,0更有效:ojit_a)

但这对于ARM或大多数其他无序的ISA来说是不可能的,就像我说过的,实际上不允许他们这样做。
ldr r3, [something]       ; load r3 = mem
eor r0, r3,r3 ; r0 = r3^r3 = 0
ldr r4, [r1, r0] ; load r4 = mem[r1+r0]. Ordered after the other load

即使加载地址 r0始终只是 r4,也需要注入(inject)对 r3的依赖性并在加载 r1+r0之后排序加载 r1,因为 r3^r3 = 0始终是ojit_code。 但是,只有该负载,而不是所有其他以后的负载;它不是获取障碍或获取负载。

关于c - C11中的内存顺序消耗用法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55741148/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com