Re: [go-nuts] Re: Understanding go routine heap

On Wed, Nov 30, 2016 at 2:35 PM, Daniel Fanjul wrote: > Err... I think you understood the opposite. > > A no answer would mean this is that issue. A yes answer means the mutex is > still not enough. I said yes. I understood that, but the only implication I could

Re: [go-nuts] Re: Understanding go routine heap

Err... I think you understood the opposite. A no answer would mean this is that issue. A yes answer means the mutex is still not enough. I said yes. On Wednesday, November 30, 2016 at 11:23:49 PM UTC+1, Ian Lance Taylor wrote: > > On Wed, Nov 30, 2016 at 2:01 PM, Daniel Fanjul >

Re: [go-nuts] Re: Understanding go routine heap

On Wed, Nov 30, 2016 at 2:01 PM, Daniel Fanjul wrote: > I was going to answer no, but after a careful review of the go memory model > section regarding locks, I am replying: yes, I would. > > Because the memory model only specifies "happens before" restrictions >

Re: [go-nuts] Re: Understanding go routine heap

I was going to answer no, but after a careful review of the go memory model section regarding locks, I am replying: yes, I would. Because the memory model only specifies "happens before" restrictions between calls to Lock() and Unlock() and that is not this case. "For any sync.Mutex or

Re: [go-nuts] Re: Understanding go routine heap

On Wed, Nov 30, 2016 at 1:31 PM, Daniel Fanjul wrote: > Case A: because there is a write and then a method call that does not touch > that variable. The go memory model apply only to reads and writes of the > same variables. So any possible reordering in this

Re: [go-nuts] Re: Understanding go routine heap

Case A: because there is a write and then a method call that does not touch that variable. The go memory model apply only to reads and writes of the same variables. So any possible reordering in this scenario fulfills "the reordering does not change the behavior within that goroutine as defined

Re: [go-nuts] Re: Understanding go routine heap

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)

Re: [go-nuts] Re: Understanding go routine heap

On Wed, Nov 30, 2016 at 10:04 AM, Daniel Fanjul 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 = {1}" might still happen concurrently. > > I think the

Re: [go-nuts] Re: Understanding go routine heap

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

Re: [go-nuts] Re: Understanding go routine heap

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 = {1}" might still happen concurrently. > > I think the problem is the semantics of the defer and the

Re: [go-nuts] Re: Understanding go routine heap

Hi, I still don't understand this issue completely. Sure, the call to *wg.Done()* will "happen before" *wg.Wait()* finishes, but the assignment *"result = {1}"* might still happen concurrently. I think the problem is the semantics of the *defer* and the discussion is reduced completely to the

Re: [go-nuts] Re: Understanding go routine heap

On Tue, Aug 23, 2016 at 3:14 AM, Yulrizka wrote: > > But the case here is indeed as Marvin explained, There is race condition. > But in my example, I make sure that wg done is to protect result pointer > before calling it to caller. > > with this structure some one could

[go-nuts] Re: Understanding go routine heap

Ah sorry I've missed that in the email. On Tuesday, August 23, 2016 at 12:48:04 PM UTC+2, T L wrote: > > > > On Tuesday, August 23, 2016 at 6:14:19 PM UTC+8, Yulrizka wrote: >> >> Thank you for the explanation and the code sample >> >> But the case here is indeed as Marvin explained, There is

Re: [go-nuts] Re: Understanding go routine heap

* Joubin Houshyar [160822 12:36]: > On Monday, August 22, 2016 at 10:27:06 AM UTC-4, Marvin Renich wrote: > > * Joubin Houshyar [160822 09:47]: > > > > > > Your firend is correct that using a WaitGroup here does not in anyway > > > address concurrent

Re: [go-nuts] Re: Understanding go routine heap

On Monday, August 22, 2016 at 10:27:06 AM UTC-4, Marvin Renich wrote: > > * Joubin Houshyar [160822 09:47]: > > > > > > On Saturday, August 20, 2016 at 2:29:41 AM UTC-4, Yulrizka wrote: > > > func process() *foo { > > > var result *foo > > > > > > var wg

[go-nuts] Re: Understanding go routine heap

On Monday, August 22, 2016 at 9:47:03 PM UTC+8, Joubin Houshyar wrote: > > > > On Saturday, August 20, 2016 at 2:29:41 AM UTC-4, Yulrizka wrote: >> >> Dear gophers >> >> I have discussion with my colleague about this code >> >> >> func process() *foo { >> var result *foo >> >> var wg

Re: [go-nuts] Re: Understanding go routine heap

* Joubin Houshyar [160822 09:47]: > > > On Saturday, August 20, 2016 at 2:29:41 AM UTC-4, Yulrizka wrote: > > func process() *foo { > > var result *foo > > > > var wg sync.WaitGroup > > wg.Add(1) > > go func() { > > defer wg.Done() > > result

[go-nuts] Re: Understanding go routine heap

On Saturday, August 20, 2016 at 2:29:41 AM UTC-4, Yulrizka wrote: > > 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

Re: [go-nuts] Re: Understanding go routine heap

Yes like Jan previously said. It is the very use case WaitGroup was developed for. On Sun, Aug 21, 2016, 15:45 T L wrote: > > > On Saturday, August 20, 2016 at 2:29:41 PM UTC+8, Yulrizka wrote: >> >> Dear gophers >> >> I have discussion with my colleague about this code >>

[go-nuts] Re: Understanding go routine heap

On Saturday, August 20, 2016 at 2:29:41 PM UTC+8, Yulrizka wrote: > > 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