Since it's caught in a closure I didn't believe it was necessary to indirect it? Maybe my mental model for how closure scoped vars get addressed in Go is wrong?

type RWMutex

[func (rw *RWMutex) Lock()](https://pkg.go.dev/sync#RWMutex.Lock)
[func (rw *RWMutex) RLock()](https://pkg.go.dev/sync#RWMutex.RLock)
[func (rw *RWMutex) RLocker() Locker](https://pkg.go.dev/sync#RWMutex.RLocker)
[func (rw *RWMutex) RUnlock()](https://pkg.go.dev/sync#RWMutex.RUnlock)
[func (rw *RWMutex) TryLock() bool](https://pkg.go.dev/sync#RWMutex.TryLock)
[func (rw *RWMutex) TryRLock() bool](https://pkg.go.dev/sync#RWMutex.TryRLock)
[func (rw *RWMutex) Unlock()](https://pkg.go.dev/sync#RWMutex.Unlock)

Given these method signatures, why did Go let me do this?

On a second readthrough, I think you're right. The fact that it's in a closure and not an argument means it's captured by reference, and the style guide at least suggests that we ought to change it to var cacheMutex sync.RWMutex. The culprit was likely not locking around the reads from the maps.

For the methods on RWMutex, unfortunately, I believe Go will let you call them with or without a reference, without having an indication at the call site. The implementation is choosing whether the receiver is passed by reference or by value.

If you haven't already seen it, I recommend reading Uber's analysis of data races in Go. I think I confused the interaction between 1. and 4. in that article, but got 3. correct.

Interesting that the zero value of a mutex is a valid mutex.

The thing that threw me here was not knowing I needed a reader lock; I (incorrectly) assumed that locks during writes would be enough, but realize now that it doesn't either implicitly lock out readers during the write lock and the corollary implication that writes aren't necessarily atomic.

Arguably this should be using sync.Map but that loses types and becomes a pain to use.

The Uber data races post was in a browser tab yesterday as to-read, and, well, now it has been read. About 12 hours too late.