-----Original Message-----
>From: burak serdar <bser...@computer.org>
>Sent: Nov 8, 2019 9:19 AM
>To: golang-nuts <golang-nuts@googlegroups.com>
>Subject: Re: [go-nuts] What is the correct way to access/modify slice elements
>concurrently
>
>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.
See https://github.com/golang/go/issues/10958 for using atomics in
tight/busy-wait loops.
--
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/1843585103.1669.1573231278267%40wamui-cheeto.atl.sa.earthlink.net.
