On Mon, Jan 30, 2023 at 11:26 AM Robert Engels <reng...@ix.netcom.com> wrote: > > 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.
The best read lock implementation is not going to be better than the best plain mutex implementation. And with current technology any implementation is going to require atomic memory operations which require coordinating cache lines between CPUs. If your reader activity is so large that you get significant contention on a plain mutex (recalling that we are assuming the case where the operations under the read lock are quick) then you are also going to get significant contention on a read lock. The effect is that the read lock isn't going to be faster anyhow in practice, and your program should probably be using a different approach. Ian > > 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/CAOyqgcWJ%2BLPOoTk9H7bxAj8_dLsuhgOpy_bZZrGW%3D%2Bz6N%3DrX-w%40mail.gmail.com.
