It is strange, the atomic package[0] exposes various low-level atomic functions but none of them seem to take ordering arguments and the docs don't mention a default order either.
Atomicity and ordering constraints are orthogonal, so you can have an atomic add but relaxed ordering, which allows the compiler to do lots of optimizations on those adds, presumably to the point where they are optimized out completely.
If this is the cause it seems like pretty bad API design to not expose the flags on low-level library functions. Even high level languages like java expose them[2]
There is no official ordering provided by the atomic package. An atomic package isn't very useful without ordering semantics. And ordering actually _is_ provided, it's just not part of the documentation.
The background is that the Go team were initially reluctant to even make the atomic package public. It's mostly there to support the runtime and the sync package which needs fiddly low level concurrency things. But, it exists and it is public. Some people on the Go team regret this (I believe).
Giving clear and precise semantics to the atomic package was delayed because, it's a lot of difficult work and you only get to do it once. There was discussion around trying to find a clear and simple semantics.
In the mean time the atomic package actually had ordering, because you would have a hard time writing runtime or the sync package without this. Also the race detector assumes some kind of ordering for operations in the atomic package. It was confirmed by Dmitry Vyukov that the race detector assumed C/C++11 acquire/release semantics for atomic operations.
After some discussion it was decided that C/C++11 semantics should be adopted. But the documentation has not been updated to reflect this. Updating the documentation doesn't appear to planned right now. Which is a shame.
Above I have sort of put words into the mouths of the Go team (or some members of it). It's not my intention and bad mouth anyone, and I think everyone was making decisions for good reasons. Whether I agree or not :)
With respect to adding ordering arguments, Go most likely won't get those for a very long time.
Atomicity and ordering constraints are orthogonal, so you can have an atomic add but relaxed ordering, which allows the compiler to do lots of optimizations on those adds, presumably to the point where they are optimized out completely.
If this is the cause it seems like pretty bad API design to not expose the flags on low-level library functions. Even high level languages like java expose them[2]
[0] https://golang.org/pkg/sync/atomic/ [1] http://en.cppreference.com/w/cpp/atomic/memory_order [2] http://download.java.net/java/jdk9/docs/api/java/lang/invoke...