Liste des Groupes | Revenir à cl c++ |
Am 16.09.2024 um 08:01 schrieb Paavo Helde:Keep in mind that using atomic<shared_ptr<>> should be examined heavily. Do you actually need it, for sure? There are very good usage cases, but strong thread safety vs basic thread safety... Do we need strong, if so, provide a strong case for it...On 15.09.2024 23:15, Chris M. Thomasson wrote:Yes, no implementation of atomic<shared_ptr<>> of MSVC, libstdc++ andOn 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.
libc++ is currently lock-free. And even if: it needs the shortcut-opti-
mization which checks if a central atomic<shared_ptr<>> is unchanged
against a shared_ptr<>. With that even a futex'd solution woul be fast
enough for RCU-like patterns, i.e. when the atomic<shared_ptr<>> is
rarely updated.
Les messages affichés proviennent d'usenet.