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: Fri, 25 Oct 2024 15:00:15 -0700
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <vfh4dh$3bnuq$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 26 Oct 2024 00:00:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8fd9edeffa64a10600130af9cd1a89e6";
	logging-data="3530714"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19S4394iB+jqXw4QHJD+6p+gsJWFZ2s8jU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xtkDG+1osMRIciZuhXxPuUT3sy4=
Content-Language: en-US
In-Reply-To: <vetj1f$39iuv$1@dont-email.me>
Bytes: 3924

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/