std::shared...lock_shared(3)

πŸ“¦ version 2024.07.05, in nixpkgs unstable, opensuse-leap 16.0

okay so this is std::shared...lock_shared(3) from the C++ Standard Libary manual β€” yes, the manual name is folded in right here, and we're moving on πŸ’…βœ¨

πŸ’– NAME πŸ’–

std::shared_mutex::unlock_shared β€” std::shared_mutex::unlock_shared (same thing twice, that's literally what the page says 🫢)

✨ Synopsis ✨

void unlock_shared();  (since C++17)

Releases the mutex from shared ownership by the calling thread. So if you're holding it in shared mode, this hands it back.

The mutex must be locked by the current thread of execution in shared mode, otherwise, the behavior is undefined. And bestie, undefined behavior is not a vibe β€” it's actual UB πŸ’€.

This operation synchronizes-with (as defined in std::memory_order) any subsequent lock() operation that obtains ownership of the same mutex. That's the whole synchronization receipt, no cap.

🌸 Parameters 🌸

  • (none) β€” no parameters, she takes nothing πŸŽ€

πŸŽ€ Return value πŸŽ€

  • (none) β€” returns nothing, periodt

πŸ¦‹ Exceptions πŸ¦‹

Throws nothing. Zero throws, zero drama, pristine exception energy ✨

πŸ’œ Notes πŸ’œ

unlock_shared() is usually not called directly: std::shared_lock is used to manage shared locking. So yeah, most of the time your bestie std::shared_lock is doing the management and you're just vibing.

🌈 Example 🌈

This section is incomplete Reason: no example

(Yes, that's the example section. It's giving placeholder era πŸ™ˆ)

πŸ‘€ See also πŸ‘€

  • lock_shared β€” locks the mutex for shared ownership, blocks if the mutex is not available (public member function)
  • unlock β€” unlocks the mutex (public member function)

🏷️ Category 🏷️

  • Todo no example

source: http://cppreference.com Β· version/date: 2024.06.10 Β· page: std::shared...lock_shared(3) β€” bye bestie, go release that shared ownership responsibly πŸ«ΆπŸ’–

πŸ“¦ where this page comes from