Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Read Locks Are Not Your Friends

eventual-consistency.vercel.app

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Read Locks Are Not Your Friends

#11

Post by PaulHoule »

ot wrote: post #8

This is drawing broad conclusions from a specific RW mutex implementation. Other implementations adopt techniques to make the readers scale linearly in the read-mostly case by using per-core state (the drawback is that write locks need to scan it). One example is folly::SharedMutex, which is very battle-tested: https://uvdn7.github.io/shared-mutex/ There are more sophisticated techniques such as RCU or hazard pointer…

I think it’s not unusual that reader-writer locks, even if well implemented, get in places where there are so many readers stacked up that writers never get to get a turn or 1 writer winds up holding up N readers which is not so scalable as you increase N.

Re: Read Locks Are Not Your Friends

#12

Post by mike_hearn »

ot wrote: post #8

This is drawing broad conclusions from a specific RW mutex implementation. Other implementations adopt techniques to make the readers scale linearly in the read-mostly case by using per-core state (the drawback is that write locks need to scan it). One example is folly::SharedMutex, which is very battle-tested: https://uvdn7.github.io/shared-mutex/ There are more sophisticated techniques such as RCU or hazard pointer…

Right, and if you're on the JVM you have access to things like ConcurrentHashMap which is lock free.

Re: Read Locks Are Not Your Friends

#13

Post by PunchyHamster »

whizzter wrote: post #2

I'd be super interested in how this compares between cpu architectures, is there an optimization in Apple silicon that makes this bad while it'd fly on Intel/AMD cpus?

Read lock requires communication between cores. It just can't scale with CPU count

Re: Read Locks Are Not Your Friends

#15

Post by the_duke »

hansvm wrote: post #4
whizzter wrote: post #2

I'd be super interested in how this compares between cpu architectures, is there an optimization in Apple silicon that makes this bad while it'd fly on Intel/AMD cpus?

I've observed the same behavior on AMD and Intel at $WORK. Our solution (ideal for us, reads happening roughly 1B times more often than writes) was to pessimize writes in favour of reads and add some per-thread state to prevent cache line sharing. We also tossed in an A/B system, so reads aren't delayed even while writes are happening; they just get stale data (also fine for our purposes).

Rust has an interesting crate for this, arc-swap [1].

It's essentially just an atomic pointer that can be swapped out.

[1] https://docs.rs/arc-swap/latest/arc_swap/

Re: Read Locks Are Not Your Friends

#16

Post by Jyaif »

ot wrote: post #8

This is drawing broad conclusions from a specific RW mutex implementation. Other implementations adopt techniques to make the readers scale linearly in the read-mostly case by using per-core state (the drawback is that write locks need to scan it). One example is folly::SharedMutex, which is very battle-tested: https://uvdn7.github.io/shared-mutex/ There are more sophisticated techniques such as RCU or hazard pointer…

And a Rust equivalent of folly::SharedMutex: https://docs.rs/crossbeam-utils/latest/crossbeam_utils/sync/...

Re: Read Locks Are Not Your Friends

#19

Post by sevensor »

gpderetta wrote: post #17
sevensor wrote: post #14

Does this apply also to std::shared_mutex in C++? This is a timely article if so; I’m in the middle of doing some C++ multithreading that relies on a shared_mutex. I have some measuring to do.

mostly yes.

Thanks, that’s what I was afraid of. The ping ponging described in the article seems hard to avoid regardless of what language you’re using.

Re: Read Locks Are Not Your Friends

#20

Post by alecco »

It always amazes me the amount these folks are willing to work and struggle just to avoid reading basic database literature.

Also Fedor Pikus has some nice cppcon talks from years ago on all this. Very low level.

Post reply on HN