Why conditional_variable::notify_all may not wake up any thread?

Question

I use conditional_variable::notify_all() to wake up a waiting thread(only one thread is waiting for the unique_lock indeed).

This code snippet works well at most time, but the log files(for details, see below) indicates that the parent thread could not aquire the unique_lock after the new created thread allready returned.

I would be grateful to have some help with this question.

Here is the related code snippet:

void MainWindow::deployAction(void)
{
    std::condition_variable cvRunOver;
    std::mutex mtxRunOver;
    std::unique_lock <std::mutex> ulkRunOver(mtxRunOver);
    QString workerThreadRes;
    std::thread workThread([&]()
    {
        workThread.detach();

        do_some_process_for_seconds();
        
        cvRunOver.notify_all();
        LOG(INFO)<<"to leave the subthread";
        google::FlushLogFiles(google::GLOG_INFO);
        return;
    });

    while (cvRunOver.wait_for(ulkRunOver, std::chrono::milliseconds(100)) == std::cv_status::timeout)
    {
        qApp->processEvents();
        auto curTim = std::chrono::steady_clock::now();
        std::chrono::duration<float> escapedTim= curTim-lastTim;
        if(std::chrono::duration_cast<std::chrono::seconds>(escapedTim).count()>=5)
        {
            LOG(INFO) << "processEvents()";
            google::FlushLogFiles(google::GLOG_INFO);
            lastTim = curTim;
        }
    }
    
    LOG(INFO) << "get lock and continue to run";
    google::FlushLogFiles(google::GLOG_INFO);
}

Here is the related log when the program does not work as experted:

Log line format: [IWEF]hh:mm:ss.uuuuuu threadid file:line] msg
20:19:14.638686 272568 mainwindow.cpp:208] to leave the subthread
20:19:17.669246 10256 mainwindow.cpp:221] processEvents()
20:19:22.678846 10256 mainwindow.cpp:221] processEvents()
20:19:17.669246 10256 mainwindow.cpp:221] processEvents()
20:19:22.678846 10256 mainwindow.cpp:221] processEvents()
20:19:17.669246 10256 mainwindow.cpp:221] processEvents()
20:19:22.678846 10256 mainwindow.cpp:221] processEvents()
20:19:17.669246 10256 mainwindow.cpp:221] processEvents()
...

Answer 1

You are misusing a condition variable. To use a condition variable:

1. One thread must be notifying another thread about some change in shared state.

2. There must actually be some shared state that has changed.

3. The shared state must be protected by the mutex associated with the condition variable.

4. The shared state must be tested before deciding to wait.

5. The thread doing the signal or broadcast must have changed the shared state under the protection of the mutex prior to signaling or broadcasting.

If you do not follow these four rules, your code will always fail. You don't seem to have any shared state protected by the mutex whose changes you are using the condition variable to notify another thread of. Without this, you cannot make a correct decision whether or not to wait and you will wind up waiting for something that has already happened.

See this answer for more information.

Imagine if you share a car with your sister. You ask your sister to ring a bell any time she brings the car back so you can stop waiting for it. Now imagine you want to use the car so you wait for the bell to ring. You will be waiting a long time if your sister wasn't using the car when you decided to wait!

Your code has this flaw because your code decides to wait without first checking if the thing it's waiting for has already happened, violating rule 4. You also seem to be violating rule 3 because I don't see any shared state protected by the mutex. You may be violating rule 5 because I don't see your workThread changing any shared state prior to calling a notify function.

I added some comments to example code from here to show how all the rules work:

    // condition_variable example
    #include <iostream>           // std::cout
    #include <thread>             // std::thread
    #include <mutex>              // std::mutex, std::unique_lock
    #include <condition_variable> // std::condition_variable

    std::mutex mtx;
    std::condition_variable cv;
    bool ready = false;

    void print_id (int id) {
      std::unique_lock<std::mutex> lck(mtx);
      while (!ready) cv.wait(lck); // rules 3 and 4 ("ready" is the shared state)
      // ...
      std::cout << "thread " << id << '\n';
    }

    void go() {
      std::unique_lock<std::mutex> lck(mtx); // rule 3
      ready = true; // rules 1 and 2
      cv.notify_all(); // rule 5
    }

    int main ()
    {
      std::thread threads[10];
      // spawn 10 threads:
      for (int i=0; i<10; ++i)
        threads[i] = std::thread(print_id,i);

      std::cout << "10 threads ready to race...\n";
      go();                       // go!

      for (auto& th : threads) th.join();

      return 0;
    }

Answer 2

The answer by David is very good. I only want to clarify some points. Look at this picture:

One thread is in pink, the other in blue, synchronization mechanism is in green.

The main idea of the condition variable is to enable passive synchronization. By passive I mean such that does not burn CPU out in a desperate while loop (while (!producer.has.data()) continue;). So you need some shared data that will be changed as the program evolves. You need a mutex to protect the data again race condition. Then a condition variable is a combinanation of sleep pills and an alarm clock.

Please notice that the shared data can be touched only under a locked mutex.

Please remember that waking up is like ringing a bell once. If the thread you want to wake up is not asleep, it will miss the alarm. Often this is what you want: if the consumer is not asleep, it does need not your data (yet). If it shall need the data, it will use it without falling asleep. So you can imagine the producer as Charles Chaplin that stands by a conveyor belt and each time he "produces" something, he rings the bell. But he does not know, nor care, whether anyone can hear it. Perhaps that's why the function is called "notify" and not signal, as signals usually have to be received. Notifications do not.

There's a mysterious "OS" (operating system) element of the diagram. Yes, the thread "controlled" by the condition variable may be waken up directly by OS. That's how some OS'es work. Perhaps they want to make sure no thread is dead. So when you wake up, you MUST, MUST, MUST check whether you were woken up by the producer, or by OS. To do this, you need to check a CONDITION that is related to the state of the shared data. So you need to acquire the lock (this is done automatically and atomically, which is not clear in the diagram) and read some shared data. It can be just an ordinary bool shared_ready that says "the data is ready / not ready" or a conditon on the data, like "!shared_container.empty()".

In the diagram, the producer notifies the other thread while being under the lock. It does not need be like this, the order could be reversed (first unlock, then notify other threads).

If you've come this far, you are ready for the professional description in the cppreference Condition Variable

Please take a look at the example there. How a lambda is used to check the condition. This is the preferred way of using a condition variable: using it, you can't forget about the CONDITION!