That quote of the spec does not apply here, because there are no multiple
reads and writes. There is one write to 'result' and one method call that
will not read or write that 'result'.
On Wednesday, November 30, 2016 at 7:34:12 PM UTC+1, Jan Mercl wrote:
>
> On Wed, Nov 30, 2016 at 7:04 PM Daniel Fanjul <daniel.fan...@gmail.com
> <javascript:>> wrote:
>
> > 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 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.
>
> The specs say that the defered function executes on return from the
> function where the defer statement is executed(1). The memory model
> specifies that "Within a single goroutine, reads and writes must behave as
> if they executed in the order specified by the program.". From (1) the
> order specified is the assignment followed by the defered function
> invocation (now actually calling wg.Done()), so the proper non-race
> condition is fully covered.
>
> --
>
> -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.
