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 draw is that
mutexes are useless.
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
> > wrote:
>
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
> between calls to Lock() and Unlock
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 sync.RWMu
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 scenario fulfills "the
> reordering do
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
On Wed, Nov 30, 2016 at 12:36 PM, Daniel Fanjul
wrote:
> 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.
>
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) hap
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 = &foo{1}" might still happen concurrently.
>
> I think the problem is the semantics of t
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 Dan
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 discus
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 = &foo{1}"* might still happen concurrently.
I think the problem is the semantics of the *defer* and the discussion is
reduced completely to
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 easily introduce a race co
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 race
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 race condition.
>
Marvin says there is no race condition in your start comment.
> But in my example, I make sur
Thank you for the explanation and the code sample
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 easily introduce a race condition
* 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 access to the heap variable 'result'.
I
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 sync.WaitGroup
> > >
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 sync
* 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 = &foo{1}
> > }()
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 =
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
>>
>>
>> func process() *
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 =
23 matches
Mail list logo
