On Tuesday, September 13, 2016 at 10:57:47 PM UTC+8, Alan Donovan wrote: > > On 13 September 2016 at 10:33, 'Paul Borman' via golang-nuts < > golan...@googlegroups.com <javascript:>> 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. >
Thank you for spelling this out! To put it into concrete terms, the hash table is likely spread over multiple cache lines and so if a goroutine executing on a processor other than the one which built the hash table was to load the cache line containing the new map reference and access it before loading the actual hash table cache lines that would spell disaster. I still kind of feel like a memory barrier after updating the map reference will be sufficient in practice; it doesn't seem likely that another processor would see the new map reference before the memory barrier caused the rest of the hash tables to also be visible? But I'm no x86 export let alone ARM or less common architectures, so the boat is certainly starting to leak. Lesson learned; use barriers if sharing memory. -sqweek -- 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.
