On Sat, Oct 11, 2014 at 4:28 AM, 'Wedson Almeida Filho' via
> On Sat, Oct 11, 2014 at 3:53 AM, Dmitry Vyukov <dvy...@google.com
>> On Sat, Oct 11, 2014 at 2:15 PM, <weds...@google.com
>> > Why is atomic.Store/Load guaranteed to solve this?
>> That is the intention.
> Then I feel like the mem ref doc should specify what we can expect.
I'm not opposed to updating the memory model.
That said, we've tried to be clear all along that we don't want people
to write Go code with one eye on the memory model. Use channels and
mutexes. Don't try to be too clever.
> In some code that I'm writing now I only need the atomicity guarantees from
> the atomics package, so I'm inclined to send a patch to modify Store* on
> amd64 to be a plain MOV, which *is* atomic, and would improve the
> performance of my code as I don't need barriers.
> This would obviously break code for example in Once.Do, which uses
> StoreUint32 and needs the barrier. But I could argue that this code (and a
> bunch more in sync) is incorrect, given that atomics don't formally offer
> any ordering guarantees.
The behaviour of sync.Once is specified in the memory model. Clearly,
breaking that behaviour would be wrong. The code in sync is correct
(assuming there aren't any bugs). The code in sync/atomic is there to
support the code in sync. To say that the code in sync is wrong
because the memory model doesn't provide guarantees about sync/atomic
is to confuse yourself about priorities. We want sync to be clearly
documented and used when appropriate. We generally don't want
sync/atomic to be used at all.
> Is that a good enough reason to update the doc?
Let me try to say this in another way. Experience has shown us again
and again that very very few people are capable of writing correct
code that uses atomic operations. Go has strong support for
concurrent programming, and we want to give people the tools they need
to give them a fighting chance to write that code correctly without
handcuffing them so much that they look for escape clauses. Those
tools are channels and mutexes, and supporting functionality like
sync.Once and sync.WaitGroup. Encourating people to use atomic
operations like the functions in sync/atomic is not giving people the
tools they need: most people who use those functions will write code
that does not work as they expect. If we had thought of internal
packages when we added the sync/atomic package, perhaps we would have
used that. Now we can't remove the package because of the Go 1
guarantee. But it's not particularly important to carefully specify
how the package behaves, because rule 1 is that you shouldn't use it.
And rule 2 is that if you think you might want to use it, see rule 1.