3. RW Mutex

The standard library also exposes a sync.RWMutex

In addition to these methods:

• Lock()

• Unlock()

The sync.RWMutex also has these methods for concurrent reads:

• RLock()

• RUnlock()

The sync.RWMutex improves performance in read-intensive processes. Multiple goroutines can safely read from the map simultaneously, as many RLock() calls can occur at the same time. However, only one goroutine can hold a Lock(), and during this time, all RLock() operations are blocked.

The Problem with Regular Mutex

With sync.Mutex, ALL operations block each other, even if they're just reading:

// Using sync.Mutex
mu.Lock()
x := data["key"]  // Just reading
mu.Unlock()

mu.Lock()
y := data["key"]  // Also just reading, but has to wait!
mu.Unlock()

Even though both are just reading (not changing anything), they block each other — this is wasteful.

The Solution: RWMutex (Read-Write Mutex)

sync.RWMutex has two types of locks:

1

Read Lock (RLock)

• Multiple goroutines can hold this at the same time.

• Use for reading-only operations.

2

Write Lock (Lock)

• Only ONE goroutine can hold this.

• Blocks all other readers and writers while held.

• Use for mutating operations.

How RWMutex Works

Scenario 1: Multiple Readers (No Writers)

// Goroutine 1
mu.RLock()
x := data["key"]  // Reading
mu.RUnlock()

// Goroutine 2 (at the same time!)
mu.RLock()
y := data["key"]  // Also reading - NO BLOCKING! ✅
mu.RUnlock()

// Goroutine 3 (also at the same time!)
mu.RLock()
z := data["key"]  // Still reading - STILL NO BLOCKING! ✅
mu.RUnlock()

All three can read simultaneously because reading doesn't change the data.

Scenario 2: Writer Arrives

// Goroutines 1, 2, 3 are reading (RLock)
mu.RLock()  // Goroutine 1
mu.RLock()  // Goroutine 2
mu.RLock()  // Goroutine 3

// Goroutine 4 wants to WRITE
mu.Lock()  // ⏸️ BLOCKS! Waits for all RLocks to finish

// After all RUnlock() calls complete:
mu.Lock()   // ✅ Now gets the lock
data["key"] = 5  // Writing
mu.Unlock()

// Now readers can continue
mu.RLock()  // ✅ Can read again

Visual Comparison

sync.Mutex (Regular)

Time →
Goroutine 1: [Lock]─────[Unlock]
Goroutine 2:              ⏸️ wait...  [Lock]─────[Unlock]
Goroutine 3:                            ⏸️ wait...  [Lock]───[Unlock]

Only ONE goroutine at a time (even for reads!)

sync.RWMutex (Read-Write)

Time →
Reader 1:    [RLock]──[RUnlock]
Reader 2:    [RLock]──[RUnlock]     (simultaneous! ✅)
Reader 3:    [RLock]──[RUnlock]     (simultaneous! ✅)
Writer:                              [Lock]──[Unlock]  (blocks readers)
Reader 4:                                       ⏸️ wait...  [RLock]──

Multiple readers OK, but writers block everyone!

Code Example

main.go

type safeCounter struct {
    counts map[string]int
    mu     *sync.RWMutex  // Use RWMutex instead of Mutex
}

// Reading - use RLock
func (sc safeCounter) val(key string) int {
    sc.mu.RLock()          // 🔓 Read lock (allows other readers)
    defer sc.mu.RUnlock()  // 🔓 Unlock read
    
    return sc.counts[key]  // Just reading, not writing
}

// Writing - use Lock
func (sc safeCounter) inc(key string) {
    sc.mu.Lock()           // 🔒 Write lock (blocks everyone)
    defer sc.mu.Unlock()   // 🔒 Unlock write
    
    sc.counts[key]++       // Modifying data
}

When to Use Each

• Use sync.Mutex when:

  • You have equal amounts of reads and writes

  • The code is simpler and you don't need optimization

  • You're mostly writing

• Use sync.RWMutex when:

  • You have way more reads than writes (e.g., 90% reads, 10% writes)

  • Multiple goroutines need to read at the same time

  • Performance matters

Performance Difference

Example: 100 goroutines, 95 reading, 5 writing

With sync.Mutex:

Total time: ~100 operations (sequential, one at a time)

With sync.RWMutex:

Total time: ~10 operations (95 readers run simultaneously, 5 writers wait)

RWMutex can be 10x faster for read-heavy workloads!

Important Rules

• Don't mix lock types:

mu.RLock()
// ...
mu.Unlock()  // ❌ WRONG! Use RUnlock()

• Writers block everything:

mu.Lock()      // Writer gets lock
// Now ALL RLock() calls are blocked
// AND all Lock() calls are blocked
mu.Unlock()

• RLock doesn't block other RLocks:

mu.RLock()     // Goroutine 1
mu.RLock()     // Goroutine 2 - NOT blocked! ✅
mu.RLock()     // Goroutine 3 - NOT blocked! ✅

• Can't upgrade locks:

mu.RLock()
// Can't "upgrade" to Lock() without unlocking first
mu.RUnlock()
mu.Lock()      // ✅ Correct way

Mental Model

Think of it like a library:

• Regular Mutex (sync.Mutex):

  • Only ONE person allowed in the library at a time

  • Even if you just want to read, you have to wait for everyone else

• RWMutex (sync.RWMutex):

  • Multiple readers can be in the library at once (using RLock())

  • ONE writer can be in the library alone (using Lock())

  • When a writer enters, all readers must leave and wait

  • When writer is done, readers can return

Summary

Feature	sync.Mutex	sync.RWMutex
Readers	Block each other	Can run simultaneously
Writers	Block everyone	Block everyone
Best for	Equal R/W or mostly writes	Read-heavy workloads
Performance	Simpler, slower for reads	Faster for many reads
Methods	Lock(), Unlock()	Lock(), Unlock(), RLock(), RUnlock()

Key takeaway: Use RWMutex when you have lots of reads and few writes. It lets multiple goroutines read at the same time, making your code faster!

Assignment

Update the val method to only lock the mutex for reading. The test suite currently hangs because val locks the RWMutex with a write lock instead of a read lock.

Original (problematic) code:

package main

import (
	"sync"
	"time"
)

type safeCounter struct {
	counts map[string]int
	mu     *sync.RWMutex
}

func (sc safeCounter) inc(key string) {
	sc.mu.Lock()
	defer sc.mu.Unlock()
	sc.slowIncrement(key)
}

func (sc safeCounter) val(key string) int {
	sc.mu.Lock()
	defer sc.mu.Unlock()
	return sc.counts[key]
}

// don't touch below this line

func (sc safeCounter) slowIncrement(key string) {
	tempCounter := sc.counts[key]
	time.Sleep(time.Microsecond)
	tempCounter++
	sc.counts[key] = tempCounter
}

Change the val method to use a read lock:

func (sc safeCounter) val(key string) int {
    sc.mu.RLock()
    defer sc.mu.RUnlock()
    return sc.counts[key]
}

Run the test suite again — it should no longer hang once val uses RLock()/RUnlock().