| Deutsch English Français Italiano |
|
<vfn2di$r8ca$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> Newsgroups: comp.lang.c++ Subject: Re: smrproxy v2 Date: Sun, 27 Oct 2024 21:02:58 -0700 Organization: A noiseless patient Spider Lines: 118 Message-ID: <vfn2di$r8ca$1@dont-email.me> References: <vequrc$2o7qc$1@dont-email.me> <verr04$2stfq$1@dont-email.me> <verubk$2t9bs$1@dont-email.me> <ves78h$2ugvm$2@dont-email.me> <vetj1f$39iuv$1@dont-email.me> <vfh4dh$3bnuq$1@dont-email.me> <vfh7mg$3c2hs$1@dont-email.me> <vfm4iq$ill4$1@dont-email.me> <vfmesn$k6mn$1@dont-email.me> <vfmf21$kavl$1@dont-email.me> <vfmm9a$lob3$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 28 Oct 2024 05:02:59 +0100 (CET) Injection-Info: dont-email.me; posting-host="22ea2bd49efaecaba901b5a855237ac5"; logging-data="893322"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bQnDdoqD4bS+k4ujMeVActdCtrQcDUCI=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:nyHKYVQ98O6Tl6QjBRBGyFncxlo= Content-Language: en-US In-Reply-To: <vfmm9a$lob3$1@dont-email.me> Bytes: 6548 On 10/27/2024 5:35 PM, jseigh wrote: > On 10/27/24 18:32, Chris M. Thomasson wrote: >> On 10/27/2024 3:29 PM, jseigh wrote: >>> On 10/27/24 15:33, Chris M. Thomasson wrote: >>>> 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? >>> >>> I don't think so. It's platform dependent. Apart from linux, mostly >>> it's done with a call to some virtual memory function that flushes >>> the TLBs (translation lookaside buffers) which involves IPI calls >>> to all the processors and those have memory barriers. This is >>> old, 1973, patent 3,947,823 cited by the patent I did. >>> >>> Anyway, I version the code so there's a asymmetric memory barrier >>> version and an explicit memory barrier version, the latter >>> being much slower. >> >> Ahh, nice! acquire/release, no seq_cst, right? ;^) >> > > The membar version? That's a store/load membar so it is expensive. I was wondering in your c++ version if you had to use any seq_cst barriers. I think acquire/release should be good enough. Now, when I say C++, I mean pure C++, no calls to FlushProcessWriteBuffers and things like that. I take it that your pure C++ version has no atomic RMW, right? Just loads and stores?