Question

boost::condition cond;
boost::mutex access;
void listener_thread()
{
  boost::mutex::scoped_lock lock(access);

  while (true) {
      while (!condition_check_var) {
          cond.wait(lock);
      }
      do_some_work();
  }
}

/// ... Main thread ...
cond.notify_all();
check_work:
{
    boost::mutex::scoped_lock lock(access);
    function_relies_on_work_been_done();
}

Is this proper design? Is it safe to assume that once the notify_all() returns, the listener_thread will have already acquired the lock? And that when the check_work block will run (since it’s locking the same mutex as the listener_thread()), some “work” will have already been done by the listener_thread()?

If not, what is the preferred way to achieve this kind of behavior?

Answer 1

There is no guarantee that any other thread has acted upon a notification or even, yet, received. In fact, there isn’t even a guarantee that there is a thread currently waiting for its reception although in your setup it looks as if it is likely the case that there are threads waiting. If you want to make sure that the receiving threads have done their work you’ll need to set up a reverse communication channel, e.g., using another condition variable and a suitable condition.

I realize that your question is about Boost but here is what the standard has to say about this (30.5.1 [thread.condition.condvar] paragraph 8):

void notify_all() noexcept;
Effects: Unblocks all threads that are blocked waiting for *this.

It doesn’t give any guarantee about what happens to the threads and/or any involved mutex.