One of Go's greatest strengths is its simplicity, especially when it comes to concurrency. In other languages, writing concurrent code often involves:

• Complex system threads
• Third-party frameworks
• Separate processes (e.g., Python)

Go offers lightweight concurrency using goroutines, managed by the Go runtime.

---

Sequential vs Concurrent Execution

Here’s some basic sequential code:

DoSomething()
DoSomething()
// each sleeps 5 seconds

Running this takes 10 seconds total.

---

Concurrent Execution with go Keyword

To run functions concurrently:

go DoSomething()
go DoSomething()

Each call runs in a goroutine — a lightweight thread managed by Go’s runtime.

However, this code exits immediately. Why?

Because the main function finishes before the goroutines complete. Go doesn’t wait for them.

---

Synchronizing Goroutines with sync.WaitGroup

To wait for concurrent operations to finish, we use a WaitGroup from the sync package.

Steps:

1. Import sync
2. Create a wait group:

var wg sync.WaitGroup

3. Add number of goroutines:

wg.Add(2)

4. Inside each goroutine:

go func() {
    defer wg.Done()
    DoSomething()
}()

5. After launching goroutines:

wg.Wait() // blocks until counter is 0

Full Example:

var wg sync.WaitGroup
wg.Add(2)

go func() {
    defer wg.Done()
    DoSomething()
}()

go func() {
    defer wg.Done()
    DoSomething()
}()

wg.Wait()

⏱️ Now it takes 5 seconds, not 10 — success!

---

Using Concurrency in Our Application

We can parallelize file processing:

for _, name := range filenames {
    go func(name string) {
        defer wg.Done()
        process(name)
    }(name)
}

We need to:

• Replace continue with return inside anonymous functions.
• Use wg.Add(len(filenames))
• Use wg.Wait() at the end

---

Bug! Race Condition Detected 🐞

Sometimes we get:

• 💥 Panics
• 🌀 Jumbled output

This is a race condition.

Why?

We're mutating shared state concurrently:

• tabwriter.Writer → used in count.Print()
• totals → modified with Add()

---

Solving Race Conditions with sync.Mutex

Go provides mutexes to prevent concurrent access to shared state.

Usage:

var mu sync.Mutex

mu.Lock()
defer mu.Unlock()

// critical section

Wrap mutations to totals and writer like so:

mu.Lock()
defer mu.Unlock()

totals.Add(count)
count.Print(writer)

This ensures only one goroutine at a time can mutate shared state.

---

⚠️ Deadlocks

If you forget to Unlock(), your program may deadlock — freeze indefinitely.

Go detects this and will panic: all goroutines are asleep - deadlock!

Always use defer mu.Unlock().

---

Ordering and Non-Determinism

The output order changes every run — that’s normal with concurrency!

If you need deterministic order, don’t use goroutines or implement your own ordering mechanism.

---

Issues with Mutexes

1. Deadlocks
   Easy to run into when multiple locks depend on each other:

   goroutine 1: holds L, waiting for M  
   goroutine 2: holds M, waiting for L  
   

2. Bottlenecks
   Mutexes serialize parts of your program, reducing concurrency benefits.

3. Complexity
   Hard to reason about and debug.

---

Better Solution: Channels

Mutating shared state should generally be avoided.

Go’s channels offer a better way to share data across goroutines.

We’ll cover channels in the next lesson.

---

Wrap-Up

Let’s commit our code:

git add .
git commit -m "Added concurrency using goroutines, wait groups, and mutexes"

🎉 We’re now ready to explore channels and test how much faster our code is with concurrency!