Multiple goroutines listening on one channel

by

Yes, it’s complicated, But there are a couple of rules of thumb that should make things feel much more straightforward.

  • prefer using formal arguments for the channels you pass to go-routines instead of accessing channels in global scope. You can get more compiler checking this way, and better modularity too.
  • avoid both reading and writing on the same channel in a particular go-routine (including the ‘main’ one). Otherwise, deadlock is a much greater risk.

Here’s an alternative version of your program, applying these two guidelines. This case demonstrates many writers & one reader on a channel:

c := make(chan string)

for i := 1; i <= 5; i++ {
    go func(i int, co chan<- string) {
        for j := 1; j <= 5; j++ {
            co <- fmt.Sprintf("hi from %d.%d", i, j)
        }
    }(i, c)
}

for i := 1; i <= 25; i++ {
    fmt.Println(<-c)
}

http://play.golang.org/p/quQn7xePLw

It creates the five go-routines writing to a single channel, each one writing five times. The main go-routine reads all twenty five messages – you may notice that the order they appear in is often not sequential (i.e. the concurrency is evident).

This example demonstrates a feature of Go channels: it is possible to have multiple writers sharing one channel; Go will interleave the messages automatically.

The same applies for one writer and multiple readers on one channel, as seen in the second example here:

c := make(chan int)
var w sync.WaitGroup
w.Add(5)

for i := 1; i <= 5; i++ {
    go func(i int, ci <-chan int) {
        j := 1
        for v := range ci {
            time.Sleep(time.Millisecond)
            fmt.Printf("%d.%d got %d\n", i, j, v)
            j += 1
        }
        w.Done()
    }(i, c)
}

for i := 1; i <= 25; i++ {
    c <- i
}
close(c)
w.Wait()

This second example includes a wait imposed on the main goroutine, which would otherwise exit promptly and cause the other five goroutines to be terminated early (thanks to olov for this correction).

In both examples, no buffering was needed. It is generally a good principle to view buffering as a performance enhancer only. If your program does not deadlock without buffers, it won’t deadlock with buffers either (but the converse is not always true). So, as another rule of thumb, start without buffering then add it later as needed.

More Related Contents:

  1. No output from goroutine
  2. Is it safe to read a function pointer concurrently without a lock?
  3. How to broadcast message using channel
  4. Can I concurrently write different slice elements
  5. Prevent the main() function from terminating before goroutines finish in Golang
  6. Goroutine does not execute if time.Sleep included
  7. Sudden Increase in the number of goroutines after upgrade [closed]
  8. Is this an idiomatic worker thread pool in Go?
  9. How to stop a goroutine
  10. cancel a blocking operation in Go
  11. Close multiple goroutine if an error occurs in one in go
  12. How to wait for all goroutines to finish without using time.Sleep?
  13. Example for sync.WaitGroup correct?
  14. How safe are Golang maps for concurrent Read/Write operations?
  15. Number of threads used by Go runtime
  16. If I am using channels properly should I need to use mutexes?
  17. Why Golang cannot generate json from struct with front lowercase character?
  18. Max number of goroutines
  19. How to collect values from N goroutines executed in a specific order?
  20. Closing channel of unknown length
  21. How do goroutines work? (or: goroutines and OS threads relation)
  22. anonymous struct and empty struct
  23. How to recover from concurrent map writes?
  24. Are slices passed by value?
  25. What are the use(s) for struct tags in Go?
  26. Optional Parameters in Go?
  27. In Go, how do I capture stdout of a function into a string?
  28. How can I access a struct field with generics (type T has no field or method)?
  29. Does Go have standard Err variables?
  30. Why a generic can’t be assigned to another even if their type arguments can?

Leave a Comment