On Fri, Nov 4, 2016 at 3:01 PM, tsuna <tsuna...@gmail.com> wrote:
>
> Follow up question, just to be sure:
>
> Do we then agree that if I see code like this:
>
> for {
> version := shmem.version // this reads a uint32 from shared memory
> doSomething()
> if version == shmem.version {
> break
> }
> }
>
> then this code is buggy because the Go compiler could re-order the
> code or factor out the subexpression “shmem.version”, or the CPU could
> even potentially execute things out of order? i.e. the only way to
> make this code correct is to atomic.LoadUint32(&shmem.version), right?
Right (and of course modify shmem.version using atomic.StoreUint32).
> I think until recently the Go compiler wasn’t optimizing much (before
> the SSA work started, was gc doing any kind of common subexpression
> elimination or whatnot?), but now that this is changing (fast), I’m
> finding more code following this pattern and I want to be 100% certain
> I can say “this is buggy, we need to change this”.
Note that it's not just the compiler. As I was saying on another
thread earlier today, it's also the memory ordering of the processor.
Without using the atomic functions, nothing ensures that that the core
reading shmem.version will also see the other values written into
memory before shmem.version was written. In this case that may not
matter, but often it does.
Ian
--
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.
