Insights derived from a talk by Gašper Ažman
Key Takeaways
- C++26 introduces a new concurrency model based on , not ad hoc threading.
- It separates what code does from where and how it runs, improving clarity and control.
- The sender/receiver model enables composable, asynchronous pipelines with built-in cancellation and error handling.
- Structured concurrency reduces common issues like deadlocks, race conditions and operational instability.
- The standard defines the core abstractions, while real-world implementations will come from libraries and platforms.
Why Concurrency Has Been So Hard to Get Right
For decades, developers have tried to manage concurrency using threads, mutexes, queues and custom scheduling logic.
These approaches work, but they come with persistent problems:
- Race conditions under load.
- Deadlocks that are difficult to diagnose.
- Systems that fail unpredictably at scale.
- Complex, hard-to-maintain code.
The root issue is a mismatch between how systems execute and how developers write code because hardware is flat, but code is hierarchical.
Bridging that gap has always required manual effort.
The Shift: From Threads to Execution
Traditionally, running code meant assigning it to a thread, and achieving concurrency required creating more threads.
C++26 offers a different model.
Instead of focusing on threads, it introduces execution as a first-class concept:
- Execution resources represent where code runs.
- Schedulers control when and how work is executed.
- Domains describe how different execution environments interact.
Developers can reason about execution without directly managing threads.
What Are Senders and Receivers?
At the center of this model is the sender/receiver abstraction.
Think of it as a way to describe:
- A unit of work (sender).
- Where the result goes (receiver).
These can be composed into pipelines that describe entire workflows.
Patterns like running multiple operations and taking the first result, chaining asynchronous steps together or fanning work out and combining the results exemplify a more declarative approach to concurrency.
Structured Concurrency Changes Everything
One of the biggest improvements is structured concurrency, where work is organized into well-defined lifetimes and relationships as opposed to loosely connected tasks. This enables automatic cancellation propagation, clear task ownership and a predictable execution flow.
For example:
- If one task completes first, others can be cancelled automatically.
- Cancellation signals propagate through the system without manual wiring.
- Cancellation is only handled by the necessary components.
Structured concurrency ultimately removes significant complexity and risk.
From Fragmented Systems to Composable Pipelines
Modern systems often require multiple layers of asynchronous logic:
- Network requests
- Data processing
- Paging and iteration
- Aggregation of results
Without structure, these layers quickly become difficult to manage. However, with execution-based design, pipelines are composable and reusable. Each layer cleanly expresses intent, and complexity can be contained instead of spreading across the system. Even multilayer asynchronous workflows can be expressed cleanly.
Concurrency Without Threads
One of this model’s more surprising aspects is that concurrency does not require multiple threads.
Using primitives like sync_wait, a single thread can reduce synchronization issues and enable more efficient resource usage and simpler execution models by:
- Coordinating multiple asynchronous operations.
- Executing work cooperatively.
- Remaining fully utilized without traditional threading overhead.
Why This Reduces System Failures
In concurrent systems, production issues often stem from uncoordinated task lifetimes, hidden dependencies and manual synchronization
Structured execution addresses these directly by eliminating:
- Implicit lifetimes.
- Hidden coordination mechanisms.
- The need for widespread mutex usage.
In well-structured systems:
- Deadlocks are far less likely.
- Race conditions are easier to avoid.
- Debugging is more straightforward.
What This Means for Engineers
C++ is moving toward a clearer separation between what the system does and how it executes.
With this separation in place, engineers can:
- Focus on behavior and intent.
- Compose complex systems from simpler building blocks.
- Avoid low-level concurrency pitfalls.
This division also concentrates expertise where it belongs, i.e., library authors handle execution details, and application developers use higher-level abstractions.
What Is Actually Standardized in C++26
C++26 introduces the core vocabulary and model, including concepts and terminology, abstractions for execution and foundational APIs.
However, it does not provide complete implementations. In practice:
- Libraries will provide concrete implementations.
- Platforms will expose their own execution resources.
- Systems will integrate multiple components.
This is a framework for interoperability, not a single, monolithic solution.
What This Means in Practice
C++26 organizes complexity. It doesn’t eliminate it.
Instead of ad hoc threading models, custom concurrency frameworks and repetitive patterns across teams, developers get a shared model and composable primitives, and they have a way to consistently describe execution.
These organizing principles enable systems that are more powerful and easier to reason about, and easy to bridge with any other paradigm.
The Bottom Line
- C++26 introduces a structured model for concurrency and execution.
- It replaces thread-centric design with composable execution pipelines.
- Built-in support for cancellation and coordination reduces system risk.
- Developers can express intent without managing low-level mechanics.
- The standard defines the foundation, while ecosystems will provide implementations.
C++26 marks a shift from managing concurrency manually to designing it systematically.
