CODEWITHSUNDEEP
c++multithreadingboost-thread
Mike C
Mike C

Reputation: 1238

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 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?

Upvotes: 0

Views: 724

Answers (2)

James Kanze
James Kanze

Reputation: 154047

Formally, you definitely need the lock in both threads: if any thread modifies an object, and more than one thread accesses it, then all accesses must be synchronized.

In practice, you'll probably get away with it without the lock; it's almost certain that notify_all will issue the necessary fence or membar instructions to ensure that the memory is properly synchronized. But why take the risk?

As to the absense of the unlock, that's the whole point of the scoped locking pattern: the unlock is in the destructor of the object, so that the mutex will be unlocked even if an exception passes through.

Upvotes: 1

Mike Seymour
Mike Seymour

Reputation: 254771

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.

Upvotes: 1

Related Questions