Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!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"
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:
References:
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:
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.