title: Is a boost::thread automatically removed from a boost::thread_group when it terminates?
body: <p><sup>(<a href="https://stackoverflow.com/questions/3970818/whats-the-best-way-to-delete-boostthread-object-right-after-its-work-is-compl">This question</a>, though similar, didn't really answer my question.)</sup></p>
  <p>I've had <a href="https://stackoverflow.com/questions/8434762/why-might-this-thread-management-pattern-result-in-a-deadlock">problems with my own &quot;thread group&quot; implementation</a>, and being no closer to solving or even identifying the issue, I'm looking into just using <code>boost::thread_grp</code>.</p>
  <p>Now, from what <a href="http://www.boost.org/doc/libs/1_40_0/doc/html/thread/thread_management.html#thread.thread_management.threadgroup" rel="noreferrer">documentation I can find on the subject</a><sup>1</sup>, I've always believed that thread objects — no matter the duration of their actual work — remain alive and a part of a thread group until the thread group is destroyed.</p>
  <p>However, a cursory test seems to indicate that <code>boost::thread_group::size()</code> decreases on its own as threads do their work and terminate. That would imply that the thread objects themselves are being cleaned up for me, too.</p>
  <p>Is this true? Can I rely on it?</p>
  <pre><code>#include &lt;cassert&gt;
  #include &lt;unistd.h&gt;         // for sleep()
  #include &lt;boost/thread.hpp&gt;
  
  boost::mutex m;
  unsigned int count = 0;
  
  void func() {
     boost::mutex::scoped_lock l(m);
     count++;
  }
  
  int main()
  {
     boost::thread_group grp;
     for (size_t i = 0; i &lt; 300; i++)
        grp.create_thread(func());
     
     sleep(10);
     
     assert(count == 300);
     assert(grp.size() == 0);  // passes, in my tests
     
     // ^ Can I rely on that?
     //   Do I really have no thread objects eating up
     //     memory, at this point?
     
     grp.join_all();
     // ^ Then I guess this is doing nothing, in this case...
  }
  </code></pre>
  <p>If it is, then my entire original <code>has_threads</code> implementation was just a broken clone and I've wasted my time. :)</p>
  <p><sup>And, yes, <code>assert</code> was a really poor choice for this snippet, since I guess it could lead to any unlikely-outstanding threads from butchering the memory under what used to be <code>count</code>? Anyway, never mind that.</sup></p>
  <hr />
  <p><sup>1</sup> - I'm stuck on Boost 1.40, but the documentation on the matter seems to be the same for more recent versions.</p>
  <hr />
  <h3>Update</h3>
  <p><a href="http://boost.2283326.n4.nabble.com/thread-group-removal-of-items-td2585545.html" rel="noreferrer">This thread</a> is an example of where people are saying the opposite of what my testing has shown. It does also provide a decent solution if that's the case, though; it's nice that <code>thread_group</code> is totally thread-safe (though I'm not convinced that that <code>shared_ptr::get()</code> is thread-safe; what if the thread ends before the <code>shared_ptr::reset</code> has finished?). Do I need to employ this solution?</p>