std::condition_variable in use as the following:
std::condition_variable cv;
...
std::unique_lock<std::mutex> lk(m);
cv.wait(lk, []{return processed;});
Seems to me to have an interesting problem. unique_lock could be deferred, it could have been swapped away. It could have numerous other reasons by code design and not necessarily bad mistakes that it is not actually locked. eg.
std::unique_lock<std::mutex> lk(m, std::try_to_lock_t); // or std::defer_lock_t
// Try to lock fails.
cv.wait(lk, []{return processed;});
Why not enforce a locked situation by making std::conditional_variable work with lock_guard instead? Then you would be very hard pressed to get into this situation. In fact the only way would be to do this:
// m is not already locked
std::lock_gaurd<std::mutex> lk(m, std::adopt_lock);
cv.wait(lk, []{return processed;});
Rather than the multitude of ways available in unique_lock. Is there a technical reason to use unique_lock over lock_guard for a condition_variable?