通知线程是否始终需要在修改期间锁定共享数据？

Question

使用条件变量时,http://en.cppreference.com/w/cpp/thread/condition_variable描述了通知的线程的典型步骤:

1. 获取std :: mutex(通常通过std :: lock_guard)
2. 在锁定时执行修改
3. 在std :: condition_variable上执行notify_one或notify_all(不需要保持锁定以进行通知)

对于下面显示的简单情况,主线程在修改它时是否需要锁定"停止"？虽然我理解在修改共享数据时锁定几乎总是一个好主意,但我不确定为什么在这种情况下它是必要的.

std::condition_variable cv;
std::mutex mutex;
bool stop = false;

void worker() {
    std::unique_lock<std::mutex> lock(mutex);
    cv.wait(lock, [] { return stop; })
}

// No lock (Why would this not work?)
void main() {
     std::thread(worker);
     std::this_thread::sleep_for(1s);
     stop = true;
     cv.notify_one();
}

// With lock: why is this neccesary?
void main() {
     std::thread mythread(worker);
     std::this_thread::sleep_for(1s);
     {
         std::unique_lock<std::mutex>(mutex);
         stop = true;
     }
     cv.notify_one();
     mythread.join();
}

Answer 1

对于下面显示的简单情况,主线程在修改它时是否需要锁定"停止"？

是的,以防止竞争.除了从不同线程访问共享数据的问题(可以修复)std::atomic,想象一下这个事件顺序:

worker_thread: checks value of `stop` it is false
main_thread: sets `stop` to true and sends signal
worker_thread: sleeps on condition variable

在这种情况下,工作线程可能会永远睡眠,并且它会错过stop设置的事件,true因为唤醒信号已经发送并且错过了它.

需要在修改共享数据时获取互斥锁,因为只有这样才能处理检查条件并进入睡眠状态或在工作线程中作为整体原子操作对其进行操作.