Channels in Go

# CHAPTER 20

Channels in Go #

1. Introduction #

"Do not communicate by sharing memory; instead, share memory by communicating." This is the famous proverb of Go. To let Goroutines talk to each other safely, Go provides Channels. Think of a Channel as a pipe that connects two Goroutines. You push data into one end of the pipe, and another Goroutine pulls it out the other end.

2. Learning Objectives #

• Create a Channel using make().

• Send data into a channel.

• Receive data from a channel.

• Understand how channels naturally Block and Synchronize execution.

• Differentiate between Unbuffered and Buffered channels.

3. Creating a Channel #

// Creates a channel that can transport integers
messages := make(chan int)

4. Sending and Receiving Data (The <- Operator) #

• Sending Data: messages <- 5 (Pushes the integer 5 INTO the pipe).

• Receiving Data: result := <-messages (Pulls data OUT of the pipe and saves it to result).

5. Goroutine Synchronization (Blocking) #

• If a Goroutine sends data (ch <- 5), it will freeze and wait until another Goroutine receives the data.

• If a Goroutine tries to receive (<-ch), it will freeze and wait until data is pushed in.

This completely eliminates the need for time.Sleep! The blocking behavior automatically synchronizes our code.

package main
import "fmt"

// This function runs in a separate Goroutine
func calculateSum(a, b int, resultChan chan int) {
    sum := a + b
    fmt.Println("Goroutine: Calculation complete, sending to channel...")
    
    // Push the result into the channel
    resultChan <- sum 
}

func main() {
    resultChan := make(chan int)

    // Spawn the Goroutine
    go calculateSum(10, 20, resultChan)

    fmt.Println("Main: Waiting for the result...")
    
    // Main Goroutine FREEZES here until data arrives in the channel
    finalResult := <-resultChan 
    
    fmt.Println("Main: Received result:", finalResult)
}

*Notice: main() didn't need time.Sleep! It waited naturally at <-resultChan until the data was delivered.*

6. Deadlocks #

func main() {
    ch := make(chan string)
    
    // Attempting to send data in the main thread without a receiver ready
    ch <- "Hello" // FATAL ERROR: all goroutines are asleep - deadlock!
    
    fmt.Println(<-ch)
}

7. Buffered Channels #

// This channel can hold up to 2 strings before it blocks the sender
ch := make(chan string, 2)

ch <- "Message 1" // Doesn't block, room is available
ch <- "Message 2" // Doesn't block, room is available

// ch <- "Message 3" // If we added this, it WOULD block, because capacity is 2!

fmt.Println(<-ch)
fmt.Println(<-ch)

8. Common Mistakes #

• Deadlocks from Single-Threaded Logic: Trying to send and receive from an unbuffered channel inside the exact same function sequentially. It will deadlock instantly. Channels require at least *two* concurrent Goroutines to function.

• Leaving Channels Open: When you are completely done sending data, you should use close(ch) so receivers know no more data is coming. (Crucial for range loops over channels).

9. Best Practices #

• Prefer Unbuffered Channels: Buffered channels can hide synchronization bugs. Unbuffered channels force you to write clean, tightly synchronized concurrent logic.

10. Exercises #

1. 1. Create a function multiply(a, b int, ch chan int).

1. 2. In main, create a channel, spawn the Goroutine, and receive/print the multiplied result.

11. MCQs with Answers & Explanations #

12. Interview Preparation #

1. 1. Explain the difference between an unbuffered channel and a buffered channel.

1. 2. What causes a Deadlock in Go? Provide an example scenario.

1. 3. How do channels solve the "race condition" problems found in traditional Thread/Mutex programming?

13. Summary #

14. Next Chapter Recommendation #