compiler_fences
The tracking issue for this feature is: #41091
The compiler_fences
feature exposes the compiler_fence
function
in std::sync::atomic
. This function is conceptually similar to C++'s
atomic_signal_fence
, which can currently only be accessed in nightly
Rust using the atomic_singlethreadfence_*
instrinsic functions in
core
, or through the mostly equivalent literal assembly:
# #![allow(unused_variables)] #![feature(asm)] #fn main() { unsafe { asm!("" ::: "memory" : "volatile") }; #}
A compiler_fence
restricts the kinds of memory re-ordering the
compiler is allowed to do. Specifically, depending on the given ordering
semantics, the compiler may be disallowed from moving reads or writes
from before or after the call to the other side of the call to
compiler_fence
. Note that it does not prevent the hardware
from doing such re-ordering. This is not a problem in a single-threaded,
execution context, but when other threads may modify memory at the same
time, stronger synchronization primitives are required.
Examples
compiler_fence
is generally only useful for preventing a thread from
racing with itself. That is, if a given thread is executing one piece
of code, and is then interrupted, and starts executing code elsewhere
(while still in the same thread, and conceptually still on the same
core). In traditional programs, this can only occur when a signal
handler is registered. In more low-level code, such situations can also
arise when handling interrupts, when implementing green threads with
pre-emption, etc.
To give a straightforward example of when a compiler_fence
is
necessary, consider the following example:
# use std::sync::atomic::{AtomicBool, AtomicUsize}; # use std::sync::atomic::{ATOMIC_BOOL_INIT, ATOMIC_USIZE_INIT}; # use std::sync::atomic::Ordering; static IMPORTANT_VARIABLE: AtomicUsize = ATOMIC_USIZE_INIT; static IS_READY: AtomicBool = ATOMIC_BOOL_INIT; fn main() { IMPORTANT_VARIABLE.store(42, Ordering::Relaxed); IS_READY.store(true, Ordering::Relaxed); } fn signal_handler() { if IS_READY.load(Ordering::Relaxed) { assert_eq!(IMPORTANT_VARIABLE.load(Ordering::Relaxed), 42); } }
The way it is currently written, the assert_eq!
is not guaranteed to
succeed, despite everything happening in a single thread. To see why,
remember that the compiler is free to swap the stores to
IMPORTANT_VARIABLE
and IS_READ
since they are both
Ordering::Relaxed
. If it does, and the signal handler is invoked right
after IS_READY
is updated, then the signal handler will see
IS_READY=1
, but IMPORTANT_VARIABLE=0
.
Using a compiler_fence
, we can remedy this situation:
#![feature(compiler_fences)] # use std::sync::atomic::{AtomicBool, AtomicUsize}; # use std::sync::atomic::{ATOMIC_BOOL_INIT, ATOMIC_USIZE_INIT}; # use std::sync::atomic::Ordering; use std::sync::atomic::compiler_fence; static IMPORTANT_VARIABLE: AtomicUsize = ATOMIC_USIZE_INIT; static IS_READY: AtomicBool = ATOMIC_BOOL_INIT; fn main() { IMPORTANT_VARIABLE.store(42, Ordering::Relaxed); // prevent earlier writes from being moved beyond this point compiler_fence(Ordering::Release); IS_READY.store(true, Ordering::Relaxed); } fn signal_handler() { if IS_READY.load(Ordering::Relaxed) { assert_eq!(IMPORTANT_VARIABLE.load(Ordering::Relaxed), 42); } }
A deeper discussion of compiler barriers with various re-ordering
semantics (such as Ordering::SeqCst
) is beyond the scope of this text.
Curious readers are encouraged to read the Linux kernel's discussion of
memory barriers, the C++ references on std::memory_order
and
atomic_signal_fence
, and this StackOverflow answer for
further details.