For the second section (the one with locks), the program is guaranteed to print a 1 (if it prints anything). The Go memory model <https://golang.org/ref/mem> guarantees this. This follows from the facts: x = 1 @29 happens before m.Unlock() @31 m.Unlock() @31 happens before m.Lock() @35 m.Lock() @35 happens before the read of x @ 39 [and similarly for the y variable]
As mentioned elsewhere, go does not guarantee fairness among goroutines, so it is possible that the second half could loop forever without printing anything. The first section (the ones with sync/atomic operations) is also guaranteed to print 1 (if it prints anything). There's no spec for how sync/atomic operations interact with Go's memory model, but I assert the following: Atomic stores (and adds, like the AddInt32 you used) are like lock releases. Atomic loads are like lock acquires. If the atomic load sees the result of an atomic store, then all loads subsequent to the atomic load will see all stores previous to the atomic store. It is hard to provide a proof for my assertion, but: A) sync/atomic operations would be pretty useless without the guarantee I mentioned, and B) the runtime makes extensive use of exactly this guarantee On Sunday, October 22, 2017 at 3:07:15 PM UTC-7, Dave Cheney wrote: > > If that we’re the case then you wouldn’t need to paid an atomic.Store with > an atomic.Load. But as I understand it, you do. -- 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.
