我阅读了"英特尔架构的英特尔优化指南指南".
但是,我仍然不知道何时应该使用
_mm_sfence()
_mm_lfence()
_mm_mfence()
任何人都可以解释在编写多线程代码时何时应该使用它们？
考虑像一个数组atomic<int32_t> shared_array[].如果你想SIMD矢量化for(...) sum += shared_array[i].load(memory_order_relaxed)怎么办？或者在数组中搜索第一个非零元素,或者将其范围归零？这可能很少见,但考虑一下不允许在元素内撕裂的任何用例,但在元素之间重新排序很好. (也许是寻找CAS候选人的搜索).
我认为 x86对齐的向量加载/存储在实践中可以安全地用于带有mo_relaxed操作的SIMD ,因为任何撕裂只会发生在当前硬件上最坏的8B边界(因为这是自然对齐的8B访问原子1的原因).不幸的是,英特尔的手册只说:
"可以使用多个存储器访问来实现访问大于四字的数据的x87指令或SSE指令."
无法保证这些组件访问是自然对齐,不重叠或其他任何内容.(有趣的事实:根据Agner Fog,大概是qword + word,fld m80在Haswell上用2个加载uops和2个ALU uops完成x87 10字节加载.)
如果你想在面向未来的方式,当前的x86手册上说,未来所有的x86 CPU将努力向量化,你可以在8B块与加载/存储movq/ movhps.
或者你可以使用vpmaskmovd带有全真掩码的256b,因为手册的操作部分用多个独立的32位负载来定义它,比如Load_32(mem + 4).这是否意味着每个元素都作为一个单独的32位访问,保证该元素内的原子性？
(在实际硬件上,它是Haswell上的1个负载和2个端口5 uops,或者Ryzen上只有1或2个负载+ ALU uops(128/256).我认为这是针对不需要从元素中抑制异常的情况进入一个未映射的页面,因为它可能会更慢(但IDK如果它需要微代码辅助).无论如何,这告诉我们它至少与vmovdqaHaswell上的正常负载一样原子,但这告诉我们没有关于x86 Deathstation 9000 16B的信息/ 32B向量访问被分解为单字节访问,因此每个元素内可能会有撕裂.
我认为实际上可以安全地假设你不会在16,32或64位元素中撕裂任何真正的x86 CPU上的对齐矢量加载/存储,因为这对于已经有效的实现是没有意义的必须保持自然对齐的64位标量存储原子,但知道手册中的保证到底有多远是有趣的.)
收集(AVX2,AVX512)/ Scatter(AVX512)
类似vpgatherdd的指令显然由多个独立的32b或64b访问组成.AVX2表格被记录为多次执行,FETCH_32BITS(DATA_ADDR);因此可能会被通常的原子性保证所覆盖,并且如果它不跨越边界,则每个元素将以原子方式收集.
AVX512褶裥都记录在英特尔公司的PDF的insn参考手册作为
DEST[i+31:i] <- MEM[BASE_ADDR + SignExtend(VINDEX[i+31:i]) * …
我正在玩这个答案的代码,稍微修改一下:
BITS 64
GLOBAL _start
SECTION .text
_start:
mov ecx, 1000000
.loop:
;T is a symbol defined with the CLI (-DT=...)
TIMES T imul eax, eax
lfence
TIMES T imul edx, edx
dec ecx
jnz .loop
mov eax, 60 ;sys_exit
xor edi, edi
syscall
没有lfence我,我得到的结果与答案中的静态分析一致.
当我介绍一个单一 lfence我期望的CPU执行imul edx, edx的序列的第k个平行于迭代imul eax, eax的下一个(的序列K + 1个)迭代.
像这样的东西(调用一个的imul eax, eax序列和d的imul edx, edx一个): …
我已经阅读了很多关于内存排序的文章,并且所有这些文章都只说CPU重新加载和存储.
CPU(我对x86 CPU特别感兴趣)是否仅重新排序加载和存储,并且不重新排序它具有的其余指令？
我试图理解atomic_forced_read定义的目的，它经常出现在malloc.c的GNU libc实现中。
我不太擅长内联汇编，但看起来这会返回完全相同的值，并且类型与输入值相同。我在这里缺少什么？
原子强制读取定义在atomic.h中
523 #ifndef atomic_forced_read
524 # define atomic_forced_read(x) \
525 ({ __typeof (x) __x; __asm ("" : "=r" (__x) : "0" (x)); __x; })
526 #endif
链接到atomic.h
https://code.woboq.org/userspace/glibc/include/atomic.h.html
我想在原子和非原子操作之间使用独立的内存屏障（我认为无论如何它都不重要）。我想我了解存储屏障和加载屏障的含义以及 4 种可能的内存重新排序；LoadLoad, StoreStore, LoadStore, StoreLoad.
但是，我总是发现获取/释放概念令人困惑。因为在阅读文档时，acquire 不仅说到loads，还说到stores，而release 不仅说到stores，还说到loads。另一方面，普通负载障碍仅为您提供负载保证，而普通商店障碍仅为您提供商店保证。
我的问题如下。在 C11/C++11 中，将独立atomic_thread_fence(memory_order_acquire)视为负载屏障（防止LoadLoad重新排序）和atomic_thread_fence(memory_order_release)存储屏障（防止StoreStore重新排序）是否安全？
如果以上是正确的，我可以用什么来防止LoadStore和StoreLoad重新排序？
当然，我对可移植性感兴趣，我不在乎上述在特定平台上产生什么。
我想从原子 uint32s 拼凑一个 uint64 原子计数器。计数器有一个写入器和多个读取器。编写器是一个信号处理程序，所以它不能阻塞。
我的想法是使用低位的代数作为读锁。读取器重试，直到整个读取过程中生成计数稳定，并且低位未设置。
以下代码在内存排序的设计和使用中是否正确？有没有更好的办法？
using namespace std;
class counter {
atomic<uint32_t> lo_{};
atomic<uint32_t> hi_{};
atomic<uint32_t> gen_{};
uint64_t read() const {
auto acquire = memory_order_acquire;
uint32_t lo, hi, gen1, gen2;
do {
gen1 = gen_.load(acquire);
lo = lo_.load(acquire);
hi = hi_.load(acquire);
gen2 = gen_.load(acquire);
} while (gen1 != gen2 || (gen1 & 1));
return (uint64_t(hi) << 32) | lo;
}
void increment() {
auto release = memory_order_release;
gen_.fetch_add(1, release);
uint32_t newlo = 1 + lo_.fetch_add(1, release);
if (newlo …