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: Eric Pederson, Paul Baxter,  Sai Raghavendra Prasad Poosa, Meeting C++, Matt Braun, Avi Lachmish, Adrian Muntea, and Roman Postanciuc.

 

 

Get your e-book at leanpub:

The C++ Standard Library

 

Concurrency With Modern C++

 

Get Both as one Bundle

cover   ConcurrencyCoverFrame   bundle
With C++11, C++14, and C++17 we got a lot of new C++ libraries. In addition, the existing ones are greatly improved. The key idea of my book is to give you the necessary information to the current C++ libraries in about 200 pages.  

C++11 is the first C++ standard that deals with concurrency. The story goes on with C++17 and will continue with C++20.

I'll give you a detailed insight in the current and the upcoming concurrency in C++. This insight includes the theory and a lot of practice with more the 100 source files.

 

Get my books "The C++ Standard Library" (including C++17) and "Concurrency with Modern C++" in a bundle.

In sum, you get more than 550 pages full of modern C++ and more than 100 source files presenting concurrency in practice.

 

Add comment


Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 553

All 1102647

Currently are 143 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments