#include <condition_variable> is a synchronization object used for inter-thread notification. Note that two additional shared variables need to be used alongside a condition variable to achieve thread-to-thread notification, a mutex and a boolean (a.k.a a condition flag).
Run this code at http://cpp.sh/7es7i.
The program above should print:
main() called. Waiting for notification... Notification received.
On entry, the
wait() method simultaneously unlocks the mutex and waits for the condition. On exit, the
wait() method relocks the mutex.
How To Improve A Condition Variable (a.k.a let’s create a semaphore!)
In my eyes, a raw
std::condition_variable is a very awkward object to use throughout your code. If you are using it for inter-thread notifications, for each
std::condition_variable you also need one
std::mutex and one
bool. And don’t forget to use/set everything in the correct manner! One way to improve on this is to wrap everything in a custom object which is commonly called a semaphore. The code below shows a header-only implementation of a Semaphore class.
Now, all we have to do is:
So much easier! Right? This code can also be found in the CppUtils repo on GitHub.
Note: If you want to do more than just send notifications between threads, and actually send data, have a look at either implementing a queue or using a future/promise instead.
Locks are C++ objects which provide safety and convenience when locking and unlock mutexes (you could call them mutex wrappers). The two main locks available in C++ are
std::lock_guard, both from
std::unique_lock can be instructed to take ownership of a mutex. It will either release the mutex when it is manually unlocked (e.g. via
unlock()) or when it goes out of scope and gets destroyed.
std::unique_lock is created, you can instruct it to not lock the mutex by deferring:
lock_guard tries to take ownership of a mutex when it is created. When control leaves the scope that lock_guard was created in,
lock_guard is destroyed and the mutex is released.
Unique Locks vs. Lock Guards
Recommendation: Use a
lock_guard unless you need to manually release the mutex without having to rely on a
lock_guard going out of scope.
std::mutex, which is designed to be used as a basic synchronization object in a multi-threaded application.
Using The mutable Keyword
One issue that can arise with a std::mutex is when using it in conjunction with methods that are defined const. Consider the method below:
What happens when you want to call
GetCount() from multiple threads? You may reach into your concurrency toolbox at pull out a
The problem with this is that locking a mutex is not a const operation, and the above code won’t compile. A solution is to declare
mutex_ as mutable:
This is one of the few use cases were the
mutable keyword should be used.
std::thread has been in the C++ language since C++11. It’s introduction standardized the way threads are used in C++, as before this time platform-specific implementations were the only option (e.g.
pthread for POSIX systems).
A Basic Example
The thread begins execution as soon as the object is created (there is no
Different Methods Of Assigning Thread Function
The below code shows the many ways you can create a std::thread and assign it a function (or method) to run.
Unfortunately, as of C++14, there is not standardized way of setting/modifying thread priorities. If you are used to using a low-level OS such as FreeRTOS you may be surprised that this functionality is not included. But this should not come as a surprise if you consider the history of the C/C++ standards. For such a long time both considered threading to be a implementation specific issue that should not handled by the standard. It was only starting with C++11 that the standard introduced the concept of a
std::thread, eliminating the need for platform specific code for creating basic threads.
However, it’s not all bad news! You can still manage thread priorities for common operating systems such as Linux and Windows via the use of
thread.native_handle(). This function hopefully returns a pointer to the native thread object, (e.g. a pthread in Linux) which can be then used with OS-specific API to set the priority.
The following code shows how to set the priority for a
std::thread running on a Linux OS:
terminate called without an active exception
This runtime error usually occurs when your program tries to end while there are still threads running.
You will usually see the following terminal output:
You can fix this by making sure you call
join() for all threads created by the program.
Actor Model Implementation
When dealing with a multi-threaded design, concurrency issues arise. One way to deal with this is to use an Actor model, where each thread waits for incoming commands that arrive on a command queue.
The below example uses a
std::shared_ptr<void> as the data type. This is to allow a different data type to be passed for each command (or no data at all). The neat thing about this is that data can be cast to this type and passed on the queue, and will still be destroyed safely when there are no more references to it. The disadvantage to this approach is that you must remember and cast back to the appropriate data type for each different command.
This code can be found and run online at https://wandbox.org/permlink/KkL4A89Z60GJdva3.
Note that the above code uses a
ThreadSafeQueue class, which is not part of
std, nor included in the above code. This class implements a thread safe queue. You can find code for this at https://github.com/gbmhunter/CppUtils/blob/master/include/CppUtils/ThreadSafeQueue.hpp.
Futures And Promises
std::promise objects allow a thread to wait for data to be returned from process occurring another thread.
The Volatile Keyword
This statement is from Microsoft’s Common Visual C++ ARM Migration Issues page:
Although volatile gains some properties that can be used to implement limited forms of inter-thread communication on x86 and x64, these additional properties are not sufficient to implement inter-thread communication in general. The C++ standard recommends that such communication be implemented by using appropriate synchronization primitives instead.
ARM’s “weak” memory model doesn’t support the strong ordering that the x86 and x64 architectures support.
This work is licensed under a Creative Commons Attribution 4.0 International License .