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”.
The text was updated successfully, but these errors were encountered:
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 theRWMutex
type is currently phrased in terms of goroutines holding the lock (emphasis mine):This stands in contrast to the documentation for the
Unlock
method, which states more clearly:The type-level documentation should be rewritten so that it does not imply that the existing holder of the RWMutex is “a goroutine”.
The text was updated successfully, but these errors were encountered: