Re: smrproxy v2

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.