Isn't the lock operation an memory acquire operation that means that the next load of the done field needs to be loaded from memory?
Perhaps it is not stated in the memory model exactly but this seems safe. On Fri, Dec 29, 2017, 08:11 Dave Cheney <d...@cheney.net> wrote: > > > On 29 Dec 2017, at 18:01, Caleb Spare <cesp...@gmail.com> wrote: > > >>> This expression: > >>> > >>> atomic.StoreUint32(&o.done, 1) > >>> > >>> does not just take the address of o.done. It also executes the > >>> StoreUint32 function, which is defined by the sync/atomic > >>> documentation to behave like '*o.done = 1'; i.e., it alters the value > >>> of o.done. > >> > >> > >> Respectfully I disagree, it store the value 1 at the memory address > &o.done. > >> It has no defined effect on other occurrences of o.done in this, or > other > >> goroutines if they have already loaded o.done. > >> > >> I agree that i'm still talking about registers and inlining; but if > there > >> were no registers, inlining, caches, or other things which are not > specified > >> by the language, then there would be no data races. So here we are. > > > > Does your argument rely on atomic.StoreUint32 being special, or would > > you also say that this program is not defined to always print 2? > > I believe that program will always print 2, however when you bring > multiple Goroutines into the mix, I’m less sure. > > > > > https://play.golang.org/p/gk3c6X_JdmQ > > -- > 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. > -- 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.
