I'm reflecting on John Graham-Cumming's Channel Compendium talk at GopherCon: Specifically, where he suggests using channel close() as a barrier synchronization method.

// example from slide 10 of https://github.com/gophercon/2014-talks/blob/master/John_Graham-Cumming_A_Channel_Compendium.pdf

func worker(start chan bool) {
  <- start
  // ... do stuff
}

func main() {
  start := make(chan bool)
  for i := 0; i < 100; i++ {"
    go worker(start)"
  }
  close(start)
  // ... all workers running now (line 12)
}

First a quick observation: there's no *guarantee* that all (or even any) of the workers have running by the the time (line 12) is encountered right? It is non-deterministic is it not? I thought that, for the moment assuming without loss of generality that we are on a single thread, that execution could proceed straight on past the close(), so actually I *don't* know that all workers are running by line 12, right?

Then on to my question:  Q: If close() is a reasonable way to implement barrier synchronization, I wondered about how to reset such a barrier; i.e. can I re-open a channel?  Of course I could over-write a global channel variable with a reference to a new open channel, but I have no guarantee that the write to a global channel would be atomic, right? (i.e. if the global variable reference was multiple words, could it ever be read in a half-written state)?

If not, it doesn't seem like close() makes for a very good barrier after all.

Thanks.

Jason

On Wed, May 7, 2014 at 10:33 AM, Jason E. Aten <j.e....@gmail.com> wrote:
> I'm reflecting on John Graham-Cumming's Channel Compendium talk at
> GopherCon: Specifically, where he suggests using channel close() as a
> barrier synchronization method.
>
> // example from slide 10 of
> https://github.com/gophercon/2014-talks/blob/master/John_Graham-Cumming_A_Channel_Compendium.pdf
>
> func worker(start chan bool) {
>   <- start
>   // ... do stuff
> }
>
> func main() {
>   start := make(chan bool)
>   for i := 0; i < 100; i++ {"
>     go worker(start)"
>   }
>   close(start)
>   // ... all workers running now (line 12)
> }
>
> First a quick observation: there's no *guarantee* that all (or even any) of
> the workers have running by the the time (line 12) is encountered right?

From the perspective of the goroutine running main() all the
goroutines are running.
It doesn't matter if they are running from their own perspectives.

If main() wants to communicate with those goroutines then it will
have to do some kind of synchronisation and wait for them to catch up.

> Then on to my question:  Q: If close() is a reasonable way to implement
> barrier synchronization, I wondered about how to reset such a barrier; i.e.
> can I re-open a channel?

You can't re-open a channel, that would be lying.

>  Of course I could over-write a global channel
> variable with a reference to a new open channel, but I have no guarantee
> that the write to a global channel would be atomic, right? (i.e. if the
> global variable reference was multiple words, could it ever be read in a
> half-written state)?

Yes, you can't 'reset' the barrier. So you'd have a different solution
if that was a requirement.

> If not, it doesn't seem like close() makes for a very good barrier after
> all.

Not if you need to reset it.

On Wed, May 7, 2014 at 4:33 AM, Jason E. Aten <j.e....@gmail.com> wrote:
> I'm reflecting on John Graham-Cumming's Channel Compendium talk at
> GopherCon: Specifically, where he suggests using channel close() as a
> barrier synchronization method.
>
> // example from slide 10 of
> https://github.com/gophercon/2014-talks/blob/master/John_Graham-Cumming_A_Channel_Compendium.pdf
>
> func worker(start chan bool) {
>   <- start
>   // ... do stuff
> }
>
> func main() {
>   start := make(chan bool)
>   for i := 0; i < 100; i++ {"
>     go worker(start)"
>   }
>   close(start)
>   // ... all workers running now (line 12)
> }
>
> First a quick observation: there's no *guarantee* that all (or even any) of
> the workers have running by the the time (line 12) is encountered right? It
> is non-deterministic is it not? I thought that, for the moment assuming
> without loss of generality that we are on a single thread, that execution
> could proceed straight on past the close(), so actually I *don't* know that
> all workers are running by line 12, right?

Correct

> Then on to my question:  Q: If close() is a reasonable way to implement
> barrier synchronization, I wondered about how to reset such a barrier; i.e.
> can I re-open a channel?  Of course I could over-write a global channel
> variable with a reference to a new open channel, but I have no guarantee
> that the write to a global channel would be atomic, right? (i.e. if the
> global variable reference was multiple words, could it ever be read in a
> half-written state)?

If somebody is reading the global variable concurrently with the
write, then you are already in trouble, because it can read the
reference to the old channel and block on it forever. If nobody is
reading the variable, then there is no need to make it atomic.

> If not, it doesn't seem like close() makes for a very good barrier after
> all.
>
> Thanks.
>
> Jason
>

Then I just have to think in terms of allocating new channels for done and ackdone on each fan-out, and it should work fine to use close(done) on a channel done to indicate shutdown.

$ go test -run=run -bench=BenchmarkChanProdCons100 runtime
BenchmarkChanProdCons100 50000000        60.1 ns/op
> 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