Hmm, https://en.cppreference.com/w/cpp/thread/condition_variable explains some of why std::lock_guard doesn't have a mutex observer, but the argument is stupid.

The example is:

#include <condition_variable>
#include <iostream>
#include <mutex>
#include <string>
#include <thread>
 
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 lk(m);
    cv.wait(lk, []{ return ready; });
 
    // after the wait, we own the lock
    std::cout << "Worker thread is processing data\n";
    data += " after processing";
 
    // send data back to main()
    processed = true;
    std::cout << "Worker thread signals data processing completed\n";
 
    // 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 lk(m);
        ready = true;
        std::cout << "main() signals data ready for processing\n";
    }
    cv.notify_one();
 
    // wait for the worker
    {
        std::unique_lock lk(m);
        cv.wait(lk, []{ return processed; });
    }
    std::cout << "Back in main(), data = " << data << '\n';
 
    worker.join();
}

It's important to be a unique_lock so that you can call unlock manually.

But the better way to do it would be:

void worker_thread()
{
    {
      // wait until main() sends data
      std::lock_guard lk(m);
      cv.wait(lk, []{ return ready; });
   
      // after the wait, we own the lock
      std::cout << "Worker thread is processing data\n";
      data += " after processing";

      // send data back to main()
      processed = true;

      // Unlock as soon as the critical section is done, before notifying.
    }
   
    std::cout << "Worker thread signals data processing completed\n";

    // Make sure to unlock before notifying, to avoid waking up
    // the waiting thread only to block again (see notify_one for details)
    cv.notify_one();
}

This doesn't call unlock manually, as it still uses a scope/destructor to do that. Presumably wait could call unlock and lock on the lock_guard wrapped mutex by being a friend class, and it doesn't break the lock_guard invariant of definitely being locked at the destructor since it will be locked again once wait returns. Any idea how that might not be true (maybe an exception?)?

Given that mutex_protected doesn't really let you choose your lock guard variant, just chooses the most performant one based on which lock variant you call, we can't really choose lock_guard or unique_lock based on whether they're going to pass it to a condition variable (other than the with variants which could). It seems wait only accepts a unique_lock, so I guess we need to either modify condition_variable::wait too, or always use unique_lock (ie option 2 above).

#include <condition_variable>
#include <iostream>
#include <mutex>
#include <string>
#include <thread>
 
std::mutex_protected<struct { 
  std::string data;
  bool ready = false;
  bool processed = false;
}> data;
std::condition_variable cv;
 
void worker_thread() {
    // wait until main() sends data
    {
        auto locked = data.lock();

        // If we add an overload to cv.wait to accept a mutex_locked
        cv.wait(locked, [&]{ return locked->ready; });  
        // Otherwise something like this?
        // cv.wait(locked.guard(), [&]{ return locked->ready; }); 

        std::cout << "Worker thread is processing data\n";
        locked->data += " after processing";

        // send data back to main()
        locked->processed = true;
    }
    std::cout << "Worker thread signals data processing completed\n";
 
    // unlock before notifying, to avoid waking up
    // the waiting thread only to block again (see notify_one for details)
    cv.notify_one();
}
 
int main() {
    std::thread worker(worker_thread);
 
    // send data to the worker thread
    {
        auto locked = data.lock();
        locked->data = "Example data";
        locked->ready = true;
    }
    std::cout << "main() signals data ready for processing\n";
    cv.notify_one();
 
    // wait for the worker
    {
        auto locked = data.lock();
        cv.wait(locked, [&]{ return locked->processed; });
        std::cout << "Back in main(), data = " << data->data << '\n';
    }
 
    worker.join();
}

It seems either way we need to not work for a shared lock.

How to interact with condition variables #15

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions