Hi Shivaram, Regarding the memory model definition and sync/atomic, there is this github issue that you likely would be interested in:
issue #5045 "doc: define how sync/atomic interacts with memory model" Including this comment: ===================================================== https://github.com/golang/go/issues/5045#issuecomment-252730563 ===================================================== rsc commented on Oct 10, 2016: Yes, I spent a while on this last winter but didn't get a chance to write it up properly yet. The short version is that I'm fairly certain the rules will be that Go's atomics guarantee sequential consistency among the atomic variables (behave like C/C++'s seqconst atomics), and that you shouldn't mix atomic and non-atomic accesses for a given memory word. ===================================================== --thepudds On Monday, March 19, 2018 at 8:46:56 AM UTC-4, Shivaram Lingamneni wrote: > > Thanks, this was very helpful. If I understand correctly: > > 1. These ordering guarantees are part of the Go memory model? I couldn't > find explicit descriptions of them in these pages: > > https://golang.org/ref/mem > https://golang.org/pkg/sync/atomic/ > > 2. The property that word-sized values are not subject to > interleaving/tearing is an implementation detail, rather than a guarantee > of the Go memory model? > > On Monday, March 19, 2018 at 1:55:07 AM UTC-4, Ian Lance Taylor wrote: >> >> On Sun, Mar 18, 2018 at 9:47 PM, shivaram via golang-nuts >> <golan...@googlegroups.com> wrote: >> > >> > 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 >> >> >> In the machine level, words like "atomicity" are overloaded with >> different meanings. I think what you are saying is that the runtime >> package is assuming that a load of a machine word will never read an >> interleaving of two different store of a machine word. It will always >> read the value written by a single store, though exactly which store >> it sees is unknown. This is true on all the processors that Go >> supports. >> >> >> > 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? >> >> You are not giving the correct reason for why atomic.LoadUint32 and >> LoadUint64 can use ordinary MOV instructions on x86 processors. The >> LoadUint32, etc., functions guarantee much more than that they read a >> value that is not an interleaving a multiple writes. They are also >> load-acquire operations, meaning that when the function completes, the >> caller will see not only the value that was loaded but also all other >> values that some other processor core wrote before writing to the >> address being loaded (assuming the write was done using StoreUint32, >> etc.). It happens that on x86 you can implement load-acquire using a >> simple MOV instruction. Most other multicore processors use a more >> complex memory model, and their sync/atomic implementations are >> accordingly more complex. >> >> Ian >> > -- 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.
