A quick search found this https://yizhang82.dev/lock-free-rw-lock which describes the algo pretty well.
> On Jan 30, 2023, at 3:00 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > Pure readers do not need any mutex on the fast path. It is an atomic CAS - > which is faster than a mutex as it allows concurrent readers. On the slow > path - fairness with a waiting or active writer - it degenerates in > performance to a simple mutex. > > The issue with a mutex is that you need to acquire it whether reading or > writing - this is slow…. (at least compared to an atomic cas) > >>> On Jan 30, 2023, at 2:24 PM, Ian Lance Taylor <i...@golang.org> wrote: >>> >>> 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. -- 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/DF457770-FC72-4AA4-AA7C-84B3900FFD95%40ix.netcom.com.
