See https://github.com/golang/go/issues/5045 
<https://github.com/golang/go/issues/5045> which has been open for 7+ years.

> On Aug 17, 2020, at 4:15 PM, Ian Lance Taylor <i...@golang.org> wrote:
> 
> On Mon, Aug 17, 2020 at 9:06 AM jake...@gmail.com <jake6...@gmail.com> wrote:
>> 
>> My understanding is that atomic does not 'synchronize memory' in general.  
>> If you use a Mutex, then everything that happened before is 'synchronized'. 
>> If you use atomic then only the atomic variable is 'synchronized'. That is 
>> kind of the point of using atomic.
>> 
>> If I am wrong, please point me at the part of the Go Memory Model that says 
>> otherwise. Personally, I have always felt that the go memory model, and 
>> specifically the guarantees of the atomic package are not as rigorously 
>> defined as I would like. But in this case, I'm pretty sure I am correct.
> 
> The behavior of the sync/atomic package is not specified at all by the
> Go memory model.  See https://golang.org/issue/5045.
> 
> I'm not sure I agree that using sync/atomic means that only that
> memory location is synchronized (assuming I understand what that
> means, which I may not).  There are other meaningful patterns for
> sync/atomic.
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXKCSHb4-g7uHvf-RMsky8veC52OFDjmguUQCxHDXbShA%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/448775D1-7E25-4767-A3D2-08CCC7A68104%40ix.netcom.com.

Reply via email to