Practical Examples of C++ Concurrency

std::timed_mutex

Imagine another bathroom. But instead of waiting forever you can wait x time before getting bored and leave the place. When the timer is done and you haven't locked yet, you leave the queue for the toilet and continue your life, you don't longer care about that bathroom (lock), you just look other, or die if there's nothing else to do (literally).

std::recursive_mutex

Imagine yet another bathroom, but this has multiple stalls. If a person is in one stall and want to switch to other or use two at a time or more, they can because they have the key. The others waiting can do nothing but wait. Made for recursive functions and loops. Be sure to have a base case because otherwise you will

std::recursive_timed_mutex:

Adds timers to the recursive lock. If we wait for more than x seconds specified in the lock, we continue. It's a mechanism to avoid contention and waiting for too long. Like if a bathroom has a person we will wait until they all leave completely, unlocking all the stalls they used, if they don't leave and x time passes we move on and find elsewhere to go to the bathroom. Basically identically to the timed mutex syntax.

std::latch:

Synchronization primitive that acts as a one-use barrier for synchronizing multiple threads. It ensures that all threads reach a certain point in the code before proceeding.

Conceptually, it's a gate that remains closed until a specified number of threads have arrived at it. Once the required number of threads has arrived, the gate opens, allowing all threads to proceed simultaneously.

All threads will wait here until EVERY thread is here, like a checkpoint that ensures everyone is at the same place!

std::barrier

A std::barrier is a synchronization primitive introduced in C++20 that allows multiple threads to synchronize at a certain point in their execution. Basically a latch, but a std::barrier is reusable, meaning it can be reset (its internal counter) and used multiple times.

Barriers make all threads wait until the capacity of  the barrier is met, then the barrier open, but we can use it later down the code!

std::atomic:

Atomic is a type that multiple threads can write/read and the atomic doesn't care about multiple threads operating on them and  handles that operations cleanlily and ordered, avoiding data races and things like that. We can use it with fundamental data types or use an atomic_ref for any type. This atomicity incurs an overhead though. Useful for synchronization and shared resources.

std::thread:

However, it's crucial to manage the lifecycle of std::thread objects properly. When you create a std::thread, you should ensure that you join it or detach it before it goes out of scope. Failing to do so can lead to resource leaks or undefined behavior. Typically, you use std::join to wait for a thread to finish its execution before proceeding with the rest of the program. However, this is the old approach...

std::jthread:

Introduced in C++20, std::jthread is a smarter and safer alternative to std::thread. Unlike std::thread, which requires manual management of its lifecycle with joins; std::jthread automatically joins itself when it goes out of scope. This automatic joining behavior eliminates the need for explicit calls to std::join, making code cleaner and less error-prone. With std::jthread, you won't have to worry about forgetting to join your threads with for loops or dealing with potential resource leaks. It's a modern and preferred choice for writing multithreaded code in C++, providing a simpler and safer experience. jthread stands for joining thread.

std::stop_token, std::stop_source, std::stop_callback:

Collaborative stopping mechanism for threads, allowing for graceful termination and cleanup of thread execution. When a thread is associated with a std::stop_token, it becomes responsive to requests for termination signaled by a corresponding std::stop_source. The source signals to its token, and the thread has the token, so it will obey its token, and by extension the source. This is actually pretty damn useful.

A std::stop_token serves as a handle for receiving source requests. When a stop request is issued, the associated tokens are notified and given the associated threads are given opportunity to halt its operations in a safe manner.

A std::stop_source acts as a signaler, allowing external entities to request the killing of a thread's execution by invoking stop_token requests.

Additionally, std::stop_callback provides a mechanism for registering callback functions to be executed upon the receipt of a stop request. std::stop_callback will be called for cleanup or whatever you want to do with it. It's basically a delegate, a witness to the thread's murder.

std::counting_semaphore:

A std::semaphore is a synchronization primitive, like a bathroom with limited capacity. The parameter <x> represents the maximum capacity of the semaphore, indicating the maximum number of entities (threads, for example) that can access a shared resource simultaneously.

x and why are normally the same value, because it would not make a lot of sense having a house where 3 can enter but only one at a time can do, or does it makes sense?

For instance, a binary semaphore (std::semaphore<1>) allows only one entity to access the resource at a time, mimicking the behavior of a single-stall bathroom where occupancy is restricted to one person (binary semaphore). 

std::binary_semaphore is a typedef introduced  for std::semaphore<1>. It is a synchronization primitive similar to a semaphore but with a capacity of 1. In other words, it allows only one entity (such as a thread) to access a shared resource at a time.

Similarly to a mutex, a binary semaphore can be used to protect critical sections of code or shared resources from concurrent access. However, compared to a mutex, a binary semaphore provides additional functionality such as signaling and waiting, making it suitable for more complex synchronization scenarios.

For example, in a producer-consumer scenario, a binary semaphore can be used to control access to a shared buffer. The producer signals the semaphore when it adds data to the buffer, and the consumer waits for the semaphore to be signaled before accessing the buffer. This ensures that the producer and consumer do not access the buffer simultaneously.

#include <iostream>
#include <thread>
#include <semaphore>

#define SIMUL_WORK std::this_thread::sleep_for(std::chrono::milliseconds(1000))

// An empty bathroom, ready for 1 to enter and produce.
std::binary_semaphore producer{ 1 };
// A full bathroom (0 can enter), when 1 releases, 1 can enter.
// Someone must produce first, and release the bathroom for the consumer.
std::binary_semaphore consumer{ 0 };

[[noreturn]] void produce() {
for (int i = 0; i < 5; ++i) {
// We enter the producer bathroom, no one can enter.
::producer.acquire();
SIMUL_WORK;
std::cout << "Produced\n";
// We leave the consumer bathroom, so 1 can enter.
::consumer.release();
}
}

[[noreturn]] void consume() {
for (int i = 0; i < 5; ++i) {
// We enter the consumer bathroom, no one can enter.
::consumer.acquire();
// Simulate consumption time
SIMUL_WORK;
std::cout << "Consumed\n";
// We leave the producer bathroom, so 1 can enter.
::producer.release();
}
}

int main() {
std::jthread t1(::produce);
std::jthread t2(::consume);
// We loop forever, so we can see the threads working.
// One thread enters the bathroom, produces, leaves the other:
// letting the other enter the other bathroom and consume.
// When consumed, it leaves the other bathroom,
// letting the other enter the other bathroom and produce...
// We could sprinkle some mutexes to make sure the threads are
// not stepping on each other, but we don't need to here.
}

std::atomic_flag:

std::atomic_flag  provides atomic operations on a boolean value. Unlike std::atomic<bool>, std::atomic_flag has less functionality but is more lightweight and suitable for simple atomic operations.

One of the primary uses of std::atomic_flag is for implementing spin locks, where threads repeatedly check the state of the flag until it changes. This makes std::atomic_flag ideal for scenarios where you need lightweight synchronization without the overhead of a mutex or a condition variable.

It's worth noting that for more complex synchronization scenarios or when additional functionality is required, std::condition_variable may be a better choice. std::condition_variable allows threads to wait efficiently for a condition to become true, providing more flexibility and options for signaling between threads.

void reader(int id) {
while (true) {
// Lock shared access (multiple readers allowed)
std::shared_lock<std::shared_mutex> lock(rw_mutex);
std::cout << "Reader " << id << " read shared data: " << shared_data;

// Simulate reading
std::this_thread::sleep_for(std::chrono::milliseconds(100));
}
}

void writer(int id) {
while (true) {
// Lock exclusive access (only one writer allowed). Writer cannot enter if there's readers and vice versa.
std::unique_lock<std::shared_mutex> lock(rw_mutex);
// Increment shared data
shared_data++;
std::cout << "Writer " << id << " incremented shared data to: " << shared_data;

// Simulate writing
std::this_thread::sleep_for(std::chrono::milliseconds(200));
}
}

int main() {
// Create reader threads
std::thread readers[6];
for (int i = 0; i < 6; ++i) {
readers[i] = std::thread(reader, i);
}

// Create writer thread
std::thread writerThread(writer, 1);

// Join threads
for (int i = 0; i < 6; ++i) {
readers[i].join();
}
writerThread.join();

return 0;
}

std::once_flag and std::call_once:

These are useful functions to ensure that a specific function is executed only once, regardless of how many times it is called from different threads or contexts.

std::once_flag serves as a synchronization flag to coordinate the execution of a function across multiple threads. It ensures that the function associated with it is called exactly once, even in the presence of concurrent access.

std::call_once is the function used in conjunction with std::once_flag to achieve this behavior. It takes a reference to a std::once_flag and a callable object (usually a function or a lambda expression) as arguments. The first time std::call_once is called with a particular std::once_flag, it executes the associated function, and subsequent calls to std::call_once with the same std::once_flag are ignored.