Learn about the C++ memory model for porting applications to Arm
Introduction
Introduction to C++ Memory Models
The C++ Memory Model and Atomics
Walk through a Race condition example
Detecting race conditions
Next Steps
Learn about the C++ memory model for porting applications to Arm
Who is this for?
This is an advanced topic for C++ developers porting applications from x86 to Arm and optimizing performance.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- Describe at a high level what a memory model does, and the types of memory ordering.
- Describe the differences between the Arm and x86 memory model.
- Employ best practices for writing C++ on Arm to avoid race conditions.
Prerequisites
Before starting, you will need the following:
- Access to an x86 Linux system and an Arm Linux system, such as a cloud instance or an Arm AGI CPU platform.
- Proficiency in C++ programming.
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
You’ll explore the C++ memory model, see how compiler and hardware reordering interact with multithreaded code, and compare Arm and x86 memory ordering. First, you’ll examine atomics and memory ordering concepts before running a small concurrent C++ example on both x86 and Arm cloud instances to expose a race that can appear differently across architectures. Then, you’ll detect data races with ThreadSanitizer (TSan) and use its diagnostic output to guide fixes. By the end, you’ll be able to recognize code that relies on implicit x86 ordering and apply C++ best practices to write correct, portable concurrency for Arm.
Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
No. The example uses an Arm-based AWS
t4g.xlarge instance, but other instance types can be used.Code with a latent race can appear to work on x86 but exhibit different or nondeterministic behavior on Arm due to memory ordering differences. The example is designed to make this contrast visible.
Use a recent version of the
clang compiler that includes ThreadSanitizer. TSan instruments your program at compile time and reports potential data races at runtime.TSan adds instrumentation and runtime checks, which introduce significant overhead. Use TSan builds for debugging data races, not for measuring performance.
Don’t assume x86 memory ordering semantics on Arm. Revisit the code with the C++ memory model in mind and use atomics and proper synchronization instead of relying on implicit ordering.