Advanced Concurrency Patterns

# CHAPTER 21

Advanced Concurrency Patterns #

1. Introduction #

2. Learning Objectives #

• Use sync.WaitGroup to wait for a fleet of Goroutines to finish.

• Listen to multiple channels simultaneously using select.

• Understand the Worker Pool pattern.

• Identify Race Conditions.

• Use sync.Mutex to lock shared memory safely.

3. Synchronizing with sync.WaitGroup #

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, wg *sync.WaitGroup) {
    // 3. Mark this Goroutine as 'Done' (subtracts 1 from counter) right before exiting
    defer wg.Done() 
    
    fmt.Printf("Worker %d starting...\n", id)
    time.Sleep(time.Second) // Simulate work
    fmt.Printf("Worker %d done.\n", id)
}

func main() {
    var wg sync.WaitGroup

    for i := 1; i <= 3; i++ {
        // 1. Add 1 to the counter
        wg.Add(1) 
        // 2. Spawn Goroutine (CRITICAL: Pass WaitGroup as a pointer!)
        go worker(i, &wg) 
    }

    // 4. Block (freeze) main until the counter hits 0
    wg.Wait() 
    fmt.Println("All workers finished!")
}

4. Multiplexing with the select Statement #

func main() {
    api1 := make(chan string)
    api2 := make(chan string)

    go func() {
        time.Sleep(2 * time.Second)
        api1 <- "Response from API 1"
    }()

    go func() {
        time.Sleep(1 * time.Second) // This one is faster!
        api2 <- "Response from API 2"
    }()

    // select will block until EITHER api1 or api2 sends data
    select {
    case res1 := <-api1:
        fmt.Println(res1)
    case res2 := <-api2:
        fmt.Println(res2) // This will print because it arrives first!
    }
}

5. Race Conditions #

*Scenario:* Two bank transactions try to deposit $5 into an account that has $10 simultaneously. Both read $10, both add $5, both write $15. The final balance should be $20, but it is corrupted to $15!

6. Memory Locking with sync.Mutex #

type SafeCounter struct {
    mu    sync.Mutex // The Lock
    value int        // The shared variable
}

func (c *SafeCounter) Increment(wg *sync.WaitGroup) {
    defer wg.Done()
    
    c.mu.Lock()   // 1. Lock the door
    c.value++     // 2. Safely modify data (No other Goroutine can touch this right now)
    c.mu.Unlock() // 3. Unlock the door
}

func main() {
    counter := SafeCounter{}
    var wg sync.WaitGroup

    // Spawn 1000 Goroutines trying to increment the counter at the exact same time
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go counter.Increment(&wg)
    }

    wg.Wait()
    // Because of the Mutex, the value will safely be exactly 1000.
    fmt.Println("Final Counter Value:", counter.value) 
}

7. Common Mistakes #

• Passing WaitGroup by Value: If you write go worker(i, wg) instead of go worker(i, &wg), you pass a *copy* of the WaitGroup. When the worker calls .Done(), it decrements the copy, not the original. main will Wait() forever (Deadlock).

• Forgetting to Unlock a Mutex: If a Goroutine panics or returns early before calling c.mu.Unlock(), the lock remains closed forever, and all other Goroutines will freeze indefinitely. Always use defer c.mu.Unlock()!

8. Best Practices #

• Test for Race Conditions: Go has a built-in tool to detect memory corruption. Run your code using go run -race main.go. If there are any race conditions, the compiler will aggressively warn you!

9. Exercises #

1. 1. Write a program that uses a sync.WaitGroup.

1. 2. Spawn 5 Goroutines that simply print "Processing...".

1. 3. Ensure main waits for all 5 to finish before printing "Done".

10. MCQs with Answers & Explanations #

11. Interview Preparation #

1. 1. You have a slice of URLs and you want to download all of them concurrently, but you need main to wait until they are all downloaded. How do you architect this? (Answer: WaitGroup).

1. 2. Explain the difference between using Channels for synchronization vs using a Mutex. (Answer: Channels pass data ownership. Mutex locks shared state).

12. Summary #

13. Next Chapter Recommendation #