Re: [go-nuts] Understanding go routine heap

[Marvin Renich]

* 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 and the 
> effect of writing to "result" could be not visible after wg.Wait().

I don't believe that https://golang.org/ref/mem should necessarily be
required to mention every library routine that guarantees a
happens-before relationship.  It should document the lowest-level
language features, and then the documentation for the library routines
should make a claim that their implementations guarantee such a
relationship.

For sync.WaitGroup, the documentation says "A WaitGroup waits for a
collection of goroutines to finish."  For func (*WaitGroup) Wait, the
documentation says "Wait blocks until the WaitGroup counter is zero."
Perhaps the documentation should explicitly mention the Go Memory Model
and state that it is implemented in such a way that a happens-before
relationship exists, but what would be the purpose of WaitGroup if it
didn't guarantee such a relationship?

I believe the happens-before relationship is implied by the current
documentation and the intended use-case for WaitGroup, even if it is not
explicitly stated.

I agree with others in this thread who have stated that there is no race
condition.  I disagree with the implication that WaitGroup, as
documented, could be implemented differently in such a way as to both
conform to the Go 1 compatibility promise and fail to provide an
appropriate happens-before relationship.

...Marvin

-- 
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.

Re: [go-nuts] Understanding go routine heap

[Konstantin Shaposhnikov]

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 visible after wg.Wait().

On Saturday, 20 August 2016 07:43:52 UTC+1, Jan Mercl wrote:
>
> 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 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.

Re: [go-nuts] Understanding go routine heap

[Dave Cheney]

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 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.

Re: [go-nuts] Understanding go routine heap

[Jan Mercl]

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 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.

[go-nuts] Understanding go routine heap

[Yulrizka]

Dear gophers

I have discussion with my colleague about this code


func process() *foo {
var result *foo

var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
result = {1}
}()

wg.Wait()

return result
}

He argues that this is heap race condition. 
the result variable which lives on the heap of the go routine is not 
guaranteed to be synced to the result on the process func's thread.
The better approach would be using a channel instead. I may agree with him 
that probably using channel is better.
But I would like to understand the reasoning behind that.

I thought that `wg.Wait()` guaranteed that the process func's thread wait 
until go func is finsihed and sync everything so that the result variable 
is safe to return.

Probably I'm missing some knowledge about how go routine work.

1. Does the process func thread has separate heap than the go func? If so 
how does is sync?
2. From I read so far, when go routine needed a bigger stack, it allocates 
memory from the heap. So what happened for object that is allocated inside 
of the go routine once the go routine returns?

I there article of source that go into details about this I would love to 
read it :)

Warm regards,

-- 
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.