Deadlock spotted! about threadpool

[Darelbi]

I believe is a race condition on stop and empty(). need more time to test it seriously :/

edit: nope it seems correct:
using "condition_variable_any" seems to fix the problem, so I think the real problem is inside the "condition_variable" implementation. (by the way. I don't understand why std have duplicated versions if "any" works for all. theorically condition_variable is fine, but seems it is a GCC problem, i search if someone fixed it or no in that case I try to make a ticket..)

edit2: lot of bugs still unresolved for condition_variable.: this one in particular seems the same (apparently they forgot to fix it):
https://svn.boost.org/trac/boost/ticket/4978

Have you been able to reproduce it at least?

[progschj]

I have issues reproducing this. What compiler/flags/operating system are you using? I tested on Linux with gcc-4.8, clang++-3.5 and icpc 14.

[progschj]

I tried the following with all combinations of 1-10 for threads and recursion. Which usually gives me about 10'000 nanoseconds per job.

#include <iostream>
#include <chrono>
#include <cstdlib>
#include "ThreadPool.h"

void recursiveWork(ThreadPool & pool, int depth){
    if (depth<=0)
        return;
    auto result = pool.enqueue( []{return 1;});
    recursiveWork(pool, depth-1);
    result.get();
}

int main(int argc, char *argv[]){
    int threads = strtol(argv[1], nullptr, 10);
    int recursion = strtol(argv[2], nullptr, 10);
    int initial_jobs = 1000;
    auto t0 = std::chrono::high_resolution_clock::now();
    {
        ThreadPool pool(threads);
        for (int i= 0; i<initial_jobs; i++){
            recursiveWork(pool,recursion);
        }
    }
    auto t1 = std::chrono::high_resolution_clock::now();
    std::cout << "threads: " << threads << " depth: " << recursion << std::endl;
    std::cout << "ns/job: " << std::chrono::duration_cast<std::chrono::nanoseconds>(t1-t0).count()/((recursion+1)*initial_jobs) << std::endl;
    return 0;
}

[Darelbi]

Compiler version:
GCC 4.8.0 posix sjlj
Compiler flags:
-Wall -Wextra -std=c++11 -s -O3 -msse2
Platform:
Windows Vista

If I run the above code with threads and recursion = 10 it never ends (well 2 minutes passed I assume it's deadlockd)

[yxbh]

I can reproduce the issue, albeit not consistently, though it does happen from time to time. Have not been able to reproduce it with std::condition_variable_any yet.

This is on Windows 7 using MinGW32 (GCC4.8.2), with test code variables threads, recusion = 10 and initial_jobs = 10,000.

by the way. I don't understand why std have duplicated versions if "any" works for all.

std::condition_variable is specialised for std::unique_lock, so it could be faster than the _any version depending on implementation. Indeed, std::condition_variable is quite a bit faster than std::condition_variable_any on my machine.

[rubixcubin]

Hey I think this is a windows issue. I saw this too, condition_variable_any fixed it for me. I think there was a bug somewhere in that implementation. I'm not too sure why

[progschj]

Given that this is apparently a stlib issue/bug and hasn't been active for a while I'll close this for now.