sync.RWMutex

Canonical guidance

• start with sync.Mutex
• switch to sync.RWMutex only for real read-heavy contention
• keep lock ownership and protected invariants obvious

Use when

• read-mostly caches
• configuration snapshots with infrequent writes
• measured lock contention on many concurrent readers

Avoid

• choosing RWMutex by reflex
• holding RLock across long operations
• trying to upgrade RLock into Lock

Preferred pattern

• short RLock sections for pure reads, short Lock sections for mutations

Anti-pattern

• replacing every mutex with RWMutex “for scalability”

Explanation: This is tempting because read locks sound cheaper, but extra lock states add complexity and may not improve throughput.

Why

• RWMutex is a specialization, not the baseline synchronization tool