std::recurs...mutex::lock(3)

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

πŸ’– NAME πŸ’–

okay so bestie, welcome to the std::recurs...mutex::lock(3) page from the C++ Standard Libary manual ✨. The NAME line is literally std::recursive_timed_mutex::lock - std::recursive_timed_mutex::lock, and it's giving recursive-timed-mutex-lock main character energy, no cap πŸ’….


✨ Synopsis ✨

void lock();  (since C++11)

Locks the mutex. If another thread has already locked the mutex, a call to lock will block execution until the lock is acquired. Periodt β€” no lock for you until it's available.

A thread may call lock on a recursive mutex repeatedly. Ownership will only be released after the thread makes a matching number of calls to unlock. Matching calls, bestie β€” it's giving stack-count energy 🌈.

The maximum number of levels of ownership is unspecified. An exception of type std::system_error will be thrown if this number is exceeded. So yes, there is a limit, and yes, it will absolutely throw if you push it too far 😭.

Prior unlock() operations on the same mutex synchronize-with (as defined in std::memory_order) this operation. Memory-order girlies, this one's for you 🫢.


πŸŽ€ Parameters πŸŽ€

(none) β€” literally zero arguments, she takes no notes πŸ’–.


🌸 Return value 🌸

(none) β€” no return value, just locking and vibes ✨.


πŸ”₯ Exceptions πŸ”₯

Throws std::system_error when errors occur, including errors from the underlying operating system that would prevent lock from meeting its specifications. The mutex is not locked in the case of any exception being thrown.

Important vibe check: if an exception is thrown, the mutex is not locked. No sneaky half-lock situation, okay? πŸ’€

πŸ¦‹ Notes πŸ¦‹

lock() is usually not called directly: std::unique_lock, std::scoped_lock, and std::lock_guard are used to manage exclusive locking. Like, yes, you can call it directly, but the cool kids let the RAII girlies handle it πŸ’….


🌈 Example 🌈

This example shows how lock and unlock can be used to protect shared data. The page also says // Run this code, so here's the whole thing, untouched and iconic:

#include <chrono>
#include <iostream>
#include <mutex>
#include <thread>

int g_num = 0; // protected by g_num_mutex
std::mutex g_num_mutex;

void slow_increment(int id)
{
    for (int i = 0; i < 3; ++i)
    {
        g_num_mutex.lock();
        ++g_num;
        // note, that the mutex also syncronizes the output
        std::cout << "id: " << id << ", g_num: " << g_num << '\n';
        g_num_mutex.unlock();

        std::this_thread::sleep_for(std::chrono::milliseconds(234));
    }
}

int main()
{
    std::thread t1{slow_increment, 0};
    std::thread t2{slow_increment, 1};
    t1.join();
    t2.join();
}

⭐ Possible output:

id: 0, g_num: 1
id: 1, g_num: 2
id: 1, g_num: 3
id: 0, g_num: 4
id: 0, g_num: 5
id: 1, g_num: 6

πŸ‘‘ See also πŸ‘‘

  • try_lock β€” tries to lock the mutex, returns if the mutex is not available (public member function)
  • try_lock_for β€” tries to lock the mutex, returns if the mutex has been unavailable for the specified timeout duration (public member function)
  • try_lock_until β€” tries to lock the mutex, returns if the mutex has been unavailable until specified time point has been reached (public member function)
  • unlock β€” unlocks the mutex (public member function)
  • C documentation for mtx_lock

Sign-off time, bestie: source/version/date vibes are http://cppreference.com, 2024.06.10, and page std::recurs...mutex::lock(3). Byeee, go lock something responsibly πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from