On Fri, 4 Aug 2023, 10:18 Bogdan Sinitsyn, <f1u77y@xxxxxxxxx> wrote: > > atomic<shared_ptr<T>>::is_lock_free is always true, which is correct. > > The attached link shows the opposite, which is the reason i asked this > question in first place. > I can't load it, I currently have barely enough internet access to download email. > If we look at the libstdc++ code, it shows this function always returns > false: See my other reply which I sent before seeing your reply. > > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr_atomic.h#L622 > > On 8/4/23 11:07, Jonathan Wakely wrote: > > > > > > On Thu, 3 Aug 2023, 14:35 Bogdan Sinitsyn, <f1u77y@xxxxxxxxx> wrote: > > > > std::atomic<std::shared_ptr<T>> operations seem to generate lock-free > > code without _Sp_locker and mutexes, while > > std::atomic_*(std::shared_ptr<T>*) operations use _Sp_locker. But > > std::atomic_is_lock_free and std::atomic::is_lock_free > > show exactly the opposite. > > > > > > Not always. > > > > atomic<shared_ptr<T>>::is_lock_free is always true, which is correct. > > > > atomic_is_lock_free(shared_ptr<T>*) is true in a single threaded > > program, false otherwise. If the program is not linked to libpthread > > then no locking is used (or needed) for the > > atomic_xxx(shared_ptr*,...) overloads. > > > > > > > > > > > > Maybe I don't interpret that correctly? What > > does that supposed to mean? > > > > https://godbolt.org/z/818v6sMGb > > > > -- > > > > Bogdan Sinisyn > > >
