C++11: What happens if you don't call join() for std::thread

Question

Given below:

void test() 
{
  std::chrono::seconds dura( 20 );
  std::this_thread::sleep_for( dura );
}

int main()
{
  std::thread th1(test);
  std::chrono::seconds dura( 5 );
  std::this_thread::sleep_for( dura );
  return 0;
}

main will exit after 5 seconds, what will happen to th1 that's still executing?

Does it continue executing until completion even if the th1 thread object you defined in main goes out of scope and gets destroyed?

Does th1 simply sits there after it's finished executing or somehow gets cleaned up when the program terminates?

What if the thread was created in a function, not main - does the thread stays around until the program terminates or when the function goes out of scope?

Is it safe to simply not call join for a thread if you want some type of timeout behavior on the thread?

Answer 1

If you have not detached or joined a thread when the destructor is called it will call std::terminate, we can see this by going to the draft C++11 standard we see that section 30.3.1.3 thread destructor says:

If joinable(), calls std::terminate(). Otherwise, has no effects. [ Note: Either implicitly detaching or joining a joinable() thread in its destructor could result in difficult to debug correctness (for detach) or performance (for join) bugs encountered only when an exception is raised. Thus the programmer must ensure that the destructor is never executed while the thread is still joinable. —end note ]

as for a rationale for this behavior we can find a good summary in (Not) using std::thread

Why does the destructor of a joinable thread have to call std::terminate? After all, the destructor could join with the child thread, or it could detach from the child thread, or it could cancel the thread. In short, you cannot join in the destructor as this would result in unexpected (not indicated explicitly in the code) program freeze in case f2 throws.

and an example follows and also says:

You cannot detach as it would risk the situation where main thread leaves the scope which the child thread was launched in, and the child thread keeps running and keeps references to the scope that is already gone.

The article references N2802: A plea to reconsider detach-on-destruction for thread objects which is argument against the previous proposal which was detach on destruction if joinable and it notes that one of the two alternatives would be to join which could lead to deadlocks the other alternative is what we have today which is std::terminate on destruction if joinable.

Answer 2

std::thread::~thread()

If *this has an associated thread (joinable() == true), std::terminate() is called

Source: http://en.cppreference.com/w/cpp/thread/thread/~thread

This means that program like this is not at all well-formed or safe.

Note, however, that boost::thread::~thread() calls detach() instead in this case. (as user dyp stated in comments, this behavior is deprecated in more recent versions)

You could always workaround this using RAII. Just wrap your thread inside another class, that will have desired behavior on destruction.

Answer 3

In C++11, you must explicitly specify 'what happens' when the newly created thread goes out of scope (our it's dtor is called). Sometimes, when we are sure that the main thread, is continuing, and our threads are acting as 'pipeline', it is safe to 'detach()' them; and sometimes when we are waiting for our WORKER threads to complete their operations, we 'join()' them.

As this says, the programmer must ensure that the destructor is never executed while the thread is still joinable.

Specify your multi-threaded strategy. In this example, std::terminate() is called.