![\"Differently](\"https:\/\/www.microconsult.de\/blog\/wp-content\/uploads\/2020\/02\/C11MT_Bild1.png\")
<\/p>\nSince the introduction of C++11, the C++ standard library has also offered support for developing multithreaded applications. While using the C++ Multithread API simplifies the porting of such applications, it also means that developers are limited to the capabilities of the standard library if they want to benefit from its features. Therefore, not only when developing new applications, but also for existing applications that still rely on platform-specific multithreading solutions, the question arises whether it makes sense to use or migrate to this API.<\/p>\n
<\/p>\n
The design of the C++11 multithreaded standard library incorporated many elements from the widely used C++ Boost library and added further functionality. The library's implementation made extensive use of new C++11 language features, such as variadic templates, rvalue references, and lambda functions.<\/p>\n
A thread is represented by an instance of the `thread` class. When creating this instance, the code to be executed by the thread can be specified as a global function, an instance or class method, a functor, or a lambda function. The constructor creates a runtime thread that can execute the code immediately. The destructor of the `thread` class checks whether the associated runtime thread is still running and throws an exception if necessary. To prevent this, you can either wait for the thread to finish using the `join()` method or detach the runtime thread from the C++ `thread` object using the `detach()` method. The thread function to be executed can have any number of parameters of any type, which are always implicitly copied to ensure a sufficiently long lifetime (see Figure 1).<\/p>\n
<\/p>\n
\u00a0Figure 1: Three differently parameterized threads with identical thread function<\/em><\/p>\n Each thread has an ID of type `thread::id` for identification. Since the ID is platform-specific, the type supports only a few operations, such as `get_id()` as a method of the `thread` class and as a function of the `this_thread` namespace, as well as comparison operators. Other functions of the `this_thread` namespace include `sleep_for()` and `sleep_until()`, which allow a thread to sleep for a relative or absolute time, respectively, and `yield()`, which releases the remainder of a thread's time slice. Thread-local memory is also supported, but in a much more intuitive way than in Boost. Finally, the static method `hardware_concurrency()` returns the number of currently available hardware execution units (cores). However, this function can also return zero, so the value it returns should only be considered indicative.<\/p>\n To protect resources, the C++ Multithreaded API supports not only "normal" mutexes of type `mutex`, but also those that can be requested multiple times (non-blocking) by a thread (`recursive_mutex`), as well as those that return an error if the mutex cannot be requested within a certain time (`timed_mutex`, `recursive_timed_mutex`). With C++14, Boost's `shared_mutex` was also incorporated into the standard as `shared_timed_mutex` for multiple-reader\/single-writer applications. The classes `lock_guard`, `unique_lock`, and `shared_lock` (C++14) reliably prevent deadlock problems caused by missing mutex releases (see Figure 2).<\/p>\n Figure 2: Protected access to a shared resource using mutex and unique_lock<\/em><\/p>\n One of the biggest highlights of the C++ multithreaded library is atomics. With their help, standard data types such as int or float can be declared as atomic. The operations on a variable of type atomic (or atomic_int for C programs) are indivisible and therefore no longer need to be explicitly protected, e.g., by a mutex (Figure 3).<\/p>\n Figure 3: Safe incrementing of a variable with atomic<\/em><\/p>\n Furthermore, a new memory model was introduced, which allows classic multithreading problems caused by compiler or processor optimizations to be reliably solved using memory barriers and atomic variables. In addition, atomics, with their `compare_exchange` methods, create the prerequisites for lock-free programming. With the exception of the `atomic_flag` data type, the standard does not guarantee that the operations of an atomic data type are lock-free. However, this can be checked using the `is_lock_free()` method. In principle, it is even possible to define custom atomic data types.<\/p>\n Condition variables are available for event synchronization. Using the `wait` method of a condition variable, a thread can wait for a condition to be met. If another thread executes code that meets the condition, the `notify_one` method of the condition variable must be called after this code execution to wake the waiting thread. `notify_all` can even wake multiple waiting threads simultaneously. In any case, after returning from the wait state, a thread must re-check the condition, as the runtime system may wake the thread for other reasons as well.<\/p>\n Finally, the `call_once` function ensures that a function is only executed once, regardless of how often or by how many threads it is called. This is typically needed in the context of initializations.<\/p>\n The return value of a thread function that uses the C++ Multithreaded API cannot be used to deliver a result, as is the case with many other multithreading platforms. Instead, an object of type `future` must be used. It can be used to temporarily store the result if the receiving thread is not yet ready, or to block the receiving thread if the result is not yet available.<\/p>\n There are 3 different ways to use it:<\/p>\n The application variant with the lowest level of abstraction consists of a promise The process creates a Future object and makes it available to the thread. The thread then determines the result, which it passes to the Promise object using the `set_value()` method. The receiver obtains a Future object using the Promise object's `get_future()` method. After completing any necessary parallel operations, it can then access the result using the Future object's `get()` method, blocking if required until the result is available.<\/p>\n At the next higher level of abstraction, a `packaged_task` object is created and parameterized with a function that returns the result as a normal return value. The `get_future` method of the `Task` object then returns the corresponding `Future` object. To achieve concurrency, a thread must again be created and parameterized with the `Task` object. The result is passed as in the first solution.<\/p>\n At the highest level of abstraction, only the `async` function specifies the code of the function that returns the calculated result using a normal return value. Whether the function is executed asynchronously in its own thread or synchronously in the context of the thread requesting the result can be left to the runtime system or determined using a parameter. `async` returns the Future object directly as its return value (Figure 4).<\/p>\n Figure 4: Concurrent execution of a function with async and passing the result using future.<\/em><\/p>\n The result of a future The object can only be read once. If multiple threads require the same result, then `shared_future` must be used. -objects are worked on.<\/p>\n Unlike, for example, the POSIX\/Pthread standard, the C++ multithreaded API does not offer a direct way to assign different priorities to threads or to create mutexes with priority inheritance or ceiling priority. This is a significant limitation, especially for use in real-time systems. While it is possible to obtain the handle of the corresponding runtime thread using the `native_handle()` method of the `thread` class and to use this handle to set the thread's priority at the operating system level, this approach comes at the expense of portability and does not solve the problem of priority inversion.<\/p>\n Furthermore, there is no support for asynchronously interrupting or terminating a thread. While one should generally try to avoid these features due to their complexity, this is often difficult in practice. The POSIX\/Pthread standard offers good support in this area as well.<\/p>\n Other things that those familiar with other multithreading solutions might miss in the C++ Multithread API include, for example, general (counting) semaphores and efficient event flag mechanisms for signaling pure events where no data access needs to be synchronized.<\/p>\n When porting multithreaded applications, it's crucial to be aware that the scheduling mechanisms of different platforms can vary significantly in detail. This applies not only to the scheduler's thread allocation behavior but also, for example, to the fairness of synchronization objects. While some aspects might be too slow\u2014a particular problem for real-time systems\u2014a ported application should, in principle, function on any supported platform without modification. If this isn't the case, it's often because the design implicitly assumed certain characteristics of the original platform to be "always present.".<\/p>\n Sometimes, porting problems stem from the fact that the standard has been implemented differently by compiler vendors. Aside from actual implementation errors, this can also be due to the standard not specifying every detail. For example, if a mutex is released by a thread that doesn't actually possess the mutex, the response depends on the implementation. For instance, GCC 4.9.2 on Linux executes the operation, while Visual Studio 2015 on Windows throws an exception (Figure 5).<\/p>\n Figure 5: Different behavior of a C++11 program under Linux and Windows<\/em><\/p>\n Due to the rapidly increasing prevalence of multicore systems, it is particularly important for developers to know how to parallelize applications in order to benefit from the performance gains. The MicroConsult training C++ Multithreading<\/a><\/strong> This video demonstrates the multithreading capabilities of C++11 and C++14 and how to apply them. Register now!<\/p>\n This is what participants of the seminar expressed:\u201eC++ Multithreading<\/a>\u201c (Excerpt):<\/p>\n \u201eI\u2019m not one for effusive praise \u2013 but this course was fantastic!\u201c<\/em><\/p>\n \u201e"The facts were explained clearly and understandably, and the basics were introduced as needed."\u201c<\/em><\/p>\n \u201e"The training was great \u2013 you could follow along perfectly even without in-depth C++11 knowledge."\u201c<\/em><\/p>\n \u201e"I received many suggestions for my own projects and a comprehensive insight into innovations."\u201c<\/em><\/p>\n More participant responses<\/a><\/p>\n MicroConsult Training: C++ Multithreading\u00a0\u00a0\u00a0 <\/a><\/strong><\/p>\n MicroConsult Training & Coaching: Software quality<\/a><\/strong><\/p>\n MicroConsult Expertise: Software Quality<\/strong><\/a><\/p>\n MicroConsult Training & Coaching: Embedded Programming<\/strong><\/a><\/p>\n MicroConsult Expertise: Embedded Software Development<\/strong><\/a><\/p>\nEvent synchronization via condition variable<\/h4>\n
![\"Protected](\"https:\/\/www.microconsult.de\/blog\/wp-content\/uploads\/2020\/02\/C11MT_Bild2.png\")
<\/p>\n![\"Safely](\"https:\/\/www.microconsult.de\/blog\/wp-content\/uploads\/2020\/02\/C11MT_Bild3.png\")
<\/p>\nCaching with Futures<\/h4>\n
![\"Concurrent](\"https:\/\/www.microconsult.de\/blog\/wp-content\/uploads\/2020\/02\/C11MT_Bild4.png\")
<\/p>\nWhat does the standard not support?\u00a0<\/strong><\/h4>\n
Things to consider during the porting process<\/h4>\n
![\"Different](\"https:\/\/www.microconsult.de\/blog\/wp-content\/uploads\/2020\/02\/C11MT_Bild5.png\")
<\/p>\nFurther information<\/h3>\n