Sujet : Re: smrproxy v2
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.lang.c++Date : 21. Nov 2024, 21:17:32
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vho4gs$pd3i$1@dont-email.me>
References : 1
User-Agent : Mozilla Thunderbird
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.
Joe Seigh