Safe Lock-free Primitives with iceoryx2's ByteAtomic

Safe Lock-free Primitives with iceoryx2's ByteAtomic - ekxide Blog | ekxide

Contact

Safe Lock-free Primitives with iceoryx2's ByteAtomic Marika Lehmann - 28/07/2026 Data Races and Sequence Lock In multithreaded programming, a common scenario involves multiple threads reading from and modifying shared data concurrently. If this read and write operations are not atomic, a data race occurs. In languages like Rust and C++, which have almost the same memory model, this results in undefined behavior. To prevent this, locks can be used to protect the data from being modified while it is being read. However, traditional locking mechanisms carry the risk of deadlocks which is unacceptable, especially in safety-critical and high-reliability systems. A common approach to mitigating the described data race without using blocking locks is to utilize a sequence lock. The sequence lock contains the shared data and an atomic counter that has an odd value whenever the data is being updated: rust struct SequenceLockT: Copy + Send> { counter: AtomicUsize, data: UnsafeCellT>, // Provides the necessary interior mutability for the writer.

Using a sequence lock, a writer thread increments the sequence counter to an odd value, updates the data, and then increments the counter to an even value. A reader thread reads the sequence counter both before and after copying the shared data. If the counter has changed or is currently odd, it indicates that the data was concurrently modified. The reader then discards the corrupted copy and retries. The Problem: Even if the reader detects that the data was modified and discards the copy before use, the act of copying the non-atomic data itself still triggers undefined behavior. While a sequence lock can detect that a data race occurred, it does not prevent it. Consequently, it is currently not possible to implement a correct sequence lock in Rust or C++ without decomposing the data into smaller, individually atomic parts. This is a known problem, and while there are ongoing proposals to introduce an "atomic memcpy"12 to the Rust and C++ standard libraries, we cannot rely on that feature yet. Targeting safety-critical and high-reliability systems, iceoryx2 provides a library of lock-free constructs that are based on mechanisms similar to a sequence lock. To make these constructs safe and correct, we need a way to perform memory copies that are atomic at the byte level, ensuring no data races occur. This is why we implemented the byte-wise atomic wrapper ByteAtomic, which we will describe in the following sections. While its concept is simple, achieving true safety required overcoming a subtle but critical issue with uninitialized memory. Solution: A Byte-wise Atomic Wrapper To prevent the aforementioned data race and thus the undefined behavior, the ByteAtomic in iceoryx2 provides byte-wise atomic read and write operations on its inner type. This wrapper only guarantees that each byte is updated/read atomically; it does not provide higher-level thread-safety guarantees. Users must still enforce proper synchronization (such as a sequence lock) to prevent torn reads or writes. The wrapper only ensures that the memory copy is not undefined behavior, but it does not guarantee data integrity on its own. Implementation The wrapper's implementation has undergone some refinement as we addressed the complexities of memory safety. The initial version of our ByteAtomic wrapper looked like this: rust /// A compile-time fixed-size, shared-memory compatible ByteAtomic. #[repr(C)] pub struct FixedSizeByteAtomicT: Copy, const SIZE: usize> { data: [AtomicU8; SIZE], _inner_type: PhantomDataT>,

implT: Copy, const SIZE: usize> FixedSizeByteAtomicT, SIZE> { pub fn new(value: T) -> Self { // create a new ByteAtomic containing the passed value pub fn read(&self) -> MaybeUninitT> { // copy the stored value byte-wise atomically into a MaybeUninit pub fn write(&self, value: T) { // store the passed value byte-wise atomically

It is named FixedSizeByteAtomic because the array size must be provided at compile time, as Rust does not yet allow using core::mem::size_of::() directly in a struct definition. Once this becomes possible, we plan to remove the SIZE generic parameter, remove the runtime fixed-size version RelocatableByteAtomic, and rename the struct to ByteAtomic. Padding Bytes To understand why the implementation had to evolve, let's take a look at the initial, naive implementation of new(): rust pub fn new(value: T) -> Self { let bytes: [u8; SIZE] = unsafe { transmute_copy(&value) }; Self { data: bytes.map(AtomicU8::new), _inner_type: PhantomData,

This version of new() accepts a copyable value, performs a transmute_copy into a byte array, and stores every byte as an AtomicU8 into the ByteAtomic's data field. This works fine - unless T contains uninitialized memory, such as a MaybeUninit or padding bytes: rust #[repr(C)] struct Foo { bar: u8, // 7 padding bytes baz: u64,

transmute_copy assumes that the...

Safe Lock-free Primitives with iceoryx2's ByteAtomic

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills