On Wed, Nov 30, 2016 at 7:04 PM Daniel Fanjul <
daniel.fanjul.alcu...@gmail.com> 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.
