Re: Atomic caching of smart pointers

On 9/28/2024 12:10 AM, Paavo Helde wrote:

On 27.09.2024 03:24, Chris M. Thomasson wrote:

[...]

>
Sorry for all the questions. ;^o

No-no! I'm happy to think over this code.
 I'm still a bit worried about the memory order parameteres, I have not used them before and I suspect they might not be distinguishable on the platforms which I need to support (x86_64 and ARM64, MSVC++ and g++), so I might not understand if they are wrong. Maybe I should just use the default memory_order_seq_cst if it does not make any difference anyway on these platforms?

Well, using memory_order_seq_cst is okay just to make sure the algorithm is working, or if the algo needs it to begin with. Then, we can think about fine tuning it down to its bare minimum. Actually, you made me think about the membars wrt basic thread saftey refcounts.
I think if a reference drops to zero, the thread that accomplished that event needs to perform an acquire membar before doing anything with it. It's hard to remember for me right now. It's coming back, but I am really busy right now, sorry. Humm...
pseudo code, typed in the newsreader, sorry for any typos:
___________________
void refcount_dec(refcount& p)
{
     // decrement the count.
     if (p.m_refs.fetch_add(-1, std::memory_order_release) == 1)
     {
         // 1 + (-1) = 0
         // drop to zero condition detected!
         // iirc, this needs to be here...
         std::atomic_thread_fence(std::memory_order_acquire);
         // okay, we are fine.
         // We are the only thread that can see it right now.
     }
}
___________________