Go Memory Model

Learning Objectives

By the end of this tutorial, you will be able to:

• Master happens-before relationships and understand memory ordering guarantees
• Prevent data races using proper synchronization primitives
• Choose the right synchronization tool for your use case
• Build lock-free data structures using atomic operations safely
• Debug concurrent issues with systematic approaches and tools
• Write production-safe concurrent code that works correctly under all conditions

Hook - The Concurrent Programming Challenge

When coordinating a team where multiple people need to read and update the same whiteboard, without clear rules about who can write when and who gets to see what changes, chaos ensues. Go's memory model is exactly that set of rules for concurrent programming—it ensures all goroutines see a consistent view of shared data.

Real-World Impact:

• Cloudflare's 2019 outage: Memory ordering bug caused incorrect request routing globally for 30 minutes
• Uber's payment system bug: Race condition allowed double charging customers
• Financial impact: These issues cost companies millions and damaged customer trust

💡 Key Takeaway: The Go memory model is your contract for safe concurrent programming. It tells you exactly when writes from one goroutine become visible to reads in another goroutine.

Why the Memory Model Matters

Think of the memory model as traffic rules for concurrent programming. Just as traffic rules prevent accidents and ensure smooth flow, memory model rules prevent data races and ensure program correctness.

🎯 Practical Analogy: Imagine a shared kitchen where multiple chefs cook simultaneously. The memory model is like the rule: "Only one chef can use the stove at a time" and "Everyone must see when a dish is finished cooking." Without these rules, you'd have burned food and confused chefs.

The Go memory model specifies the conditions under which reads of a variable in one goroutine are guaranteed to observe values produced by writes to the same variable in another goroutine.

Critical Need for Memory Model Knowledge

• 🔒 Correctness: Prevent data races and undefined behavior that can corrupt data
• 🚀 Performance: Use appropriate synchronization—not too much and not too little
• 🐛 Debugging: Understand why concurrent bugs happen and how to fix them systematically
• 📊 Optimization: Know when compiler and runtime optimizations are safe to apply

Real-world Example: In a high-frequency trading system, understanding the memory model ensures that price updates from one goroutine are immediately visible to trading decision goroutines, preventing stale data trades worth millions.

Real-World Incidents

Cloudflare's Race Condition:

• What happened: Memory ordering bug caused incorrect request routing across their global network
• Impact: 30 minutes of global service degradation affecting millions of users
• Root cause: Misunderstanding of Go's memory model—assuming writes would be visible without proper synchronization
• Fix: Implemented proper mutex synchronization around shared routing data
• Cost: Estimated millions in lost revenue and customer trust

Uber's Payment Bug:

• What happened: Race condition in payment processing allowed double charging
• Impact: Money debited twice from customer accounts, some customers charged thousands instead of hundreds
• Root cause: Concurrent goroutines accessing shared payment state without proper synchronization
• Fix: Added atomic operations and proper locking around payment state transitions
• Cost: $250,000 in refunds plus reputational damage

⚠️ Important: These incidents show that data races aren't just theoretical—they can cause real production issues with financial impact.

Fundamentals of the Memory Model

What is a Memory Model

A memory model defines the contract between programmers and the system about memory access ordering in concurrent programs. It specifies:

1. Visibility: When writes from one thread become visible to reads in another
2. Ordering: What order operations appear to execute in
3. Atomicity: Which operations complete as indivisible units
4. Coherence: How different memory locations relate to each other

💡 Key Concept: Without a memory model, compilers and CPUs can reorder operations in ways that break concurrent programs. The memory model defines what reorderings are allowed and what guarantees you have.

Sequential Consistency vs Weak Memory Models

Sequential Consistency (strongest guarantee):

• Operations appear to execute in some total order
• All processors see operations in the same order
• Easy to reason about but expensive to implement

Weak Memory Models (what Go uses):

• Allow reordering for performance
• Provide happens-before relationships instead of total ordering
• More complex but much faster

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"runtime"
 7	"sync"
 8	"time"
 9)
10
11// Demonstration of memory ordering effects
12func demonstrateWeakMemory() {
13	var x, y int
14	var a, b int
15
16	iterations := 1000
17	concurrent := 0
18
19	for i := 0; i < iterations; i++ {
20		x, y, a, b = 0, 0, 0, 0
21
22		done := make(chan bool, 2)
23
24		// Goroutine 1: Write x, read y
25		go func() {
26			x = 1
27			a = y
28			done <- true
29		}()
30
31		// Goroutine 2: Write y, read x
32		go func() {
33			y = 1
34			b = x
35			done <- true
36		}()
37
38		<-done
39		<-done
40
41		// In a sequentially consistent model, a=0,b=0 is impossible
42		// But with weak memory ordering, it can happen!
43		if a == 0 && b == 0 {
44			concurrent++
45		}
46	}
47
48	fmt.Printf("Out of %d runs:\n", iterations)
49	fmt.Printf("Concurrent executions (a=0, b=0): %d\n", concurrent)
50	fmt.Printf("This shows weak memory ordering in action\n")
51}
52
53func main() {
54	fmt.Println("=== Memory Ordering Demonstration ===\n")
55	runtime.GOMAXPROCS(4) // Use multiple processors
56	demonstrateWeakMemory()
57}

Memory Barriers and Synchronization

Memory Barriers (or fences) prevent certain types of reordering:

• Compiler barriers: Prevent compiler reordering
• Hardware barriers: Prevent CPU reordering
• Both: Go's synchronization primitives provide both

Synchronization Primitives in Go:

1. Channels: Send/receive operations
2. Mutexes: Lock/unlock operations
3. Atomic operations: Load/store/CAS operations
4. sync.Once: One-time initialization
5. sync.WaitGroup: Coordination barriers

Happens-Before Relationship

🎯 Practical Analogy: Think of happens-before relationships like a timeline of events in a story. If Chapter 1 happens-before Chapter 2, then everything established in Chapter 1 is available to readers when they start Chapter 2. In Go, this ensures that all writes from one point are visible to reads at later points.

The Core Concept

A happens-before relationship defines when memory operations are guaranteed to be visible across goroutines. Without these relationships, there are no guarantees about order or visibility.

💡 Key Takeaway: If there's no happens-before relationship between two operations, the order in which they appear to execute is undefined, even if they're in the same program!

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"time"
 7)
 8
 9var a, b int
10
11// WITHOUT synchronization
12func wrong() {
13	// Goroutine 1
14	go func() {
15		a = 1 // Write 1
16		b = 2 // Write 2
17	}()
18
19	// Goroutine 2
20	go func() {
21		for b == 0 { // Wait for b
22			// Busy wait
23		}
24		// When we get here, is a guaranteed to be 1?
25		// NO! There's no happens-before relationship
26		fmt.Println(a) // Could print 0 or 1
27	}()
28
29	time.Sleep(100 * time.Millisecond)
30}
31
32func main() {
33	wrong()
34}

Correct Synchronization

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9var a, b int
10var mu sync.Mutex
11
12// WITH synchronization
13func correct() {
14	var wg sync.WaitGroup
15	wg.Add(2)
16
17	// Goroutine 1
18	go func() {
19		defer wg.Done()
20		mu.Lock()
21		a = 1
22		b = 2
23		mu.Unlock()
24	}()
25
26	// Goroutine 2
27	go func() {
28		defer wg.Done()
29		mu.Lock()
30		val := b
31		mu.Unlock()
32
33		if val != 0 {
34			mu.Lock()
35			fmt.Println("a =", a) // Guaranteed to be 1
36			mu.Unlock()
37		}
38	}()
39
40	wg.Wait()
41}
42
43func main() {
44	correct()
45}

Formal Happens-Before Rules

The Go memory model defines several happens-before relationships:

Rule 1: Within a single goroutine, operations execute in program order

If statement A appears before statement B in the source code,
then A happens-before B

Rule 2: Send on a channel happens-before receive completes

ch <- value  // Send
...
<-ch         // Receive sees the value

Rule 3: Receive from an unbuffered channel happens-before send completes

<-ch         // Receive
...
ch <- value  // Send can complete

Rule 4: Unlock happens-before any subsequent lock

mu.Lock()
// Critical section 1
mu.Unlock()  // Unlock happens-before next Lock

mu.Lock()
// Critical section 2: sees effects from critical section 1
mu.Unlock()

Rule 5: Read from atomic variable observes any prior write

atomic.Store(&x, 42)  // Write happens-before read
v := atomic.Load(&x)  // Sees 42

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9func demonstrateHappensBefore() {
10	var x, y int
11	var wg sync.WaitGroup
12
13	// Rule 1: Within a single goroutine, happens-before order is program order
14	wg.Add(1)
15	go func() {
16		defer wg.Done()
17		x = 1  // Statement A
18		y = 2  // Statement B
19		// A happens-before B
20	}()
21
22	// Rule 2: Send on channel happens-before receive completes
23	ch := make(chan int)
24	wg.Add(2)
25
26	go func() {
27		defer wg.Done()
28		x = 3
29		ch <- 1 // Send happens-before receive
30	}()
31
32	go func() {
33		defer wg.Done()
34		<-ch // Receive
35		fmt.Println(x) // Guaranteed to see x = 3
36	}()
37
38	// Rule 3: Unlock happens-before any subsequent lock
39	var mu sync.Mutex
40	wg.Add(2)
41
42	go func() {
43		defer wg.Done()
44		mu.Lock()
45		x = 4
46		mu.Unlock() // Unlock happens-before next Lock
47	}()
48
49	go func() {
50		defer wg.Done()
51		mu.Lock() // This Lock happens-after above Unlock
52		fmt.Println(x) // Guaranteed to see x = 4
53		mu.Unlock()
54	}()
55
56	wg.Wait()
57}
58
59func main() {
60	demonstrateHappensBefore()
61}

Real-world Example: In a web server, this ensures that when a request handler updates user session data, subsequent requests from the same user see those updates, preventing inconsistent session states.

Transitivity of Happens-Before

If A happens-before B and B happens-before C, then A happens-before C.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9// Transitivity demonstration
10func demonstrateTransitivity() {
11	var x int
12	ch1 := make(chan int)
13	ch2 := make(chan int)
14
15	// Goroutine A
16	go func() {
17		x = 42        // Operation 1
18		ch1 <- 1      // Operation 2: Signals B
19	}()
20
21	// Goroutine B
22	go func() {
23		<-ch1         // Waits for A (Operation 2 happens-before this)
24		// Now we can see x = 42 (Operation 1 happens-before Operation 2)
25		ch2 <- 1      // Operation 3: Signals C
26	}()
27
28	// Goroutine C
29	go func() {
30		<-ch2         // Waits for B (Operation 3 happens-before this)
31		// Now we can see x = 42 due to transitivity:
32		// Operation 1 happens-before Operation 2
33		// Operation 2 happens-before receive in B
34		// B's send Operation 3 happens-before receive in C
35		fmt.Println("x =", x) // Guaranteed to see 42
36	}()
37
38	// Wait for completion
39	var wg sync.WaitGroup
40	wg.Add(1)
41	go func() {
42		<-ch2
43		wg.Done()
44	}()
45	wg.Wait()
46}
47
48func main() {
49	demonstrateTransitivity()
50}

Synchronization Primitives

🎯 Practical Analogy: Synchronization primitives are like traffic signals for concurrent programming. Just as traffic lights prevent car accidents, these primitives prevent data accidents in concurrent code.

Mutex

💡 Key Takeaway: A mutex is like a bathroom key—only one person can use it at a time, and everyone knows when it's occupied or available.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9type SafeCounter struct {
10	mu    sync.Mutex
11	count int
12}
13
14func (c *SafeCounter) Increment() {
15	c.mu.Lock()
16	c.count++ // Protected by mutex
17	c.mu.Unlock()
18}
19
20func (c *SafeCounter) Value() int {
21	c.mu.Lock()
22	defer c.mu.Unlock()
23	return c.count
24}
25
26func main() {
27	counter := &SafeCounter{}
28	var wg sync.WaitGroup
29
30	// 100 goroutines incrementing
31	for i := 0; i < 100; i++ {
32		wg.Add(1)
33		go func() {
34			defer wg.Done()
35			for j := 0; j < 100; j++ {
36				counter.Increment()
37			}
38		}()
39	}
40
41	wg.Wait()
42	fmt.Println("Count:", counter.Value()) // Always 10000
43}

Real-world Example: In a banking system, mutexes protect account balances during transfers, preventing double-spending. When Alice transfers money to Bob, both accounts are locked until the transfer completes, ensuring no other operations can interfere.

RWMutex

🎯 Practical Analogy: An RWMutex is like a library reference section—many people can read simultaneously, but only one person can write.

💡 Key Takeaway: Use RWMutex when reads are much more frequent than writes. It allows multiple readers to proceed concurrently while still protecting against writer interference.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"time"
 8)
 9
10type Cache struct {
11	mu    sync.RWMutex
12	data  map[string]string
13}
14
15func NewCache() *Cache {
16	return &Cache{
17		data: make(map[string]string),
18	}
19}
20
21// Multiple readers can hold RLock simultaneously
22func (c *Cache) Get(key string) (string, bool) {
23	c.mu.RLock()
24	defer c.mu.RUnlock()
25	val, ok := c.data[key]
26	return val, ok
27}
28
29// Writer needs exclusive Lock
30func (c *Cache) Set(key, value string) {
31	c.mu.Lock()
32	defer c.mu.Unlock()
33	c.data[key] = value
34}
35
36func main() {
37	cache := NewCache()
38	var wg sync.WaitGroup
39
40	// Writer goroutine
41	wg.Add(1)
42	go func() {
43		defer wg.Done()
44		for i := 0; i < 10; i++ {
45			cache.Set(fmt.Sprintf("key%d", i), fmt.Sprintf("value%d", i))
46			time.Sleep(10 * time.Millisecond)
47		}
48	}()
49
50	// Multiple reader goroutines
51	for i := 0; i < 5; i++ {
52		wg.Add(1)
53		go func(id int) {
54			defer wg.Done()
55			for j := 0; j < 20; j++ {
56				if val, ok := cache.Get("key5"); ok {
57					fmt.Printf("Reader %d got: %s\n", id, val)
58				}
59				time.Sleep(5 * time.Millisecond)
60			}
61		}(i)
62	}
63
64	wg.Wait()
65}

Real-world Example: Content delivery networks use RWMutex-like patterns. Millions of users read cached content simultaneously, while content updates happen much less frequently. This allows massive read scalability while still protecting content integrity during updates.

Channels

🎯 Practical Analogy: Channels are like mail carriers with guaranteed delivery. When you send a letter, you know it will be delivered before the recipient acts on it. The "happens-before" guarantee ensures the message is received intact.

💡 Key Takeaway: Channels provide both communication and synchronization. The act of sending and receiving establishes a happens-before relationship, making them perfect for coordinating goroutines.

 1// run
 2package main
 3
 4import "fmt"
 5
 6// Channels provide happens-before guarantees
 7
 8func channelSynchronization() {
 9	// Unbuffered channel: send happens-before receive completes
10	ch1 := make(chan int)
11	var value int
12
13	go func() {
14		value = 42
15		ch1 <- 1 // Send
16	}()
17
18	<-ch1 // Receive happens-after send
19	fmt.Println(value) // Guaranteed to see 42
20
21	// Buffered channel: receive happens-before send completes
22	ch2 := make(chan int, 1)
23	ch2 <- 10
24
25	go func() {
26		<-ch2 // Receive
27		value = 100
28	}()
29
30	ch2 <- 20 // This send blocks until receive happens
31	fmt.Println(value) // Guaranteed to see 100
32}
33
34func main() {
35	channelSynchronization()
36}

Real-world Example: In Kubernetes, channels coordinate between controllers and the API server. When a controller detects a change, the API server processes it, ensuring state changes are applied in the correct order across the cluster.

sync.Once

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9var (
10	instance *Singleton
11	once     sync.Once
12)
13
14type Singleton struct {
15	data string
16}
17
18// Thread-safe singleton initialization
19func GetInstance() *Singleton {
20	once.Do(func() {
21		fmt.Println("Initializing singleton...")
22		instance = &Singleton{data: "I'm a singleton!"}
23	})
24	return instance
25}
26
27func main() {
28	var wg sync.WaitGroup
29
30	// Multiple goroutines try to get instance
31	for i := 0; i < 10; i++ {
32		wg.Add(1)
33		go func(id int) {
34			defer wg.Done()
35			inst := GetInstance()
36			fmt.Printf("Goroutine %d got: %s\n", id, inst.data)
37		}(i)
38	}
39
40	wg.Wait()
41	// "Initializing singleton..." printed only once
42}

sync.WaitGroup

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"time"
 8)
 9
10func worker(id int, wg *sync.WaitGroup) {
11	defer wg.Done() // Decrements counter when done
12
13	fmt.Printf("Worker %d starting\n", id)
14	time.Sleep(time.Second)
15	fmt.Printf("Worker %d done\n", id)
16}
17
18func main() {
19	var wg sync.WaitGroup
20
21	for i := 1; i <= 5; i++ {
22		wg.Add(1) // Increment counter
23		go worker(i, &wg)
24	}
25
26	wg.Wait() // Block until counter reaches 0
27	fmt.Println("All workers completed")
28}

sync.Cond - Condition Variables

Condition variables allow goroutines to wait for specific conditions to become true.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"time"
 8)
 9
10type Queue struct {
11	mu    sync.Mutex
12	cond  *sync.Cond
13	items []int
14}
15
16func NewQueue() *Queue {
17	q := &Queue{
18		items: make([]int, 0),
19	}
20	q.cond = sync.NewCond(&q.mu)
21	return q
22}
23
24func (q *Queue) Enqueue(item int) {
25	q.mu.Lock()
26	defer q.mu.Unlock()
27
28	q.items = append(q.items, item)
29	q.cond.Signal() // Wake up one waiting goroutine
30}
31
32func (q *Queue) Dequeue() int {
33	q.mu.Lock()
34	defer q.mu.Unlock()
35
36	// Wait while queue is empty
37	for len(q.items) == 0 {
38		q.cond.Wait() // Releases lock and waits
39	}
40
41	item := q.items[0]
42	q.items = q.items[1:]
43	return item
44}
45
46func main() {
47	queue := NewQueue()
48	var wg sync.WaitGroup
49
50	// Consumer
51	wg.Add(1)
52	go func() {
53		defer wg.Done()
54		for i := 0; i < 5; i++ {
55			item := queue.Dequeue()
56			fmt.Printf("Consumed: %d\n", item)
57		}
58	}()
59
60	// Producer
61	wg.Add(1)
62	go func() {
63		defer wg.Done()
64		for i := 1; i <= 5; i++ {
65			time.Sleep(500 * time.Millisecond)
66			queue.Enqueue(i)
67			fmt.Printf("Produced: %d\n", i)
68		}
69	}()
70
71	wg.Wait()
72}

Memory Ordering

Sequential Consistency

⚠️ Important: Go does NOT guarantee sequential consistency! This is a critical difference from languages like Java. Without proper synchronization, the compiler and CPU can reorder operations in surprising ways.

🎯 Practical Analogy: Think of memory ordering like a queue at a coffee shop. Without proper rules, people might cut in line, and the order of service becomes unpredictable. Synchronization establishes clear ordering rules.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"runtime"
 7	"sync"
 8	"sync/atomic"
 9)
10
11// WITHOUT atomic
12func withoutAtomic() {
13	var x, y, a, b int
14
15	go func() {
16		x = 1
17		a = y
18	}()
19
20	go func() {
21		y = 1
22		b = x
23	}()
24
25	runtime.Gosched()
26
27	// Possible outcomes:
28	// a=0, b=1
29	// a=1, b=0
30	// a=1, b=1
31	// a=0, b=0 ← This is possible due to reordering!
32
33	fmt.Printf("a=%d, b=%d\n", a, b)
34}
35
36// WITH atomic
37func withAtomic() {
38	var x, y atomic.Int32
39
40	var wg sync.WaitGroup
41	wg.Add(2)
42
43	go func() {
44		defer wg.Done()
45		x.Store(1)
46		a := y.Load()
47		fmt.Printf("a=%d\n", a)
48	}()
49
50	go func() {
51		defer wg.Done()
52		y.Store(1)
53		b := x.Load()
54		fmt.Printf("b=%d\n", b)
55	}()
56
57	wg.Wait()
58}
59
60func main() {
61	fmt.Println("Without atomic:")
62	withoutAtomic()
63
64	fmt.Println("\nWith atomic:")
65	withAtomic()
66}

Real-world Example: In a stock trading system, without proper memory ordering, different threads might see different orderings of trades, leading to inconsistent pricing and regulatory violations. Atomic operations ensure all traders see the same sequence of events.

Atomic Operations

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"sync/atomic"
 8)
 9
10type Metrics struct {
11	requests atomic.Int64
12	errors   atomic.Int64
13}
14
15func (m *Metrics) RecordRequest(success bool) {
16	m.requests.Add(1)
17	if !success {
18		m.errors.Add(1)
19	}
20}
21
22func (m *Metrics) ErrorRate() float64 {
23	reqs := m.requests.Load()
24	errs := m.errors.Load()
25
26	if reqs == 0 {
27		return 0
28	}
29
30	return float64(errs) / float64(reqs)
31}
32
33func main() {
34	metrics := &Metrics{}
35	var wg sync.WaitGroup
36
37	// Simulate requests
38	for i := 0; i < 100; i++ {
39		wg.Add(1)
40		go func(id int) {
41			defer wg.Done()
42			success := id%10 != 0 // 10% error rate
43			metrics.RecordRequest(success)
44		}(i)
45	}
46
47	wg.Wait()
48
49	fmt.Printf("Total requests: %d\n", metrics.requests.Load())
50	fmt.Printf("Total errors: %d\n", metrics.errors.Load())
51	fmt.Printf("Error rate: %.2f%%\n", metrics.ErrorRate()*100)
52}

Memory Order Semantics

Different atomic operations provide different ordering guarantees:

Sequential Consistency (strongest):

• All operations appear in some total order
• All processors agree on this order
• Example: atomic.LoadInt32, atomic.StoreInt32

Acquire-Release (medium):

• Acquire loads see all prior releases
• Release stores are visible to subsequent acquires
• Example: sync.Mutex.Lock() (acquire), sync.Mutex.Unlock() (release)

Relaxed (weakest):

• No ordering guarantees beyond atomicity
• Only guarantees individual operation is atomic
• Example: Some internal runtime operations

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"sync/atomic"
 8)
 9
10type SharedData struct {
11	ready atomic.Bool
12	value int
13}
14
15// Publish-subscribe pattern with proper memory ordering
16func demonstrateAcquireRelease() {
17	data := &SharedData{}
18	var wg sync.WaitGroup
19
20	// Publisher (uses release semantics)
21	wg.Add(1)
22	go func() {
23		defer wg.Done()
24
25		// Prepare data
26		data.value = 42
27
28		// Release: All prior writes are visible after this
29		data.ready.Store(true)
30		fmt.Println("Publisher: Data published")
31	}()
32
33	// Subscriber (uses acquire semantics)
34	wg.Add(1)
35	go func() {
36		defer wg.Done()
37
38		// Acquire: See all writes that happened before release
39		for !data.ready.Load() {
40			// Spin wait
41		}
42
43		fmt.Printf("Subscriber: Read value = %d\n", data.value)
44	}()
45
46	wg.Wait()
47}
48
49func main() {
50	demonstrateAcquireRelease()
51}

Race Condition Prevention

🎯 Practical Analogy: Race conditions are like multiple chefs adding ingredients to the same recipe without coordination—one chef might add salt twice while another skips it entirely, ruining the dish.

Common Race Patterns

⚠️ Important: These are the most common sources of bugs in concurrent Go programs. The race detector is your best friend for catching these early.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9// WRONG: Map race
10func mapRaceWrong() {
11	m := make(map[int]int)
12
13	for i := 0; i < 100; i++ {
14		go func(n int) {
15			m[n] = n // DATA RACE!
16		}(i)
17	}
18}
19
20// CORRECT: Map with mutex
21func mapRaceFixed() {
22	m := make(map[int]int)
23	var mu sync.Mutex
24
25	var wg sync.WaitGroup
26	for i := 0; i < 100; i++ {
27		wg.Add(1)
28		go func(n int) {
29			defer wg.Done()
30			mu.Lock()
31			m[n] = n // Protected
32			mu.Unlock()
33		}(i)
34	}
35	wg.Wait()
36
37	fmt.Println("Map size:", len(m))
38}
39
40// WRONG: Slice race
41func sliceRaceWrong() {
42	var slice []int
43
44	for i := 0; i < 100; i++ {
45		go func(n int) {
46			slice = append(slice, n) // DATA RACE!
47		}(i)
48	}
49}
50
51// CORRECT: Slice with mutex
52func sliceRaceFixed() {
53	var slice []int
54	var mu sync.Mutex
55
56	var wg sync.WaitGroup
57	for i := 0; i < 100; i++ {
58		wg.Add(1)
59		go func(n int) {
60			defer wg.Done()
61			mu.Lock()
62			slice = append(slice, n) // Protected
63			mu.Unlock()
64		}(i)
65	}
66	wg.Wait()
67
68	fmt.Println("Slice length:", len(slice))
69}
70
71func main() {
72	fmt.Println("=== Race Condition Examples ===")
73
74	// mapRaceWrong() // Would cause race
75	mapRaceFixed()
76
77	// sliceRaceWrong() // Would cause race
78	sliceRaceFixed()
79}

💡 Key Takeaway: Go maps are not concurrent-safe! Always protect them with mutexes. The same goes for slices and any data structure that can be modified concurrently.

Closure Variable Capture

🎯 Practical Analogy: Capturing loop variables is like giving multiple people the same shopping list that keeps changing. Everyone ends up buying the same final item, not what was on the list when they started shopping.

💡 Key Takeaway: This is one of the most common Go beginner mistakes. Always pass loop variables as parameters to goroutines or create local copies.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9// WRONG: Capturing loop variable
10func closureCaptureWrong() {
11	var wg sync.WaitGroup
12
13	for i := 0; i < 5; i++ {
14		wg.Add(1)
15		go func() {
16			defer wg.Done()
17			fmt.Println(i) // Captures loop variable
18		}()
19	}
20
21	wg.Wait()
22	// Prints unpredictable values, often all 5s
23}
24
25// CORRECT: Pass as parameter
26func closureCaptureFixed1() {
27	var wg sync.WaitGroup
28
29	for i := 0; i < 5; i++ {
30		wg.Add(1)
31		go func(n int) {
32			defer wg.Done()
33			fmt.Println(n) // Each goroutine gets its own copy
34		}(i)
35	}
36
37	wg.Wait()
38	// Prints 0, 1, 2, 3, 4 in some order
39}
40
41// CORRECT: Create local copy
42func closureCaptureFixed2() {
43	var wg sync.WaitGroup
44
45	for i := 0; i < 5; i++ {
46		i := i // Create local copy
47		wg.Add(1)
48		go func() {
49			defer wg.Done()
50			fmt.Println(i)
51		}()
52	}
53
54	wg.Wait()
55}
56
57func main() {
58	fmt.Println("Wrong:")
59	closureCaptureWrong()
60
61	fmt.Println("\nFixed:")
62	closureCaptureFixed1()
63
64	fmt.Println("\nFixed:")
65	closureCaptureFixed2()
66}

Real-world Example: In a web crawler, this bug caused all goroutines to process the same URL instead of distributing the work, severely limiting crawling efficiency.

Double-Checked Locking

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9type Resource struct {
10	data string
11}
12
13// WRONG: Double-checked locking without proper synchronization
14func wrongDoubleCheck() *Resource {
15	var resource *Resource
16	var mu sync.Mutex
17
18	initialize := func() *Resource {
19		mu.Lock()
20		defer mu.Unlock()
21
22		if resource == nil { // Check again under lock
23			resource = &Resource{data: "initialized"}
24		}
25
26		return resource
27	}
28
29	// First check without lock
30	if resource == nil {
31		return initialize()
32	}
33
34	return resource
35}
36
37// CORRECT: Use sync.Once
38func correctDoubleCheck() *Resource {
39	var resource *Resource
40	var once sync.Once
41
42	once.Do(func() {
43		resource = &Resource{data: "initialized"}
44	})
45
46	return resource
47}
48
49func main() {
50	var wg sync.WaitGroup
51
52	// Test with sync.Once
53	for i := 0; i < 10; i++ {
54		wg.Add(1)
55		go func() {
56			defer wg.Done()
57			res := correctDoubleCheck()
58			fmt.Printf("Got resource: %s\n", res.data)
59		}()
60	}
61
62	wg.Wait()
63}

Data Race Detection

Go provides a built-in race detector to find data races at runtime.

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7)
 8
 9func demonstrateRaceDetector() {
10	// To detect races: go run -race main.go
11
12	var counter int
13	var wg sync.WaitGroup
14
15	// This will be detected by race detector
16	for i := 0; i < 10; i++ {
17		wg.Add(1)
18		go func() {
19			defer wg.Done()
20			counter++ // DATA RACE!
21		}()
22	}
23
24	wg.Wait()
25	fmt.Println("Counter:", counter)
26}
27
28func main() {
29	fmt.Println("=== Race Detector Demo ===")
30	fmt.Println("Run with: go run -race main.go")
31	demonstrateRaceDetector()
32}

How to Use the Race Detector:

1# Run with race detection
2go run -race main.go
3
4# Test with race detection
5go test -race ./...
6
7# Build with race detection
8go build -race

Race Detector Output Example:

==================
WARNING: DATA RACE
Write at 0x00c000018098 by goroutine 7:
  main.main.func1()
      /path/to/main.go:15 +0x3c

Previous write at 0x00c000018098 by goroutine 6:
  main.main.func1()
      /path/to/main.go:15 +0x3c
==================

Production Patterns

Message Passing

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"time"
 7)
 8
 9type Task struct {
10	ID   int
11	Data string
12}
13
14type Result struct {
15	TaskID int
16	Output string
17}
18
19// Worker pool using channels
20func messagePassingPattern() {
21	tasks := make(chan Task, 10)
22	results := make(chan Result, 10)
23
24	// Start workers
25	for w := 1; w <= 3; w++ {
26		go worker(w, tasks, results)
27	}
28
29	// Send tasks
30	go func() {
31		for i := 1; i <= 5; i++ {
32			tasks <- Task{ID: i, Data: fmt.Sprintf("task-%d", i)}
33		}
34		close(tasks)
35	}()
36
37	// Collect results
38	for i := 1; i <= 5; i++ {
39		result := <-results
40		fmt.Printf("Result %d: %s\n", result.TaskID, result.Output)
41	}
42}
43
44func worker(id int, tasks <-chan Task, results chan<- Result) {
45	for task := range tasks {
46		fmt.Printf("Worker %d processing task %d\n", id, task.ID)
47		time.Sleep(100 * time.Millisecond)
48
49		results <- Result{
50			TaskID: task.ID,
51			Output: fmt.Sprintf("processed by worker %d", id),
52		}
53	}
54}
55
56func main() {
57	messagePassingPattern()
58}

Read-Copy-Update

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"sync/atomic"
 8	"unsafe"
 9)
10
11// RCU pattern for high-read, low-write scenarios
12type ConfigRCU struct {
13	current unsafe.Pointer // *Config
14}
15
16type Config struct {
17	Value string
18}
19
20func NewConfigRCU(initial *Config) *ConfigRCU {
21	return &ConfigRCU{
22		current: unsafe.Pointer(initial),
23	}
24}
25
26// Read
27func (c *ConfigRCU) Get() *Config {
28	return (*Config)(atomic.LoadPointer(&c.current))
29}
30
31// Write
32func (c *ConfigRCU) Update(newConfig *Config) {
33	atomic.StorePointer(&c.current, unsafe.Pointer(newConfig))
34}
35
36func main() {
37	config := NewConfigRCU(&Config{Value: "v1"})
38
39	var wg sync.WaitGroup
40
41	// Many readers
42	for i := 0; i < 10; i++ {
43		wg.Add(1)
44		go func(id int) {
45			defer wg.Done()
46			for j := 0; j < 100; j++ {
47				cfg := config.Get()
48				fmt.Printf("Reader %d: %s\n", id, cfg.Value)
49			}
50		}(i)
51	}
52
53	// One writer
54	wg.Add(1)
55	go func() {
56		defer wg.Done()
57		for i := 2; i <= 5; i++ {
58			config.Update(&Config{Value: fmt.Sprintf("v%d", i)})
59		}
60	}()
61
62	wg.Wait()
63}

Lock-Free Stack

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"sync/atomic"
 8	"unsafe"
 9)
10
11// Node in the stack
12type Node struct {
13	value int
14	next  *Node
15}
16
17// LockFreeStack implements a lock-free stack using CAS
18type LockFreeStack struct {
19	head unsafe.Pointer // *Node
20}
21
22func NewLockFreeStack() *LockFreeStack {
23	return &LockFreeStack{}
24}
25
26// Push adds a value to the stack
27func (s *LockFreeStack) Push(value int) {
28	node := &Node{value: value}
29
30	for {
31		old := atomic.LoadPointer(&s.head)
32		node.next = (*Node)(old)
33
34		if atomic.CompareAndSwapPointer(&s.head, old, unsafe.Pointer(node)) {
35			return
36		}
37	}
38}
39
40// Pop removes and returns a value from the stack
41func (s *LockFreeStack) Pop() (int, bool) {
42	for {
43		old := atomic.LoadPointer(&s.head)
44		if old == nil {
45			return 0, false
46		}
47
48		node := (*Node)(old)
49		next := unsafe.Pointer(node.next)
50
51		if atomic.CompareAndSwapPointer(&s.head, old, next) {
52			return node.value, true
53		}
54	}
55}
56
57func main() {
58	stack := NewLockFreeStack()
59	var wg sync.WaitGroup
60
61	// Concurrent pushes
62	for i := 0; i < 10; i++ {
63		wg.Add(1)
64		go func(val int) {
65			defer wg.Done()
66			stack.Push(val)
67			fmt.Printf("Pushed: %d\n", val)
68		}(i)
69	}
70
71	wg.Wait()
72
73	// Concurrent pops
74	for i := 0; i < 10; i++ {
75		wg.Add(1)
76		go func() {
77			defer wg.Done()
78			if val, ok := stack.Pop(); ok {
79				fmt.Printf("Popped: %d\n", val)
80			}
81		}()
82	}
83
84	wg.Wait()
85}

Practice Exercises

Exercise 1: Fix the Race

🎯 Learning Objectives:

• Identify common data race patterns in concurrent Go code
• Master mutex and atomic operation solutions
• Understand when to use different synchronization primitives
• Practice race detection and debugging techniques

🌍 Real-World Context:
Data races are among the most dangerous and costly bugs in concurrent systems. A famous incident at Cloudflare in 2017 caused a global service outage when a race condition in their routing software sent traffic to wrong servers. Similarly, Uber experienced payment processing races that double-charged customers. Learning to spot and fix data races is essential for building reliable concurrent systems.

⏱️ Time Estimate: 30-45 minutes
📊 Difficulty: Intermediate

Find and fix the data race in the provided code. This classic counter race demonstrates how concurrent increments without proper synchronization can lead to incorrect results. Your solution should ensure thread safety while maintaining good performance.

 1// run
 2package main
 3
 4import "fmt"
 5
 6var counter int
 7
 8func main() {
 9	for i := 0; i < 1000; i++ {
10		go func() {
11			counter++ // Race!
12		}()
13	}
14
15	fmt.Println(counter)
16}

 1// run
 2package main
 3
 4import (
 5	"fmt"
 6	"sync"
 7	"sync/atomic"
 8)
 9
10// Solution 1: Using mutex
11func withMutex() {
12	var counter int
13	var mu sync.Mutex
14	var wg sync.WaitGroup
15
16	for i := 0; i < 1000; i++ {
17		wg.Add(1)
18		go func() {
19			defer wg.Done()
20			mu.Lock()
21			counter++
22			mu.Unlock()
23		}()
24	}
25
26	wg.Wait()
27	fmt.Println("With mutex:", counter)
28}
29
30// Solution 2: Using atomic
31func withAtomic() {
32	var counter atomic.Int64
33	var wg sync.WaitGroup
34
35	for i := 0; i < 1000; i++ {
36		wg.Add(1)
37		go func() {
38			defer wg.Done()
39			counter.Add(1)
40		}()
41	}
42
43	wg.Wait()
44	fmt.Println("With atomic:", counter.Load())
45}
46
47func main() {
48	withMutex()
49	withAtomic()
50}