去原子和记忆顺序

Question

我正在从c ++ 11移植一个无锁队列,然后我遇到了诸如此类的东西

auto currentRead = writeIndex.load(std::memory_order_relaxed);

在某些情况下std::memory_order_release,并std::memory_order_aqcuire 也为C11以上的equivelent是一样的东西

unsigned long currentRead = atomic_load_explicit(&q->writeIndex,memory_order_relaxed);

这里描述了那些的含义

是否有相当于这样的事情或我只是使用类似的东西

var currentRead uint64 = atomic.LoadUint64(&q.writeIndex)

在移植我基准测试并且仅使用LoadUint64后,它似乎按预期工作但数量级更慢,我想知道这些专业操作对性能有多大影响.

• 我附上的链接的进一步信息

memory_order_relaxed:宽松操作:没有同步或排序约束,此操作只需要原子性.

memory_order_consume:具有此内存顺序的加载操作对受影响的内存位置执行使用操作:在此加载之前,可以重新排序当前线程中与当前加载的值无关的读取.这确保了在当前线程中可以看到对释放相同原子变量的其他线程中的数据相关变量的写入.在大多数平台上,这仅影响编译器优化.

memory_order_acquire:具有此内存顺序的加载操作会对受影响的内存位置执行获取操作:在此加载之前,不能对当前线程中的内存访问进行重新排序.这确保了在当前线程中可以看到释放相同原子变量的其他线程中的所有写入.

memory_order_release:具有此内存顺序的存储操作执行释放操作:在此存储之后,当前线程中的内存访问不能重新排序.这确保了当前线程中的所有写入在获取或相同原子变量的其他线程中可见,并且带有依赖关系到原子变量的写入在消耗相同原子的其他线程中变得可见.

Answer 1

你需要阅读The Go Memory Model

您会发现Go与C++中的控件完全不同 - 您的帖子中没有C++功能的直接翻译.这是Go作者故意做出的设计决定 - Go的座右铭是不要通过共享记忆来沟通; 相反,通过沟通分享记忆.

假设标准go通道不足以满足您的要求,每个内存访问都有2个选择,使用同步/原子设备或不使用,以及是否需要使用它们将取决于仔细阅读Go Memory Model并分析你的代码,只有你能做到.