Path: ...!weretis.net!feeder8.news.weretis.net!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:16:55 -0700
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <ves9do$2ugvm$3@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Oct 2024 02:16:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f276c36720a0a7a49bc7397de7896a56";
	logging-data="3097590"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+7smb5EwQqT2TKP9N/B4WZLMJzRguSBv8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JyKgFoDfh8ro/EZn7HVabR//zXk=
In-Reply-To: <ves78h$2ugvm$2@dont-email.me>
Content-Language: en-US
Bytes: 3679

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.