The job_available_mutex will unlock after calling the condition_variable::wait, and lock after it return. It means queue_mutex is unnecessary.

change:

1. reduce the unnecessary mutex
2. avoid dead-lock in job_available_var.wait's predicate, remove the call of JobsRemaining

• Fixes deadlocks (in WaitAll and JoinAll specifically)
• Supports setting amount of threads in constructor
• Clearer datatypes: queue instead of list
• Removes redundancies
• Simplifies the code

More info can be found here: http://stackoverflow.com/q/37110370

atomic_bool does not have a constructor on VS 2012/2013 but can be replaced by atomic<bool> which has one. Same for atomic_int

http://stackoverflow.com/a/15751036

Hi nbsdx, I am confused about the introduction of jobs_left. What is the purpose of introducing atomic_int type jobs_left(in line 27)? I think, we could simply add the queue_mutex's lock in function WaitAll() (in line 148), rather than using the atomic_int variable jobs_left? So, what is your consideration here?

Best, CHE Yulin

• Could not understand one line of code
  • std::unique_lockstd::mutex lk, the std::unique_lockstd::mutex is designed with RAII, why do you add extra lk.unlock(); in line 151?
  • I am puzzled about that. Could you give me some hints? @nbsdx

Is there a way to make the number of threads (ThreadCount) dynamically used by the program? Something like: ThreadPool pool(std::thread::hardware_concurrency())

I'm getting this error /usr/include/c++/5.3.0/condition_variable: In instantiation of ‘void std::condition_variable::wait(std::unique_lock<std::mutex>&, _Predicate) [with _Predicate = ThreadPool::next_job()::<lambda()>]’: lib/../lib/ThreadPool.hpp:53:78: required from here /usr/include/c++/5.3.0/condition_variable:97:13: error: could not convert ‘__p.ThreadPool::next_job()::<lambda()>()’ from ‘void’ to ‘bool’ while (!__p())

while using your header with lambda:

ThreadPool<8> pool;
pool.AddJob( [it, &l, this]() {
    // Do something
    if (...) {
    }else {...}
    std::lock_guard<std::mutex> lock(this->mtx);
    {...}
});

The job_available_mutex will unlock after calling the condition_variable::wait, and lock after it return. It means queue_mutex is unnecessary.

http://stackoverflow.com/questions/2763714/why-do-pthreads-condition-variable-functions-require-a-mutex

• Hi, nbsdx, I try the following code to use the ThreadPool, but it seemed to be a dead-lock there.
• I use a script to run the program many times, but it occasionally got stuck.
• The code I wrote is as follows, which could also be found in my branch.
• Briefly speaking, I just want to do stage-synchronization-computation, where the inner loop is regarded as a stage.
• I am not able to solve that.
• Could you please help me with that? Thanks, CHE Yulin

#include <thread>
#include <iostream>

#include "ThreadPool.h"

using std::cout;
using std::endl;

int main() {
    using namespace nbsdx::concurrent;
    ThreadPool<20> pool;
    for (auto j = 0; j < 3000; j++) {
        cout << "Round:" << j << endl;
        for (int i = 0; i < 5000; ++i) {
            std::function<int(void)> task_function = [i]() {
                return i * i;
            };
            pool.AddJob(task_function);
        }
        cout << "Finish Add" << endl;
        pool.WaitAll();
    }
}