Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #120752

Re: smrproxy v2

From jseigh <jseigh_es00@xemaps.com>
Newsgroups comp.lang.c++
Subject Re: smrproxy v2
Date 2024-10-27 18:29 -0400
Organization A noiseless patient Spider
Message-ID <vfmesn$k6mn$1@dont-email.me> (permalink)
References (3 earlier) <ves78h$2ugvm$2@dont-email.me> <vetj1f$39iuv$1@dont-email.me> <vfh4dh$3bnuq$1@dont-email.me> <vfh7mg$3c2hs$1@dont-email.me> <vfm4iq$ill4$1@dont-email.me>

Show all headers | View raw

On 10/27/24 15:33, Chris M. Thomasson wrote:
> On 10/25/2024 3:56 PM, jseigh wrote:
>> On 10/25/24 18:00, Chris M. Thomasson wrote:
>>> On 10/18/2024 5:07 AM, jseigh wrote:
>>>> On 10/17/24 19:40, 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 ?
>>>>
>>>> Yes, linux membarrier() in smr_poll.
>>>>
>>>> Not seqlock, not least for the reason that exiting the critical region
>>>> is 3 instructions unless you use atomics which are expensive and have
>>>> memory barriers usually.
>>>>
>>>> A lot of the qsbr and ebr reader lock/unlock code is going to look
>>>> somewhat similar so you have to know how the reclaim logic uses it.
>>>> In this case I am slingshotting off of the asymmetric memory barrier.
>>>>
>>>> Earlier at one point I was going to have smrproxy use hazard pointer
>>>> logic or qsbr logic as a config option, but the extra code complexity
>>>> and the fact that qsbr required 2 grace periods kind of made that
>>>> unfeasible.  The qsbr logic was mostly ripped out but there were still
>>>> some pieces there.
>>>>
>>>> Anyway I'm working a c++ version which involves a lot of extra work
>>>> besides just rewriting smrproxy.  There coming up with an api for
>>>> proxies and testcases which tend to be more work than the code that
>>>> they are testing.
>>>
>>> Damn! I almost missed this post! Fucking Thunderbird... Will get back 
>>> to you. Working on something else right now Joe, thanks.
>>>
>>> https://www.facebook.com/share/p/ydGSuPLDxjkY9TAQ/
>>
>>
>> No problem.  The c++ work is progressing pretty slowly, not least in
>> part because the documentation is not always clear as to what
>> something does or even what problem it is supposed to solve.
>> To think I took a pass on on rust because I though it was
>> more complicated than it needed to be.
> 
> Never even tried Rust, shit, I am behind the times. ;^)
> 
> Humm... I don't think we can get 100% C++ because of the damn asymmetric 
> membar for these rather "specialized" algorithms?
> 
> Is C++ thinking about creating a standard way to gain an asymmetric membar?

I don't think so.  It's platform dependent.  Apart from linux, mostly
it's done with a call to some virtual memory function that flushes
the TLBs (translation lookaside buffers) which involves IPI calls
to all the processors and those have memory barriers.  This is
old, 1973, patent 3,947,823 cited by the patent I did.

Anyway, I version the code so there's a asymmetric memory barrier
version and an explicit memory barrier version, the latter
being much slower.

Joe Seigh

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-17 08:10 -0400
  Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 13:10 -0700
    Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-17 17:08 -0400
      Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 16:40 -0700
        Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 17:16 -0700
          Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 17:24 -0700
        Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-18 08:07 -0400
          Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-25 15:00 -0700
            Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-25 18:56 -0400
              Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 12:33 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-27 18:29 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 15:32 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-27 20:35 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:02 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-28 07:45 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 14:57 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 15:09 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-28 21:17 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:35 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-29 07:23 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 14:51 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:38 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-29 07:27 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 14:56 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:36 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-01 12:20 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:41 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 15:05 -0700
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:39 -0400
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-03 21:14 -0800
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-04 07:46 -0500
                Re: smrproxy v2 Muttley@DastartdlyHQ.org - 2024-11-04 14:09 +0000
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-04 12:42 -0800
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 13:51 -0800
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-12 00:43 -0800
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-12 07:29 -0500
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-12 13:55 -0800
                Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-12 19:48 -0500
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-25 20:36 -0800
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:08 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:09 -0700
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:13 -0700
  Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 22:02 -0700
    Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:40 -0700
    Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:42 -0700
      Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:53 -0700
  Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:54 -0700
    Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:43 -0400
  Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-02 13:50 -0700
  Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-21 15:17 -0500
    Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-23 11:10 -0500
      Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-23 13:31 -0800
        Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-23 17:12 -0500
          Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-23 17:46 -0800
      Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-24 15:14 -0500
        Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 15:19 -0800
          Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-24 19:09 -0500
            Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:37 -0800
              Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:48 -0800
            Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:47 -0800
              Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-25 06:31 -0500
                Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:12 -0800
        Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-27 10:29 -0500
          Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-09 13:34 -0500
            Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-11 07:13 -0500
              Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-11 16:22 -0800

csiph-web