在修改过程中，通知线程是否总是需要锁定共享数据？

Question

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

对于下面所示的简单情况，主线程修改时是否需要锁定“stop”？虽然我知道在修改共享数据时锁定几乎总是一个好主意，但我不确定为什么在这种情况下有必要这样做。

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

对于下面所示的简单情况，主线程修改时是否需要锁定“stop”？

是的，为了防止比赛。除了可以通过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

在这种情况下，工作线程可能会永远Hibernate，并且它会错过将stop设置为true的事件，这仅仅是因为已经发送了唤醒信号，而它错过了它。