Class 15: Memory barriers

Date: 09.06.2026

Summary

• Read Linux kernel memory barriers

Memory barriers are only required where there's a possibility of interaction between two CPUs or between a CPU and a device. If it can be guaranteed that there won't be any such interaction in any particular piece of code, then memory barriers are unnecessary in that piece of code.

[!] Memory barriers are _not_ needed within a given CPU, as CPUs always see their own loads and stores as if they had happened in program order.

TL;DR: Use locks and iowrite. You may want to try atomics in some cases. Be very careful with memory barriers, they are usually not necessary if you use locks and I/O helpers.

Hands-on

• Analyze examples from "EXAMPLES OF MEMORY BARRIER SEQUENCES" section of Linux kernel memory barriers

• Read Circular Buffers

• Analyze the example producer/consumer code. How could it break if you remove one, or all of the barriers?

References

• Memory barriers

• Semantics and Behavior of Local Atomic Operations

• Atomic types

• Linux source, atomic64_t

• Linux source, raw_atomic_read

• Kernel Concurrency Sanitizer (KCSAN)

• Why the “volatile” type class should not be used

• [RFC/PATCH] doc: volatile considered evil

• An introduction to lockless algorithms

• Support for the TSO memory model on Arm CPUs

• Linux source, spin_lock

• Linux source, READ_ONCE

• Linux source, barrier

• Linux source, x86_64 mb

• Extended Asm - Assembler Instructions with C Expression Operands

• MFENCE — Memory Fence

• CoffeeBeforeArch - Compiler Memory Re-Ordering

• Preshing on Programming - Memory Reordering Caught in the Act

• Wei Wang - Speculative Execution

• Lars Wrenger, Dominik Töllner, Daniel Lohmann, Analyzing the memory ordering models of the Apple M1, Journal of Systems Architecture

• cppreference - volatile type qualifier

• Kernel Rust documentation, kernel::sync::atomic

• READ_ONCE(), WRITE_ONCE(), but not for Rust - LWN

• Re: [PATCH 0/5] Add READ_ONCE and WRITE_ONCE to Rust

• Dynamic DMA mapping Guide, Types of DMA mappings

• Linux-Kernel Memory Model

• Owens, S., Sarkar, S., Sewell, P. (2009). A Better x86 Memory Model: x86-TSO