Multiple goroutines waiting for event

[Miki Tebeka]

Greetings,

I want to have several goroutines wait for an event. There are several ways to do it - wait on a channel, sync.WaitGroup ...
Is there a "preferred" way?

Thanks,
--
Miki

[Dmitry Vyukov]

I think the "default" way is to use channels. If you can express it with channels and are satisfied with the result, then you are done. If not, then it depends on details.

[Robert Bloomquist]

Multiple goroutines waiting for an event sounds like a job for sync.Cond to me, but it really depends on what exactly is going on.  Channels work, but you'd have to send the signal as many times as you have goroutines waiting, which seems kind of inefficient to me, but I'm not all that familiar with the implementation details of sync.WaitGroup or sync.Cond.

[roger peppe]

yes, sync.Cond can be a better fit than channels for this kind of problem.

but if the event happens only once, then closing a channel works well too,
because an indeterminate number of reading goroutines can
all be woken with that single action.

one advantage of using a channel is that it is easily added to
a select with other channels where using sync.Cond would require an
extra waiting goroutine.

On 20 September 2011 08:01, Robert Bloomquist

[Kyle Lemons]

I highly recommend using channels for this.  Lock-based "broadcast" messages are very difficult to reason about, sync.Cond doubly so---for instance, the following does not work as one might expect:

        l := new(sync.Mutex)

        c := sync.NewCond(l)

        for i := 0; i < 10; i++ {

                go func() {

                        l.Lock()

                        defer l.Unlock()

                        c.Wait()

                        fmt.Println(i)

                }()

        }

        c.Broadcast()

Whereas the following works fine:

        c := make(chan bool)

        for i := 0; i < 10; i++ {

                go func() {

                        <-c

                        fmt.Println(i)

                }()

        }

        close(c)

https://gist.github.com/1229645

[Miki Tebeka]

but if the event happens only once, then closing a channel works well too,

Nice, will use that one. Thanks!

[Kevin Ballard]

On Tue, Sep 20, 2011 at 10:01 AM, Kyle Lemons <kev...@google.com> wrote:

I highly recommend using channels for this.  Lock-based "broadcast" messages are very difficult to reason about, sync.Cond doubly so---for instance, the following does not work as one might expect:

        l := new(sync.Mutex)

        c := sync.NewCond(l)

        for i := 0; i < 10; i++ {

                go func() {

                        l.Lock()

                        defer l.Unlock()

                        c.Wait()

                        fmt.Println(i)

                }()

        }

        c.Broadcast()

Am I correct in believing that this may fail because the call to c.Broadcast() may happen before all goroutines have executed c.Wait()?

-Kevin

--
Kevin Ballard
http://kevin.sb.org
kbal...@gmail.com

[Kyle Lemons]

I highly recommend using channels for this.  Lock-based "broadcast" messages are very difficult to reason about, sync.Cond doubly so---for instance, the following does not work as one might expect:

        l := new(sync.Mutex)

        c := sync.NewCond(l)

        for i := 0; i < 10; i++ {

                go func() {

                        l.Lock()

                        defer l.Unlock()

                        c.Wait()

                        fmt.Println(i)

                }()

        }

        c.Broadcast()

Am I correct in believing that this may fail because the call to c.Broadcast() may happen before all goroutines have executed c.Wait()

Precisely.  The difference is that close is persistent, broadcast is not.  I have actually seen waitgroup used in reverse of its normal way (e.g. Wait() in all of the clients, Add() in the source), but I think the channel send is clearer.

~K