Modern C++ on kenji.blog

Introduction to C++ Multithreading and Asynchronous Programming (std::async)

Sat, 12 Sep 2026 08:00:00 +0900

In modern software development, multithreading programming is essential to maximize the performance of multi-core CPUs. Starting with C++11, C++ introduced multithreading and asynchronous processing APIs (<thread>, <mutex>, <condition_variable>, <future>) as part of its standard library, making it possible to implement portable and safe concurrent processing without writing platform-dependent code (such as POSIX threads or the Windows API). Furthermore, with each version upgrade—C++14, C++17, and C++20—safer and more advanced features like std::scoped_lock and std::jthread have been added.

In this article, we will thoroughly explain the basics of C++ multithreading programming, synchronization mechanisms to prevent data races, and modern asynchronous processing (std::async) as well as the concept of thread pools, with detailed code examples.

1. Basics of Concurrency and Amdahl’s Law

The primary goal of multithreading is “performance improvement”, but it is not possible to parallelize an entire program. This is where Amdahl’s Law becomes important.

Amdahl’s Law is a model used to predict the extent to which overall system performance will improve when a part of the program is parallelized and optimized.

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

$S(N)$ : Theoretical maximum speedup ratio
$P$ : The proportion of the program that can be parallelized (0 ≤ $P$ ≤ 1)
$N$ : The number of processors (threads)

An important fact indicated by this formula is that “no matter how much you increase the number of processors $N$, the non-parallelizable serial portion $(1 - P)$ becomes a bottleneck, and there is an upper limit to the speedup”. For example, even if $90\%$ of the program can be parallelized ($P = 0.9$), as long as the remaining $10\%$ is processed serially, the maximum speedup will be only $10$ times ($S(\infty) = 1 / 0.1$), even with an infinite number of processors.

Therefore, when doing multithreaded programming in C++, it is required not just to increase the number of threads, but to adopt a design that minimizes the serial processing parts (such as lock contention and synchronization overhead) as much as possible.

2. Thread Basics: `std::thread` and `std::jthread` (C++20)

The Traditional `std::thread` (C++11)

std::thread, introduced in C++11, is the most fundamental class for executing functions or lambda expressions in a new thread.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <thread>

void workerFunction(int id) {
 std::cout << "Worker " << id << " is running on thread "
 << std::this_thread::get_id() << std::endl;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // Create and start the thread
 std::thread t1(workerFunction, 1);

 // Create a thread using a lambda expression
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // Wait for the thread to finish (join)
 t1.join();
 t2.join();

 std::cout << "All threads completed." << std::endl;
 return 0;
}

A point to note about std::thread is that you must always call either join() or detach() before it is destroyed. If the destructor of std::thread is called without either of them having been invoked, std::terminate() is called and the program crashes. To ensure exception safety, it was necessary to create your own wrapper class using the RAII pattern.

The Modern `std::jthread` (C++20)

In C++20, std::jthread (joining thread) was introduced to resolve these shortcomings. Because std::jthread automatically calls join() in its destructor, you can safely wait for the thread to terminate even when exceptions occur. It also provides a cooperative cancellation feature for threads via std::stop_token.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <iostream>
#include <thread>
#include <chrono>

int main() {
 // C++20: std::jthread
 // Can detect cancellation requests by receiving std::stop_token as the first argument
 std::jthread jt([](std::stop_token stoken) {
 while (!stoken.stop_requested()) {
 std::cout << "Working..." << std::endl;
 std::this_thread::sleep_for(std::chrono::milliseconds(500));
 }
 std::cout << "Stop requested. Exiting thread." << std::endl;
 });

 std::this_thread::sleep_for(std::chrono::seconds(2));

 // Explicitly request cancellation
 jt.request_stop();

 // Since join is automatically called by the jthread destructor, manual join() is unnecessary
 return 0;
}

3. Avoiding Data Races and Synchronization: Mutexes and Locks

When multiple threads access the same memory area (such as a variable) simultaneously, and at least one of them writes to it, a Data Race occurs. In the C++ standard, a data race causes Undefined Behavior. To prevent this, exclusive control using std::mutex is required.

`std::mutex` and `std::lock_guard`

Calling raw std::mutex::lock() and unlock() manually is not recommended because if an exception is thrown, unlock() may not be called, risking a deadlock. In C++, std::lock_guard (C++11) or std::scoped_lock (C++17), which use the RAII pattern, are used.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <iostream>
#include <vector>
#include <thread>
#include <mutex>

std::mutex g_mutex;
int g_counter = 0;

void incrementCounter(int iterations) {
 for (int i = 0; i < iterations; ++i) {
 // Automatically unlocked when leaving the scope
 std::lock_guard<std::mutex> lock(g_mutex);
 ++g_counter;
 }
}

int main() {
 std::vector<std::thread> threads;
 for (int i = 0; i < 10; ++i) {
 threads.emplace_back(incrementCounter, 10000);
 }

 for (auto& t : threads) {
 t.join();
 }

 std::cout << "Final counter value: " << g_counter << std::endl;
 // Becomes 100000 as expected
 return 0;
}

`std::unique_lock`

std::lock_guard is a simple scope-based lock, but if you need more flexible control (such as deferred locking, time-constrained locking, or unlocking mid-way), you use std::unique_lock. std::unique_lock is required for the std::condition_variable explained next.

4. Inter-thread Communication: `std::condition_variable`

To implement patterns such as the “Producer-Consumer Pattern”, where one thread waits until a specific condition is met, and another thread sends a notification when that condition is fulfilled, you use std::condition_variable.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

std::mutex g_mtx;
std::condition_variable g_cv;
std::queue<int> g_dataQueue;
bool g_isFinished = false;

void producer() {
 for (int i = 1; i <= 5; ++i) {
 std::this_thread::sleep_for(std::chrono::milliseconds(200));
 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_dataQueue.push(i);
 std::cout << "Produced: " << i << std::endl;
 }
 g_cv.notify_one(); // Notify consumer
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // Notify completion
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // Wait until the condition is met (queue is not empty, or finished flag is set)
 // Specify the condition with a lambda expression to prevent spurious wakeups
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // Unlock and perform heavy processing (here, just output)
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // Acquire lock again
 }

 if (g_isFinished && g_dataQueue.empty()) {
 break;
 }
 }
}

int main() {
 std::thread t1(producer);
 std::thread t2(consumer);
 t1.join();
 t2.join();
 return 0;
}

In this example, std::condition_variable::wait puts the thread to sleep until the condition is met, preventing unnecessary consumption of CPU resources (busy waiting).

5. High-level Asynchronous Processing: `std::future`, `std::promise`, `std::async`

The std::thread and std::mutex introduced so far are powerful, but they bring the OS’s low-level thread mechanisms directly into C++, which often leads to verbose code when handling result retrieval and exception propagation. If you want to perform concurrent processing that returns a value or higher-level asynchronous processing, you use the features of the <future> header.

`std::promise` and `std::future`

std::promise represents the side that “sets” the result, and std::future represents the side that “receives” the result. These function as safe channels for passing results and exceptions between threads.

Task-based Concurrency with `std::async`

The most recommended way to execute asynchronous tasks in C++ is to use std::async. std::async executes a task asynchronously and returns a std::future to retrieve the result.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#include <iostream>
#include <future>
#include <chrono>

int complexCalculation(int x) {
 std::cout << "Calculation started on thread: "
 << std::this_thread::get_id() << std::endl;
 std::this_thread::sleep_for(std::chrono::seconds(2));
 if (x < 0) {
 throw std::invalid_argument("x must be positive");
 }
 return x * 42;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // Explicitly run in a separate thread by specifying std::launch::async
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

 std::cout << "Main thread is doing other work..." << std::endl;

 try {
 // Calling get() blocks the current thread and waits until the calculation is complete
 int result = resultFuture.get();
 std::cout << "Result: " << result << std::endl;
 } catch (const std::exception& e) {
 std::cerr << "Exception caught: " << e.what() << std::endl;
 }

 return 0;
}

The behavior of std::async is shown in the sequence diagram below.

sequenceDiagram participant Main as "Main Thread" participant Async as "std::async Worker" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "Do other work..." Main->>Async: "future.get() (Blocks until ready)" Note right of Async: "Computations..." Async-->>Main: "Return Result or Throw Exception" deactivate Async

There are two types of Launch Policies for the first argument of std::async:

std::launch::async: Always creates a new thread (or allocates from a thread pool) and executes asynchronously.
std::launch::deferred: Lazy evaluation. Executes synchronously on the calling thread when future.get() or future.wait() is called.

The default (if not specified) is implementation-defined, and either one is chosen depending on the system load. If you definitely want asynchronous execution, explicitly specify std::launch::async.

6. Concept of a Thread Pool

Calling std::async every time, or creating and destroying a std::thread in a loop, causes the overhead of thread context switching and OS resource allocation to become non-negligible. Especially when processing a large number of fine-grained tasks, using a Thread Pool is essential.

A thread pool is an architecture where a certain number of worker threads are created in advance when the application starts, tasks are queued up, and available worker threads process the tasks one by one.

The C++ standard library (as of C++23) does not have a standard thread pool class, but it is possible to implement an efficient thread pool in a few dozen lines by combining std::thread, std::mutex, std::condition_variable, std::function, and std::packaged_task. In actual operations, it is also common to use Boost.Asio’s asynchronous I/O or third-party libraries.

7. Considerations for Performance and Scalability

To extract the maximum performance in multithreaded programming, it is necessary to pay attention not only to the parallelization of the code but also to the hardware architecture.

False Sharing: Even if multiple threads update different variables, if those variables are placed in the same CPU cache line (typically 64 bytes), unnecessary memory synchronization occurs to maintain cache coherency, resulting in a dramatic drop in performance. To prevent this, it is necessary to align variables on cache line boundaries using the alignas specifier.
Lock-Free and std::atomic: To avoid the overhead of locking/unlocking mutexes, introducing atomic operations (like Compare-And-Swap) using <atomic> or lock-free data structures is considered. However, this requires a correct understanding of memory ordering (std::memory_order) and is very difficult to implement. Therefore, it is usually introduced only when deemed necessary after careful performance measurements.

8. Conclusion

We have explained multithreading and asynchronous programming in C++, from the basics to the latest C++20 features. The key points are as follows:

Basically use std::async: For single asynchronous tasks or concurrent processing that returns a result, utilize std::async and std::future, which are safer than managing threads manually.
Use std::jthread for thread management: For threads running in the background long-term, use C++20’s std::jthread to guarantee safe termination processing.
Leverage RAII for synchronization: Always use std::lock_guard or std::unique_lock for locking mutexes to prevent data races.
Be aware of overhead: Avoid creating an excessive number of threads, and introduce a thread pool architecture as needed.

Concurrency bugs (deadlocks, data races) have low reproducibility and fall into the most difficult category to debug. By always being aware of thread safety and choosing appropriate standard library tools, let’s achieve robust and fast system development with modern C++.

How to Prevent Memory Leaks: A Guide to Smart Pointers (std::unique_ptr / shared_ptr)

Sat, 12 Sep 2026 07:00:00 +0900

Memory management in C++ has been one of the biggest challenges for developers for many years. The traditional memory management style relying on manual new and delete has been a hotbed for serious bugs such as memory leaks, dangling pointers, and double frees. However, with the advent of Modern C++ (C++11 and later), the situation has changed dramatically. At the core of this change are “Smart Pointers”.

In this article, we will provide an extremely detailed explanation of the mechanisms and advanced usage of std::unique_ptr, std::shared_ptr, and std::weak_ptr—powerful tools for eradicating memory leaks and achieving safe and efficient resource management. We will cover their internal implementation (control blocks and atomic operations), performance impact, and the mathematical formulation of reference counting.

1. Introduction: The Dark Age of C++ Memory Management and the Dawn of Modern C++

In past C++ development, developers themselves were responsible for freeing memory allocated on the heap.

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... some processing ...
 if (some_condition) {
 return; // Memory leak! delete is not called
 }
 delete ptr;
}

In code like the above, if an exception occurs or an early return is executed, delete is skipped, resulting in a memory leak. The paradigm to prevent this is “RAII (Resource Acquisition Is Initialization)”. RAII is a technique that ties resource allocation to object initialization (constructor) and resource deallocation to object destruction (destructor). Smart pointers are a class stack in the standard library that applies this RAII idiom to memory management.

2. `std::unique_ptr`: Zero-Overhead Exclusive Ownership

std::unique_ptr is a smart pointer that has “Exclusive Ownership” over a dynamically allocated object. There can always be only one unique_ptr that owns a given resource.

2.1 The Principle of Zero Overhead

The biggest appeal of std::unique_ptr is its performance. In its default state without a custom deleter, the size of a std::unique_ptr is exactly the same as a raw pointer. It has no unnecessary member variables and uses no virtual functions. Through compiler optimization, access via std::unique_ptr expands to assembly code equivalent to that of a raw pointer.

2.2 Transferring Ownership and `std::move`

Because it has exclusive ownership, a std::unique_ptr cannot be copied (its copy constructor and copy assignment operator are deleted). To transfer ownership to another unique_ptr, you must use std::move to utilize Move Semantics.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <memory>

class Resource {
public:
 Resource() { std::cout << "Resource acquired\n"; }
 ~Resource() { std::cout << "Resource destroyed\n"; }
 void do_something() { std::cout << "Doing something\n"; }
};

void process_resource(std::unique_ptr<Resource> ptr) {
 ptr->do_something();
 // When leaving scope, ptr is destroyed and Resource is also freed
}

int main() {
 std::unique_ptr<Resource> my_ptr = std::make_unique<Resource>();

 // process_resource(my_ptr); // Error: cannot copy
 process_resource(std::move(my_ptr)); // Transfer ownership

 if (!my_ptr) {
 std::cout << "my_ptr is now empty.\n";
 }
 return 0;
}

The Mermaid diagram below illustrates the concept of transferring ownership using std::move.

2.3 Implementing Custom Deleters

When wrapping legacy C APIs (such as FILE* or sockets), you need to call a function other than delete (such as fclose) to free memory. std::unique_ptr allows you to specify a custom deleter as its second template argument.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <cstdio>
#include <memory>

// Functor for custom deleter
struct FileDeleter {
 void operator()(FILE* fp) const {
 if (fp) {
 std::cout << "Closing file.\n";
 std::fclose(fp);
 }
 }
};

using UniqueFile = std::unique_ptr<FILE, FileDeleter>;

int main() {
 UniqueFile file(std::fopen("test.txt", "w"));
 if (file) {
 std::fputs("Hello, Smart Pointers!", file.get());
 }
 // FileDeleter is called and fclose is executed at the end of the scope
 return 0;
}

Using a function pointer or a lambda expression as a custom deleter may increase the size of the unique_ptr. However, if you use a stateless function object (Functor) as shown above, C++’s EBCO (Empty Base Class Optimization) or C++20’s [[no_unique_address]] ensures the size does not increase compared to a raw pointer (maintaining zero overhead).

3. `std::shared_ptr`: Shared Ownership and the Control Block

std::shared_ptr is a smart pointer for multiple pointers to share ownership of the same object. When the last shared_ptr is destroyed, the managed object is freed.

3.1 Internal Architecture: Control Block

Apart from the pointer to the managed object, std::shared_ptr allocates and shares metadata called a Control Block on the heap. The control block contains the following information:

Strong Count: The number of shared_ptrs that own the object. When this reaches 0, the object is destroyed.
Weak Count: The number of weak_ptrs monitoring the object. When both the Strong Count and Weak Count reach 0, the control block itself is freed.
Custom Deleter and Allocator (if specified).

Because of this, the size of a std::shared_ptr object itself is usually twice that of a raw pointer (a pointer to the object and a pointer to the control block).

3.2 Performance and Atomic Operations

The reference counts within the control block are implemented as Atomic Operations so they can safely increase and decrease even in multi-threaded environments.

On x86/x64 architectures, atomic instructions like lock xadd are used to increment and decrement reference counts. This carries an overhead of several dozen cycles compared to normal integer addition. Therefore, if you pass a shared_ptr to a function by value, atomic increments and decrements occur with each copy, degrading performance.

Best Practice: When passing a shared_ptr to a function, unless you need to share ownership, you should pass it as const std::shared_ptr<T>& (const reference) or pass a raw pointer/reference.

3.3 `std::make_shared` vs `new`

When creating a shared_ptr, you should use std::make_shared whenever possible. There are two major reasons for this.

Memory Allocation Optimization: Using new results in two heap allocations: one for the object itself and one for the control block. Using std::make_shared allows you to secure a single large memory block containing both in one heap allocation, which also improves cache efficiency.
Exception Safety: In standards prior to C++17, the evaluation order of function arguments was unspecified, so if an exception occurred during the evaluation of other arguments before passing the pointer allocated by new to the shared_ptr constructor, there was a risk of a memory leak. make_shared completely avoids this problem.

1
2
3
4
5


// Bad practice (2 memory allocations)
std::shared_ptr<MyClass> ptr1(new MyClass());

// Recommended practice (1 memory allocation)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: Resolving and Monitoring Circular References

Shared ownership has a fatal weakness called “Circular References”. If Object A and Object B point to each other with shared_ptrs, their respective Strong Counts are maintained at a minimum of 1 and will never reach 0 until the program terminates, resulting in a memory leak.

graph TD subgraph "Circular Reference (Memory Leak)" A["Object A"] -->|"shared_ptr (Strong=1)"| B["Object B"] B -->|"shared_ptr (Strong=1)"| A end

4.1 Breaking Cycles with `std::weak_ptr`

std::weak_ptr solves this problem. A weak_ptr is created from a shared_ptr and references the object, but it does not increase the Strong Count. Instead, it increases the Weak Count. This allows you to “monitor” an object without possessing ownership.

graph TD subgraph "Breaking Circular Reference" C["Object A"] -->|"shared_ptr (Strong=1)"| D["Object B"] D -.->|"weak_ptr (Weak=1)"| C end

4.2 Safe Access Using the `lock()` Method

A weak_ptr does not have operators (-> or *) to access the object directly. This is because the target object might have already been destroyed. To access it safely, call the lock() method to temporarily obtain a shared_ptr.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#include <memory>

class Node {
public:
 std::string name;
 std::shared_ptr<Node> next;
 std::weak_ptr<Node> prev; // Use weak_ptr to prevent circular references

 Node(const std::string& n) : name(n) { std::cout << "Created " << name << "\n"; }
 ~Node() { std::cout << "Destroyed " << name << "\n"; }
};

int main() {
 auto nodeA = std::make_shared<Node>("A");
 auto nodeB = std::make_shared<Node>("B");

 nodeA->next = nodeB;
 nodeB->prev = nodeA;

 // Get a shared_ptr from weak_ptr to access it
 if (auto locked_prev = nodeB->prev.lock()) {
 std::cout << "Node B's prev is " << locked_prev->name << "\n";
 } else {
 std::cout << "Node B's prev is already destroyed.\n";
 }

 return 0; // nodeA and nodeB are properly destroyed
}

5. Constraints of Shared Ownership in Multi-Threaded Environments

The thread safety of shared_ptr is often misunderstood. “Updating the reference count within the control block is thread-safe”, but “reading and writing the shared_ptr object itself is not thread-safe”.

Safe Operations: Multiple threads reading and writing their own respective shared_ptr instances (even though they share the same control block).
Data Race (Dangerous): Multiple threads simultaneously reading and writing the exact same shared_ptr instance.

If you need to share the same instance across multiple threads, you must use std::atomic<std::shared_ptr<T>> (C++20) or protect it with a mutex (std::mutex).

6. Mathematical Formulation of Reference Counting

Expressing the lifecycle state transitions in the control block mathematically yields the following. Let the Strong Count at time $t$ be $S(t)$ and the Weak Count be $W(t)$.

Initial state (immediately after make_shared):

$$ S(0) = 1, \quad W(0) = 0 $$

When a copy (duplication of shared_ptr) occurs:

$$ S(t_{next}) = S(t) + 1 $$

Condition for the Managed Object to be destroyed:

$$ \lim_{t \to t_d} S(t) = 0 $$

Condition for the Control Block itself to be freed from memory:

$$ S(t) = 0 \quad \land \quad W(t) = 0 $$

In other words,

$$ S(t) + W(t) = 0 $$

As these formulas show, as long as a weak_ptr continues to exist ($W(t) > 0$), the small memory space for the control block will remain allocated even if the managed object has been destroyed. This is the only drawback of make_shared (because the managed object’s memory and the control block are unified, if a weak reference remains, the large memory space for the managed object is also not returned to the system). However, usually, the performance advantages of make_shared overwhelmingly outweigh this.

7. Conclusion

Memory management in Modern C++ is no longer about managing new/delete manually.

Always use std::unique_ptr by default, taking advantage of zero overhead while incorporating clear ownership into your design.
Use std::shared_ptr only when you truly need to share lifecycle ownership among multiple owners, and use std::make_shared to create it.
For implementing data structures or observer patterns where rings of sharing (circular references) may occur, utilize std::weak_ptr to proactively prevent memory leaks.

By deeply understanding smart pointers and using them in the right places, it is possible to build safe and robust software architectures without sacrificing C++’s performance in any way.

Modern C++ on kenji.blog

Introduction to C++ Multithreading and Asynchronous Programming (std::async)

1. Basics of Concurrency and Amdahl’s Law

2. Thread Basics: std::thread and std::jthread (C++20)

The Traditional std::thread (C++11)

The Modern std::jthread (C++20)

3. Avoiding Data Races and Synchronization: Mutexes and Locks

std::mutex and std::lock_guard

std::unique_lock

4. Inter-thread Communication: std::condition_variable

5. High-level Asynchronous Processing: std::future, std::promise, std::async

std::promise and std::future

Task-based Concurrency with std::async