If you don’t share, no data races can happen. Not sharing means that your thread works on local variables. This can be achieved by copying the value, using thread-specific storage, or transferring the result of a thread to its associated future via a protected data channel.
The patterns in this section are quite obvious, but I will present them with a short explanation for completeness. Let me start with Copied Value.
If a thread gets its arguments by copy and not by reference, there is no need to synchronize access to any data. No data races and no lifetime issues are possible.
Data Races with References
The following program creates three threads. One thread gets its argument by copy, the other by reference, and the last by constant reference.
Each thread sleeps for one millisecond (lines 1, 2, and 3) before displaying the boolean value. Only the thread
t1 has a local copy of the boolean and has, therefore, no data race. The program’s output shows that the boolean values of threads
t3 are modified without synchronization.
You may think that the thread t3 in the previous example
copiedValueDataRace.cpp can just be replaced with
std::thread t3(byConstReference, shared). The program compiles and runs, but what seems like a reference is a copy. The reason is that the type traits function std::decay is applied to each thread argument.
std::decay performs lvalue-to-rvalue, array-to-pointer, and function-to-pointer implicit conversions to its type
T. In particular, it invokes, in this case, the type traits function
std::remove_reference on the type
The following program
perConstReference.cpp uses a non-copyable type
nonCopy (line 1) is not copyable. This is fine if I invoke the function
perConstReference with the argument
nonCopy (line 2) because the function accepts its argument per constant reference. Using the same function in the thread
t (line 3) causes GCC to generate a verbose compiler error with more than 300 lines:
The error message’s essential part is in the middle of the screenshot in red rounded rectangle: “
error: use of deleted function”. The copy-constructor of the class
NonCopyableClass is not available.
When you borrow something, you have to ensure that the underlying value is still available when you use it.
Lifetime Issues with References
If a thread uses its argument by reference and you detach the thread, you have to be extremely careful. The small program
copiedValueLifetimeIssues.cpp has undefined behavior.
executeTwoThreads (lines 1) starts two threads. Both threads are detached (lines 2 and 3) and print the local variable
localString (line 4). The first thread captures the local variable by copy, and the second the local variable by reference. For simplicity reasons, I used a lambda expression in both cases to bind the arguments. Because the
executeTwoThreads function doesn’t wait until the two threads have finished, the thread
t2 refers to the local string, which is bound to the lifetime of the invoking function. This causes undefined behavior. Curiously, with GCC the maximum optimized executable
-O3 seems to work, and the non-optimized executable crashes.
Thanks to thread-local storage, a thread can easily work on its data.
Thread-specific or thread-local storage allows multiple threads to use local storage via a global access point. By using the storage specifier
thread_local, a variable becomes a thread-local variable. This means you can use the thread-local variable without synchronization.
Assume you want to calculate the sum of all elements of a vector randValues. Doing it with a range-based for-loop is straightforward.
But your PC has four cores. Therefore, you make a concurrent program out of the sequential program:
You put the range-based for-loop into a function and let each thread calculate a fourth of the sum in the
tmpSum. The line
sum.fetch_add(tmpSum) (line 1) finally sums up all values in the atomic
sum. You can read more about thread_local storage in my previous post “Thread-Local Data“.
Promises and futures share a protected data channel.
C++11 provides futures and promise in three flavors:
std::packaged_task, and the pair
std::future. The future is a read-only placeholder for the value that a promise sets. From the synchronization perspective, a promise/future pair’s critical property is that a protected data channel connects both. There are a few decisions to make when implementing a future.
- A future can ask for its value implicitly or explicitly with the
getcall, such as in C++.
- A future can eagerly or lazily start the computation. Only the promise
std::asyncsupports lazy evaluation via launch policies.
If I don’t specify a launch policy, it’s up to the system to start the job eager or lazy. Using the launch policy
std::launch::async, a new thread is created, and the promise immediately starts its job. This
is in contrast to the launch policy
std::launch::deferred. The call
eager.get() starts the promise. Additionally, the promise is executed in the thread requesting the result with
If you want to read more about futures in C++, read the following post: “Asynchronous Function Calls“.
No data race can happen if you don’t write and read data concurrently. In my next, I will write about patterns that help you to protect against mutation.
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, 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, Ann Shatoff, Rob North, and Bhavith C Achar.
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|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
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++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,