Introduction

std::condition_variable uses std::unique_lock because waiting on a condition variable requires temporarily unlocking and then re-locking the mutex. std::lock_guard cannot do that, while std::unique_lock was designed specifically to support that level of control.

What wait() Needs to Do

A thread waiting on a condition variable must perform an atomic-looking sequence:

1. release the mutex
2. go to sleep
3. wake up when notified or spuriously awakened
4. re-acquire the mutex before returning

That means the wait operation needs a lock object whose ownership can be manipulated during the wait.

std::unique_lock supports that. std::lock_guard does not.

Why lock_guard Is Not Enough

std::lock_guard is intentionally minimal. It locks in the constructor and unlocks in the destructor. There is no API to unlock and re-lock it in the middle.

That simplicity is great for short critical sections:

1std::mutex m;
2
3void f() {
4    std::lock_guard<std::mutex> guard(m);
5    // protected work
6}

But a condition variable wait is more complicated than a simple scope guard.

How unique_lock Fits the Need

std::unique_lock supports:

• explicit lock() and unlock()
• deferred locking
• ownership transfer
• condition-variable waiting APIs

Typical condition-variable usage looks like this:

1#include <condition_variable>
2#include <mutex>
3#include <thread>
4#include <queue>
5
6std::mutex m;
7std::condition_variable cv;
8std::queue<int> q;
9
10void consumer() {
11    std::unique_lock<std::mutex> lock(m);
12    cv.wait(lock, [] { return !q.empty(); });
13
14    int value = q.front();
15    q.pop();
16}

The condition variable can safely unlock lock while waiting and re-lock it before returning control to consumer().

Why Re-Locking Matters

When wait() returns, the waiting thread must hold the mutex again before it examines shared state. Otherwise, another thread could change the condition between wakeup and inspection.

That is why the lock is passed into wait() and why the predicate form is so important.

The predicate version:

cv.wait(lock, [] { return ready; });

handles spurious wakeups by rechecking the condition while the mutex is held.

Could the API Have Been Designed Differently?

In theory, the library could have invented a completely separate lock concept just for condition variables. Instead, C++ standardized on std::unique_lock because it already expresses the needed ownership semantics.

That keeps the API more coherent:

• 'lock_guard for simple scoped locking'
• 'unique_lock for flexible ownership and waiting'

The split is intentional, not accidental.

Performance and Tradeoffs

std::unique_lock is usually a little heavier than std::lock_guard because it stores more state and supports more operations. That is why lock_guard still exists.

Use lock_guard when you just need RAII locking.

Use unique_lock when:

• you need a condition variable
• you need deferred locking
• you need manual unlock and re-lock behavior
• you need to transfer lock ownership

The overhead is usually negligible compared with the fact that condition-variable waits are already synchronization-heavy operations.

Common Pitfalls

The most common mistake is thinking wait() only needs a mutex, not a flexible lock object. The unlock and re-lock step is the whole reason unique_lock is required.

Another issue is ignoring spurious wakeups and using wait(lock) without checking a condition in a loop or predicate. The lock type is correct, but the waiting logic is still incomplete.

People also overuse unique_lock everywhere. If you do not need its extra features, lock_guard is the simpler tool.

Finally, do not manually unlock the mutex around wait() yourself. Let the condition variable manage that sequence correctly.

Summary

• 'std::condition_variable needs a lock that can be unlocked and re-locked during waiting.'
• 'std::unique_lock supports that ownership model; std::lock_guard does not.'
• The waiting thread must hold the mutex again before checking shared state after wakeup.
• Predicate-based wait() is the safest standard pattern.
• Use lock_guard for simple critical sections and unique_lock when flexibility is required.