Boost condition variables - do calls to "notify_one" stack?

Question

In a single producer / single consumer application using Boost threads, what happens if the producer thread makes more than one call to cond_var.notify_one() before the consumer thread has called cond_var.wait(lock) ?

Will the additional calls to notify_one be stacked, such that each call to .wait() will correspond 1:1 with a .notify_one() call?

EDIT A commonly quoted example for implementing a concurrent queue has these methods:

void push(Data const& data)
{
    boost::mutex::scoped_lock lock(the_mutex);
    the_queue.push(data);
    lock.unlock();
    the_condition_variable.notify_one();
}

void wait_and_pop(Data& popped_value)
{
    boost::mutex::scoped_lock lock(the_mutex);
    while(the_queue.empty())
    {
        the_condition_variable.wait(lock);
    }

    popped_value=the_queue.front();
    the_queue.pop();
}

I've used some very similar code, and experienced some odd memory growth which appears to be explained by the consumer thread not waking up for every .notify_one() (because it's still busy doing other work), and wondered whether lack of "stacking" might be the cause.

It would seem that without stacking this code would fail if (on occasion) the consumer thread cannot keep up with the producer thread. If my theory is correct, I'd appreciate suggestions on how to remedy this code.

Answer 1

The specification of notify_one is:

C++11 30.5.1/7: Effects: If any threads are blocked waiting for *this, unblocks one of those theads.

So the answer is no: calls to notify_one and notify_all will only wake thread(s) currently waiting, and are not remembered for later.

UPDATE: Sorry, I misread the question as std::condition_variable. Not surprisingly, the Boost specification is more or less identical:

If any threads are currently blocked waiting on *this in a call to wait or timed_wait, unblocks one of those threads.

Regarding your edit: If there is no thread waiting when someone calls push, then the next thread to call pop won't wait at all, since the_queue will not be empty. So there's no need for the condition variable to remember that it shouldn't wait; that information is stored in the state being managed, not the condition variable. If the consumer can't keep up with the producer, then you need to either speed up consumption or slow down production; there's nothing you can do to the signalling mechanism to help with that.