Safe Lock-free Primitives with iceoryx2's ByteAtomic

Marika Lehmann - 28/07/2026Data Races and Sequence LockIn 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: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 WrapperTo 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.ImplementationThe 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: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::<T>() 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 BytesTo understand why the implementation had to evolve, let's take a look at the initial, naive implementation of new():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:transmute_copy assumes that the value being copied is a valid representation of the destination type, in our case a valid u8. This assumption fails for padding bytes because they are uninitialized memory; reading them leads to undefined behavior3. Therefore, we have to ensure that we only copy the fields (i.e., the initialized bytes) of the passed value. This led to the current, correct implementation of new():We now require the inner type T to implement the AtomicCopy trait from iceoryx2 for types that can be atomically copied. It provides for_each_field(), a field-wise accessor for byte-wise copying. This method applies the provided callback to each offset-size pair of every field in T. With this, new() copies only the initialized bytes of value into the data field, effectively skipping potential padding bytes. Of course, implementations of the AtomicCopy trait must ensure that the offset and size of each field are calculated correctly; otherwise, undefined behavior may still occur.Note that the return type of read() has also evolved. In its initial version, read() returned a MaybeUnint<T> to alert the user that, while the ByteAtomic prevents undefined behavior during memory copies, torn reads can still occur. To emphasize this risk, we changed the return type to MaybeTorn<T>. This type wraps a MaybeUninit<T> and serves as a constant reminder that the data integrity is not yet guaranteed. Only after verifying that no concurrent writes occurred can the user safely call assume_consistent() to extract the read value. Otherwise, the returned T may be logically invalid and its use could lead to undefined behavior.UsageThe manual implementation of AtomicCopy for Foo would look like this:For convenience, we have implemented AtomicCopy for all scalar types and provided a derive macro. This macro automatically implements the trait for all structs whose fields also implement AtomicCopy. This is how it looks like in use for Foo:ConclusionWriting correct lock-free code is difficult. Even the "simple" and well-known sequence lock, which often forms the basis for more complex lock-free constructs, entails data races and undefined behavior. While a future standard library "atomic memcpy" would be the ideal and efficient solution, the byte-wise atomic wrapper provided by iceoryx2 enables developers to implement a correct and safe sequence lock and other lock-free primitives today. We are working to integrate this wrapper into our existing lock-free constructs to finalize their transition to a fully safe implementation.Discuss on iceoryx2 community forumDiscuss on RedditDiscuss on programming.devFootnotesFootnoteshttps://github.com/rust-lang/rfcs/pull/3301 ↩https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1478r7.html ↩Using copy_nonoverlapping would shift the problem to the AtomicU8 creation. ↩