This may be of interest to you: https://github.com/golang/go/issues/5045
> On Sep 21, 2021, at 4:17 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Tue, Sep 21, 2021 at 12:54 PM xie cui <cuiwei...@gmail.com > <mailto:cuiwei...@gmail.com>> wrote: >> >> >> https://stackoverflow.com/questions/2599238/are-memory-barriers-necessary-for-atomic-reference-counting-shared-immutable-dat >> this answer say that: >> On x86, it will turn into a lock prefixed assembly instruction, like LOCK >> XADD. >> Being a single instruction, it is non-interruptible. As an added "feature", >> the lock prefix results in a full memory barrier. >> >> In my opinion, full memory barrier means flush store buffer and invalid >> queue(not very sure, is this right?) > > Can you be specific about exactly what you are asking? You originally > said "atomic instruction," and my answer was based on the functions > sync/atomic.LoadInt32 and sync/atomic.StoreInt32. Here you seem to be > talking about sync/atomic.AddInt32, which is fine, but let's agree on > what the question is. This is a Go language mailing list, so can you > ask your question about a Go function, rather than about an "atomic > instruction"? Thanks. > > Ian > > >> On Saturday, September 18, 2021 at 3:17:26 AM UTC+8 Ian Lance Taylor wrote: >>> >>> On Fri, Sep 17, 2021 at 6:25 AM xie cui <cuiw...@gmail.com> wrote: >>>> >>>> how atomic insturction work in golang at x86/amd64, >>>> I think the atomic insturtion will flush the store buffer and invalid >>>> queue of current cpu core, >>>> but I am not sure, does someone know about it? >>> >>> I assume that you are asking about the sync/atomic package. The >>> functions in that package will ensure sequential consistency of atomic >>> operationns, but they will not flush the store buffer. See >>> https://research.swtch.com/gomm . >>> >>> 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/aa7487d1-13f1-451b-86a3-f7f70a7c040cn%40googlegroups.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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-12SQkcow1az%2BPhOYfubvmuD0q72yOc_xOo%3Dia2J_SQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-12SQkcow1az%2BPhOYfubvmuD0q72yOc_xOo%3Dia2J_SQ%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/7A0E5DBB-57FB-45AD-88AE-DC06C94DA15A%40ix.netcom.com.
