On Sat, Aug 20, 2016, 12:34 Konstantin Shaposhnikov <
k.shaposhni...@gmail.com> wrote:
> The code might be race free for the current Go implementation but I don't
> think this behaviour is documented.
>
It does not have to. There's no way to implement the documented behavior of
sync.Waitgroup suc
* Konstantin Shaposhnikov [160820 06:34]:
> The code might be race free for the current Go implementation but I don't
> think this behaviour is documented.
>
> https://golang.org/ref/mem doesn't mention sync.WaitGroup at all. So
> wg.Done() doesn't necessarily happen before wg.Wait() returns a
I may be trying to suggest more than I properly understand, but looking at
src for WaitGroup,
- Done() calls and Add(-1) which in turn calls atomic.AddUint64() that
should be a store-release
- Wait() calls a atomic.LoadUint64() that should be a load-acquire
So anything written before calling D
The code might be race free for the current Go implementation but I don't
think this behaviour is documented.
https://golang.org/ref/mem doesn't mention sync.WaitGroup at all. So
wg.Done() doesn't necessarily happen before wg.Wait() returns and the
effect of writing to "result" could be not vi
I haven't run the code under the race detector (hint, do this and you'll have
the official answer) but I don't believe wg.Wait creates a happens before event
that ensures the assignment to result will be visible to other goroutine.
--
You received this message because you are subscribed to the
On Sat, Aug 20, 2016 at 8:29 AM Yulrizka wrote:
> He argues that this is heap race condition.
I don't know what is a heap race condition but the code is race free.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from th
