RE: [go-nuts] does Go memory model guarantee this program always prints 1?
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?
* 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?
* 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?
[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?
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?
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?
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?
On Mon, Jul 10, 2017 at 2:24 PM T Lwrote: > 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?
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?
* 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?
On Sun, Jul 9, 2017 at 10:56 AM T Lwrote: > 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?
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?
* 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?
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?
> 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?
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?
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.