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.

Reply via email to