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.
- CP.23: Think of a joining
thread
as a scoped container - CP.24: Think of a
thread
as a global container - CP.25: Prefer
gsl::joining_thread
overstd::thread
- CP.26: Don’t
detach()
a thread
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
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.
// 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.
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 |
Seminars
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
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
- Mobil: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,
Leave a Reply
Want to join the discussion?Feel free to contribute!