I noticed that internally, the language implementation seems to rely on the atomicity of reads to single-word values:
https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160 As I understand it, this atomicity is provided by the cache coherence algorithms of modern architectures. Accordingly, the implementations in sync.atomic of word-sized loads (e.g., LoadUint32 on 386 and LoadUint64 on amd64) use ordinary MOV instructions: https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/sync/atomic/asm_386.s#L146 https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/sync/atomic/asm_amd64.s#L103 However, word-sized stores on these architectures use special instructions: https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/sync/atomic/asm_amd64.s#L133 Given that the APIs being implemented don't provide any global ordering guarantees, what's the reason they can't be implemented solely with MOV? Thanks very much for your time. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
