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?
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”.
On Sun, Feb 8, 2015 at 6:25 AM, Rob Pike <r...@golang.org> wrote:
> The documentation of sync/atomic is simple and clear.
>
> -rob
>
>
> On Sat, Feb 7, 2015 at 10:13 PM, John Souvestre <jo...@sstar.com> wrote:
>>
>> It doesn’t say which primitives in sync/atomic are sequentially consistent
>> / memory barriers. Perhaps if it were clearer about this then it wouldn’t
>> confuse so many users and even Go developers?
>>
>>
>>
>> John
>>
>> John Souvestre - New Orleans LA
>>
>>
>>
>> From: Rob Pike [mailto:r...@golang.org]
>> Sent: 2015 February 08, Sun 00:05
>> To: John Souvestre
>> Cc: Ian Lance Taylor; tsuna; golang-nuts; Dmitry Vyukov
>> Subject: Re: [go-nuts] Compiler level memory barrier in Go i.e. asm
>> volatile("" : : : "memory")
>>
>>
>>
>> The sync/atomic functions are mentioned in the memory model doc.
>>
>>
>>
>> -rob
>>
>>
>>
>>
>>
>> On Sat, Feb 7, 2015 at 8:19 PM, John Souvestre <jo...@sstar.com> wrote:
>>
>> Ø It has to, or the runtime package wouldn't work as it must.
>>
>> Ø The sync/atomic functions probably ought to be in the memory model, but
>> we're tired of arguing about the memory model doc.
>>
>> You are saying that Go itself, and programs which use sync/atomic
>> functions, would fail if it is not true. Yet it’s not guaranteed
>> (documented)?
>>
>>
>>
>> If I understand issue 5045 correctly, it would seem that the argument
>> against the guarantee has been superseded (resolved?) by implementation. So
>> why not now document this essential and often-questioned issue?
>>
>>
>>
>> John
>>
>> John Souvestre - New Orleans LA
>>
>>
>>
>> From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
>> On Behalf Of Ian Lance Taylor
>> Sent: 2015 February 07, Sat 21:27
>> To: tsuna
>> Cc: golang-nuts; Dmitry Vyukov
>> Subject: Re: [go-nuts] Compiler level memory barrier in Go i.e. asm
>> volatile("" : : : "memory")
>>
>>
>>
>> --
>> 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.
>>
>>
>
>
--
Benoit "tsuna" Sigoure
--
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.
