I don’t think that is true. A RW lock is always better when the reader activity is far greater than the writer - simply because in a good implementation the read lock can be acquired without blocking/scheduling activity.
> On Jan 30, 2023, at 12:49 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina > <diegoaugustomol...@gmail.com> wrote: >> >> From times to times I write a scraper or some other tool that would >> authenticate to a service and then use the auth result to do stuff >> concurrently. But when auth expires, I need to synchronize all my goroutines >> and have a single one do the re-auth process, check the status, etc. and >> then arrange for all goroutines to go back to work using the new auth result. >> >> To generalize the problem: multiple goroutines read a cached value that >> expires at some point. When it does, they all should block and some I/O >> operation has to be performed by a single goroutine to renew the cached >> value, then unblock all other goroutines and have them use the new value. >> >> I solved this in the past in a number of ways: having a single goroutine >> that handles the cache by asking it for the value through a channel, using >> sync.Cond (which btw every time I decide to use I need to carefully re-read >> its docs and do lots of tests because I never get it right at first). But >> what I came to do lately is to implement an upgradable lock and have every >> goroutine do: > > > We have historically rejected this kind of adjustable lock. There is > some previous discussion at https://go.dev/issue/4026, > https://go.dev/issue/23513, https://go.dev/issue/38891, > https://go.dev/issue/44049. > > For a cache where checking that the cached value is valid (not stale) > and fetching the cached value is quick, then in general you will be > better off using a plain Mutex rather than RWMutex. RWMutex is more > complicated and therefore slower. It's only useful to use an RWMutex > when the read case is both contested and relatively slow. If the read > case is fast then the simpler Mutex will tend to be faster. And then > you don't have to worry about upgrading the lock. > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXNVFkc5H-L6K4Mt81gB6u91Ja07hob%3DS8Qwgy2buiQjQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CC51E5B9-B829-49D3-8421-7E19CA6570BC%40ix.netcom.com.
