Vfrdtyky

The question comes from an exmaple of std::condition_variable

As far as I know, when I construct a new thread, it starts to execute immediately.

So I wonder, would cv.wait(lk, {return ready;}); in worker_thread(), and std::lock_guard<std::mutex> lk(m); in main, lock the mutex at the same time? Could this happen?

(From cppreference I know that std::condition_variable::wait and std::lock_guard would lock the mutex during the construction.)

#include <iostream>

#include <string>

#include <thread>

#include <mutex>

#include <condition_variable>



std::mutex m;

std::condition_variable cv;

std::string data;

bool ready = false;

bool processed = false;



void worker_thread()

{

    // Wait until main() sends data

    std::unique_lock<std::mutex> lk(m);

    cv.wait(lk, {return ready;});



    // after the wait, we own the lock.

    std::cout << "Worker thread is processing datan";

    data += " after processing";



    // Send data back to main()

    processed = true;

    std::cout << "Worker thread signals data processing completedn";



    // Manual unlocking is done before notifying, to avoid waking up

    // the waiting thread only to block again (see notify_one for details)

    lk.unlock();

    cv.notify_one();

}



int main()

{

    std::thread worker(worker_thread);



    data = "Example data";

    // send data to the worker thread

    {

        std::lock_guard<std::mutex> lk(m);

        ready = true;

        std::cout << "main() signals data ready for processingn";

    }

    cv.notify_one();



    // wait for the worker

    {

        std::unique_lock<std::mutex> lk(m);

        cv.wait(lk, {return processed;});

    }

    std::cout << "Back in main(), data = " << data << 'n';



    worker.join();

}

Mutex are meant to get a lock on resource, only 1 thread can get that lock. Locking of mutex is atomic, 2 threads cannot acquire a lock on mutex, if they can, then it defeats the purpose of mutex locks!

Mutexes are built such that locking is an atomic operation: it will only complete on one thread at a time, regardless of how many threads are attempting to lock

"Mutex" is a contraction of "mutual exclusion"; it's purpose is to allow only one thread to lock the mutex at any time.

That said, there's a serious problem in that example. It has a potential deadlock, because it tries too hard to sequence inherently non-sequential operations.

The problem occurs if main goes through its locking code, sets ready to true, and calls notify() before the new thread locks the mutex and calls wait(). If that happens, main will proceed to its call to wait() while the new thread is sitting in wait(), and neither one will notify the other one; they're both waiting for the other one to do something.

If you're unlucky, you won't see this when you're testing the code; it might happen that the new thread starts to wait() before the main thread calls notify(), and then the code will work as expected. That's unlucky because sooner or later it will lock up, most likely when you're demonstrating your code to your most important customer.