When machines (compilers or processors) are allowed to optimise things, reality gets weird.
The compiler may elide the check because it is not conformant with the spec via the memory model, or value A.a may be in a local CPU cache and so never be altered as far as the core is concerned. On Fri, 2019-02-01 at 13:58 -0800, Michael Ellis wrote: > I'm confused. I can see how that would fail if the test were A.a == > 100 > since Go routine #1 might increment past 100 before #2 , but as > written it > seems wrong only if the application logic depends on Go routine #2 > exiting > the loop as soon as A.a reaches 100 (as opposed to any time > afterward.) > > What am I missing? -- 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.
