What happens to a detached thread when main() exits?

by

The answer to the original question “what happens to a detached thread when main() exits” is:

It continues running (because the standard doesn’t say it is stopped), and that’s well-defined, as long as it touches neither (automatic|thread_local) variables of other threads nor static objects.

This appears to be allowed to allow thread managers as static objects (note in [basic.start.term]/4 says as much, thanks to @dyp for the pointer).

Problems arise when the destruction of static objects has finished, because then execution enters a regime where only code allowed in signal handlers may execute ([basic.start.term]/1, 1st sentence). Of the C++ standard library, that is only the <atomic> library ([support.runtime]/9, 2nd sentence). In particular, that—in general—excludes condition_variable (it’s implementation-defined whether that is save to use in a signal handler, because it’s not part of <atomic>).

Unless you’ve unwound your stack at this point, it’s hard to see how to avoid undefined behaviour.

The answer to the second question “can detached threads ever be joined again” is:

Yes, with the *_at_thread_exit family of functions (notify_all_at_thread_exit(), std::promise::set_value_at_thread_exit(), …).

As noted in footnote [2] of the question, signalling a condition variable or a semaphore or an atomic counter is not sufficient to join a detached thread (in the sense of ensuring that the end of its execution has-happened-before the receiving of said signalling by a waiting thread), because, in general, there will be more code executed after e.g. a notify_all() of a condition variable, in particular the destructors of automatic and thread-local objects.

Running the signalling as the last thing the thread does (after destructors of automatic and thread-local objects has-happened) is what the _at_thread_exit family of functions was designed for.

So, in order to avoid undefined behaviour in the absence of any implementation guarantees above what the standard requires, you need to (manually) join a detached thread with an _at_thread_exit function doing the signalling or make the detached thread execute only code that would be safe for a signal handler, too.

More Related Contents:

  1. Passing object by reference to std::thread in C++11
  2. Thread pooling in C++11
  3. std::thread pass by reference calls copy constructor
  4. How to check if a std::thread is still running?
  5. Difference between pointer and reference as thread parameter
  6. I want to kill a std::thread using its thread object? [duplicate]
  7. C++11 introduced a standardized memory model. What does it mean? And how is it going to affect C++ programming?
  8. Concurrency: Atomic and volatile in C++11 memory model
  9. What are the correct link options to use std::thread in GCC under linux?
  10. Why is the destructor of a future returned from `std::async` blocking?
  11. What does the thread_local mean in C++11?
  12. Does MinGW-w64 support std::thread out of the box when using the Win32 threading model?
  13. C++11 thread-safe queue
  14. How to implement multithread safe singleton in C++11 without using
  15. Does the C++ volatile keyword introduce a memory fence?
  16. Which std::async implementations use thread pools?
  17. How can I use something like std::vector?
  18. Get the status of a std::future
  19. Delayed start of a thread in C++ 11
  20. What is std::promise?
  21. Is it smart to replace boost::thread and boost::mutex with c++11 equivalents?
  22. C++11 STL containers and thread safety
  23. Can I use std::async without waiting for the future limitation?
  24. Passing arguments to std::async by reference fails
  25. C++ terminate called without an active exception
  26. std::thread::join() hangs if called after main() exits when using VS2012 RC
  27. thread safety of MPI send using threads created with std::async
  28. GCC std::thread not found in namespace std
  29. C++11 Implementation of Spinlock using header “
  30. Why does this simple std::thread example not work?

Leave a Comment