why does std::condition_variable::wait need mutex?

Question

TL;DR

Why does std::condition_variable::wait needs a mutex as one of its variables?

---

Answer 1

You may look a the documentation and quote that:

 wait... Atomically releases lock

But that's not a real reason. That's just validate my question even more: why does it need it in the first place?

Answer 2

predicate is most likely query the state of a shared resource and it must be lock guarded.

OK. fair. Two questions here

1. Is it always true that predicate query the state of a shared resource? I assume yes. I t doesn't make sense to me to implement it otherwise
2. What if I do not pass any predicate (it is optional)?

Using predicate - lock makes sense

int i = 0;
void waits()
{
    std::unique_lock<std::mutex> lk(cv_m);
    cv.wait(lk, []{return i == 1;});
    std::cout << i;
}

Not Using predicate - why can't we lock after the wait?

int i = 0;
void waits()
{
    cv.wait(lk);
    std::unique_lock<std::mutex> lk(cv_m);
    std::cout << i;
}

Notes

I know that there are no harmful implications to this practice. I just don't know how to explain to my self why it was design this way?

Question

If predicate is optional and is not passed to wait, why do we need the lock?

Answer 1

When using a condition variable to wait for a condition, a thread performs the following sequence of steps:

1. It determines that the condition is not currently true.
2. It starts waiting for some other thread to make the condition true. This is the wait call.

For example, the condition might be that a queue has elements in it, and a thread might see that the queue is empty and wait for another thread to put things in the queue.

If another thread were to intercede between these two steps, it could make the condition true and notify on the condition variable before the first thread actually starts waiting. In this case, the waiting thread would not receive the notification, and it might never stop waiting.

The purpose of requiring the lock to be held is to prevent other threads from interceding like this. Additionally, the lock must be unlocked to allow other threads to do whatever we're waiting for, but it can't happen before the wait call because of the notify-before-wait problem, and it can't happen after the wait call because we can't do anything while we're waiting. It has to be part of the wait call, so wait has to know about the lock.

Now, you might look at the notify_* methods and notice that those methods don't require the lock to be held, so there's nothing actually stopping another thread from notifying between steps 1 and 2. However, a thread calling notify_* is supposed to hold the lock while performing whatever action it does to make the condition true, which is usually enough protection.

Answer 2

TL;DR

If predicate is optional and is not passed to wait, why do we need the lock?

condition_variable is designed to wait for a certain condition to come true, not to wait just for a notification. So to "catch" the "moment" when the condition becomes true you need to check the condition and wait for the notification. And to avoid a race condition you need those two to be a single atomic operation.

Purpose Of condition_variable:

Enable a program to implement this: do some action when a condition C holds.

Intended Protocol:

• Condition producer changes state of the world from !C to C.
• Condition consumer waits for C to happen and takes the action while/after condition C holds.

Simplification:

For simplicity (to limit number of cases to think of) let's assume that C never switches back to !C. Let's also forget about spurious wakeups. Even with this assumptions we'll see that the lock is necessary.

Naive Approach:

Let's have two threads with an essential code summarized like this:

void producer() {
  _condition = true;
  _condition_variable.notify_all();
}

void consumer() {
  if (!_condition) {
    _condition_variable.wait();
  }
  action();
}

The Problem:

The problem here is a race condition. A problematic interleaving of the threads is following:

• The consumer reads condition, checks it to be false and decides to wait.
• A thread scheduler interrupts consumer and resumes producer.
• The producer updates condition to become true and invokes notify_all().
• The consumer is resumed.
• The consumer actually does wait(), but is never notified and waken up (a liveness hazard).

So without locking the consumer may miss the event of the condition becoming true.

Solution:

Disclaimer: this code still does not handle spurious wakeups and possibility of condition becoming false again.

void producer() {
  { std::unique_lock<std::mutex> l(_mutex);
    _condition = true;
  }
  _condition_variable.notify_all();
}

void consumer() {
  { std::unique_lock<std::mutex> l(_mutex);
    if (!_condition) {
      _condition_variable.wait(l);
    }
  }
  action();
}

Here we check condition, release lock and start waiting as a single atomic operation, preventing the race condition mentioned before.

See Also

Why Lock condition await must hold the lock

Answer 3

You need a std::unique_lock when using std::condition_variable for the same reason you need a std::FILE* when using std::fwrite and for the same reason a BasicLockable is necessary when using std::unique_lock itself.

The feature std::fwrite gives you, entire the reason it exists, is to write to files. So you have to give it a file. The feature std::unique_lock provides you is RAII locking and unlocking of a mutex (or another BasicLockable, like std::shared_mutex, etc.) so you have to give it something to lock and unlock.

The feature std::condition_variable provides, the entire reason it exists, is the atomically waiting and unlocking a lock (and completing a wait and locking). So you have to give it something to lock.

---

Why would someone want that is a separate question that has been discussed already. For example:

• When is a condition variable needed, isn't a mutex enough?
• Conditional Variable vs Semaphore
• Advantages of using condition variables over mutex

And so on.

---

As has been explained, the pred parameter is optional, but having some sort of a predicate and testing it isn't. Or, in other words, not having a predicate doesn't make any sense inn a manner similar to how having a condition variable without a lock doesn't making any sense.

The reason you have a lock is because you have shared state you need to protect from simultaneous access. Some function of that shared state is the predicate.

If you don't have a predicate and you don't have a lock you really don't need a condition variable just like if you don't have a file you really don't need fwrite.

---

A final point is that the second code snippet you wrote is very broken. Obviously it won't compile as you define the lock after you try to pass it as an argument to condition_variable::wait(). You probably meant something like:

std::mutex mtx_cv;
std::condition_variable cv;

...

{
    std::unique_lock<std::mutex> lk(mtx_cv);
    cv.wait(lk);
    lk.lock();    // throws std::system_error with an error code of std::errc::resource_deadlock_would_occur
}

The reason this is wrong is very simple. condition_variable::wait's effects are (from [thread.condition.condvar]):

Effects:
— Atomically calls lock.unlock() and blocks on *this.
— When unblocked, calls lock.lock() (possibly blocking on the lock), then returns.
— The function will unblock when signaled by a call to notify_one() or a call to notify_all(), or spuriously

After the return from wait() the lock is locked, and unique_lock::lock() throws an exception if it has already locked the mutex it wraps ([thread.lock.unique.locking]).

Again, why would someone want coupling waiting and locking the way std::condition_variable does is a separate question, but given that it does - you cannot, by definition, lock a std::condition_variable's std::unique_lock after std::condition_variable::wait has returned.