RE: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-14 Thread John Souvestre
Hi Marvin.

 > Yes, assuming the Go authors agree that atomic operations guarantee 
 > non-concurrency.  Can we have someone authoritative weigh in here?

The Memory Model says that "synchronization primitives" are in the sync and 
sync/atomic packages.  It also says that a "synchronization mechanism" 
establishes relative ordering as observed by another goroutine.  In other 
words, Go's atomics are full memory barriers/fences which guarantee sequential 
consistency for any number of goroutines.

I'm not an authority, but I believe that both Rob and Ian confirm this in 
https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ

John

John Souvestre - New Orleans LA

-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Marvin Renich
Sent: 2017 July 10, Mon 12:09
To: golang-nuts
Subject: Re: [go-nuts] does Go memory model guarantee this program always 
prints 1?

[Reply-To set; I don't need two copies of replies.]

* T L <tapir@gmail.com> [170710 12:31]:
> so this is guaranteed by Go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> } 

Asked and answered in your previous msg.  Yes, assuming the Go authors
agree that atomic operations guarantee non-concurrency.  Can we have
someone authoritative weigh in here?

...Marvin

-- 
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.

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread Marvin Renich
* T L  [170710 12:35]:
> so this is guaranteed by Go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> import "unsafe"
> 
> func main() {
> var x, y int32
> 
> var p = unsafe.Pointer()
> 
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", *(*int32)(p)) // always 1 if it is printed?
> }
> } 

Again, no concurrency.  Order is as written.

I've only used unsafe.Pointer once and in a way that was specifically
documented to work, and I have not otherwise researched it, so I may be
wrong here, but assuming the GC is guaranteed to update p if x moves,
then I believe this will always print "x = 1".

...Marvin

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread Marvin Renich
* T L  [170710 12:32]:
> so this is guaranteed by go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> 
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> } 

No concurrency here.  Order is as written.

...Marvin

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread Marvin Renich
[Reply-To set; I don't need two copies of replies.]

* T L  [170710 12:31]:
> so this is guaranteed by Go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> } 

Asked and answered in your previous msg.  Yes, assuming the Go authors
agree that atomic operations guarantee non-concurrency.  Can we have
someone authoritative weigh in here?

...Marvin

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread T L


On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by Go memory model?

package main

import "fmt"
import "sync/atomic"
import "unsafe"

func main() {
var x, y int32

var p = unsafe.Pointer()

atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", *(*int32)(p)) // always 1 if it is printed?
}
} 

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread T L


On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by go memory model?

package main

import "fmt"
import "sync/atomic"

func main() {
var x, y int32

atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
printed?
}
} 

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread T L


On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by Go memory model?

package main

import "fmt"
import "sync/atomic"

func main() {
var x, y int32
go func() {
atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
}()
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
printed?
}
} 

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread Jan Mercl
On Mon, Jul 10, 2017 at 2:24 PM T L  wrote:

> Aha, what I wanted to express is the execution orders of the two lines
may be randomized.
>
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)

No, assuming those two lines are as written, ie. part of single function
and thus executed in a single/the same goroutine. Then the memory model
guarantees they are executed in order, ie. x will be updated before y. But
there's no such guarantee when the same variable x and y are observed in a
different, concurrently executing goroutine. To establish such ordering you
have to synchronize, only that gives you the H-B relation within the
synchronization participants.

-- 

-j

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-10 Thread T L


On Sunday, July 9, 2017 at 5:10:20 PM UTC+8, Jan Mercl wrote:
>
> On Sun, Jul 9, 2017 at 10:56 AM T L  
> wrote:
>
> > But I remember that the "happens-before relationship" is never written 
> down in any official Go documentation.
>
> https://golang.org/ref/mem#tmp_2
>
>
> -- 
>
> -j
>

Aha, what I wanted to express is the execution orders of the two lines may 
be randomized.

 atomic.AddInt32(, 1) 
 atomic.AddInt32(, 1) 


 

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-09 Thread Marvin Renich
* T L  [170709 04:56]:
> On Friday, July 7, 2017 at 8:42:28 PM UTC+8, Marvin Renich wrote:
> > Yes, the go routine establishes a happens-before relationship such that 
> > x is incremented before y, and the atomic Add of y and Load of y ensure 
> > that the Load either happens before or after, but not during, the Add. 
> 
> But I remember that the "happens-before relationship" is never written down 
> in any official Go documentation.

Actually, I believe the documentation is specific enough, at least if
you accept a reasonable definition of "atomic" as it is used in the
documentation of the atomic package.

Without atomic operations, a write to memory in one go routine and a
read from the same memory in another (without other synchronization)
cannot be guaranteed to have any specific behavior at all.
Specifically, the read may return garbage that has nothing to do with
either the value that was originally in the memory or the value that is
being written to the memory.

If you are performing atomic writes and reads, this guarantees that the
read must either observe the original value or the value placed by the
write; no other value may be observed.  So, if the initial value of
variable X is 0, and the only code that changes variable X is in go
routine A, which changes it atomically (exactly one time) to have a
value 1, then go routine B, which atomically reads variable X, must
either get a value of 0, which implies that the read MUST happen-before
the write in go routine A, or it must get a value of 1, which implies
that the write in go routine A MUST happen-before the read in go routine
B.  So, the value read by go routine B can be used to determine which of
the read and write happens before the other.

In other words, if we take the existing description under "Happens
Before" it the memory model documentation, specifically:

  Also, if e1 does not happen before e2 and does not happen after e2,
  then we say that e1 and e2 happen concurrently.

And we add the following definition, which currently is implicit in the
atomic documentation:

  An atomic read and an atomic write of the same variable cannot happen
  concurrently [for the definition of "concurrently" above].

Then an atomic read and an atomic write on the same variable establish a
happens before relationship between the two, but it is up to the code to
be able to prove which one happens first.

This is slightly different than most of the other happens-before
relationships, such as channel writes and reads, where the operation
determines which one happens first, but it is still good enough to
establish a happens-before relationship based on the result of the read.

...Marvin

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-09 Thread Jan Mercl
On Sun, Jul 9, 2017 at 10:56 AM T L  wrote:

> But I remember that the "happens-before relationship" is never written
down in any official Go documentation.

https://golang.org/ref/mem#tmp_2


-- 

-j

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-09 Thread T L


On Friday, July 7, 2017 at 8:42:28 PM UTC+8, Marvin Renich wrote:
>
> * T L  [170707 01:32]: 
> > Then how about this? 
> > 
> > package main 
> > 
> > import "fmt" 
> > import "sync/atomic" 
> > 
> > func main() { 
> > var x, y int32 
> > go func() { 
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
> > }() 
> > 
> > if atomic.LoadInt32() == 1 { 
> > fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed? 
> > } 
>
> Yes, the go routine establishes a happens-before relationship such that 
> x is incremented before y, and the atomic Add of y and Load of y ensure 
> that the Load either happens before or after, but not during, the Add. 
>

But I remember that the "happens-before relationship" is never written down 
in any official Go documentation.
 

>
> > if atomic.LoadInt32() == 0 { 
> > fmt.Println("y =", atomic.LoadInt32()) // always 0 if it is 
> printed? 
> > } 
>  

No.  If the Load of x returns 0, it must happen before the Add of 1 to x. 
> But after the test and before the Load of y, the main go routine and the 
>
func go routine are both runnable and there is nothing to establish a 
> happens-before relationship between the Load of y and the Add of 1 to y. 
>
> > } 
>
> ...Marvin 
>
>
 Great explanation.

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-07 Thread Marvin Renich
* T L  [170707 01:32]:
> Then how about this?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
> 
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is printed?
> }

Yes, the go routine establishes a happens-before relationship such that
x is incremented before y, and the atomic Add of y and Load of y ensure
that the Load either happens before or after, but not during, the Add.

> if atomic.LoadInt32() == 0 {
> fmt.Println("y =", atomic.LoadInt32()) // always 0 if it is printed?
> }

No.  If the Load of x returns 0, it must happen before the Add of 1 to x.
But after the test and before the Load of y, the main go routine and the
func go routine are both runnable and there is nothing to establish a
happens-before relationship between the Load of y and the Add of 1 to y.

> }

...Marvin

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-07 Thread peterGo
T L,

No: https://github.com/golang/go/issues/19182

Peter

On Friday, July 7, 2017 at 5:31:33 AM UTC, T L wrote:
>
>
>
> On Friday, July 7, 2017 at 3:26:24 AM UTC+8, Lars Seipel wrote:
>>
>> On Thu, Jul 06, 2017 at 12:19:05PM -0700, T L wrote: 
>> > 
>> > package main 
>> > 
>> > import "fmt" 
>> > import "sync/atomic" 
>> > 
>> > func main() { 
>> > var x int32 
>> > atomic.AddInt32(, 1) 
>> > fmt.Println(atomic.LoadInt32()) 
>> > } 
>>
>> Sure. 
>>
>> > Within a single goroutine, the happens-before order is the order 
>> > expressed by the program. 
>> - https://golang.org/ref/mem
>
>
> Thanks.
>
> Then how about this?
>
> package main
>
> import "fmt"
> import "sync/atomic"
>
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
> 
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> 
> if atomic.LoadInt32() == 0 {
> fmt.Println("y =", atomic.LoadInt32()) // always 0 if it is 
> printed?
> }
> }
>  
>

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-06 Thread andrey mirtchovski
> Then how about this?

No.

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-06 Thread T L


On Friday, July 7, 2017 at 3:26:24 AM UTC+8, Lars Seipel wrote:
>
> On Thu, Jul 06, 2017 at 12:19:05PM -0700, T L wrote: 
> > 
> > package main 
> > 
> > import "fmt" 
> > import "sync/atomic" 
> > 
> > func main() { 
> > var x int32 
> > atomic.AddInt32(, 1) 
> > fmt.Println(atomic.LoadInt32()) 
> > } 
>
> Sure. 
>
> > Within a single goroutine, the happens-before order is the order 
> > expressed by the program. 
> - https://golang.org/ref/mem


Thanks.

Then how about this?

package main

import "fmt"
import "sync/atomic"

func main() {
var x, y int32
go func() {
atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
}()

if atomic.LoadInt32() == 1 {
fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
printed?
}

if atomic.LoadInt32() == 0 {
fmt.Println("y =", atomic.LoadInt32()) // always 0 if it is 
printed?
}
}
 

-- 
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.


Re: [go-nuts] does Go memory model guarantee this program always prints 1?

2017-07-06 Thread Lars Seipel
On Thu, Jul 06, 2017 at 12:19:05PM -0700, T L wrote:
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x int32
> atomic.AddInt32(, 1)
> fmt.Println(atomic.LoadInt32())
> }

Sure.

> Within a single goroutine, the happens-before order is the order
> expressed by the program.
- https://golang.org/ref/mem

-- 
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.