sync: deemphasize goroutines in RWMutex documentation #41555
Description
sync.RWMutex performs no goroutine-specific accounting (see also #9201) and cannot be locked reentrantly.
Despite the fact that a sync.RWMutex is not held by a specific goroutine, the documentation for the RWMutex type is currently phrased in terms of goroutines holding the lock (emphasis mine):
If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
This stands in contrast to the documentation for the Unlock method, which states more clearly:
As with Mutexes, a locked RWMutex is not associated with a particular goroutine. One goroutine may RLock (Lock) a RWMutex and then arrange for another goroutine to RUnlock (Unlock) it.
The type-level documentation should be rewritten so that it does not imply that the existing holder of the RWMutex is “a goroutine”.