c++multithreadingc++11threadpoolstdthread

C++11: std::thread pooled?


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::threads 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?


Solution

  • 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.