The article is very suspect. In the first section "A simple implementation"
the code is badly broken. You can't get a reader lock if the writer has the
write lock - which the code doesn't test:
func (l *ReaderCountRWLock) RLock()
{
l.m.Lock()
l.readerCount++
l.m.Unlock()
}
A single writer RWMutex implementation can be more efficient than the
general case RWMutex - since you don't need to maintain a list of waiting
writers. Usually though you would use a specialized data structure designed
for single writer - multiple reader which can be lock-free for both reading
and writing.
On Sunday, February 5, 2023 at 12:42:29 AM UTC-6 ba...@iitbombay.org wrote:
> You can implement your own multiple-reader-single-writer-lock using what
> Go gives you.
> For example:
> https://eli.thegreenplace.net/2019/implementing-reader-writer-locks/
>
> > On Jan 30, 2023, at 4:42 PM, Robert Engels <ren...@ix.netcom.com> wrote:
> >
> > Yes but only for a single reader - any concurrent reader is going to
> park/deschedule.
> >
> > There’s a reason RW locks exist - and I think it is pretty common - but
> agree to disagree :)
> >
> >> On Jan 30, 2023, at 6:23 PM, Ian Lance Taylor <ia...@golang.org> wrote:
> >>
> >> On Mon, Jan 30, 2023 at 1:00 PM Robert Engels <ren...@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)
> >>
> >> The fast path of a mutex is also an atomic CAS.
> >>
> >> Ian
> >>
> >>>>> On Jan 30, 2023, at 2:24 PM, Ian Lance Taylor <ia...@golang.org>
> wrote:
> >>>>
> >>>> On Mon, Jan 30, 2023 at 11:26 AM Robert Engels <ren...@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 <ia...@golang.org>
> wrote:
> >>>>>>
> >>>>>> On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina
> >>>>>> <diegoaugu...@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...@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...@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...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVLzkTgiYqw%2BWh6pTFX74X-LYoyPFK5bkX7T8J8j3mb%3Dg%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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/E700E6A8-0114-4F64-9042-B9E9C62F06FA%40ix.netcom.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/5c9ca527-5bea-478d-8f4a-40748dcd063bn%40googlegroups.com.
