On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich <m...@renich.org> wrote: > > * burak serdar <bser...@computer.org> [191108 08:42]: > > I was thinking about this. In general, it should be safe to replace > > > > Lock() > > read/write one value > > Unlock() > > > > with > > > > AtomicRead/Write > > > > Is that correct? The go memory model does not say anything about this. > > Yes. > > While others have argued that the GMM is not specific enough about this > case, I disagree. The atomic package says it is "useful for > implementing synchronization algorithms". This wording is, in my > opinion, sufficient to make two guarantees: > > 1. Values read and written with the atomic package will read and > write whole values without corruption. > 2. If a memory write from one goroutine is observed by another > goroutine, this establishes a "happens before" relationship. > > If these are not true, than the documentation in the atomic package is a > blatant lie. Thus, the memory model does not need any additional > verbiage to clarify this. > > And while the next paragraph in the atomic documentation discourages > using it for synchronization, I think the doc'n is overly pessimistic. > Certainly for the simple case of avoiding races due to concurrent > write/read of a single value, the atomic operations are a very good > solution. If you can guarantee that all writes to a particular value > are done on a single goroutine, and all reads and writes are done using > the atomic package, than it is safe to have many other goroutines > reading that value, and using a mutex is overkill. > > I do agree that channels and the sync package should be preferred over > implementing something similar with atomic, but don't shy away from > atomic for the simple cases that it does well.
That's what I figured as well. Atomic read/writes have memory barriers, so this should work. Afaik, an atomic read/write does not yield, so busy-waiting using an atomic will probably not work. Maybe some of these guarantees (and non-guarantees) can be explicitly stated in the docs. > > ...Marvin > > -- > 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/20191108145435.3tdii3v3zgx3jv22%40basil.wdw. -- 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/CAMV2RqoyJMC3XXTBKdcAitKUyvyzbykvrfZPgQcLw5%3D%2BY%2B0%2BCQ%40mail.gmail.com.
