Table of Contents for
Mastering C++ Multithreading

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering C++ Multithreading by Maya Posch Published by Packt Publishing, 2017
  1. Mastering C++ Multithreading
  2. Title Page
  3. Copyright
  4. Mastering C++ Multithreading
  5. Credits
  6. About the Author
  7. About the Reviewer
  8. www.PacktPub.com
  9. Why subscribe?
  10. Customer Feedback
  11. Table of Contents
  12. Preface
  13. What this book covers
  14. What you need for this book
  15. Who this book is for
  16. Conventions
  17. Reader feedback
  18. Downloading the example code
  19. Errata
  20. Piracy
  21. Questions
  22. Revisiting Multithreading
  23. Getting started
  24. The multithreaded application
  25. Makefile
  26. Other applications
  27. Summary
  28. Multithreading Implementation on the Processor and OS
  29. Defining processes and threads
  30. Tasks in x86 (32-bit and 64-bit)
  31. Process state in ARM
  32. The stack
  33. Defining multithreading
  34. Flynn's taxonomy
  35. Symmetric versus asymmetric multiprocessing
  36. Loosely and tightly coupled multiprocessing
  37. Combining multiprocessing with multithreading
  38. Multithreading types
  39. Temporal multithreading
  40. Simultaneous multithreading (SMT)
  41. Schedulers
  42. Tracing the demo application
  43. Mutual exclusion implementations
  44. Hardware
  45. Software
  46. Summary
  47. C++ Multithreading APIs
  48. API overview
  49. POSIX threads
  50. Windows support
  51. PThreads thread management
  52. Mutexes
  53. Condition variables
  54. Synchronization
  55. Semaphores
  56. Thread local storage (TLC)
  57. Windows threads
  58. Thread management
  59. Advanced management
  60. Synchronization
  61. Condition variables
  62. Thread local storage
  63. Boost
  64. Qt
  65. QThread
  66. Thread pools
  67. Synchronization
  68. QtConcurrent
  69. Thread local storage
  70. POCO
  71. Thread class
  72. Thread pool
  73. Thread local storage (TLS)
  74. Synchronization
  75. C++ threads
  76. Putting it together
  77. Summary
  78. Thread Synchronization and Communication
  79. Safety first
  80. The scheduler
  81. High-level view
  82. Implementation
  83. Request class
  84. Worker class
  85. Dispatcher
  86. Makefile
  87. Output
  88. Sharing data
  89. Using r/w-locks
  90. Using shared pointers
  91. Summary
  92. Native C++ Threads and Primitives
  93. The STL threading API
  94. Boost.Thread API
  95. The 2011 standard
  96. C++14
  97. C++17
  98. STL organization
  99. Thread class
  100. Basic use
  101. Passing parameters
  102. Return value
  103. Moving threads
  104. Thread ID
  105. Sleeping
  106. Yield
  107. Detach
  108. Swap
  109. Mutex
  110. Basic use
  111. Non-blocking locking
  112. Timed mutex
  113. Lock guard
  114. Unique lock
  115. Scoped lock
  116. Recursive mutex
  117. Recursive timed mutex
  118. Shared mutex
  119. Shared timed mutex
  120. Condition variable
  121. Condition_variable_any
  122. Notify all at thread exit
  123. Future
  124. Promise
  125. Shared future
  126. Packaged_task
  127. Async
  128. Launch policy
  129. Atomics
  130. Summary
  131. Debugging Multithreaded Code
  132. When to start debugging
  133. The humble debugger
  134. GDB
  135. Debugging multithreaded code
  136. Breakpoints
  137. Back traces
  138. Dynamic analysis tools
  139. Limitations
  140. Alternatives
  141. Memcheck
  142. Basic use
  143. Error types
  144. Illegal read / illegal write errors
  145. Use of uninitialized values
  146. Uninitialized or unaddressable system call values
  147. Illegal frees
  148. Mismatched deallocation
  149. Overlapping source and destination
  150. Fishy argument values
  151. Memory leak detection
  152. Helgrind
  153. Basic use
  154. Misuse of the pthreads API
  155. Lock order problems
  156. Data races
  157. DRD
  158. Basic use
  159. Features
  160. C++11 threads support
  161. Summary
  162. Best Practices
  163. Proper multithreading
  164. Wrongful expectations - deadlocks
  165. Being careless - data races
  166. Mutexes aren't magic
  167. Locks are fancy mutexes
  168. Threads versus the future
  169. Static order of initialization
  170. Summary
  171. Atomic Operations - Working with the Hardware
  172. Atomic operations
  173. Visual C++
  174. GCC
  175. Memory order
  176. Other compilers
  177. C++11 atomics
  178. Example
  179. Non-class functions
  180. Example
  181. Atomic flag
  182. Memory order
  183. Relaxed ordering
  184. Release-acquire ordering
  185. Release-consume ordering
  186. Sequentially-consistent ordering
  187. Volatile keyword
  188. Summary
  189. Multithreading with Distributed Computing
  190. Distributed computing, in a nutshell
  191. MPI
  192. Implementations
  193. Using MPI
  194. Compiling MPI applications
  195. The cluster hardware
  196. Installing Open MPI
  197. Linux and BSDs
  198. Windows
  199. Distributing jobs across nodes
  200. Setting up an MPI node
  201. Creating the MPI host file
  202. Running the job
  203. Using a cluster scheduler
  204. MPI communication
  205. MPI data types
  206. Custom types
  207. Basic communication
  208. Advanced communication
  209. Broadcasting
  210. Scattering and gathering
  211. MPI versus threads
  212. Potential issues
  213. Summary
  214. Multithreading with GPGPU
  215. The GPGPU processing model
  216. Implementations
  217. OpenCL
  218. Common OpenCL applications
  219. OpenCL versions
  220. OpenCL 1.0
  221. OpenCL 1.1
  222. OpenCL 1.2
  223. OpenCL 2.0
  224. OpenCL 2.1
  225. OpenCL 2.2
  226. Setting up a development environment
  227. Linux
  228. Windows
  229. OS X/MacOS
  230. A basic OpenCL application
  231. GPU memory management
  232. GPGPU and multithreading
  233. Latency
  234. Potential issues
  235. Debugging GPGPU applications
  236. Summary

The multithreaded application

In its most basic form, a multithreaded application consists of a singular process with two or more threads. These threads can be used in a variety of ways; for example, to allow the process to respond to events in an asynchronous manner by using one thread per incoming event or type of event, or to speed up the processing of data by splitting the work across multiple threads.

Examples of asynchronous responses to events include the processing of the graphical user interface (GUI) and network events on separate threads so that neither type of event has to wait on the other, or can block events from being responded to in time. Generally, a single thread performs a single task, such as the processing of GUI or network events, or the processing of data.

For this basic example, the application will start with a singular thread, which will then launch a number of threads, and wait for them to finish. Each of these new threads will perform its own task before finishing.

Let's start with the includes and global variables for our application:

#include <iostream>
#include <thread>
#include <mutex>
#include <vector>
#include <random>

using namespace std;

// --- Globals
mutex values_mtx;
mutex cout_mtx;
vector<int> values;

Both the I/O stream and vector headers should be familiar to anyone who has ever used C++: the former is here used for the standard output (cout), and the vector for storing a sequence of values.

The random header is new in c++11, and as the name suggests, it offers classes and methods for generating random sequences. We use it here to make our threads do something interesting.

Finally, the thread and mutex includes are the core of our multithreaded application; they provide the basic means for creating threads, and allow for thread-safe interactions between them.

Moving on, we create two mutexes: one for the global vector and one for cout, since the latter is not thread-safe.

Next we create the main function as follows:

int main() {
values.push_back(42);

We push a fixed value onto the vector instance; this one will be used by the threads we create in a moment:

    thread tr1(threadFnc, 1);
thread tr2(threadFnc, 2);
thread tr3(threadFnc, 3);
thread tr4(threadFnc, 4);

We create new threads, and provide them with the name of the method to use, passing along any parameters--in this case, just a single integer:


tr1.join();
tr2.join();
tr3.join();
tr4.join();

Next, we wait for each thread to finish before we continue by calling join() on each thread instance:


cout << "Input: " << values[0] << ", Result 1: " << values[1] << ", Result 2: " << values[2] << ", Result 3: " << values[3] << ", Result 4: " << values[4] << "\n";


return 1;
}

At this point, we expect that each thread has done whatever it's supposed to do, and added the result to the vector, which we then read out and show the user.

Of course, this shows almost nothing of what really happens in the application, mostly just the essential simplicity of using threads. Next, let's see what happens inside this method that we pass to each thread instance:

void threadFnc(int tid) {
cout_mtx.lock();
cout << "Starting thread " << tid << ".\n";
cout_mtx.unlock();

In the preceding code, we can see that the integer parameter being passed to the thread method is a thread identifier. To indicate that the thread is starting, a message containing the thread identifier is output. Since we're using a non-thread-safe method for this, we use the cout_mtx mutex instance to do this safely, ensuring that just one thread can write to cout at any time:

    values_mtx.lock();
int val = values[0];
values_mtx.unlock();

When we obtain the initial value set in the vector, we copy it to a local variable so that we can immediately release the mutex for the vector to enable other threads to use the vector:

    int rval = randGen(0, 10);
val += rval;

These last two lines contain the essence of what the threads created do: they take the initial value, and add a randomly generated value to it. The randGen() method takes two parameters, defining the range of the returned value:


cout_mtx.lock();
cout << "Thread " << tid << " adding " << rval << ". New value: " << val << ".\n";
cout_mtx.unlock();

values_mtx.lock();
values.push_back(val);
values_mtx.unlock();
}

Finally, we (safely) log a message informing the user of the result of this action before adding the new value to the vector. In both cases, we use the respective mutex to ensure that there can be no overlap when accessing the resource with any of the other threads.

Once the method reaches this point, the thread containing it will terminate, and the main thread will have one less thread to wait for to rejoin. The joining of a thread basically means that it stops existing, usually with a return value passed to the thread which created the thread. This can happen explicitly, with the main thread waiting for the child thread to finish, or in the background.

Lastly, we'll take a look at the randGen() method. Here we can see some multithreaded specific additions as well:

int randGen(const int& min, const int& max) {
static thread_local mt19937 generator(hash<thread::id>()(this_thread::get_id()));
uniform_int_distribution<int> distribution(min, max);
return distribution(generator)
}

This preceding method takes a minimum and maximum value as explained earlier, which limits the range of the random numbers this method can return. At its core, it uses a mt19937-based generator, which employs a 32-bit Mersenne Twister algorithm with a state size of 19937 bits. This is a common and appropriate choice for most applications.

Of note here is the use of the thread_local keyword. What this means is that even though it is defined as a static variable, its scope will be limited to the thread using it. Every thread will thus create its own generator instance, which is important when using the random number API in the STL.

A hash of the internal thread identifier is used as a seed for the generator. This ensures that each thread gets a fairly unique seed for its generator instance, allowing for better random number sequences.

Finally, we create a new uniform_int_distribution instance using the provided minimum and maximum limits, and use it together with the generator instance to generate the random number which we return.