Re: [go-nuts] Upgradable RLock

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 RWM

Re: [go-nuts] Upgradable RLock

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 wrote: > > Yes but only for a single reader - any concurrent reader is going to

Re: [go-nuts] Upgradable RLock

That is similar to sync.Map works, but it involves much more complex code. More importantly though, if multiple entries need to be keep in sync that technique doesn’t work - at least not directly/easily. This is a common need with associated caches. Even copy on write isn’t always suitable. Ass

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 3:24 PM Robert Engels wrote: > > That only works if what it is pointing to is cheap to copy. If it is a large > multi-layer structure a RW lock is usually more efficient. No significant copying is required, you just get a pointer to the value. Then you have some way to de

Re: [go-nuts] Upgradable RLock

That only works if what it is pointing to is cheap to copy. If it is a large multi-layer structure a RW lock is usually more efficient. > On Feb 4, 2023, at 5:19 PM, Ian Lance Taylor wrote: > > On Sat, Feb 4, 2023 at 3:11 PM Robert Engels wrote: >> >> I think with server processes - with p

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 3:11 PM Robert Engels wrote: > > I think with server processes - with possibly 100k+ connections - the > contention on a “read mainly” cache is more than you think. This test only > uses 500 readers with little work to simulate the 100k case. Not to get too far into the w

Re: [go-nuts] Upgradable RLock

I think with server processes - with possibly 100k+ connections - the contention on a “read mainly” cache is more than you think. This test only uses 500 readers with little work to simulate the 100k case. > On Feb 4, 2023, at 4:59 PM, Ian Lance Taylor wrote: > > On Sat, Feb 4, 2023 at 8:49

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 8:49 AM robert engels wrote: > > I took some time to put this to a test. The Go program here > https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the lock - but > a large % of runtime holding the lock. > > (You can’t run it on the Playground because of the leng

Re: [go-nuts] Upgradable RLock

Agreed. Copy-on-write is also very good if the shared structure is small. > On Feb 4, 2023, at 1:00 PM, Kurtis Rader wrote: > >  > FWIW, Using an RCU (https://en.wikipedia.org/wiki/Read-copy-update) algorithm > is often the best choice for caches where reads happen several orders of > magnit

Re: [go-nuts] Upgradable RLock

FWIW, Using an RCU (https://en.wikipedia.org/wiki/Read-copy-update) algorithm is often the best choice for caches where reads happen several orders of magnitude more often than writes. RCU usually avoids the need for any mutex by readers. I was working at Sequent Computer Systems when this was impl

Re: [go-nuts] Upgradable RLock

I took some time to put this to a test. The Go program here https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the lock - but a large % of runtime holding the lock. (You can’t run it on the Playground because of the length of time). You can commen

Re: [go-nuts] Upgradable RLock

On Mon, Jan 30, 2023 at 4:42 PM Robert Engels wrote: > > Yes but only for a single reader - any concurrent reader is going to > park/deschedule. If we are talking specifically about Go, then it's more complex than that. In particular, the code will spin briefly trying to acquire the mutex, befo

Re: [go-nuts] Upgradable RLock

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 wrote: > > On Mon, Jan 30, 2023 at 1:00 PM Robert Engels wrote:

Re: [go-nuts] Upgradable RLock

On Mon, Jan 30, 2023 at 1:00 PM Robert Engels 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

Re: [go-nuts] Upgradable RLock

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 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 re

Re: [go-nuts] Upgradable RLock

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 acq

Re: [go-nuts] Upgradable RLock

On Mon, Jan 30, 2023 at 11:26 AM Robert Engels 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

Re: [go-nuts] Upgradable RLock

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 wrote: > > On Sun, Jan

Re: [go-nuts] Upgradable RLock

On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina 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 si

Re: [go-nuts] Upgradable RLock

On Sun, Jan 29, 2023 at 7: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

[go-nuts] Upgradable RLock

>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 arra