@tobinbaker more interesting biased lock (replace the time bound on TSO with membarrier) https://dl.acm.org/doi/10.1145/2775054.2694374

@pkhuong thanks I remember that paper but hadn’t thought of abstracting out the asymmetric barrier! btw how do you think asymmetric barriers change the tradeoffs between hazptrs and EBR? I feel like hazptrs are more compelling now given the reduced read side overhead, though still more intrusive than EBR/QSBR.

@tobinbaker I think of EBR as proxy reclamation on top of HP, so it's a continuum for me. You can have as many and as fine grained reclamation domains as makes sense for the application.

@pkhuong @tobinbaker
#hazardpointers w/o the membar was done as POC around this time
https://groups.google.com/g/comp.programming.threads/c/XU6BtGNSkF0/m/AmWXvkGn3DAJ?pli=1

EBR wait-free w/o membar implementation (smrproxy) in here https://github.com/jseigh/proxies

Also there are about 2 or more ways to do #waitfree hazard pointers. See postings in https://jseigh.wordpress.com/

@jwseigh thanks for the pointers! @pkhuong has been namedropping proxy reclamation but I haven't seen it in the concurrency lit so I look forward to checking out your github repo and blog posts!

btw I'm getting tired of constant customer issues from GC delay with EBR, and looking for alternatives (we abandoned hazptrs many years ago because of overhead but EBR is just a different kind of poison).

@tobinbaker @pkhuong
Deferred reclamation is sort of meant for short read access and not frequently doing writes.
Reference counting has the least latency for reclamation but has a lot of overhead.
RCU w/ restartable sequences could be a thing but I don't know where that went. I had a discussion with
@paulmckrcu about implementing it w/ signals but it turned out not to be feasible. This was back herehttps://groups.google.com/g/comp.os.linux.development.system/c/q9W9svf_DgY/m/3-RYj32I1Q4J .

@jwseigh @tobinbaker @pkhuong One way of looking at RCU (of which EBR is a set of implementations) is as a replacement for reader-writer locking. Staying in an RCU reader for too long is just as bad as staying in a reader-writer-locking reader for too long. In the Linux kernel, we use stall warnings to catch these usage bugs, but user-mode implementations seem slow to adopt this approach.

@paulmckrcu @pkhuong @jwseigh yeah we have “epoch stall asserts” everywhere in test builds

@tobinbaker @pkhuong @jwseigh OK, I will bite... Why do you need them "everywhere" instead of only on the update side?

@paulmckrcu @pkhuong @jwseigh it's mostly slow ops like I/O or lock waits where we want to ensure that the current thread isn't holding an epoch open

@tobinbaker @pkhuong @jwseigh OK, that does make a lot of sense!

Do you also have the update side flag the offending thread when a grace period extends for too long? (AKA thread keeping epoch open for too long.)

@paulmckrcu @pkhuong @jwseigh yes, we do track epoch time held in debug builds and assert on long hold times in GC, sorry forgot to mention that

@tobinbaker @pkhuong @jwseigh Sounds good, then! And for its part, Linux-kernel (ab)uses the lock dependency checker (lockdep) to detect blocking within RCU readers.

Circling back to Joe Seigh's post, RCU (including EBR) is a specialized tool, so it does have limits. Part of the problem is that we do not yet have a complete concurrency toolkit (and maybe never will), so concurrency tools will continue to get put to jobs for which they are not well suited, RCU included. C'est la vie!