1. Forum
  2. Usenet
  3. COMP.LANG.C++

  • Re: "New features in C++26" By Daroc Alden

    From jseigh@21:1/5 to Lynn McGuire on Mon Jul 29 11:15:46 2024
    On 7/22/24 23:11, Lynn McGuire wrote:
    "New features in C++26" By Daroc Alden
       https://lwn.net/Articles/979870/

    "ISO releases new C++ language standards on a three-year cadence; now
    that it's been more than a year since the finalization of C++23, we have
    a good idea of what features could be adopted for C++26 — although proposals can still be submitted until January 2025. Of particular
    interest is the addition of support for hazard pointers and user-space read-copy-update (RCU). Even though C++26 is not yet a standard, many of
    the proposed features are already available to experiment with in GCC or Clang."

    Lynn

    Speaking of hazard pointers, does anyone know where the idea of using asymmetric memory barriers in them came from. I think I know but I
    haven't found any independent confirmation of it. I know these are
    coming from the folly library but I got no answers from them.

    There isn't a lot of attribution in open source so you can't tell where something came from or if it was independently developed. I know "split reference counting" is now folklore according to a cppcon talk.

    Joe Seigh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jseigh@21:1/5 to Chris M. Thomasson on Tue Aug 6 14:06:16 2024
    On 8/5/2024 10:40 PM, Chris M. Thomasson wrote:
    On 8/5/2024 7:38 PM, Chris M. Thomasson wrote:
    On 8/5/2024 1:41 PM, Chris M. Thomasson wrote:


    Using RCU to get around the #StoreLoad membar in SMR loads is asymmetric in a sense... ?

    RCU grace periods, quiescent periods can all be used in an asymmetric realm. We can artificially initiate them, or detect them. That is an implementation detail, right'ish?

    I used term RCU because RCU used context switches as quiesce points and I was tracking them since context switches are effectively a memory barrier.

    Linux membarrier() uses context switches (effected by IPI, interprocessor interrupts) in its implementation. That being the case,
    if you were using RSEQ (restartable sequences) and wanted to do something like work stealing, i.e. moving something
    from one processor's local storage to another processor's (the one doing the stealing) storage, you could use a call to
    membarrier() after the move to make sure any ongoing operations by the former processor were complete before you access
    the appropriated storage. I don't know how performant it would be, though.

    Joe Seigh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jseigh@21:1/5 to jseigh on Tue Aug 6 14:29:13 2024
    On 7/29/2024 11:15 AM, jseigh wrote:

    There isn't a lot of attribution in open source so you can't tell where something came from or if it was independently developed.  I know "split reference counting" is now folklore according to a cppcon talk.

    I tried to find that "folklore" comment. I thought it was in the cppcon 2023 talk
    'Lock-free Atomic Shared Pointers Without a Split Reference Count? It Can Be Done! by Daniel Anderson'
    but I couldn't find it again (it's an hour long talk). I did notice the split reference counting
    technique described was slightly different than what I called differential reference counting.
    It looks to me like split reference counting as described has an ABA problem.

    Joe Seigh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jseigh@21:1/5 to jseigh on Tue Aug 6 18:58:14 2024
    On 8/6/2024 2:29 PM, jseigh wrote:
    On 7/29/2024 11:15 AM, jseigh wrote:

    There isn't a lot of attribution in open source so you can't tell where something came from or if it was independently developed.  I know "split reference counting" is now folklore according to a cppcon talk.

    I tried to find that "folklore" comment.  I thought it was in the cppcon 2023 talk
    'Lock-free Atomic Shared Pointers Without a Split Reference Count? It Can Be Done! by Daniel Anderson'
    but I couldn't find it again (it's an hour long talk).  I did notice the split reference counting
    technique described was slightly different than what I called differential reference counting.
    It looks to me like split reference counting as described has an ABA problem.


    Or maybe not. I took a quick look at the folly code. You really can't easily read c++ code in that style
    so I basically guessed a bit. It would be better described as cached local references, rather than split
    reference counting. You increment and decrement the local ref count in the atomic shared pointer and just
    update the global ref count if the atomic shared pointer is changed. When the local ref is dropped and
    the atomic shared ref is different or the local ref count is zero, the global ref count is decremented instead.

    It's all about which cache lines you are hitting and how often. If you have a lot of atomic shared pointers to
    an object, then maybe "split" reference counting is better since you are splitting across more cache lines. If
    you have just one atomic shared pointer then differential reference counting might be better. At any rate,
    reference counting performs rather poorly compared to other methods of deferred reclamation.

    Joe Seigh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)