Yes, I saw your assert and I trust it but I don't see how that answers my
question.
There are 4 things that we expect to happen in order:
1) assignment to *result,*
2) call to *wg.Done()*,
3) call to *wg.Wait()*,
4) read of *result*.
So there is no race condition if we can prove:
A) that (1) happens before (2),
B) that (2) happens before (3),
C) and that (3) happens before (4).
I understand that B) is true, because of the WaitGroup spec and because of
your assertion. I don't see how it affects the other two points.
I fail to prove A). How does the spec ensure that (1) happens before (2)?
The spec would ensure it if both actions accessed the same variable, but
they actually do not.
I would expect the spec to say something like "all statements of the
function/method happens before the call to the deferred functions/methods,
regardless the variables they may access"
Now I realize that I also fail to prove C). I am probably missing some
obvious detail now. I am sorry if that is the case.
I would expect something like "all statements of the function/method happen
before the read of the variable that holds the value to be returned,
regardless the variables they may access"
On Wednesday, November 30, 2016 at 8:42:59 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Nov 30, 2016 at 10:04 AM, Daniel Fanjul
> <daniel.fan...@gmail.com <javascript:>> wrote:
> >
> > I still don't understand this issue completely.
> >
> > Sure, the call to wg.Done() will "happen before" wg.Wait() finishes, but
> the
> > assignment "result = &foo{1}" might still happen concurrently.
> >
> > I think the problem is the semantics of the defer and the discussion is
> > reduced completely to the question: is the assignment "result = &foo{1}"
> > going to *happen before" the deferred called to "wg.Done()"?
>
> I am asserting that the wg.Done is a store-release and the wg.Wait is
> a load-acquire.
>
>
> > I don't see any occurrence of 'defer' in https://golang.org/ref/mem nor
> a
> > proper description in https://golang.org/ref/spec#Defer_statements, so
> I
> > feel inclined to conclude this behavior is undefined by the spec.
>
> I don't see why the spec needs to say anything beyond what it already
> says about defer statements.
>
> What kind of statement do you think needs to be added?
>
> Ian
>
--
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.
