On Friday, 29 December 2017 16:55:37 UTC+11, Caleb Spare wrote:
>
> > 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. 


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.

 

> 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.

Reply via email to