Question

I understand how to use condition variables (crummy name for this construct, IMO, as the cv object neither is a variable nor indicates a condition). So I have a pair of threads, canonically set up with Boost.Thread as:

bool awake = false;
boost::mutex sync;
boost::condition_variable cv;
void thread1()
{
    boost::unique_lock<boost::mutex> lock1(sync);
    while (!awake)
        cv.wait(lock1);
    lock1.unlock();    // this line actually not canonical, but why not?
    // proceed...
}
void thread2()
{
    //...
    boost::unique_lock<boost::mutex> lock2;
    awake = true;
    lock2.unlock();
    cv.notify_all();
}

My question is: does thread2 really need to be protecting the assignment to awake? It seems to me the notify_all() call should be sufficient. If the data being manipulated and checked against were more than a simple “ok to proceed” flag, I see the value in the mutex, but here it seems like overkill.

A secondary question is that asked in the code fragment: Why doesn’t the Boost documentation show the lock in thread1 being unlocked before the “process data” step?

EDIT: Maybe my question is really: Is there a cleaner construct than a CV to implement this kind of wait?

Answer 1

does thread2 really need to be protecting the assignment to awake?

Yes. Modifying an object from one thread and accessing it from another without synchronisation gives undefined behaviour. Even if it’s just a bool.

For example, on some multiprocessor systems the write might only affect local memory; without an explicit synchronisation operation, other threads might never see the change.

Why doesn’t the Boost documentation show the lock in thread1 being unlocked before the “process data” step?

If you unlocked the mutex before clearing the flag, then you might miss another signal.

Is there a cleaner construct than a CV to implement this kind of wait?

In Boost and the standard C++ library, no; a condition variable is flexible enough to handle arbitrary shared state and not particularly over-complicated for this simple case, so there’s no particular need for anything simpler.

More generally, you could use a semaphore or a pipe to send a simple signal between threads.