我是否需要同步 std::condition_variable/condition_variable_any::notify_one

Question

我需要同步std::condition_variable/condition_variable_any::notify_one吗？

据我所知，如果丢失通知是可以接受的 - 可以调用 notify_one 不受保护（例如通过互斥锁）。

例如，我看到了以下使用模式（抱歉，不记得在哪里）：

{
    {
        lock_guard<mutex> l(m);
        // do work
    }
    c.notify_one();
}

---

但是，我检查了 libstdc++ 源代码，发现：

condition_variable::notify_one

void condition_variable::notify_one() noexcept
{
    int __e = __gthread_cond_signal(&_M_cond);
    // XXX not in spec
    // EINVAL
    if (__e)
        __throw_system_error(__e);
}

和condition_variable_any::notify_one:

void condition_variable_any::notify_one() noexcept
{
    lock_guard<mutex> __lock(_M_mutex);
    _M_cond.notify_one();
}

这里是 condition_variable_any 的布局：

class condition_variable_any
{
    condition_variable _M_cond;
    mutex _M_mutex;
    // data end

即它只是 condition_variable+mutex 的薄包装。

所以，问题：

1. 对于condition_variable_any 或condition_variable，不通过互斥锁保护notify_one 是否是线程安全的？
2. 为什么 condition_variable_any 的实现使用额外的互斥锁？
3. 为什么condition_variable_any::notify_one 和condition_variable::notify_one 的实现不同？也许condition_variable::notify_one 需要手动保护但condition_variable_any::notify_one 不需要？是 libstdc++ 错误吗？

Answer 1

即它只是 condition_variable+mutex 的薄包装。

呃，不。仅仅因为它具有这些类型的成员并不能使它成为一个薄包装器。尝试了解它实际上做了什么，而不仅仅是它的私有成员的类型。那里有一些非常微妙的代码。

1. 对于 condition_variable_any 或 condition_variable，不通过互斥锁保护 notify_one 是否是线程安全的？

是的。

实际上，在互斥锁被锁定的情况下调用notify_one()会导致等待线程被唤醒，尝试锁定互斥锁，发现它仍然被通知线程锁定，然后回到休眠状态，直到互斥锁被释放。

如果您在没有锁定互斥锁的情况下调用notify_one()，那么唤醒线程可以立即运行。

2 为什么 condition_variable_any 的实现使用额外的互斥锁？

condition_variable_any 可以与任何Lockable 类型一起使用，不仅仅是std:mutex，而且在libstdc++ 内部使用condition_variable，它只能与std::mutex 一起使用，所以它也有一个内部的std::mutex 对象。

所以condition_variable_any 与两个互斥锁一起工作，一个由用户提供的外部互斥锁和一个由实现使用的内部互斥锁。

3 为什么 condition_variable_any::notify_one 和 condition_variable::notify_one 的实现不同？也许 condition_variable::notify_one 需要手动保护，但 condition_variable_any::notify_one 不需要？是 libstdc++ 的错误吗？

不，这不是错误。

标准要求调用wait(mx) 必须以原子方式解锁mx 并休眠。 libstdc++ 使用内部互斥体来提供原子性保证。如果其他线程即将等待condition_variable_any，则必须锁定内部互斥锁以避免错过通知。

Answer 2

(1) 从数据竞争的角度来看，我没有看到任何理由表明条件变量必须由互斥锁保护。显然，您有可能收到冗余通知或丢失通知，但如果这是您的程序可接受或可恢复的错误条件，我不相信标准中有任何内容会使其非法。当然，标准不会保护您免受竞争条件的影响。确保竞争条件是良性的是程序员的责任。 （当然，程序员不要放置任何“数据竞争”，这些竞争在标准中非常明确地定义但不直接应用于同步原语，否则会引发未定义的行为。）

(2) 我无法回答关于标准库设施的内部实现这样的问题。当然，供应商有责任提供正常工作并符合规范的库设施。这个库的实现可能有一些内部状态需要互斥以避免损坏，或者它可能执行锁定以避免丢失或冗余通知。 （仅仅因为您的程序可以容忍它们，并不意味着该库的任意用户可以，而且总的来说我希望他们不能。）这只是我的猜测，他们用这个互斥锁来保护什么。

(3) condition_variable_any 可用于任何类似锁的对象，而condition_variable 专门设计用于unique_lock<mutex>。后者可能比前者更容易实现和/或性能更高，因为它明确知道它正在操作哪些类型以及它们需要什么（它们是否微不足道，它们是否适合缓存行，它们是否直接映射到特定平台的一组系统调用、栅栏或缓存一致性保证它们暗示的内容等），而前者提供了一种通用工具，用于在锁定对象上进行操作，而不会受到std::mutex 或std::unique_lock<> 的限制。