std::atomic<std::shared_ptr> lockfree

std::atomic<std::shared_ptr> lockfree

[Bogdan Sinitsyn]

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. Maybe I don't interpret that correctly? What 
does that supposed to mean?

https://godbolt.org/z/818v6sMGb

--

Bogdan Sinisyn

Re: std::atomic<std::shared_ptr> lockfree

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

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
>
>

Re: std::atomic<std::shared_ptr> lockfree

[Bogdan Sinitsyn]

 > 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.

If we look at the libstdc++ code, it shows this function always returns 
false: 
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
>

Re: std::atomic<std::shared_ptr> lockfree

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Fri, 4 Aug 2023, 10:07 Jonathan Wakely, <jwakely.gcc@gmail.com> 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.
>

Or did I make it always false? I don't remember now. But it's always the
same and doesn't depend on linking to libpthread.

The lock free property doesn't mean no mutex is used, it's about forward
progress guarantees and blocking, not about the explicit presence of a
mutex.





> 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
>>
>>

Re: std::atomic<std::shared_ptr> lockfree

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

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
> >
>