Channel in Golang and use case – part I

Preamble

• Concurrency programming has always been something that gophers are proud of compared to other languages. Popular languages ​​like JAVA, C# implements concurrency using threads, and GO uses 2 built-in features – goroutine and channels. They make accessing or managing concurrent jobs much easier and less costly.
• Goroutines are essentially functions or methods that are executed independently and concurrently but can still be connected. And the channel is the communication channel between those goroutines.

Channel

• Channels provide a way for goroutines to communicate with each other and synchronize their execution.
• When it comes to communication, there must be two ways – sending and receiving. Channels are the same, goroutine can send data to the channel and get data from the channel.
• Channels are classified into two types: buffer channels and unbuffered channels . For unbuffer channel , when a goroutine A sends data, it will block goroutine A again until any go routine comes to get the data. And vice versa, the buffer channel will be lighter, without any strict requirements, it has a certain capacity and does not need any receiver goroutine . However, when the capicity reaches the limit, it also needs goroutines to retrieve the data.

Play with unbuffered channel

• From main goroutine, send data to channel without receiver goroutine
  
  func main() { /* Without receiver goroutine from main goroutine */ chanelAtMainRoutine := make(chan int) chanelAtMainRoutine <- 5 } result: fatal error: all goroutines are asleep - deadlock!

  1 2 3 4 5 6 7 8

  func main() {    /* Without receiver goroutine from main goroutine */    chanelAtMainRoutine := make(chan int)    chanelAtMainRoutine <- 5 } result:    fatal error: all goroutines are asleep - deadlock!

  
  The program crashed (terminated) and reported an error because the main goroutine was blocked for a period of time.
• From anonymous goroutine, send data to channel without receiver goroutine
  
  func main() { /* Without receiver from anonymous goroutine */ chanelAtMainRoutine := make(chan int) go func() { chanelAtMainRoutine <- 5 }() fmt.Println("Completing ...") } result: Completing ...

  1 2 3 4 5 6 7 8 9 10 11

  func main() {     /* Without receiver from anonymous goroutine */     chanelAtMainRoutine := make(chan int)     go func() {         chanelAtMainRoutine <- 5     }()     fmt.Println("Completing ...") } result:     Completing ...

  
  It is completely correct that the program is not terminated or crashed here even though the channel has not yet had a goroutine to get data. The channel actually only blocks anonymous goroutine and the main goroutine continues to run and prints the result “completing ….”
• From main goroutine, send data to channel with receiver goroutine
  
  func main() { /* With receiver from main goroutine */ chanelAtMainRoutine := make(chan int) go func() { fmt.Println("Start getting value from channel ...") <-chanelAtMainRoutine fmt.Println("Complete getting value from channel ...") }() chanelAtMainRoutine <- 5 fmt.Println("Completing ...") } result: Start getting value from channel ... Complete getting value from channel ... Completing ...

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  func main() {     /* With receiver from main goroutine */     chanelAtMainRoutine := make(chan int)     go func() {         fmt.Println("Start getting value from channel ...")         <-chanelAtMainRoutine         fmt.Println("Complete getting value from channel ...")     }()     chanelAtMainRoutine <- 5     fmt.Println("Completing ...") } result:     Start getting value from channel ...     Complete getting value from channel ...     Completing ...

  
  The recevier goroutine appears and the main goroutine is no longer locked. However, if in the process of running func main many times, we will see the line ” Complete getting value from channel … ” will sometimes not be printed to the console screen because at the moment the statement ” <-chanelAtMainRoutine ” is Once execution is done, the golang runtime scheduler actually switches to the main goroutine and if the transition is fast enough, no statement will be able to execute immediately after. To test this, I will perform a one-second sleep on the recevier goroutine.
  Increase time at recevier goroutine
  
  func main() { /* Increase time at receiver goroutine */ chanelAtMainRoutine := make(chan int) go doBigJob(chanelAtMainRoutine) chanelAtMainRoutine &lt;- 5 fmt.Println("Completing ...") } func doBigJob(ch &lt;-chan int) { fmt.Println("Start getting value from channel ...") &lt;-ch time.Sleep(time.Second * 1) fmt.Println("Complete getting value from channel ...") } result: Start getting value from channel ... // Cannot see "Complete getting value ..." any more Completing ...

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  func main() {     /* Increase time at receiver goroutine */     chanelAtMainRoutine := make(chan int)     go doBigJob(chanelAtMainRoutine)     chanelAtMainRoutine <- 5     fmt.Println("Completing ...") }   func doBigJob(ch <-chan int) {     fmt.Println("Start getting value from channel ...")     <-ch     time.Sleep(time.Second * 1)     fmt.Println("Complete getting value from channel ...") } result:     Start getting value from channel ... // Cannot see "Complete getting value ..." any more     Completing ...

Ending

• In principle, unbuffered channel works like table tennis. When the ball is served, someone must help. In the above example we can switch to using buffer channel , so that the fmt.Println(“Complete getting value from channel …”) statement is executed as soon as the channel’s data is retrieved.
• Source code
• See you in the next part. We will go to learn more about buffered channel and its use cases.