In C++03 I used pthread
with a self-built thread pool that always kept a couple of threads running (since pthread_create
is slow), this way I was able to launch threads for small tasks without thinking about performance issues.
Now, in C++11 we have std::thread
. I guess the standard doesn't say anything about the specific implementation, so my question is about the standard library implementations. Are they generally opting for a pooled approach where constructing std::thread
s is cheap (and e.g. doesn't call pthread_create
on posix), or will std::thread
just be a wrapper?
In other words, is a thread pool still recommended in C++11, or should I just create a std::thread
whenever I need one and leave performance up to the standard library?
Generally, std::thread
should be a minimal wrapper around underlying system primitive. For example, if you're on pthread
platform, you can test with the following program that no matter how many threads you create, they are all created with unique pthread_t
ids (which implies they're created on the fly and not borrowed from a thread pool):
#include <assert.h>
#include <mutex>
#include <set>
#include <thread>
#include <vector>
#include <pthread.h>
int main() {
std::vector<std::thread> workers;
std::set<long long> thread_ids;
std::mutex m;
const int n = 1024;
for (int i = 0; i < n; ++i) {
workers.push_back(std::thread([&] {
std::lock_guard<std::mutex> lock(m);
thread_ids.insert(pthread_self());
}));
}
for (auto& worker : workers) {
worker.join();
}
assert(thread_ids.size() == n);
return 0;
}
So thread pools still make perfect sense. That said, I've seen a video where C++ committee members discussed thread pools with regard to std::async
(IIRC), but I can't find it right now.