From a35bb44adcc56e4ea8594e34723b7182ffa0035c Mon Sep 17 00:00:00 2001 From: qiulaidongfeng <2645477756@qq.com> Date: Tue, 15 Aug 2023 02:13:47 +0000 Subject: [PATCH] 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 --- src/sync/rwmutex.go | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) 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 -- 2.50.0