title: Does async(launch::async) in C++11 make thread pools obsolete for avoiding expensive thread creation?
body: <p>It is loosely related to this question: <a href="https://stackoverflow.com/questions/12993451/c11-stdthread-pooled">Are std::thread pooled in C++11?</a>. Though the question differs, the intention is the same:</p>
  
  <p><strong>Question 1: Does it still make sense to use your own (or 3rd-party library) thread pools to avoid expensive thread creation?</strong></p>
  
  <p>The conclusion in the other question was that you cannot rely on <code>std::thread</code> to be pooled (it might or it might be not). However, <code>std::async(launch::async)</code> seems to have a much higher chance to be pooled.</p>
  
  <p>It don't think that it is forced by the standard, but IMHO I would expect that all good C++11 implementations would use thread pooling if thread creation is slow. Only on platforms where it is inexpensive to create a new thread, I would expect that they always spawn a new thread.</p>
  
  <p><strong>Question 2: This is just what I think, but I have no facts to prove it. I may very well be mistaken. Is it an educated guess?</strong></p>
  
  <p>Finally, here I have provided some sample code that first shows how I think thread creation can be expressed by <code>async(launch::async)</code>:</p>
  
  <p>Example 1:</p>
  
  <pre><code> thread t([]{ f(); });
   // ...
   t.join();
  </code></pre>
  
  <p>becomes</p>
  
  <pre><code> auto future = async(launch::async, []{ f(); });
   // ...
   future.wait();
  </code></pre>
  
  <p>Example 2: Fire and forget thread</p>
  
  <pre><code> thread([]{ f(); }).detach();
  </code></pre>
  
  <p>becomes</p>
  
  <pre><code> // a bit clumsy...
   auto dummy = async(launch::async, []{ f(); });
  
   // ... but I hope soon it can be simplified to
   async(launch::async, []{ f(); });
  </code></pre>
  
  <p><strong>Question 3: Would you prefer the <code>async</code> versions to the <code>thread</code> versions?</strong></p>
  
  <hr>
  
  <p><strong>The rest is no longer part of the question, but only for clarification:</strong></p>
  
  <p>Why must the return value be assigned to a dummy variable?</p>
  
  <p>Unfortunately, the current C++11 standard forces that you capture the return value of <code>std::async</code>, as otherwise the destructor is executed, which blocks until the action terminates. It is by some considered an error in the standard (e.g., by Herb Sutter).</p>
  
  <p>This example from <a href="http://en.cppreference.com/w/cpp/thread/async" rel="noreferrer">cppreference.com</a> illustrates it nicely:</p>
  
  <pre><code>{
    std::async(std::launch::async, []{ f(); });
    std::async(std::launch::async, []{ g(); });  // does not run until f() completes
  }
  </code></pre>
  
  <hr>
  
  <p>Another clarification:</p>
  
  <p>I know that <strong>thread pools may have other legitimate uses but in this question I am only interested in the aspect of avoiding expensive thread creation costs</strong>.</p>
  
  <p>I think there are still situations where thread pools are very useful, especially if you need more control over resources.
  For example, a server might decide to handle only a fixed number of requests simultaneously to guarantee fast response times and to increase the predictability of memory usage. Thread pools should be fine, here.</p>
  
  <p>Thread-local variables may also be an argument for your own thread pools, but I'm not sure whether it is relevant in practice:</p>
  
  <ul>
  <li>Creating a new thread with <code>std::thread</code> starts without initialized thread-local variables. Maybe this is not what you want.</li>
  <li>In threads spawned by <code>async</code>, it is somewhat unclear for me because the thread could have been reused. From my understanding, thread-local variables are not guaranteed to be resetted, but I may be mistaken.</li>
  <li>Using your own (fixed-size) thread pools, on the other hand, gives you full control if you really need it.</li>
  </ul>