Sujet : Re: smrproxy v2
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.lang.c++Date : 23. Nov 2024, 17:10:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vhsuq6$1p56f$1@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
On 11/21/24 15:17, jseigh wrote:
On 10/17/24 08:10, 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 got a port to c++ working now. There are 5 proxy implementations
1) smrproxy v2
2) arcproxy - reference counted proxy
3) rwlock based proxy
4) mutex based proxy
5) an unsafe proxy with no locking
The testcase is templated so you can use any of the
5 proxy implementations without rewriting for each proxy
type. You can do apple to apple comparisons. I
realize that's the complete antithesis of current
programming practices but there you have it. :)
A bit of clean up and performance tuning now.
Ok, smrproxy lock/unlock is down to 0.6 nanoseconds now,
about what the C version was.
Joe Seigh