On Sun, Oct 22, 2017 at 7:37 PM, <keith.rand...@gmail.com> wrote: > For the second section (the one with locks), the program is guaranteed to > print a 1 (if it prints anything). > The Go memory model 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
I agree. In C++ memory model terms I believe that the sync/atomic Load operations are memory_order_acquire, and I believe that the sync/atomic Store operations are memory_order_release. It's possible that if we ever document it we will go for stronger memory ordering, but I believe that these operations must at least carry those guarantees. I'm somewhat less certain of the memory order guarantees of the Swap, CompareAndSwap, and Add functions. I guess that Swap and CompareAndSwap are probably at least memory_order_acq_rel, but Add may be memory_order_relaxed. 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.
