From: qiulaidongfeng <2645477756@qq.com> Date: Tue, 15 Aug 2023 02:13:47 +0000 (+0000) Subject: sync: deemphasize goroutines in RWMutex documentation X-Git-Tag: go1.22rc1~965 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=a35bb44adcc56e4ea8594e34723b7182ffa0035c;p=gostls13.git sync: deemphasize goroutines in RWMutex documentation Fixes #41555 Change-Id: I46b9535b1687d481d2ac76296e8ba7de26d6e2e2 Change-Id: I46b9535b1687d481d2ac76296e8ba7de26d6e2e2 GitHub-Last-Rev: 38af46c18922eea80e05c8ed9f5e10002ab7244d GitHub-Pull-Request: golang/go#61977 Reviewed-on: https://go-review.googlesource.com/c/go/+/518859 Reviewed-by: Bryan Mills Reviewed-by: Cherry Mui Run-TryBot: Bryan Mills LUCI-TryBot-Result: Go LUCI TryBot-Result: Gopher Robot Auto-Submit: Bryan Mills --- diff --git a/src/sync/rwmutex.go b/src/sync/rwmutex.go index 1317624035..f445b66fd7 100644 --- a/src/sync/rwmutex.go +++ b/src/sync/rwmutex.go @@ -19,12 +19,11 @@ import ( // // A RWMutex must not be copied after first use. // -// 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. +// If any goroutine calls Lock while the lock is already held by +// one or more readers, concurrent calls to RLock will block until +// the writer has acquired (and released) the lock, to ensure that +// the lock eventually becomes available to the writer. +// Note that this prohibits recursive read-locking. // // In the terminology of the Go memory model, // the n'th call to Unlock “synchronizes before” the m'th call to Lock