On Fri, 4 Aug 2023, 10:18 Bogdan Sinitsyn, <f1u77y@yandex.ru> 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@yandex.ru> 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
> >
>