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