Yes, that is very true, though in the OP's case, the memory barrier can easily be done by the writer without affecting the reader (simply by switching the write to the channel with the assignment of x.myMap). Granted, the reader might have stale information, but I believe that the compiler currently will only cache the pointer to the map with relative locality, so for practical (but not guaranteed) purposes, it will not appear to be a problem.
But I will reiterate what I said: *The Go memory model does not guarantee this, however, so while it might work for you now on your current target, that is a side effect of an implementation and architecture detail.* On Tue, Sep 13, 2016 at 7:57 AM, Alan Donovan <adono...@google.com> wrote: > On 13 September 2016 at 10:33, 'Paul Borman' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> That said, a map is represented by a single machine word (32 or 64 >> bits). I don't know of any modern architecture where reading a cache >> aligned word while it is being written will yield anything but the old or >> new value. >> > > This line of reasoning is what leads to trouble. The atomicity problem is > not with the map reference, which will be either old or new, but with all > the memory writes to the actual hash table, which may be in any number of > intermediate states including "impossible" ones. You must ensure that the > completion of those writes happens before another goroutine attempts to > read from the hashtable, and for that, you need some kind of barrier: a > channel, mutex, or atomic.Value. > -- 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. For more options, visit https://groups.google.com/d/optout.
