c++ - Safely Destroying a Thread Pool -

consider following implementation of trivial thread pool written in c++14.

• threadpool.h
• threadpool.cpp

observe each thread sleeping until it's been notified awaken -- or spurious wake call -- , following predicate evaluates true:

std::unique_lock<mutex> lock(this->instance_mutex_);  this->cond_handle_task_.wait(lock, [this] {   return (this->destroy_ || !this->tasks_.empty()); }); 

furthermore, observe threadpool object uses data member destroy_ determine if being destroyed -- destructor has been called. toggling data member true notify each worker thread it's time finish current task , of other queued tasks synchronize thread that's destroying object; in addition prohibiting enqueue member function.

for convenience, implementation of destructor below:

threadpool::~threadpool() {   {     std::lock_guard<mutex> lock(this->instance_mutex_); // line.      this->destroy_ = true;   }    this->cond_handle_task_.notify_all();    (auto &worker : this->workers_) {     worker.join();   } } 

q: not understand why it's necessary lock object's mutex while toggling destroy_ true in destructor. furthermore, necessary setting value or necessary accessing value?

bq: can thread pool implementation improved or optimized while maintaining it's original purpose; thread pool can pool n amount of threads , distribute tasks them executed concurrently?

---

this thread pool implementation forked jakob progsch's c++11 thread pool repository thorough code step through understand purpose behind implementation , subjective style changes.

i introducing myself concurrent programming , there still learn -- novice concurrent programmer stands right now. if questions not worded correctly please make appropriate correction(s) in provided answer. moreover, if answer can geared towards client being introduced concurrent programming first time best -- myself , other novices well.

if owning thread of threadpool object thread atomically writes destroy_ variable, , worker threads atomically read destroy_ variable, no, mutex not needed protect destroy_ variable in threadpool destructor. typically mutex necessary when atomic set of operations must take place can't accomplished through single atomic instruction on platform, (i.e., operations beyond atomic swap, etc.). being said, author of thread pool may trying force type of acquire semantics on destroy_ variable without restoring atomic operations (i.e. memory fence operation), and/or setting of flag not considered atomic operation (platform dependent)... other options include declaring variable volatile prevent being cached, etc. can see this thread more info.

without sort of synchronization operation in place, worst case scenario end worker won't complete due destroy_ variable being cached on thread. on platforms weaker memory ordering models, that's possibility if allowed benign memory race condition exist ...