A tutorial on modern multithreading and concurrency in C++

Modern C++20 concurrency features#

C++ has supported multithreading since C++11 through tools like std::thread, mutexes, condition variables, and atomic operations. These features remain essential, but they often require careful resource management and can be difficult to use correctly in large applications.

C++20 expands the concurrency toolkit with safer and more expressive abstractions. New features such as std::jthread, coroutines, std::latch, and std::barrier make it easier to manage thread lifecycles, coordinate work between threads, and write asynchronous code.

Rather than replacing existing concurrency primitives, these features build on them and address common pain points developers have faced for years.

If you are learning C++ concurrency today, learn std::thread first, then move to std::jthread and C++20 synchronization tools.

std::jthread#

One of the most useful additions in C++20 is std::jthread, a safer alternative to std::thread.

With std::thread, forgetting to call join() or detach() before a thread object is destroyed results in program termination. std::jthread automatically joins when it goes out of scope, reducing the risk of thread-management bugs.

Traditional std::thread#

C++20 std::jthread#

Cooperative cancellation#

Another advantage of std::jthread is support for stop tokens.

This makes cancellation much cleaner than manually managing shared flags.

Coroutines#

Coroutines are one of the most significant additions to modern C++. They allow functions to pause and resume execution without blocking a thread.

Traditional asynchronous code often relies on callbacks, state machines, or complex thread management. Coroutines make these workflows much easier to express.

Key coroutine keywords#

Conceptual example#

Instead of manually tracking state, the compiler generates the machinery needed to suspend and resume execution.

Common use cases#

Coroutines are particularly useful for:

• Networking applications

• Web servers

• Database operations

• Event-driven systems

• Generators and streams

• High-performance asynchronous APIs

A useful mental model is to think of coroutines as functions that can "pause here and continue later."

std::latch#

A std::latch allows multiple threads to wait until a counter reaches zero.

Unlike condition variables, a latch is simple to use when you only need one synchronization point.

When to use it#

A common use case is waiting for multiple worker threads to finish initialization before continuing.

Example#

Important characteristic#

A latch is one-time use only.

Once the counter reaches zero, it cannot be reset.

Think of a latch as a starting gate that opens once and never closes again.

std::barrier#

A std::barrier is similar to a latch, but it can be reused multiple times.

This makes it useful for applications where threads repeatedly synchronize at different stages of execution.

When to use it#

Typical scenarios include:

• Scientific computing

• Simulation systems

• Parallel algorithms

• Multi-stage processing pipelines

Example#

Each thread waits until all participants reach the synchronization point before moving to the next phase.

Unlike a latch, the barrier remains available for future synchronization phases.

Comparing modern C++ concurrency tools#

When should you use each?#

Use std::jthread when:#

• You need safer thread ownership

• Automatic joining is beneficial

• You want built-in cancellation support

• You're writing new C++20 code

For most modern applications, std::jthread is a better default than std::thread.

Use coroutines when:#

• Building asynchronous applications

• Writing network services

• Handling large numbers of concurrent operations

• Avoiding callback-heavy code

Coroutines improve readability and scalability for async workflows.

Use std::latch when:#

• You need one-time synchronization

• Worker threads must finish setup before execution begins

• A countdown mechanism is sufficient

Use std::barrier when:#

• Threads repeatedly synchronize

• Work happens in multiple phases

• Parallel algorithms need coordination

Use std::thread when:#

• Working with older standards

• You need maximum control

• Compatibility is important

• Existing codebases already use it extensively

Practical guidance#

A good progression for learning modern C++ concurrency looks like this:

Start by understanding how threads work, then move toward the safer abstractions introduced in C++20.

A note on safety#

While these features improve ergonomics and reduce common mistakes, they do not eliminate concurrency bugs.

You still need to understand:

• Race conditions

• Shared state

• Synchronization

• Atomic operations

• Memory visibility

Modern tools make concurrent code easier to write, but correctness still depends on careful design.

C++20 significantly improves the concurrency experience. std::jthread provides safer thread management, coroutines simplify asynchronous programming, and synchronization primitives like std::latch and std::barrier make thread coordination more intuitive.

For most developers learning concurrency today, mastering std::thread and then adopting these C++20 features is one of the best ways to build modern, scalable, and maintainable concurrent applications.

Understanding the C++ memory model#

When developers first learn multithreading, they often focus on creating threads with std::thread and synchronizing them with mutexes. However, the real foundation of concurrent programming lies deeper: understanding how threads interact with memory.

The C++ memory model defines the rules that govern shared memory access between threads. Without these rules, programs could behave differently depending on the compiler, operating system, or CPU architecture being used. The memory model provides a common set of guarantees that make concurrent code predictable and portable.

Understanding the memory model is important because many concurrency bugs aren't caused by thread creation itself. Instead, they're caused by threads seeing stale data, reading values unexpectedly, or modifying shared memory without proper synchronization.

Many concurrency bugs are actually memory visibility problems rather than thread creation problems.

What is the C++ memory model?#

The C++ memory model defines how threads interact with shared memory.

Specifically, it establishes:

• Rules for reading and writing shared data

• Visibility guarantees between threads

• Synchronization requirements

• Ordering constraints for memory operations

• Portable behavior across compilers and CPU architectures

Without a memory model, two threads could observe completely different views of the same data, making reliable concurrent programming nearly impossible.

A useful way to think about the memory model is that it acts as a contract between:

• Your code

• The compiler

• The operating system

• The hardware

That contract defines what behavior is allowed and what behavior is not.

Why C++11 introduced the memory model#

Before C++11, multithreaded behavior was not formally defined by the language standard.

This created several problems:

• Compilers could perform aggressive optimizations that broke threaded code.

• Hardware architectures had different memory visibility rules.

• Portable concurrent programming was difficult.

• Developers often relied on platform-specific behavior.

C++11 introduced a standardized memory model so that concurrency primitives such as:

could behave consistently across platforms.

This was one of the most important changes in modern C++ because it provided a formal foundation for multithreaded programming.

Data races and undefined behavior#

One of the most important concepts in the memory model is the data race.

A data race occurs when:

1. Two or more threads access the same memory location.

2. At least one thread performs a write.

3. No synchronization mechanism is used.

Example#

At first glance, you might expect:

But because both threads modify counter simultaneously without synchronization, the result is undefined.

Possible outcomes include:

or even more surprising behavior.

Why is this dangerous?#

The compiler and CPU are allowed to reorder operations and perform optimizations that assume no data race exists.

Once a data race occurs, the C++ standard considers the program's behavior undefined.

Atomic operations#

To safely share simple values between threads, C++ provides std::atomic.

An atomic operation completes as a single indivisible action from the perspective of other threads.

Atomic counter example#

Output:

Why atomics work#

Atomic operations:

• Prevent data races

• Ensure updates are visible between threads

• Often avoid the overhead of mutexes

• Can be implemented using hardware-supported instructions

Atomics are particularly useful for:

• Counters

• Flags

• Reference counts

• State indicators

However, they are not a replacement for mutexes when dealing with complex shared data structures.

Memory ordering#

One of the more advanced aspects of the memory model is memory ordering.

Memory ordering controls how operations become visible to other threads.

The most common memory orderings are:

memory_order_relaxed#

Provides atomicity but minimal synchronization guarantees.

Useful for:

• Statistics counters

• Metrics

• Independent values

memory_order_release#

Used when publishing data.

This tells other threads that preceding writes should become visible before the flag is observed.

memory_order_acquire#

Used when consuming published data.

Acquire and release often work together.

memory_order_seq_cst#

Most atomic operations default to sequential consistency.

This is the easiest ordering to reason about because it creates behavior that resembles a single global execution order.

For beginners, memory_order_seq_cst is usually the best choice until performance requirements justify more advanced orderings.

Memory visibility: a visual explanation#

The key idea is that writing data is not enough.

Without synchronization:

Synchronization creates a visibility guarantee.

This distinction is one of the most important ideas in concurrent programming.

The problem is often not whether a thread executed—it is whether another thread can reliably see the result.

When should you use atomics vs mutexes?#

Use atomics when:#

• Managing counters

• Tracking status flags

• Updating simple numeric values

• Building lock-free structures

Use mutexes when:#

• Multiple variables must remain consistent

• Updating complex objects

• Protecting containers such as vectors or maps

• Simplicity is more important than micro-optimizations

A common rule of thumb is:

If you're sharing a single value, consider an atomic. If you're sharing a data structure, use a mutex.

Common memory model interview questions#

What is a data race?#

A data race occurs when multiple threads access the same memory location, at least one access is a write, and no synchronization mechanism is used.

What is std::atomic?#

std::atomic provides thread-safe operations on shared values without requiring a mutex.

What is memory ordering?#

Memory ordering controls how reads and writes become visible across threads and defines synchronization guarantees.

Why does C++ need a memory model?#

The memory model provides portable rules for concurrent programming and ensures consistent behavior across compilers and hardware platforms.

Atomic vs mutex?#

Atomics work well for simple shared values. Mutexes are generally preferred for protecting complex shared state.

Best practices#

A few habits can prevent many concurrency bugs:

• Avoid unsynchronized shared state whenever possible.

• Prefer higher-level synchronization primitives over custom lock-free solutions.

• Use std::atomic only when it genuinely simplifies the problem.

• Favor correctness over premature performance optimization.

• Keep shared mutable state to a minimum.

• Use thread sanitizers during development.

• Document synchronization assumptions clearly.

For most applications, a correct mutex-based solution is better than a complicated lock-free solution that's difficult to maintain.

Takeaway#

The C++ memory model is the foundation of modern concurrency. It defines how threads interact with shared memory, establishes visibility guarantees, and provides the rules that synchronization primitives rely on.

You don't need to memorize every memory-ordering detail to write concurrent programs, but understanding data races, atomics, visibility, and synchronization will help you reason about thread interactions and avoid some of the most subtle bugs in software development.

Lock-free programming with std::atomic#

As concurrent applications scale across more CPU cores, synchronization overhead can become a significant performance bottleneck. Traditional locking mechanisms such as mutexes are simple and reliable, but they can force threads to wait for one another, reducing parallelism and throughput.

This is where lock-free programming comes in. Instead of coordinating access through locks, threads communicate using atomic operations that allow safe concurrent access to shared data without blocking. The result can be lower latency, reduced contention, and better scalability under heavy workloads.

It's important to understand that lock-free programming is not synchronization-free programming. Synchronization still exists—it simply happens through carefully designed atomic operations rather than traditional mutexes.

Many high-performance systems use lock-free techniques selectively rather than attempting to make the entire application lock-free.

What is lock-free programming?#

Lock-free programming is a concurrency technique in which threads coordinate access to shared data without using mutexes or other blocking locks.

Instead of this:

lock-free code relies on atomic operations:

The primary goals are:

• Reduce thread contention

• Avoid blocking

• Improve scalability

• Increase throughput on multicore systems

Lock-free programming is particularly useful in systems where even small delays can impact performance.

Why locks can be expensive#

Mutexes are extremely useful, but they are not free.

When many threads compete for the same lock, several costs appear:

• Thread contention

• Context switching

• Blocking

• Cache synchronization overhead

• Reduced scalability

Mutex-protected counter#

This code is correct, but every increment requires acquiring and releasing the mutex.

As the number of threads grows, the lock can become a bottleneck because only one thread can modify the counter at a time.

Introducing std::atomic#

The C++ standard library provides std::atomic, which allows certain operations to be performed atomically.

Atomic operations are indivisible from the perspective of other threads.

Example 1: Atomic counter#

Why it works#

The increment operation is performed atomically, preventing data races even when multiple threads update the same variable simultaneously.

Example 2: Atomic flag#

Atomic flags are often used to signal events between threads.

Why it works#

The flag update becomes safely visible across threads without requiring a mutex.

Example 3: Compare-and-swap#

One of the most powerful atomic operations is compare-and-swap (CAS).

What happens?#

The operation says:

"Change the value to 20 only if the current value is still 10."

This allows multiple threads to coordinate updates without locking.

Many lock-free algorithms are built around compare-and-swap operations.

Lock-free vs mutex-based synchronization#

Key takeaway#

Atomics excel when:

• Only a few shared values exist

• Operations are simple

• Throughput matters

Mutexes excel when:

• Multiple variables must remain consistent

• Shared objects are complex

• Code maintainability is important

Real-world lock-free applications#

Lock-free programming is commonly used in systems where performance and latency are critical.

High-frequency trading systems#

Financial platforms often process millions of events per second.

Even tiny synchronization delays can impact profitability.

Game engines#

Modern game engines coordinate rendering, physics, audio, and networking across multiple CPU cores.

Lock-free queues are frequently used for communication between subsystems.

Networking systems#

High-performance servers often rely on lock-free structures to process network events efficiently.

Databases#

Database engines use atomic operations for:

• Reference counting

• Internal synchronization

• Transaction coordination

Message queues#

Distributed systems frequently implement lock-free queues to move messages between worker threads.

Operating system kernels#

Many kernel-level synchronization mechanisms rely heavily on atomic instructions rather than traditional locks.

Common lock-free interview questions#

What is lock-free programming?#

Lock-free programming allows multiple threads to coordinate access to shared data without using blocking locks such as mutexes.

What is std::atomic?#

std::atomic provides thread-safe atomic operations on shared variables and prevents data races.

Atomic vs mutex?#

Atomics work best for simple shared values. Mutexes are usually better for protecting complex shared state.

What is compare-and-swap?#

Compare-and-swap (CAS) updates a value only if it still matches an expected value. It is a fundamental building block for many lock-free algorithms.

Why aren't atomics used everywhere?#

Because lock-free programming is significantly more complex. Many problems are easier, safer, and more maintainable when solved with mutexes.

Challenges of lock-free programming#

Lock-free programming offers impressive performance benefits, but it comes with trade-offs.

Increased complexity#

Correct lock-free algorithms are much harder to design and reason about than mutex-based solutions.

Memory ordering issues#

Developers must understand the C++ memory model and visibility guarantees.

Incorrect memory ordering can introduce subtle bugs.

Difficult debugging#

Race conditions and timing-related bugs can be extremely difficult to reproduce.

ABA problem#

A classic lock-free issue occurs when:

A compare-and-swap operation may incorrectly assume nothing changed.

Many advanced lock-free structures must explicitly address this problem.

Best practices#

When working with lock-free programming:

• Start with mutexes unless performance requirements justify lock-free solutions.

• Use std::atomic for simple shared variables such as counters and flags.

• Measure before optimizing.

• Favor correctness over micro-optimizations.

• Understand the C++ memory model before writing lock-free code.

• Keep lock-free algorithms as simple as possible.

• Use profiling and benchmarking to validate improvements.

A common engineering rule is:

If a mutex meets your performance goals, use the mutex.

Lock-free programming is an advanced optimization technique that helps high-performance systems scale under heavy concurrency. Rather than relying on blocking locks, it uses atomic operations to coordinate threads safely and efficiently.

std::atomic provides the foundation for lock-free programming in modern C++, enabling atomic reads, writes, increments, and compare-and-swap operations. While lock-free techniques can deliver significant performance benefits, they also introduce additional complexity.

In practice, most production systems combine atomics, mutexes, and higher-level synchronization primitives, choosing the right tool for each problem rather than trying to make everything lock-free.