(boost) overhead of a unique_lock when used with a conditional_variable

Question

why does the wait() method of a boost::conditiona_variable require a boost::unique_lock object as parameter and not a simple boost::mutex?

Actually, it is not completely clear the purpose of a unique_lock at all. Why should I create another wrapper object around my boost::mutex, and what is the impact on performance?

For example, assume I have two threads, thread1 and thread2:

on thread1

void process() {
  while(true){
    while (objectToProcess == NULL) {
      boost::unique_lock lock(mutex);
      waitingVariable.wait(lock);
    }

    doSomething(objToProcess);

    objToProcess = NULL;
    waitingVariable.notify();
  }
}

on thread2:

void feedProcessor() {
  while(true) {
        while (objectToProcess != NULL) {
          boost::unique_lock lock(mutex);
          waitingVariable.wait(lock);
        }

        objToProcess = createNewObjectToProcess();
        waitingVariable.notify();
  }
}

In this case, I find wasteful to create new unique_lock objects every time I need to call the wait() method of a conditional variable. Can you please enlighten me on the purpose of such objects and whether they introduce significant overhead?

Thanks!

(I see that my question overlaps with this question, but my concern is more about overhead than purpose...)

Answer 1

The idea of a condition variable is the following:

You protect the consumption of an asynchronous event via an unique_lock. But you only lock the mutex if the condition variable has at least one not yet consumed event available. Otherwise the lock is not locked and waits instead for a notify event.

With this understanding your code should change to the following, in order to protect your processing of the object:

boost::unique_lock lock(mutex);
while (objectToProcess == NULL) {

  waitingVariable.wait(lock);
}

see http://www.boost.org/doc/libs/1_55_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref

Answer 2

Passing in a std::unique_lock instead of a mutex ensures that you meet the requirement for the wait function of giving it an already-locked mutex. If you could pass in a mutex you could pass in an unlocked instance so the wait function would either have to fail, which means handling the error somehow, or have undefined behavior which isn't a good thing.

In an optimized build there is likely no overhead to using the addition object over manually locking the mutex (and remembering to do so, and to unlock it properly as required )