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

Contents[Show]

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 which are bound to your lifetime 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 high probability in undefined behaviour.

gleise

Here are the rules for today that deal exactly with the lifetime 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 joins it's created thread but the second variation detaches all created thread.

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 synchronisation 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.
  • To 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 behaviour.

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.

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.

threadForgetJoin

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;
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 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 a 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 object with static duration can be critical. For example, have a look at this small program that has undefined behaviour.

#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 behaviour because the child thread t uses the variables s which goes out of scope. STOP! This is the obvious problem but the hidden issue is std::cout. std::cout has 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 thread, and the costs of thread creation and destruction.

 

 

 

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Darshan Mody, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Wolfgang Gärtner,  Louis St-Amour, Stephan Roslen, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Avi Kohn, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, Sudhakar Balagurusamy, lennonli, and Pramod Tikare Muralidhara.

 

Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, and Dendi Suhubdy

 

Seminars

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

Bookable (Online)

Deutsch

English

Standard Seminars 

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

New

Contact Me

Modernes C++,

RainerGrimmSmall

My Newest E-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

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 7947

Yesterday 5442

Week 7947

Month 215350

All 5084664

Currently are 150 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments