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: Sat, 2 Nov 2024 13:50:51 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <vg63bc$3ukov$6@dont-email.me>
References: <vequrc$2o7qc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 02 Nov 2024 21:50:56 +0100 (CET)
Injection-Info: dont-email.me; posting-host="6e8fcc6cbd8587a7e26447d4479abcfd";
	logging-data="4150047"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+TmakzTrCJy2sI1rZi6biv6kKqkElJLlE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Il7dUJnkevRNRxR1OC5Pvh7m9zc=
In-Reply-To: <vequrc$2o7qc$1@dont-email.me>
Content-Language: en-US
Bytes: 2587

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.
> 
> Joe Seigh

Another crude experiment I was testing out back in the day. Heart beat 
for per threads, wrt a version that does not use asymmetric membars to 
test against:

per_thread
{
     word cur = 0;

     void beat()
     {
         word global = g_version;
         if (cur == global) return;
         store_seq_cst(&cur, global);
     }
}


Well, this case requires worker threads to beat every now and then when 
they are outside of critical sections. Just a test case against my 
asymmetric versions. The _single_ poll thread would increment the 
g_version then check for threads that were equal to the new version. 
This was a quiescent period when all threads went through it.

Of course the asymmetric version beat it, but it was fun to test against 
anyway.