On Wed, 6 Jul 2016 08:55:03 -0700 (PDT) T L <tapir....@gmail.com> wrote:
> > > On Wednesday, July 6, 2016 at 11:38:58 PM UTC+8, Axel Wagner wrote: > > > > You are misreading this. a) it implicitly refers to a single > > architecture and b) it doesn't say that single-word accesses are > > atomic, it says that multi-word accesses are inherently non-atomic. > > > > I can't get the conclusion for a) from that article. > > That article really imply (at least) pointers in go are atomic. Please consider reading [1, 2] to get a rough overview of what can go wrong about word-sized loads/stores etc. While the articles mostly talk about C and C++, Go's stance on atomicity are the same -- the only thing about sharing memory its specification actually codifies is those "happens-before" relations which are at a level above "the metal" and boil down to a simple thing: you either use implicit synchronization (channels) or explicit (mutexes) or explicitly use atomic operations on shared memory using the sync/atomic package, and then you're safe. Any other non-synchronized memory access is undefined behaviour and renders your program incorrect (as in "anything can happen"). [3] is a must read as well. 1. http://preshing.com/20130618/atomic-vs-non-atomic-operations/ 2. http://preshing.com/20120515/memory-reordering-caught-in-the-act/ 3. https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong -- 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.
