Re: smrproxy v2

On 10/25/2024 3:56 PM, jseigh wrote:

On 10/25/24 18:00, Chris M. Thomasson wrote:

On 10/18/2024 5:07 AM, jseigh wrote:

On 10/17/24 19:40, Chris M. Thomasson wrote:

On 10/17/2024 2:08 PM, jseigh wrote:

On 10/17/24 16:10, Chris M. Thomasson wrote:

On 10/17/2024 5:10 AM, jseigh wrote:

I replaced the hazard pointer logic in smrproxy.  It's now wait-free
instead of mostly wait-free.  The reader lock logic after loading
the address of the reader lock object into a register is now 2
instructions a load followed by a store.  The unlock is same
as before, just a store.
>
It's way faster now.
>
It's on the feature/003 branch as a POC.   I'm working on porting
it to c++ and don't want to waste any more time on c version.
>
No idea of it's a new algorithm.  I suspect that since I use
the term epoch that it will be claimed that it's ebr, epoch
based reclamation, and that all ebr algorithms are equivalent.
Though I suppose you could argue it's qsbr if I point out what
the quiescent states are.

>
I have to take a look at it! Been really busy lately. Shit happens.
>

>
There's a quick and dirty explanation at
http://threadnought.wordpress.com/
>
repo at https://github.com/jseigh/smrproxy
>
I'll need to create some memory access diagrams that
visualize how it works at some point.
>
Anyway if it's new, another algorithm to use without
attribution.

>
Interesting. From a quick view, it kind of reminds me of a distributed seqlock for some reason. Are you using an asymmetric membar in here? in smr_poll ?

>
Yes, linux membarrier() in smr_poll.
>
Not seqlock, not least for the reason that exiting the critical region
is 3 instructions unless you use atomics which are expensive and have
memory barriers usually.
>
A lot of the qsbr and ebr reader lock/unlock code is going to look
somewhat similar so you have to know how the reclaim logic uses it.
In this case I am slingshotting off of the asymmetric memory barrier.
>
Earlier at one point I was going to have smrproxy use hazard pointer
logic or qsbr logic as a config option, but the extra code complexity
and the fact that qsbr required 2 grace periods kind of made that
unfeasible.  The qsbr logic was mostly ripped out but there were still
some pieces there.
>
Anyway I'm working a c++ version which involves a lot of extra work
besides just rewriting smrproxy.  There coming up with an api for
proxies and testcases which tend to be more work than the code that
they are testing.

>
Damn! I almost missed this post! Fucking Thunderbird... Will get back to you. Working on something else right now Joe, thanks.
>
https://www.facebook.com/share/p/ydGSuPLDxjkY9TAQ/

  No problem.  The c++ work is progressing pretty slowly, not least in
part because the documentation is not always clear as to what
something does or even what problem it is supposed to solve.
To think I took a pass on on rust because I though it was
more complicated than it needed to be.

Never even tried Rust, shit, I am behind the times. ;^)
Humm... I don't think we can get 100% C++ because of the damn asymmetric membar for these rather "specialized" algorithms?
Is C++ thinking about creating a standard way to gain an asymmetric membar?