Need to mutex-protect (atomic) assignment sought by condition variable?
===

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][1] 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?


  [1]: http://www.boost.org/doc/libs/1_49_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref