Interpretation Channels orchestrate; mutexes serialize

Channels are a feature unique to the Go language and are more abstract and difficult to understand than Goroutine. After all, the latter can be compared to threads and processes. Go Channels Are Bad and You Should Feel Bad mentions the confusion of using Channel and Mutex. I mentioned a simple program that can save the highest score of each player in a game. The authors use channel and Mutex respectively to achieve this function.

The channel version

First, define the Game structure:

type Game struct {
  bestScore int
  scores    chan int
}
Copy the code

Instead of using mutex protection, bestScore uses a separate Goroutine to receive data from a channel and then update its status.

func (g *Game) run() {
  for score := range g.scores {
    if g.bestScore < score {
      g.bestScore = score
    }
  }
}
Copy the code

The constructor is then defined to start a game

func NewGame() (g *Game) {
  g = &Game{
    bestScore: 0,
    scores:    make(chan int),
  }
  go g.run()
  return g
}
Copy the code

Next, the Player interface is defined to return the Player’s score and error to indicate that the Player has abandoned the match.

type Player interface {
  NextScore() (score int, err error)
}
Copy the code

The game receives all players’ scores through channels

func (g *Game) HandlePlayer(p Player) error { for { score, err := p.NextScore() if err ! = nil { return err } g.scores <- score } }Copy the code

In the end, Game was able to achieve thread-safe recording of a player’s highest score, and everything worked out perfectly.

The implementation was so successful that the game service created many games at once. After a while, you find that players occasionally stop playing, and many games no longer have players playing, but there is no mechanism to stop the loop. You are being crushed by the abandoned (*Game).run goroutine.

The mutex version

type Game struct { mtx sync.Mutex bestScore int } func NewGame() *Game { return &Game{} } func (g *Game) HandlePlayer(p Player) error { for { score, err := p.NextScore() if err ! = nil { return err } g.mtx.Lock() if g.bestScore < score { g.bestScore = score } g.mtx.Unlock() } }Copy the code

Channels are used for orchestration and mutex is used for serialization

If you were implementing it, would you rather use channel or Mutex? On the information provided so far, there is no doubt that I would choose the latter.

What’s the difference between Channel and Mutex? When should channel be used?

Actually Rob Pike sums it up in Go Proverbs:

Channels orchestrate; mutexes serialize.

Translation is a

Channels are used for orchestration and mutex is used for serialization

This sentence is simple, but also abstract. How to understand it?

channel vs mutex

choreography

To talk more about channel layouts, take a look at the Go Concurrency Patterns search example:

/*
Example: Google Search 3.0
Given a query, return a page of search results (and some ads).
Send the query to web search, image search, YouTube, Maps, News, etc. then mix the results.
*/
c := make(chan Result)
go func() { c <- First(query, Web1, Web2) } ()
go func() { c <- First(query, Image1, Image2) } ()
go func() { c <- First(query, Video1, Video2) } ()
timeout := time.After(80 * time.Millisecond)
for i := 0; i < 3; i++ {
    select {
    case result := <-c:
        results = append(results, result)
    case <-timeout:
        fmt.Println("timed out")
        return
    }
}
Copy the code

The parallel structure of the program remains unchanged regardless of whether the program is executed on several core machines, as follows:

When it comes to programming, it can be compared with Kubernetes for service orchestration. If a Goroutine is a container for K8S, a channel is a network of K8S (e.g., overlay). Kubernetes enables users to deploy and scale their microservices applications on any scale, and Golang enables applications to execute and scale fully in parallel on any number of cpus.

conclusion