I am using std::conditional_variable for timing a signal in a multi-threaded program for controlling the flow of various critical sections. The program works but during exit I am compelled to use a predicate (kill_ == true) to avoid destroying of threads which are still waiting on the std::conditional_variable ::wait(). I don't know if its the proper way to destroy all the waiting threads, advice solicited. Here's a code snippet:
class timer
{
// ...
timer(std::shared_ptr<parent_object> parent,const bool& kill)
:parent_(parent),kill_(kill){}
private:
std::condition_variable cv_command_flow_;
std::mutex mu_flow_;
const bool& kill_;
std::shared_ptr<parent_object> parent_;
};
void timer::section()
{
auto delay = get_next_delay();
std::unique_lock<std::mutex> lock(mu_flow_);
std::cv_command_flow_.wait_until(lock,delay,[] { return kill_ == true; });
if( kill_) return;
parent_->trigger();
std::cv_command_exec_.notify_all();
}
This is generally how I handle the destruction of my waiting threads. You'll want a code section such as this where you want to perform clean up (in a class destructor, the main thread before process exit, etc.):
{
std::lock_guard<std::mutex> lock(mu_flow);
kill_ = true;
}
cv_command_exec_.notify_all();
thread1.join();
I'm assuming that timer::section()
was executing within some thread std::thread thread1
.
Ownership duration of the mutex is controlled by the scoped block. You'll want the mutex held only when you set kill_ = true
and released before you call .notify_all()
(otherwise the woken thread might find the lock still held and go back to sleep).
Of course, std::unique_lock usage would look like:
std::unique_lock<std::mutex> lock(mu_flow);
kill_ = true;
lock.unlock();
cv_command_exec_.notify_all();
thread1.join();
It's personal preference to a large degree ... both code sections accomplish the same task.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.