Sujet : Re: smrproxy v2
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.lang.c++Date : 23. Nov 2024, 23:12:56
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vhtk18$1smrp$1@dont-email.me>
References : 1 2 3 4
User-Agent : Mozilla Thunderbird
On 11/23/24 16:31, Chris M. Thomasson wrote:
On 11/23/2024 8:10 AM, jseigh wrote:
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.
Nice! Are you using pthread_getspecific or tss_get in you C version?
Just thread_local.