Path: ...!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 15:32:33 -0700
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <vfmf21$kavl$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 27 Oct 2024 23:32:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9f277b258384b51a19551de63f05f922";
	logging-data="666613"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rU0ZtfjfjxWMBp01kLWTS68Elo9GJ14c="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:q2vRGf7NFHU9m2FJP2eLYo4+a20=
In-Reply-To: <vfmesn$k6mn$1@dont-email.me>
Content-Language: en-US
Bytes: 5665

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? ;^)