std::atomic...is_lock_free(3)

💅 std::atomic...is_lock_free(3)

okay bestie, welcome to the std::atomic...is_lock_free(3) page from the C++ Standard Libary manual — yes, that's the manual name as printed, we're keeping it. This is the whole std::atomic_ref::is_lock_free moment, and it's lowkey important.

✨ NAME ✨

• std::atomic_ref::is_lock_free — std::atomic_ref::is_lock_free

🌸 Synopsis 🌸

bool is_lock_free() const noexcept;  (since C++20)

Checks whether the atomic operations on this object are lock-free.

🎀 Parameters 🎀

• (none) — literally none, bestie, no parameters at all.

💖 Return value 💖

• true if the atomic operations on this object are lock-free.
• false otherwise.

🦋 Notes 🦋

• All atomic types except for std::atomic_flag may be implemented using mutexes or other locking operations, rather than using the lock-free atomic CPU instructions. So yeah, that's the vibe: lock-free is not automatically the whole story for every atomic type.
• Atomic types are also allowed to be sometimes lock-free, e.g. if only aligned memory accesses are naturally atomic on a given architecture, misaligned objects of the same type have to use locks. It's giving "same type, different day, different lock situation" 😭
• The C++ standard recommends (but does not require) that lock-free atomic operations are also address-free, that is, suitable for communication between processes using shared memory. Recommend, not require — no cap.

🌈 Example 🌈

This section is incomplete Reason: no example

👑 See also 👑

• is_always_lock_free indicates that the type is always lock-free
• [static] — (public static member constant)

🍓 Category 🍓

• Todo no example

mwah 💋 — source: http://cppreference.com, version/date: 2024.06.10. That's the whole page, bestie 🫶✨