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