Aha, if the second gorotuine "go func() { close(ch) }()" is removed from
your example,
then I can't find any flaw in what your said.
The two new created goroutines in your example really builds a relationship
as described in the Go 1 memory model article.
The relationship guarantees "a, b = 0, 1" will never happen.
On Friday, October 27, 2017 at 4:50:18 PM UTC-4, Axel Wagner wrote:
>
> I'm not an expert, but I think this is an invalid oversimplification. Say
> you have three goroutines:
>
> var x, y int
> ch := make chan int
> go func() {
> x = 1
> <-ch
> y = 1
> }()
> go func() {
> close(ch)
> }()
> a, b := x, y
>
> From my understanding of the memory model, it would be legal to get a, b =
> 0, 1 (thus, the write of y was observed before the write of x).
> The reason is, that the memory model only makes guarantees for the
> ordering of effects of goroutine A observed by goroutine B, if there is a
> happens-before edge *between these two goroutines*. The assignments to a
> resp. b have no happens-before edges with the assignments of x or y.
>
> So, any formulation of the memory-model guarantees necessarily have to
> talk about relationships between multiple goroutines and their statements.
>
> But I'm not an expert. I consider all of this memory-model,
> happens-before-relationship arguing to be incredibly tedious. Which is why
> I just a) add synchronization points when I need to concurrently access
> data, b) just in general rather lock too much than too little and c) hope
> that the race detector can tell me when I'm wrong. Rules-lawyering, it
> would seem to me, is not a terribly promising strategy.
>
>
> On Fri, Oct 27, 2017 at 10:39 PM, T L <tapi...@gmail.com <javascript:>>
> wrote:
>
>> Go 1 memory model guarantee that the relative order of the two statements
>> will not get exchanged,
>> if there is one any of the following operation between the two statements
>> in code:
>> * a channel read
>> * a channel write
>> * a channel close
>> * a sync.Mutex.Lock()
>> * a sync.Mutex.Unlock()
>>
>> --
>> 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...@googlegroups.com <javascript:>.
>> 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.
