You have also to prevent deadlocks - so sometimes it would be faster to hold a lock but a deadlock could be raised.
I figured you did that for a reason. Deadlocks are tricky and one way is to indeed hold one lock at the time. Another possibility is to make sure you take all the locks in the same order every time... You can also reduce the number of locks. I know this is not straightforward and it takes a lot of time to find the right settings. How many different locks do you have?
that's what threadpool does - you submit work and you get for each item a handle (task) back. the pool schedules and executes the work inside to the worker-threads. the pool itself is not interessted in the result of the work-items nor should the pool have knowledge about the submitted work. This can only be done outside the pool where you have anougth context. So it makes no sense that the pool waits for a subset of the submitted work.
I understand. This sounds logical. But... I don't want to sound narrow minded, I really think there are use cases where you simply want to know that your pool has done all the work you gave to it (without knowing what the work actually was). That would be waiting for pending() and running() to be == 0. Of course when your threadpool is handling a lot of tasks coming from different clients, that doesn't make sense anymore. In which case it would be nice to have some sort of "root" task on which other tasks depend. You would only need to wait for the root task to finish, making code simpler to write (and maybe the waiting more efficient to write?). Alternatively you can embed in your task some sort of synchronization mechanism... But I think it's best to have the client write as little synchronization code as possible.
you could take a look into the future library - because future is used to transfer the result between threads (using condition variables inside).
The problem is that you can have lots of tasks when sorting a container, and that means a lot of overhead with this approach. If I'm correct, if you have many tasks the wait_all starts to be slow. Maybe it's just a problem on my platform. I would need to investigate this further. Regards. -- EA