I think it is simpler to create a SyncPoint with Wait and Release methods - it
is easily implemented with a WaitGroup and a Semaphore.
> On Jan 16, 2021, at 9:31 PM, Pete Wilson wrote:
>
> By ‘at the same time’ I would understand that none of them are able to see
> the counter in the wait
By ‘at the same time’ I would understand that none of them are able to see the
counter in the wait group after one member had triggered release.
That is, I believed that “release by any go routine (that is, a Wait() done by
any collaborating goroutine which saw a zero counter) " happened before
It does release them all at once. They all become ready to run at the “same
time” - the scheduler has to get them to run. Even if the release was atomic it
would make no difference in the race condition.
> On Jan 16, 2021, at 7:35 PM, Pete Wilson wrote:
>
> Makes sense.
> Thanks very much.
Makes sense.
Thanks very much.
Simpler than a double waitgroup, same overall effect.
I may have a weird use case, but maybe this might be worth adding to the
examples.
— P
> On Jan 16, 2021, at 6:14 PM, Robert Engels wrote:
>
> WaitGroups are deterministic in that sense. Whether they are all
Brian
Thanks for advice. I’ll take a look
— P
> On Jan 16, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>
> Brian Candler mailto:b.cand...@pobox.com>>: Jan 16
> 01:02PM -0800
>
> On Saturday, 16 January 2021 at 16:28:59 UTC Pete Wilson wrote:
>
> > In short, what I want to do is
WaitGroups are deterministic in that sense. Whether they are all released at
once (there is no such thing as “at once” in practice) you have a race.
You can restructure this to avoid the race. You should Add() to to the stage 1
and 2 wait groups after the Wait() returns and before you Wait()
Jake
Thanks for thoughts
My approach made the assumption that Wait() worked as advertised - all the
goroutines are released when the Wait() hits zero.
What you’re pointing out is that Wait() is in some sense racy itself.
I had assumed that no goroutine in a waitgroup was ‘released' until they
