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.