* std::atomic<std::shared_ptr> lockfree @ 2023-08-03 12:33 Bogdan Sinitsyn 2023-08-04 8:07 ` Jonathan Wakely 0 siblings, 1 reply; 5+ messages in thread From: Bogdan Sinitsyn @ 2023-08-03 12:33 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: std::atomic<std::shared_ptr> lockfree 2023-08-03 12:33 std::atomic<std::shared_ptr> lockfree Bogdan Sinitsyn @ 2023-08-04 8:07 ` Jonathan Wakely 2023-08-04 8:18 ` Bogdan Sinitsyn 2023-08-04 8:22 ` Jonathan Wakely 0 siblings, 2 replies; 5+ messages in thread From: Jonathan Wakely @ 2023-08-04 8:07 UTC (permalink / raw) To: Bogdan Sinitsyn; +Cc: gcc-help [-- 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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: std::atomic<std::shared_ptr> lockfree 2023-08-04 8:07 ` Jonathan Wakely @ 2023-08-04 8:18 ` Bogdan Sinitsyn 2023-08-04 8:24 ` Jonathan Wakely 2023-08-04 8:22 ` Jonathan Wakely 1 sibling, 1 reply; 5+ messages in thread From: Bogdan Sinitsyn @ 2023-08-04 8:18 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help > 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: std::atomic<std::shared_ptr> lockfree 2023-08-04 8:18 ` Bogdan Sinitsyn @ 2023-08-04 8:24 ` Jonathan Wakely 0 siblings, 0 replies; 5+ messages in thread From: Jonathan Wakely @ 2023-08-04 8:24 UTC (permalink / raw) To: Bogdan Sinitsyn; +Cc: gcc-help [-- 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 > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: std::atomic<std::shared_ptr> lockfree 2023-08-04 8:07 ` Jonathan Wakely 2023-08-04 8:18 ` Bogdan Sinitsyn @ 2023-08-04 8:22 ` Jonathan Wakely 1 sibling, 0 replies; 5+ messages in thread From: Jonathan Wakely @ 2023-08-04 8:22 UTC (permalink / raw) To: Bogdan Sinitsyn; +Cc: gcc-help [-- 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 >> >> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-08-04 8:24 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-03 12:33 std::atomic<std::shared_ptr> lockfree Bogdan Sinitsyn 2023-08-04 8:07 ` Jonathan Wakely 2023-08-04 8:18 ` Bogdan Sinitsyn 2023-08-04 8:24 ` Jonathan Wakely 2023-08-04 8:22 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).