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

Tracing the demo application

In the demonstration code of Chapter 1, Revisiting Multithreading, we looked at a simple c++11 application which used four threads to perform some processing. In this section, we will look at the same application, but from a hardware and OS perspective.

When we look at the start of the code in the main function, we see that we create a data structure containing a single (integer) value:

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

After the OS creates a new task and associated stack structure, an instance of a vector data structure (customized for integer types) is allocated on the stack. The size of this was specified in the binary file's global data section (BSS for ELF).

When the application's execution is started using its entry function (main() by default), the data structure is modified to contain the new integer value.

Next, we create four threads, providing each with some initial data:

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

For the OS, this means creating new data structures, and allocating a stack for each new thread. For the hardware, this initially does not change anything if no hardware-based task switching is used.

At this point, the OS's scheduler and the CPU can combine to execute this set of tasks (threads) as efficiently and quickly as possible, employing features of the hardware including SMP, SMT, and so on.

After this, the main thread waits until the other threads stop executing:

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

These are blocking calls, which mark the main thread as being blocked until these four threads (tasks) finish executing. At this point, the OS's scheduler will resume execution of the main thread.

In each newly created thread, we first output a string on the standard output, making sure that we lock the mutex to ensure synchronous access:

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

A mutex, in essence, is a singular value being stored on the stack of heap, which then is accessed using an atomic operation. This means that some form of hardware support is required. Using this, a task can check whether it is allowed to proceed yet, or has to wait and try again.

In this last particular piece of code, this mutex lock allows us to output on the standard C++ output stream without other threads interfering.

After this, we copy the initial value in the vector to a local variable, again ensuring that it's done synchronously:

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

The same thing happens here, except now the mutex lock allows us to read the first value in the vector without risking another thread accessing or even changing it while we use it.

This is followed by the generating of a random number as follows:

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

This uses the randGen() method, which is as follows:

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 method is interesting due to its use of a thread-local variable. Thread-local storage is a section of a thread's memory which is specific to it, and used for global variables, which, nevertheless, have to remain limited to that specific thread.

This is very useful for a static variable like the one used here. That the generator instance is static is because we do not want to reinitialize it every single time we use this method, yet we do not want to share this instance across all threads. By using a thread-local, static instance, we can accomplish both goals. A static instance is created and used, but separately for each thread.

The Thread function then ends with the same series of mutexes being locked, and the new value being copied to the array.

    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();
}

Here we see the same synchronous access to the standard output stream, followed by synchronous access to the values data structure.