Golang Concurrency Tricks
Golang concurrency model based on goroutines and channels is not free from sharp edges.
This page intends both (1) to collect helpful guidelines for writing concurrent code in Go and (2) to bring up well known potential issues to attention.
Channel Hints
-
C1. Some channel operations cause runtime panic:
- P1. Closing the nil channel.
- P2. Closing a closed channel.
- P3. Sending on a closed channel.
-
C2. Do not close a channel from a receiver goroutine. Closing the channel from a receiver could make future sender goroutines to panic.
-
C3. If a channel has multiple senders,do not close the channel from a sender goroutine. Closing the channel from a sender could make future sender goroutine to panic.
Alternatively,coordinate senders so that only the last sender to leave closes the channel (for instance by using either atomic int or sync.WaitGroup)
Last one sender to leave,turns off the lights,which can be controlled by a atomic int.
https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/oZFSD-oMAwAJ -
C4. It is not required to close an unused channel. If no goroutine is left referencing the channel,it will be garbage collected.
Note that it is only necessary to close a channel if the receiver is looking for a close. Closing the channel is a control signal on the channel indicating that no more data follows.
https://groups.google.com/forum/#!msg/golang-nuts/pZwdYRGxCIk/qpbHxRRPJdUJ -
C5. Channels work well when enclosed in a 'select'.
If you are ever using a channel outside of a select in production code,you are probably doing it wrong.
https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/j5eHsPc2AwAJ -
C6. If you need bidirectional communication between two goroutines,consider using two unidirectional channels. Thus both channel sides will be able to use the close idiom to signal termination.
-
C7. Beware: one sender goroutine risks blocking indefinitely when writing on a channel if there is no goroutine left receiving from it.
-
C8. When designing a goroutine which provides service through channels,and at some point a running goroutine is no longer needed,consider exactly how it will finish. Otherwise,unused goroutines may leak idly servicing an unattended channel.
-
C9. Keep Dave Cheney's Four Channel Axioms in mind:
- A1. A send to a nil channel blocks forever.
- A2. A receive from a nil channel blocks forever. (Why?Here is why.Example.)
- A3. A send to a closed channel panics.
- A4. A receive from a closed channel returns the zero value immediately.
-
C10. 'select' never selects a blocking case.
Goroutine Hints
-
G1. Only one goroutine accessing a piece of data is good practice.
In particular,consider structuring your program so that only one goroutine at a time is ever responsible for a particular piece of data.
https://golang.org/doc/faq#What_operations_are_atomic_What_about_mutexes -
G2.runtime.Goexit()terminates the goroutine that calls it.
See also:
- http://www.slideshare.net/cloudflare/a-channel-compendium
- https://github.com/golang/go/wiki/LearnConcurrency
- http://dave.cheney.net/2014/03/19/channel-axioms
- Repository: git clonehttps://github.com/udhos/golang-concurrency-tricks.git