C++ Core Guidelines: Taking Care of your Child Thread


When you create a new child thread, you have to answer an important question: should you wait for the child or detach yourself from it? If you detach yourself from the newly created child, and your child uses variables that are bound to your life as creator a new question arises: Will the variables stay valid during the lifetime of the child thread?

 If you don't carefully handle the lifetime and the variables of your child thread, you will end with a high probability of undefined behavior.


Here are the rules for today that deal exactly with the life issues of the child thread and its variables.

The rules of today depend strongly on each other.

Rule CP.23 and CP.24 about a scoped versus global container may sound a little bit weird but they are quite good to explain the difference between a child thread which you join or detach.

CP.23: Think of a joining thread as a scoped container and CP.24: Think of a thread as a global container

Here is a slight variation of the code snippet from the C++ core guidelines:

void f(int* p)
    // ...
    *p = 99;
    // ...

int glob = 33;

void some_fct(int* p)                // (1)
    int x = 77;
    std::thread t0(f, &x);           // OK
    std::thread t1(f, p);            // OK
    std::thread t2(f, &glob);        // OK
    auto q = make_unique<int>(99);
    std::thread t3(f, q.get());      // OK
    // ...
    // ...

void some_fct2(int* p)               // (2)
    int x = 77;
    std::thread t0(f, &x);           // bad
    std::thread t1(f, p);            // bad
    std::thread t2(f, &glob);        // OK
    auto q = make_unique<int>(99);
    std::thread t3(f, q.get());      // bad
    // ...
    // ...


The only difference between the functions some_fct (1) and some_fct2 (2) is that the first variations join its created thread but the second variation detaches all created threads.

First of all, you have to join or detach the child thread. If you won't do it, you will get a std::terminate exception in the destructor of the child thread. I will write about this issue in the next rule CP.25.

Here is the difference between joining of detaching a child thread:

  • To join a thread means according to the guidelines that your thread is a kind of scoped container. What? The reason is that the thr.join() call on a thread thr is a synchronization point. thr.join() guarantees that the creator of the thread will wait until its child is done. To put it the other way around. The child thread thr can use all variables (state) of the enclosing scope, in which it was created. Consequently, all calls of the function f are well defined.
  • On the contrary, this will not hold if you detach all your child threads. Detaching means, you will lose the handle to your child and your child can even outlive you. Due to this fact, it's only safe to use in the child thread variables with global scope. According to the guidelines, your child thread is a kind of global container. Using variables from the enclosing scope is, in this case, undefined behavior.

If you are irritated by a detached thread, let me give you an analogy. When you create a file and you lose the handle to the file, the file will still exist. The same holds for a detached thread. If you detach a thread, the "thread of execution" will continue to run but you lost the handle to the "thread of execution". You may guess it: t0 is just the handle to the thread of execution that was started with the call std::thread t0(f, &x).

As I already mentioned it you have to join or detach the child thread.


Rainer D 6 P2 540x540Modernes C++ Mentoring

Stay informed about my mentoring programs.



Subscribe via E-Mail.

CP.25: Prefer gsl::joining_thread over std::thread

In the following program, I forgot to join the thread t.

// threadWithoutJoin.cpp

#include <iostream>
#include <thread>

int main(){

  std::thread t([]{std::cout << std::this_thread::get_id() << std::endl;});



The execution of the program ends abruptly.


And now the explanation:

The lifetime of the created thread t ends with its callable unit. The creator has two choices. First: it waits, until its child is done (t.join()). Second: it detaches itself from its child: t.detach(). A thread t with a callable unit  - you can create threads without callable units - is called joinable if neither a t.join() or t.detach() call happened. The destructor of a joinable thread throws a std::terminate exception which ends in std::abort. Therefore, the program terminates.

The rule is called "Prefer gsl::joining_thread over std::thread" because a gsl::joinging_thread joins automatically at the end of its scope. Sad to say but I found no implementation of the gsl::joining_thread in the guidelines support library. Thanks to the scoped_thread from Anthony Williams this is not really a problem:
// scoped_thread.cpp

#include <iostream>
#include <thread>
#include <utility>

class scoped_thread{
  std::thread t;
  explicit scoped_thread(std::thread t_): t(std::move(t_)){
    if ( !t.joinable()) throw std::logic_error("No thread");
  scoped_thread(scoped_thread&)= delete;
  scoped_thread& operator=(scoped_thread const &)= delete;

int main(){

  scoped_thread t(std::thread([]{std::cout << std::this_thread::get_id() << std::endl;}));



The scoped_thread checks in its constructor if the given thread is joinable and joins in its destructor the given thread.

CP.26: Don’t detach() a thread

This rule sounds strange. The C++11 standard supports it to detach a thread but we should not do it! The reason is that detaching a thread can be quite challenging. As rule C.25 said: CP.24: Think of an thread as a global container. Of course, this means you are totally fine if you use only variables with global scope in the detached threads. NO!

Even objects with static duration can be critical. For example, have a look at this small program that has undefined behavior.

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

func(){ std::string s{"C++11"}; std::thread t([&s]{ std::cout << s << std::endl;}); t.detach(); }

int main(){


This is easy. The lambda function takes s by reference. This is undefined behavior because the child thread t uses the variable s which goes out of scope. STOP! This is the obvious problem but the hidden issue is std::cout. std::cout has a static duration. This means, the lifetime of std::cout ends with the end of the program and we have, additionally, a race condition: thread t may use std::cout at this time. 

What's next?

We are not yet done with the rules to concurrency in the C++ core guidelines. In the next post, more rules will follow: they are about passing data to threads, sharing ownership between threads, and the costs of thread creation and destruction.





Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, and Ann Shatoff.


Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, and Slavko Radman.



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo


My special thanks to Tipi.build tipi.build logo


I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

  • C++ - The Core Language
  • C++ - The Standard Library
  • C++ - Compact
  • C++11 and C++14
  • Concurrency with Modern C++
  • Design Pattern and Architectural Pattern with C++
  • Embedded Programming with Modern C++
  • Generic Programming (Templates) with C++


  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,



Stay Informed about my Mentoring


English Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Interactive Course: The All-in-One Guide to C++20

Subscribe to the newsletter (+ pdf bundle)

All tags

Blog archive

Source Code


Today 3829

Yesterday 5317

Week 3829

Month 148000

All 11629154

Currently are 255 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments