Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 9212607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 18, 20262026-06-18T01:33:49+00:00 2026-06-18T01:33:49+00:00

In a single producer / single consumer application using Boost threads, what happens if

  • 0

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.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-18T01:33:51+00:00Added an answer on June 18, 2026 at 1:33 am

    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.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I am building a multi-producer/single-consumer application using IPC, implemented using Boost.Interprocess . Each producer
I'm writing an application that has a multiple producer, single consumer model (multiple threads
Imagine a producer-consumer scenario, thread A produces entries, one to many other threads consume
I'm implementing a single-producer single-consumer queue, by which one thread waits for the global
Does using a lock have better performance than using a local (single application) semaphore?
I'm implementing a lock-free single producer single consumer queue for an intensive network application.
I am using a multi-threaded producer/consumer queue with a single (very fast) producer and
I'm looking for a single-producer, single-consumer FIFO implementation that would perform faster than the
I have a C# 4.0 application (single producer/single consumer) which transfers huge amount of
I'm using a single producer-single consumer model with a blocking queue. I would like

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.