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

A basic OpenCL application

A common example of a GPGPU application is one which calculates the Fast Fourier Transform (FFT). This algorithm is commonly used for audio processing and similar, allowing you to transform, for example, from the time domain to the frequency domain for analysis purposes.

What it does is apply a divide and conquer approach to a dataset, in order to calculate the DFT (Discrete Fourier Transform). It does this by splitting the input sequence into a fixed, small number of smaller subsequences, computing their DFT, and assembling these outputs in order to compose the final sequence.

This is fairly advanced mathematics, but suffice it to say that what makes it so ideal for GPGPU is that it's a highly-parallel algorithm, employing the subdivision of data in order to speed up the calculating of the DFT, as visualized in this graphic:

Each OpenCL application consists of at least two parts: the C++ code that sets up and configures the OpenCL instance, and the actual OpenCL code, also known as a kernel, such as this one based on the FFT demonstration example from Wikipedia:

// This kernel computes FFT of length 1024.  
// The 1024 length FFT is decomposed into calls to a radix 16 function,  
// another radix 16 function and then a radix 4 function
__kernel void fft1D_1024 (__global float2 *in, __global float2 *out, __local float *sMemx, __local float *sMemy) {
int tid = get_local_id(0);
int blockIdx = get_group_id(0) * 1024 + tid;
float2 data[16];

// starting index of data to/from global memory
in = in + blockIdx; out = out + blockIdx;

globalLoads(data, in, 64); // coalesced global reads
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 1024, 0);

// local shuffle using local memory
localShuffle(data, sMemx, sMemy, tid, (((tid & 15) * 65) + (tid >> 4)));
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 64, 4); // twiddle factor multiplication

localShuffle(data, sMemx, sMemy, tid, (((tid >> 4) * 64) + (tid & 15)));

// four radix-4 function calls
fftRadix4Pass(data); // radix-4 function number 1
fftRadix4Pass(data + 4); // radix-4 function number 2
fftRadix4Pass(data + 8); // radix-4 function number 3
fftRadix4Pass(data + 12); // radix-4 function number 4

// coalesced global writes
globalStores(data, out, 64);
}

This OpenCL kernel shows that, like the GLSL shader language, OpenCL's kernel language is essentially C with a number of extensions. Although one could use the OpenCL C++ kernel language, this one is only available since OpenCL 2.1 (2015), and as a result, support and examples for it are less common than the C kernel language.

Next is the C++ application, using which, we run the preceding OpenCL kernel:

#include <cstdio>
#include <ctime>
#include "CL\opencl.h"

#define NUM_ENTRIES 1024

int main() { // (int argc, const char * argv[]) {
const char* KernelSource = "fft1D_1024_kernel_src.cl";

As we can see here, there's only one header we have to include in order to gain access to the OpenCL functions. We also specify the name of the file that contains the source for our OpenCL kernel. Since each OpenCL device is likely a different architecture, the kernel is compiled for the target device when we load it:

          const cl_uint num = 1;
clGetDeviceIDs(0, CL_DEVICE_TYPE_GPU, 0, 0, (cl_uint*) num); cl_device_id devices[1];
clGetDeviceIDs(0, CL_DEVICE_TYPE_GPU, num, devices, 0);

Next, we have to obtain a list of OpenCL devices we can use, filtering it by GPUs:

    cl_context context = clCreateContextFromType(0, CL_DEVICE_TYPE_GPU,  
                                                   0, 0, 0); 

We then create an OpenCL context using the GPU devices we found. The context manages the resources on a range of devices:

    clGetDeviceIDs(0, CL_DEVICE_TYPE_DEFAULT, 1, devices, 0);
cl_command_queue queue = clCreateCommandQueue(context, devices[0], 0, 0);

Finally, we will create the command queue that will contain the commands to be executed on the OpenCL devices:

    cl_mem memobjs[] = { clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(float) * 2 * NUM_ENTRIES, 0, 0),              
   clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(float) * 2 * NUM_ENTRIES, 0, 0) }; 

In order to communicate with devices, we need to allocate buffer objects that will contain the data we will copy to their memory. Here, we will allocate two buffers, one to read and one to write:

    cl_program program = clCreateProgramWithSource(context, 1, (const char **)& KernelSource, 0, 0); 

We have now got the data on the device, but still need to load the kernel on it. For this, we will create a kernel using the OpenCL kernel source we looked at earlier, using the filename we defined earlier:

    clBuildProgram(program, 0, 0, 0, 0, 0); 

Next, we will compile the source as follows:

   cl_kernel kernel = clCreateKernel(program, "fft1D_1024", 0); 

Finally, we will create the actual kernel from the binary we created:

    size_t local_work_size[1] = { 256 };

clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *) &memobjs[0]);
clSetKernelArg(kernel, 1, sizeof(cl_mem), (void *) &memobjs[1]);
clSetKernelArg(kernel, 2, sizeof(float) * (local_work_size[0] + 1) * 16, 0);
clSetKernelArg(kernel, 3, sizeof(float) * (local_work_size[0] + 1) * 16, 0);

In order to pass arguments to our kernel, we have to set them here. Here, we will add pointers to our buffers and dimensions of the work size as follows:

    size_t global_work_size[1] = { 256 };
global_work_size[0] = NUM_ENTRIES;
local_work_size[0] = 64; // Nvidia: 192 or 256
clEnqueueNDRangeKernel(queue, kernel, 1, 0, global_work_size, local_work_size, 0, 0, 0);

Now we can set the work item dimensions and execute the kernel. Here, we will use a kernel execution method that allows us to define the size of the work group:

          cl_mem C = clCreateBuffer(context, CL_MEM_WRITE_ONLY, (size), 0, &ret);
cl_int ret = clEnqueueReadBuffer(queue, memobjs[1], CL_TRUE, 0, sizeof(float) * 2 * NUM_ENTRIES, C, 0, 0, 0);

After executing the kernel, we wish to read back the resulting information. For this, we tell OpenCL to copy the assigned write buffer we passed as a kernel argument into a newly assigned buffer. We are now free to use the data in this buffer as we see fit.

However, in this example, we will not use the data:

    clReleaseMemObject(memobjs[0]);
clReleaseMemObject(memobjs[1]); clReleaseCommandQueue(queue); clReleaseKernel(kernel); clReleaseProgram(program); clReleaseContext(context); free(C);
}

Finally, we free the resources we allocated and exit.