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

@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/

Hazard Pointers w/o memory barrier.

Show threadTobin BakerMar 8

@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).

Show threadJoe SeighMar 8
@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 .
Show threadPaul E. McKenney
@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.
Mar 9 at 3:24pmWeb
Show threadTobin BakerMar 9
@paulmckrcu @pkhuong @jwseigh yeah we have “epoch stall asserts” everywhere in test builds
Show threadPaul E. McKenneyMar 9
@tobinbaker @pkhuong @jwseigh OK, I will bite... Why do you need them "everywhere" instead of only on the update side?
Show threadTobin BakerMar 9
@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
Show threadPaul E. McKenneyMar 9
@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.)
Show threadTobin BakerMar 9
@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
Show threadPaul E. McKenneyMar 10
@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!