转到原子和内存顺序

Question

I am porting a lock free queue from c++11 to go and i came across things such as

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

and in some cases std::memory_order_release and std::memory_order_aqcuire also the equivelent for the above in c11 is something like

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

the meaning of those is described here

is there an equivalent to such thing in go or do i just use something like

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

after porting i benchmarked and just using LoadUint64 it seems to work as expected but orders of magnitude slower and i wonder how much effect dose those specialized ops have on performance.

• further info from the link i attached

memory_order_relaxed:Relaxed operation: there are no synchronization or ordering constraints, only atomicity is required of this operation.

memory_order_consume:A load operation with this memory order performs a consume operation on the affected memory location: no reads in the current thread dependent on the value currently loaded can be reordered before this load. This ensures that writes to data-dependent variables in other threads that release the same atomic variable are visible in the current thread. On most platforms, this affects compiler optimizations only.

memory_order_acquire:A load operation with this memory order performs the acquire operation on the affected memory location: no memory accesses in the current thread can be reordered before this load. This ensures that all writes in other threads that release the same atomic variable are visible in the current thread.

memory_order_release:A store operation with this memory order performs the release operation: no memory accesses in the current thread can be reordered after this store. This ensures that all writes in the current thread are visible in other threads that acquire or the same atomic variable and writes that carry a dependency into the atomic variable become visible in other threads that consume the same atomic.

Answer 1

You need to read The Go Memory Model

You'll discover that Go has nothing like the control that you have in C++ - there isn't a direct translation of the C++ features in your post. This is a deliberate design decision by the Go authors - the Go motto is Do not communicate by sharing memory; instead, share memory by communicating.

Assuming that the standard go channel isn't good enough for what you want to do, you'll have 2 choices for each memory access, using the facilities in sync/atomic or not, and whether you need to use them or not will depend on a careful reading of the Go Memory Model and analysis of your code which only you can do.