为什么 boost::condition_variable 可以使用 pthread_cond_signal 只唤醒一个线程

Question

In the source code of boost::condition_variable, method condition_variable::notify_one() try to use pthread_cond_signal() to wake up only one thread. https://code.woboq.org/appleseed/include/boost/thread/pthread/condition_variable.hpp.html

inline void condition_variable::notify_one() BOOST_NOEXCEPT
    {
#if defined BOOST_THREAD_PROVIDES_INTERRUPTIONS
        boost::pthread::pthread_mutex_scoped_lock internal_lock(&internal_mutex);
#endif
        BOOST_VERIFY(!pthread_cond_signal(&cond));
    }

However, POSIX says:

The pthread_cond_signal() function shall unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).

So why boost::condition_variable make sure that the pthread_cond_signal just wake up one thread???

Answer 1

So why boost::condition_variable make sure that the pthread_cond_signal just wake up one thread???

Why? That question is moot. The question is "whether". And it doesn't (as you see).

You can see that it uses the pthread API there to unblock at least one waiting thread.

This is merely as opposed to notify_all , which uses pthread_cond_broadcast .

The distinction is useful because it can improve the efficiency of concurrent operations in situations where waking up all waiters would be wasteful.

Related: when using condition variables, you must always take spurious wake-up into account

Answer 2

You seem to be asking about the name of boost::condition_variable::notify_one() in light of the fact that the pthread-based implementation may in fact wake up more than one thread.

The fact is that although the specifications for pthread_cond_signal() say that it will unblock "at least one" thread blocked on the CV (provided there are any), that is weaselly standard-speak. Although it is allowed for pthread_cond_signal() to unblock more than one thread, it is usual and expected that if any threads are blocked on the CV when it is signaled, then exactly one will be unblocked. Allowing for more than one to be unblocked allows for implementations to be lighter-weight and more efficient, and it places no new burden on programmers because the same measures that handle spurious wakeups should be equally effective against extra wakeups, supposing that you even choose to distinguish between those.

Thus, boost::condition_variable::notify_one() is so named because "notify_one" accurately represents a behavior that programmers are anticipated sometimes to want, and the so-named method is the way for them to request it. That occasionally it delivers something a bit different is a characteristic of a very wide variety of functions. It is not helpful to try to capture all the details in the name. Not only would you end up with unreadably long names, such as notify_at_least_one_if_any_are_waiting , but you would lose the sense of the primary expectation for the function's behavior.