ok.
Thanks both for the explanations.
On Saturday, October 28, 2017 at 2:06:06 AM UTC-4, Axel Wagner wrote:
>
> On Sat, Oct 28, 2017 at 12:58 AM, T L <tapi...@gmail.com <javascript:>>
> wrote:
>
>> 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.
>>
>
> No. My program has the following (relevant) events:
> A: go func() {…}
> B: x = 1
> C: <-ch
> D: y = 1
> E: go func() {…}
> F: close(ch)
> G: a = x
> H: b = y
>
> Now, let's look at happens-before relationships:
>
> Within a single goroutine, the happens-before order is the order expressed
>> by the program.
>
>
> B ≤ C ≤ D
> A ≤ E ≤ G ≤ H
>
> Goroutine creation
>
>
> A ≤ B, C, D
> E ≤ F
>
> Channel communication
>
>
> F ≤ C
>
> This enumerates the partial order guaranteed:
>
> As should be immediately obvious, that B/D and G/H happen concurrently (as
> defined by the memory model); there is no ordered path from one to the
> other (in either direction).
>
> Now, looking at the memory model to see what G/H are thus allowed to
> observe. We need to answer two questions to see whether we can observe
> a,b=0,1: a) is H allowed to observe D? and b) is G guaranteed to observe C?
> If a) is answered with "yes" and b) is answered with "no", then a,b=0,1 is
> valid.
>
> A read r of a variable v is allowed to observe a write w to v if both of
>> the following hold:
>> * r does not happen before w.
>> * There is no other write w' to v that happens after w but before r.
>
>
> H does not happen before D. There is no other write to y (and the only
> other write in general also does not happen before H). So both of these
> conditions are true, the answer to a) is "yes".
>
> […] r is guaranteed to observe w if both of the following hold:
>> * w happens before r.
>> * Any other write to the shared variable v either happens before w or
>> after r.
>
>
> C does not happen before G, so the first condition is violated. Thus, G is
> not guaranteed to observe C, the answer to b) is "no".
>
> Thus, the memory model allows a,b=0,1.
>
> I hope this discussion illustrates, why it's important to talk about
> multiple goroutines and observability. It certainly helped me understand
> the memory model better :)
>
> Lastly, there is this relevant quote from the page:
>
> If you must read the rest of this document to understand the behavior of
>> your program, you are being too clever.
>
>
> Best,
>
> Axel
>
>
>>
>> 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> 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.
>>>> 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...@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.
