Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!eternal-september.org!feeder3.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: Thu, 17 Oct 2024 17:24:08 -0700
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <ves9r9$2v6q6$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>
 <ves9do$2ugvm$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Oct 2024 02:24:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f276c36720a0a7a49bc7397de7896a56";
	logging-data="3119942"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Deq5zy537U/v21W3tnUfD/6atvV8btDs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4k1FPEtPufeMeuyUH6AfV6VGmoc=
In-Reply-To: <ves9do$2ugvm$3@dont-email.me>
Content-Language: en-US
Bytes: 4248

On 10/17/2024 5:16 PM, Chris M. Thomasson wrote:
> On 10/17/2024 4:40 PM, 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 ?
> 
> I remember a long time ago I was messing around where each thread had 
> two version counters:
> 
> pseudo code:
> 
> per_thread
> {
>      word m_version[2];
> 
> 
>      word acquire()
>      {
>          word ver = load(global_version);
>          m_version[ver % 2] = ver ;
>          return ver ;
>      }
> 
> 
>      void release(word ver)
>      {
>          m_version[ver % 2] = 0;
>      }
> }
> 
> 
> The global_version would only be incremented by the polling thread. This 
> was WAY back. I think I might of posted about it on cpt.
> 
> So, when a node was made unreachable, it would be included in the 
> polling logic. The polling could increment the version counter then wait 
> for all the threads prior m_versions to be zero. Collect the current 
> generation of objects in a defer list. Then on the next cycle it would 
> increment the version counter, wait until all threads prior versions 
> were zero, then delete the defer count, and transfer the current gen to 
> the defer.
> 
> It went something like that.
> 

Iirc, I was using FlushProcessWriteBuffers back then for an asymmetric 
barrier for my experiment. The polling thread would execute one after it 
increased the global version. Actualy, I can't remember where I placed 
it exactly, after or before. The defer list made things work.