Re: Atomic caching of smart pointers

On 9/15/2024 11:01 PM, Paavo Helde wrote:

On 15.09.2024 23:15, Chris M. Thomasson wrote:

On 9/15/2024 11:54 AM, Paavo Helde wrote:
[...]

So, what do you think? Should I just use std::atomic<std::shared_ptr> instead? Any other suggestions? Did I get the memory order parameters right in compare_exchange_weak()?

>
Keep in mind that you need to make sure that std::atomic<std::shared_ptr> is actually lock-free...
>
Make sure to investigate is_always_lock_free on your various arch's:
>
https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free

 I already checked this, it is returning false at least on one of my target platforms (Visual Studio 2022, Windows x86_64). IIRC Bonita claimed this might be a false negative though.

I sure hope Bonita is right about that! Because it should be lock-free for many arch's. Damn it!... People rely on is_always_lock_free for certain things to be true about it, as in its result can be trusted. Bonita found that its actually always lock-free after all wrt libatomic, iirc. C/C++ should report this correctly. I have not investigated this for myself yet. Been really busy lately.

Meanwhile I think I found a bug in my posted code, I should probably use compare_exchange_strong() instead of compare_exchange_weak(). I somehow thought the latter would err on the safe side, but it does not. In my test harness there seems to be no difference.

Keep in mind that compare_exchange_weak can fail even though the comparands are the same. It can spuriously fail. compare_exchange_strong acts more like CMPXCHG on x86 vs a LL/SC on a PPC or something. Pessimistic vs optimistic... Also, make sure to pad and align things properly on cache line boundaries. Well, get it working first, then think about that... I still have not properly examined your code. Sorry! ;^o Way busy.