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

When you create a new child thread, you must 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 your child thread’s lifetime and variables, 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
    // ...
    t0.join();
    t1.join();
    t2.join();
    t3.join();
    // ...
}

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
    // ...
    t0.detach();
    t1.detach();
    t2.detach();
    t3.detach();
    // ...
}

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.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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 on 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.

Let me give you an analogy if you are irritated by a detached thread. When you create a file and lose the handle, 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 lose 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 you have to join or detach the child thread.

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() nor 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 a problem:

// scoped_thread.cpp

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


class scoped_thread{
  std::thread t;
public:
  explicit scoped_thread(std::thread t_): t(std::move(t_)){
    if ( !t.joinable()) throw std::logic_error("No thread");
  }
  ~scoped_thread(){
    t.join();
  }
  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 detaching 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 magnificent if you use only variables with global scope in the detached threads. NO!

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

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

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

int main(){
  func();
}

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 apparent 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 for 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.

Post Views: 6,484

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, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, 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, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery,and Matt Godbolt.

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

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS