使用具有相同条件变量的不同互斥体是否有意义？答案

【问题标题】：Does it make sense to use different mutexes with the same condition variable?使用具有相同条件变量的不同互斥体是否有意义？
【发布时间】：2021-10-22 05:48:52
【问题描述】：

cppreference.com 的条件变量 notify_one() 函数的文档说明如下

通知线程不需要持有与等待线程持有的互斥锁相同的互斥锁；实际上这样做是一种悲观，因为被通知的线程会立即再次阻塞，等待通知线程释放锁。

这句话的第一部分很奇怪，如果我在 notifying 和 notified 线程中持有不同的互斥锁，那么互斥锁就没有真正的意义，因为没有这里的“阻塞”操作。事实上，如果持有不同的互斥锁，那么虚假唤醒可能导致错过通知是可能的！我的印象是，在这种情况下，我们最好不要锁定 notifying 线程。有人可以澄清一下吗？

以条件变量的 cppreference 页面为例。

std::mutex m;    // this is supposed to be a pessimization
std::condition_variable cv;
std::string data;
bool ready = false;
bool processed = false;
 
void worker_thread()
{
    // Wait until main() sends data
    std::unique_lock<std::mutex> lk(m);   // a different, local std::mutex is supposedly better
    cv.wait(lk, []{return ready;});
 
    // after the wait, we own the lock.
    std::cout << "Worker thread is processing data\n";
    data += " after processing";
 
    // Send data back to main()
    processed = true;
    std::cout << "Worker thread signals data processing completed\n";
 
    lk.unlock();
    cv.notify_one();
}
 
int main()
{
    std::thread worker(worker_thread);
 
    data = "Example data";
    // send data to the worker thread
    {
        std::lock_guard<std::mutex> lk(m);   // a different, local std::mutex is supposedly better
        ready = true;
        std::cout << "main() signals data ready for processing\n";
    }
    cv.notify_one();
 
    // wait for the worker
    {
        std::unique_lock<std::mutex> lk(m);
        cv.wait(lk, []{return processed;});
    }
    std::cout << "Back in main(), data = " << data << '\n';
 
    worker.join();
}

PS。我看到了一些标题相似的问题，但它们涉及问题的不同方面。

【问题讨论】：

您的印象是正确的。这句话的措辞可能很尴尬，但意思是通知线程不需要持有与条件变量关联的互斥锁来通知它。它可能持有也可能不持有其他不相关的互斥锁。
我不确定您的问题到底是什么。请注意，在 cppreference 示例中，互斥锁 m 在调用 cv.notify_one() 时不由主线程持有。
@NateEldredge 非常感谢！固定。

标签： c++ multithreading condition-variable

【解决方案1】：

我认为 cppreference 的措辞在这里有些尴尬。我认为他们只是试图将与条件变量结合使用的互斥锁与其他不相关的互斥锁区分开来。

使用具有不同互斥锁的条件变量是没有意义的。互斥体用于对实际语义条件（在示例中它只是变量ready）进行任何原子更改，因此无论何时更新或检查条件都必须保持它。还需要确保未阻塞的等待线程可以立即检查条件，而不会再次遇到竞争条件。

我的理解如下：可以，在调用 notify_one 时不持有与条件变量关联的互斥锁，或者根本不持有任何互斥锁，但是可以出于不同原因持有其他互斥锁。

悲观的不是只使用了一个互斥锁，而是当你知道另一个线程应该在收到通知后立即尝试获取互斥锁时，持有这个互斥锁的时间超过了必要的时间。

我认为我的解释与cppreference on condition variable中给出的解释一致：

打算修改共享变量的线程必须

获取std::mutex（通常通过std::lock_guard）

在持有锁时执行修改

在std::condition_variable上执行notify_one或notify_all（通知不需要持有锁）

即使共享变量是原子的，也必须在互斥体下进行修改，才能正确地将修改发布到等待线程。

任何打算等待std::condition_variable 的线程必须在用于保护共享变量的同一互斥体上获取std::unique_lock<std::mutex>

此外，standard 明确禁止为wait、wait_for 或wait_until 使用不同的互斥锁：

lock.mutex() 为所有并发等待（通过 wait、wait_for 或 wait_until）线程提供的每个锁定参数返回相同的值。

【讨论】：

【解决方案2】：

通知线程不需要持有与等待线程持有的互斥锁相同的互斥锁；

这是误导。问题在于“相同”这个词。他们应该说，“...不需要锁定 any 互斥体...”这才是重点。等待线程在进入wait()调用时应该有一个互斥锁被锁定的一个重要原因：它正在等待一些共享数据结构的一些变化，它需要在访问该结构时锁定互斥锁以检查是否期待的变化实际上已经发生了。

notify()ing 线程可能需要锁定同一个互斥锁以实现该更改，但程序的正确性并不取决于它是在释放互斥锁之前还是之后调用notify()。

【讨论】：