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
?