> My argument is all that 'happens-before' is a comparison of o.done == > 0 happens before the address of o.done is passed to > atomic.StoreUint32. The rest is just luck.
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. When I say that there's a total ordering among the reads and writes within the mutex, this is the write that I'm referring to. > I agree it should print 2, but my reading of the memory model and > https://github.com/golang/go/issues/5045 doesn't give me any concrete > guarantee that it must. This is why i'm not sure about the > interactions between atomic and non atomic loads. Here, too, I think we need to turn to the sync/atomic documentation, which says what the effect of StoreUint32 is. The precise nature of concurrent atomic operations can be left to #5045, but here we are concerned with something simpler: after StoreUint32 returns ("after" in a happens-before sense), are we guaranteed to read the stored value? The answer must be yes. (If the answer were no, then StoreUint32(p, val) would be in some sense *less atomic* than the statement *p = val.) -- 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.
