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

Question

Assume I'm starting a std::thread and then detach() it, so the thread continues executing even though the std::thread that once represented it, goes out of scope.

Assume further that the program does not have a reliable protocol for joining the detached thread¹, so the detached thread still runs when main() exits.

I cannot find anything in the standard (more precisely, in the N3797 C++14 draft), which describes what should happen, neither 1.10 nor 30.3 contain pertinent wording.

¹ Another, probably equivalent, question is: "can a detached thread ever be joined again", because whatever protocol you're inventing to join, the signalling part would have to be done while the thread was still running, and the OS scheduler might decide to put the thread to sleep for an hour just after signalling was performed with no way for the receiving end to reliably detect that the thread actually finished.

If running out of main() with detached threads running is undefined behaviour, then any use of std::thread::detach() is undefined behaviour unless the main thread never exits².

Thus, running out of main() with detached threads running must have defined effects. The question is: where (in the C++ standard, not POSIX, not OS docs, ...) are those effects defined.

² A detached thread cannot be joined (in the sense of std::thread::join()). You can wait for results from detached threads (e.g. via a future from std::packaged_task, or by a counting semaphore or a flag and a condition variable), but that doesn't guarantee that the thread has finished executing. Indeed, unless you put the signalling part into the destructor of the first automatic object of the thread, there will, in general, be code (destructors) that run after the signalling code. If the OS schedules the main thread to consume the result and exit before the detached thread finishes running said destructors, what will^Wis defined to happen?

Dolliedolloff

I can only find a very vague non-mandatory note in [basic.start.term]/4: "Terminating every thread before a call to std::exit or the exit from main is sufficient, but not necessary, to satisfy these requirements." (the whole paragraph may be relevant) Also see [support.start.term]/8 (std::exit is called when main returns) – Brandon

Answer 1

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.

Dolliedolloff

Are you sure about this? Everywhere I tested (GCC 5, clang 3.5, MSVC 14), all detached threads are killed when the main thread exits. – Unwieldy

I believe that the issue is not what a specific implementation does, but is how to avoid what the standard defines as undefined behavior. – Glaucescent

This answer seems to imply that after destruction of static variables the process will go into some kind of sleep state waiting for any remaining threads to finish. That is not true, after exit finishes destroying static objects, running atexit handlers, flushing streams etc. it returns control to the host environment, i.e. the process exits. If a detached thread is still running (and has somehow avoided undefined behaviour by not touching anything outside its own thread) then it just disappears in a puff of smoke as the process exits. – Shorthorn

If you're OK using non-ISO C++ APIs then if main calls pthread_exit instead of returning or calling exit then that will cause the process to wait for detached threads to finish, and then call exit after the last one finishes. – Shorthorn

The core guidelines support your claim that static objects might be destructed before a detached thread exits (see the note under CP.24: github.com/isocpp/CppCoreGuidelines/blob/master/…): "... if the thread continues until the end of the program, it might be running concurrently with the destruction of objects with static storage duration, and thus accesses to such objects might race." Note also that detach() is generally advised against (CP.26: github.com/isocpp/CppCoreGuidelines/blob/master/…) – Quintan

"It continues running (because the standard doesn't say it is stopped)" --> Can anyone tell me HOW a thread can continiu execution whiout its container process? – Lovesome

i think the real answer is "the behavior is undefined. although on most OSes detached threads get killed, it is good to let the main process handle the signal". – Estuarine

@JonathanWakely I'm sure your comment is right, because you implemented it like that, but the point is: where in standard is that written down? If I detach() a thread and the OS decides not to schedule the thread until main() exits, how do I avoid UB? My answer: even though it's detached, I still need to do some form of join (e.g. by upping a semaphore from an _at_thread_exit() function and down'ing it from main()). – Dolliedolloff

@Marc, where is which part written down? Returning control to the host environment is the last bullet of the description of exit in [support.start.term]. There's no "wait for detached threads to exit" step before that. Some programs just ignore the problem and let the detached threads run until the process exits, because they don't care (or don't know) about the UB from the detached thread accessing globals while they're being destroyed. Maybe it kinda sorta works for them, without setting anything on fire. But to avoid that UB, yes, you need to arrange for them to "join" somehow. – Shorthorn

In practice, if your thread has communicated that it's "done" (e.g. by making a future ready) and you know all it does after that is exit (and run some trivial dtors), then "but that doesn't guarantee that the thread has finished executing" probably isn't a real problem. You can use set_value_at_thread_exit to defer making the future ready until after the thread has exited if you know there are non-trivial dtors that will run when the thread exits. Or, just avoid detached threads altogether. They are hard to use correctly. – Shorthorn

pthread_detach(3) — Linux manual page: (But note that the resources of any threads for which one of these actions has not been done will be freed when the process terminates.) – Dierolf

Answer 2

Detaching Threads

According to std::thread::detach:

Separates the thread of execution from the thread object, allowing execution to continue independently. Any allocated resources will be freed once the thread exits.

From pthread_detach:

The pthread_detach() function shall indicate to the implementation that storage for the thread can be reclaimed when that thread terminates. If thread has not terminated, pthread_detach() shall not cause it to terminate. The effect of multiple pthread_detach() calls on the same target thread is unspecified.

Detaching threads is mainly for saving resources, in case the application does not need to wait for a thread to finish (e.g. daemons, which must run until process termination):

1. To free the application side handle: One can let a std::thread object go out of scope without joining, what normally leads to a call to std::terminate() on destruction.
2. To allow the OS to cleanup the thread specific resources (TCB) automatically as soon as the thread exits, because we explicitly specified, that we aren't interested in joining the thread later on, thus, one cannot join an already detached thread.

Killing Threads

The behavior on process termination is the same as the one for the main thread, which could at least catch some signals. Whether or not other threads can handle signals is not that important, as one could join or terminate other threads within the main thread's signal handler invocation. (Related question)

As already stated, any thread, whether detached or not, will die with its process on most OSes. The process itself can be terminated by raising a signal, by calling exit() or by returning from the main function. However, C++11 cannot and does not try to define the exact behaviour of the underlying OS, whereas the developers of a Java VM can surely abstract such differences to some extent. AFAIK, exotic process and threading models are usually found on ancient platforms (to which C++11 probably won't be ported) and various embedded systems, which could have a special and/or limited language library implementation and also limited language support.

Thread Support

If threads aren't supported std::thread::get_id() should return an invalid id (default constructed std::thread::id) as there's a plain process, which does not need a thread object to run and the constructor of a std::thread should throw a std::system_error. This is how I understand C++11 in conjunction with today's OSes. If there's an OS with threading support, which doesn't spawn a main thread in its processes, let me know.

Controlling Threads

If one needs to keep control over a thread for proper shutdown, one can do that by using sync primitives and/or some sort of flags. However, In this case, setting a shutdown flag followed by a join is the way I prefer, since there's no point in increasing complexity by detaching threads, as the resources would be freed at the same time anyway, where the few bytes of the std::thread object vs. higher complexity and possibly more sync primitives should be acceptable.

Cancel

Since every thread has its own stack (which is in the megabytes range on Linux), I would choose to detach the thread (so its stack will be freed as soon as it exits) and use some sync primitives if the main thread needs to exit (and for proper shutdown it needs to join the still running threads instead of terminating them upon return/exit). – Maplemaples

I really don't see how this answers the question – Halfhearted

Answer 3

Consider the following code:

#include <iostream>
#include <string>
#include <thread>
#include <chrono>

void thread_fn() {
  std::this_thread::sleep_for (std::chrono::seconds(1)); 
  std::cout << "Inside thread function\n";   
}

int main()
{
    std::thread t1(thread_fn);
    t1.detach();

    return 0; 
}

Running it on a Linux system, the message from the thread_fn is never printed. The OS indeed cleans up thread_fn() as soon as main() exits. Replacing t1.detach() with t1.join() always prints the message as expected.

Erbium

This behaviour happens exactly on Windows. So, it seems that Windows kills the detached threads when the program is finished. – Lovesome

I tried writing to file also with detached thread and parent exited, thinking that may be stdout not working after parent finished. But It won't write to file either. so you are right. – Salamone

so it means there is no difference with or without detach, the thread will terminate when main thread returns? – Canicular

Answer 4

The fate of the thread after the program exits is undefined behavior. But a modern operating system will clean up all threads created by the process on closing it.

When detaching an std::thread, these three conditions will continue to hold:

1. *this no longer owns any thread
2. joinable() will always equal to false
3. get_id() will equal std::thread::id()

Waxman

Why undefined? Because the standard doesn't define anything? By my footnote, wouldn't that make any call to detach() have undefined behaviour? Hard to believe... – Dolliedolloff

@MarcMutz-mmutz It is undefined in the sense that if the process exits, the fate of the thread is undefined. – Waxman

@Waxman and how do I ensure not exiting before thread finishes? – Meilen

@Meilen you use join() – Giblets

You can avoid UB if the program never exits, e.g. if main does its work in an infinite loop and never returns. – Substitution

Answer 5

When the main thread (that is, the thread that runs the main() function) terminates, then the process terminates and all other threads stop.

Reference: https://mcmap.net/q/129629/-do-child-threads-exit-when-the-parent-thread-terminates

Hobgoblin

Answer 6

When the main process terminates all the worker threads created by that process are also killed. So, if the main() returns before a detached thread it created completes execution the detached thread will be killed by OS. Take this example:

void work(){
     this_thread::sleep_for(chrono::seconds(2));
     cout<<"Worker Thread Completed"<<endl;
}
int main(){
     thread t(work);
     t.detach();
     cout<<"Main Returning..."<<endl;
     return 0;
}

In the above program Worker Thread Completed will never be printed. Since main returns before the 2 second delay in the worker thread. Now if we change the code a little and add a delay greater than 2 seconds before main returns. Like:

void work(){
     this_thread::sleep_for(chrono::seconds(2));
     cout<<"Worker Thread Completed"<<endl;
}
int main(){
     thread t(work);
     t.detach();
     cout<<"Main Returning..."<<endl;
     this_thread::sleep_for(chrono::seconds(4));
     return 0;
}

Output

Main Returning...
Worker Thread Completed

Now if a thread is created from any functions other than main the detached thread will stay alive until it's executions has completed even after the function returns. For example:

void child()
{
     this_thread::sleep_for(chrono::seconds(2));
     cout << "Worker Thread Completed" << endl;
}
void parent(){
     thread t(child);
     t.detach();
     cout<<"Parent Returning...\n";
     return;
}
int main()
{
     parent();
     cout<<"Main Waiting..."<<endl;
     this_thread::sleep_for(chrono::seconds(5));
}

Output

Parent Returning...
Main Waiting...
Worker Thread Completed

A workaround to make main to wait for a detached worker thread before returning is to use condition_variable. For example:

#include <bits/stdc++.h>
using namespace std;
condition_variable cv;
mutex m;
void work(){
    this_thread::sleep_for(chrono::seconds(2));
    cout << "Worker Thread Completed" << endl;
    cv.notify_all();
}
int main(){
    thread t(work);
    t.detach();
    cout << "Main Returning..." << endl;
    unique_lock<mutex>ul(m);
    cv.wait(ul);
    return 0;
}

Necessity

Answer 7

To allow other threads to continue execution, the main thread should terminate by calling pthread_exit() rather than exit(3). It's fine to use pthread_exit in main. When pthread_exit is used, the main thread will stop executing and will remain in zombie(defunct) status until all other threads exit. If you are using pthread_exit in main thread, cannot get return status of other threads and cannot do clean-up for other threads (could be done using pthread_join(3)). Also, it's better to detach threads(pthread_detach(3)) so that thread resources are automatically released on thread termination. The shared resources will not be released until all threads exit.

Kief

@kgvinod, why not add "pthread_exit(0);" after the "ti.detach()"; – Kief

Reference : #3559963 – Kief