19 — sync Package

// sync.Map is safe for concurrent use without a mutex.
// Optimized for write-rarely/read-many (caches with few updates).
// Uses `any` (no generics — must type-assert on Load).

func syncMapDemo() {
    var m sync.Map
    m.Store("key", "value")

    v, ok := m.Load("key")  // v is any — must assert: v.(string)
    if ok {
        fmt.Println(v.(string))
    }

    // LoadOrStore — atomic "get or set":
    actual, loaded := m.LoadOrStore("key", "default")
    // loaded=false if newly stored, true if existing value returned

    m.Delete("key")

    m.Range(func(k, v any) bool {
        fmt.Println(k, v)
        return true  // continue iteration
    })
}

// ─── Generic concurrent map (usually better than sync.Map) ───
type ConcurrentMap[K comparable, V any] struct {
    mu sync.RWMutex
    m  map[K]V
}

func (c *ConcurrentMap[K, V]) Get(key K) (V, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    v, ok := c.m[key]
    return v, ok
}

func (c *ConcurrentMap[K, V]) Set(key K, val V) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.m[key] = val
}
// Type-safe, often faster than sync.Map for balanced read/write workloads.

💡 Tips & Tricks

• Idiom: always pair Lock/Unlock with defer — mu.Lock(); defer mu.Unlock() guarantees the unlock runs even on panic. A missing Unlock (early return) deadlocks all other goroutines.
• Idiom: use RWMutex only when reads vastly outnumber writes and the critical section is non-trivial — the RWMutex has higher overhead than a Mutex (two atomic ops per RLock). For short sections or write-heavy workloads, a plain Mutex is faster.
• Idiom: wg.Add(n) before go f(), not inside f — there's a race where Wait sees counter 0 before Add runs. defer wg.Done() inside f ensures it runs even on panic.
• Idiom: use sync.Once for lazy initialization — runs exactly once across all goroutines, without double-checked locking boilerplate. The canonical singleton pattern.
• Idiom: prefer a map + RWMutex over sync.Map for general concurrent maps — sync.Map is optimized for write-rarely/read-many (caches) and uses any (no type safety). A generic map + RWMutex is type-safe and often faster.
• Performance: sync.Pool for short-lived allocation-heavy objects (buffers) — reset before Put, don't store long-lived state. Objects can be reclaimed between GC cycles.

⚠️ Edge Cases & Gotchas

• Copying a Mutex/WaitGroup/Once is a bug: these have internal state. go vet catches this ("assignment copies lock value"). Pass by pointer, never by value.
• Mutex is not reentrant: locking twice from the same goroutine deadlocks (Go's Mutex has no concept of "owner").
• Forgetting Unlock: a Lock without Unlock (early return) deadlocks. Use defer.
• RWMutex can starve writers: if readers continuously hold RLock, a writer may wait indefinitely (Go has anti-starvation, but be aware). For write-heavy, use Mutex.
• WaitGroup.Add inside the goroutine is a race: go func() { wg.Add(1); ... }() — Wait may see counter 0. Add before go.
• Once.Do blocks concurrent callers: the first call runs f; other callers block until it completes. If f is slow, all concurrent Do calls wait.
• sync.Pool objects can be reclaimed: between GC cycles, pooled objects may be freed. Don't store state you need to persist. Reset before Put.
• sync.Map is not generic: uses any — type-assert on Load. For type safety, use map + RWMutex.
• Cond.Wait must be called with the mutex locked: Wait unlocks, waits, re-locks. Calling without the lock is a runtime error.
• Cond spurious wakeups: Wait can wake without Signal/Broadcast. Always loop: for !condition { cond.Wait() }.

🧠 Quick Quiz

type S struct {
    mu sync.Mutex
    v  int
}

func f(s S) {  // ⚠️ s is passed BY VALUE
    s.mu.Lock()
    s.v++
    s.mu.Unlock()
}

func main() {
    s := S{}
    f(s)
}