Mutexes & Sync Primitives

sync.Mutex gives mutual exclusion: only one goroutine holds the lock at a time, protecting a critical section. Call Lock before the section and Unlock after — usually via defer. The zero value is an unlocked, ready mutex.

sync.WaitGroup waits for a set of goroutines to finish. Add(n) raises an internal counter, each goroutine calls Done to decrement it, and Wait blocks until the counter reaches zero. Add must run before the goroutine it counts is started.

sync.RWMutex allows many concurrent RLock readers OR one Lock writer. It wins for read-heavy workloads where readers vastly outnumber writers. The cost is a heavier lock — slower than sync.Mutex under low contention, and a pending writer blocks new readers.

sync provides low-level concurrency primitives: Mutex and RWMutex for mutual exclusion, WaitGroup to wait for a group of goroutines, Once for one-time init, Cond for condition waits, Map for a concurrent map, and Pool to reuse temporaries. The sync/atomic subpackage adds lock-free atomic operations.

A data race is two goroutines accessing the same memory concurrently with at least one write and no synchronization, giving an undefined result; catch it with the -race detector and fix it with a sync.Mutex, channel, or atomic. A deadlock is goroutines each blocked waiting on a resource another holds, so none progress; prevent it with consistent lock ordering and context timeouts.

sync.Once.Do(f) runs f exactly once across all callers. It uses an atomic done flag for a cheap fast path, and a mutex for the slow path: the first caller runs f under the lock, concurrent callers block until it finishes, and later calls see the flag and return immediately.

sync.Map keeps two internal maps — a mostly-read read map served without a lock via atomics, and a dirty map under a Mutex for writes. Reads of keys already present avoid locking entirely. It pays off only for read-mostly or write-once-read-many workloads; for general mixed read/write traffic a plain map under an RWMutex is faster.

Built-in maps are not safe for concurrent use. Concurrent writes trip the runtime's guard and abort with fatal error: concurrent map writes — even a concurrent read alongside a write can crash. Fix: guard every access with a sync.Mutex (or RWMutex), or use sync.Map for concurrent workloads.

wg.Add(1) runs inside the goroutine, but the scheduler may not start any goroutine before main reaches wg.Wait(). If Wait sees a zero counter it returns at once and the program can exit before the goroutines run. Fix: call wg.Add(1) in the loop before launching each goroutine.

The sync.Mutex is a local variable, so every call locks its own copy and the shared cache is never protected — concurrent calls race and crash with fatal error: concurrent map writes. Also value = cache[key] overwrites the argument, so the create path stores "", and unlocking between read and write makes get-or-create non-atomic. Fix: one shared lock — an RWMutex since reads dominate — held across the whole check-then-set, and stop clobbering value.

Go's RWMutex is not reentrant. A holds a read lock and calls B, which requests the write Lock. If another goroutine is already waiting for Lock, the runtime blocks new readers to avoid writer starvation — so B waits on a read lock that A still holds. The docs forbid recursive read locking; fix by locking once at the top level.

mu &sync.RWMutex{} is missing := — write mu := &sync.RWMutex{}. The lock discipline is otherwise sound: the updater reassigns rates under Lock, handlers read it under RLock, so every access is guarded. Keep the != http.ErrServerClosed check on ListenAndServe.

Store entries in a map keyed by User.ID, each with an expiry timestamp, guarded by a sync.RWMutex. Set writes the value and now+ttl under Lock; Get takes RLock and treats an entry whose expiry is past as a miss. A background cleaner goroutine sweeps expired keys so untouched entries don't linger; a Close method stops it from leaking.