That is not required for simple counters that are incremented by multiple and read by one. Atomics suffice.
> On Feb 1, 2019, at 8:24 AM, Jesper Louis Andersen > <[email protected]> wrote: > >> On Thu, Aug 3, 2017 at 9:21 AM Henrik Johansson <[email protected]> wrote: > >> I think I am mostly after a mental pattern to easily recognise when >> synchronizations are needed. > > Assume every write to memory takes 10 seconds and is asynchronous, except > that you have Read-Your-Own writes in a goroutine. > > You can reduce the 10 seconds by doing synchronization: atomics, locks, > waitgroups, channels. > > To a first approximation, the mental model has to include a severe artificial > lag insofar that is what makes you realize where to synchronize. Also, > suppose a goroutine executes a 10 second long blocking call. Your program > must still be correct, which means synchronization. > > Yet, such mental models can and will eventually fall apart and you need a > more formal model to address the problems. I've written systems in which you, > artificially mind you, reorder the schedules of processes in a system > randomly, but within the realm of the possible. Programs tend to be wrong in > really subtle ways, sometimes catastrophically so. A mental model is good for > intuition, but it cannot---in my experience---substitute for proper > formality. Being proficient in a tool such as Lamport's TLA+ can do wonders > for system correctness. > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
